RealSprint AB
Döbelnsgatan 19
90330, Umeå Sweden
info@realsprint.com
VAT SE556946531201
We have gathered some common questions and answers below. If there are uncovered questions, please feel free to reach out to us. Vindral is massively extensible, configurable and has been adapter to work in several different verticals all across the globe.
Adaptive Bitrate, or ABR, is important in use cases where video quality matters. ABR is a mechanism that enables the client (video player) to upgrade or downgrade to a different bitrate/quality (rendition) based on the performance of the player. For example, if a viewer struggles playing back a stream at 3Mbit/s, the Vindral player automatically downgrades that viewer to a lower bitrate. Competitors: In most HLS setups, ABR is enabled by default. In VOD-scenarios, ABR is not that big of a challenge as ABR only means that the VOD-files should be available at different bitrates. However, in live streaming, ABR is much more challenging as the transcoding into different bitrates has to happen realtime. As a built-in core feature of Vindral, around 99% of our customers run ABR for their streams.
It may be crucial to your success or completely irrelevant – the truth is that its significance varies depending on the use case. Video-based communication over the internet constitutes a typical example where latency needs to be as close to zero as possible, which is why solutions such as Zoom or Microsoft Meetings use the real-time-based protocol WebRTC.
However, reducing latency to the absolute minimum means that video quality will be sacrificed at some point as viewers watch from widely spread-out geographical locations or when networks start to fluctuate. On the contrary, in case your streamed content does not require exceedingly fast end-to-end delivery, nor the playout to be synchronized among all viewers, HLS is a solid option as it maintains a stable high-quality playout.
A high level of interactivity together with ultra-low latency and high quality constitute the typical requirements for the Vindral use cases. We serve clients from online auctions, online seminars, iGaming, and horse racing, among others – all verticals where ultra-low latency must be guaranteed together with high quality and synchronization, even as networks fluctuate.
Vindral puts you in charge of the latency by featuring a configurable client buffer. Set one latency for all viewers or have different configurations for different regions; even dynamic settings are available for especially challenging regions. Most of our clients reside around one second of latency.
Basically, if you need your viewers to share the same experience exactly at the same time no matter what device they’re using, you need a solution that supports synchronized playout. While real-time solutions such as WebRTC support this feature, traditional HLS, as well as LL-HLS Chunked CMAF, fall short in this regard. To test synchronization, visit Vindral.com/testing.
In simple terms, higher latencies translate into greater margins, as it’s easier to maintain a high-quality playout, even as networks fluctuate. Correspondingly, solutions that provide real-time latencies, i.e., faster delivery, are less resistant to network fluctuations, making them more vulnerable.
Network fluctuations are a collective term used to describe disturbances in networks. These disturbances affect the solution’s level of stability. Packets can be lost, delayed, or deviate in their delivery (called jitter). Varying bandwidths among viewers equals different network capacities, which in turn makes it difficult to guarantee a trouble-free experience for all viewers. As stability is crucial to achieving a trouble-free experience for viewers, any solid live streaming solution needs to take these aspects into account. We recommend testing before committing to any solution, which is why we have created guides on testing that you can watch here.
It may very well be. As Vindral delivers content at sub-second latency, in sync, and at video qualities up to 4K, it’s particularly suitable in use cases such as live casinos, online auctions, sports betting, horse racing, or in any other use case where a high level of interactivity between viewers is crucial. The Vindral Engine contains all the necessary components and tools for deployment, scaling, maintenance, and monitoring.
Yes. Vindral is available as a Software as a Service solution, partially or fully managed services, or as a White label version with a complete deployment of the tech stack. More on this at https://www.vindral.com/white-label.
We support most platforms, from desktop browsers to mobile browsers and apps.
Chromecast, Android TV, and Apple TV are also supported. Our adaptive ultra-low latency guarantees synchronized playout between all viewers, even on iOS Safari.
Yes, Chromecast and smart TV:s with integrated casting are compatible, along with Apple TV.
Yes, it is. Viewers get fast channel switching alongside perfect sync, meaning that a switch in channels resumes playout at the exact same point in the stream; this is a pivotal feature for creating coherent experiences.
Yes, our frame synchronized data channel makes it possible to inject cue points which are then received by the player and can be used as triggers for events.
Vindral streams work in apps and browsers, from Android to iOS – both browsers and native apps – to desktop and Google Cast.
We adjust our business model to the specific use case. Some clients prefer a flat rate consisting of channel price including transcoding at a maximum concurrent viewership capacity. Others are more interested in a channel fee plus traffic. Also, for events the typical pricing is 1/3 of the monthly fee – as long as one event is not longer than 7 days.
Yes, each stream has a separate data channel you can use for messaging, events, and synchronization. This feature is called timed metadata or out-of-band metadata.
Yes, most certainly. RealSprint has been working with iGaming customers since 2012, and our CDN has been serving several iGaming vendors worldwide. The ultra-low latency, high quality (including 4K), and global reach of the Vindral make it highly applicable for immersive experiences in the iGaming vertical.
Yes, you can have one stream optimized for landscape and another for playback. Our SDK supports fast channel switching between streams.
No. As WebRTC struggles with playout on varying network conditions, Vindral does not rely on it for playout. Our proprietary transport method adds a configurable buffer to provide a higher-quality throughput.
Vindral features a configurable latency that can be set as low as 500 milliseconds. Most use cases reside around one second of latency.
Vindral features a playback synchronization feature that takes several parameters into consideration when trying to provide a stable, controlled, and synchronized playback of a stream. One of them is the RTT between the client(player) and the edge server, and another is the decoding performance of the client. As Vindral doesn’t use “segments” similar to LL-HLS and other protocols, there is no risk for clients falling behind and the viewing experience getting out of sync. In most use cases, the latency between clients is less than 50 ms, but depending on device type, distance (RTT) to the edge server, and distance to the origin, the difference can reach 200 ms on a global level. For streams running on Chromecast, the likelihood of viewers getting more out of sync is greater, depending on the type of hardware used.
No, ISP caching is only relevant in use cases with seven-figure amounts of viewers. Traditional HLS allows for this functionality.
Vindral only utilizes standard ports that are allowed on networks in general. Unlike some competing solutions that get caught in firewalls and network policies, especially on corporate networks, Vindral uses ports 80 and 443.
While HESP is an open-source protocol, Vindral is not. There are, however, licensing fees connected to HESP. Both HESP (Theolive) and Vindral are optimized to retain high-quality playout while reducing the latency, and thus, both solutions target similar clients. However, HESP is primarily optimized for small-scale use cases. Adding the volume of 24/7 channels multiplies the cost compared to Vindral by approximately 10X. Besides, HESP generates performance issues on iOS.
As a future-ready solution, Vindral is most beneficial in use cases that require a balanced performance between video quality, latency, and playout sync. As a result, it is highly applicable in verticals such as live sports, live auctions, multi-angle experiences, iGaming, live events, horse racing, and greyhound racing, among others.
As DRM requires a higher latency, Vindral does not currently support it.
DRM is mainly a feature of interest in the Live Sports vertical, in which brands that rather prioritize latency and quality of experience are the primary targets for Vindral. Instead of DRM, Vindral utilizes a token-based auth mechanism to secure streams from unauthorized access. If DRM is a strict requirement, HLS is a viable option, but then at the expense of playout synchronization and low latency.
Server-side ad insertion, SSAI, is currently not supported as it increases latency.
There are several layers of security in the Vindral. All streams are sent using secure Web Sockets. By activating the authentication feature in the CDN, only authorized viewers can connect to the CDN and view your stream. Authentication can be set independently per stream.
Yes. If we have ingress, transcode and egress in that area, we can limit traffic flow to that specific area.
No, only if you want them to. The stream will only be distributed to the regions where there are viewers and to regions where you have allowed egress. Also, if stream authorization is activated, the viewers need to be authenticated before they can access the stream.
There are several options for this:
No, all traffic is encrypted, and all access is protected by several layers of security. A stream being distributed internally within the CDN is not publicly accessible.
Yes, by using traffic rules, we can ensure your streams are protected based on the viewer’s location.
Yes, access control can be based on user ASN and can be configured per stream.
Yes, data usage is available in the Customer Portal (the management web page available for our customers). IP addresses are stripped and not stored.
To be able to ingest to the CDN, you must have access to a private stream identifier. This identifier is automatically generated when your stream is created and replaces the need for a username and password.
Yes, in several use cases, we have provided customer-specific egress solutions. This is accomplished by using either Cloud Providers, bare metal servers, or a mix of server types.
By using Traffic routing and traffic rules, the new egress site can be configured to only be available for your streams. Depending on the use case requirements, funding for a customer-specific egress site might need to be provided by you.
Yes. There are a couple of options:
Please contact RealSprint for more information on licensing the Streaming Engine or Managed Services.
Yes, using Vindral Streaming Engine or utilizing our CDN as a Managed Service are two ways of creating a white-label solution.
Yes, the CDN is redundant in all layers. The details of how this redundancy is implemented are trade secrets, but in general terms, it utilizes load-balancers and redundant instances of all services, running on several different ISP:s, networks, and data centers.
The video player will automatically switch to the closest available and accessible data center that is online and healthy. It does not matter if the reason for the outage is a data center issue or a peering issue on some ISP networks. From the viewers’ perspective, switching to a different data center will render a short glitch and is usually resolved within a few seconds.
The global load balancer service built into the CDN will automatically choose the closest available data center with available egress capacity. Viewers are not affected.
For redundancy, we provide a primary and a backup ingest site. If the primary ingest URL goes offline, you can switch to the backup URL. In many regions, the primary ingest site is load-balanced between several physical data centers. If one of those primary data centers goes offline, the load-balanced mechanism will route all traffic to the operating data centers. If switching between data centers occurs, there will be a short glitch in the stream. Active viewers will automatically be reconnected once the stream is back online.
It is difficult to provide such an estimate. We utilize several major ISP:s and Cloud Providers that have extremely high bandwidth, and we constantly add more data centers and vendors to our CDN. We normally have a much higher capacity than the average load, and if necessary, more capacity is easily added. Our vendors include Tata Communications, GCP, Azure, Clouvider, OVH, Digital Ocean, Cloudflare, and Oracle.
Normally, there is no need to inform us about your expected number of viewers. Our capacity in specific regions can be adjusted to match the expected load. To ensure your 1M+ viewers can access the stream, we can pre-allocate bandwidth for this specific region. From the CDN side, this will guarantee that the egress capacity manages the expected number of viewers. Depending on where the viewers are located, there might be peering limitations on lower tiers that may act as limiting factors. To illustrate this, imagine having 1M+ viewers on a single WiFi or 4G antenna. The “Last mile” of each viewer’s internet connection is outside the scope of the actual CDN.
Yes. More viewers are also possible, but for large crowds, the geographical distribution of viewers along with -mile ISP capacity becomes more relevant.
It is difficult to provide such an estimate. We utilize several major ISP:s and Cloud Providers that have extremely high bandwidth, and we constantly add more data centers and vendors to our CDN. We normally have a much higher capacity than the average load, and if necessary, more capacity is easily added. Our vendors include Tata Communications, GCP, Azure, Clouvider, OVH, Digital Ocean, Cloudflare, and Oracle.
Yes, all technical parts and the performance of the CDN are constantly monitored by our team. All the important KPIs are logged, and alarms exist on all important metrics. If there is an issue, our team will be instantly notified. Our on-call team is available 24/7 for critical issues.
Yes, the operational status of the CDN, planned maintenance, and known limitations or issues are available at https://status.vindral.com/. You can also subscribe to email notifications related to the operational status of the CDN.
Yes, by using traffic routing and redundant resources, we can perform upgrades and maintenance without operational outages. In rare cases, we do need to perform changes that can affect operations. In such a case, this is appropriately communicated to make sure that the operational impact is minimal.
We have the option to collect client statistics, including information on the type of device, web browser, uptime, time-to-first-frame, latency, bitrate, audio/video codecs, geo-location, number of ABR-stream changes, errors, and much more. This information is also available via the Web SDK and can be sent to your own data storage. Client statistics is important for us as it helps us analyze stream performance.
Vindral Composer is a video compositing tool that runs on-prem (in the studio or the facility/site in which the broadcast originates). Composer creates a video stream that can be sent to the CDN using secure RTMPS. In the CDN, the incoming stream is either transcoded to the required ABR qualities or just passed on to the viewers without transcoding.
Vindral Composer is a cost-efficient tool frequently used within the iGaming vertical and game shows. Composer is licensed separately from our CDN and operates independently. As a result, Vindral Composer is compatible with any CDN supporting RTMPS.
Yes, you can. In rare cases, it might be beneficial to run the transcoders on-prem. For example, when the incoming video format/protocol is unsuitable for transport over the internet. Or where there are regulations on where transcoding is allowed from a geographical perspective or when content cannot be processed outside the facility.
The disadvantage of running the transcoder on-prem is that it will be unmanaged by RealSprint, which translates to more responsibilities for your team. The potential advantages include slightly higher image quality (rare) or improved performance (for AV1 streams, for example). On-prem setup is quite uncommon and is, although possible and supported, not considered best practice.
Yes, we provide two players: one player, which is easily embedded into your application, and a fully featured Web SDK that can be used for more complex implementations. Our resources can be found at docs.vindral.com
Yes. We provide an online QoS tool that can be used to view your streams, as well as study KPIs relevant to stream performance, codecs, latency, and more. The QoS tool is free of charge for our customers.
Yes, RealSprint provide support for their Vindral CDN. We recommend our partners to do the same: offer different SLAs depending on the requirements. For many customers, we provide a shared Slack space where they can chat with our development and support teams. Training is also available and can be configured to specific client needs. Finally, we also offer our customers Professional Services, including web- and app development, custom setups for monitoring, etc.
Yes, in the Customer Portal, you can access an overview of all your channels, view your streams, and find all the relevant information, such as stream keys and ingest URLs.
On the player side, Vindral requires a custom player that is available in both an embeddable version, hosted by us, and as a player library. Implementing the player is as easy as two lines of code, but with the option of customizing according to your needs if desired. On the ingest side, practically all relevant protocols are supported.
RealSprint AB
Döbelnsgatan 19
90330, Umeå Sweden
info@realsprint.com
VAT SE556946531201
