Stream player with web browser1/10/2024 ![]() Of all the options, I think WebRTC is the most promising. But what if we pushed Apple, Google, and Mozilla to implement SRT? They are very unlikely to do that, because SRT is not a true standard, and it would take significant effort to get buy-in and deployment of SRT throughout the delivery ecosystem (servers, CDNs, etc.). ![]() To stream SRT, viewers must install dedicated SRT client software, certainly not ideal in today’s plugin-less web. ![]() The trouble is, SRT is not supported natively in any web browser. SRT is a true real-time protocol and therefore a contender to replace RTMP. The Secure Reliable Transport (SRT) protocol began as a collaboration between Wowza and Haivision and has grown into the SRT Alliance. The BBC is doing some very interesting work with HTTP Server Push, but it is still in the proof-of-concept phase and would require new web APIs to work natively in browsers. As such, they run into problems of scalability and lack of interoperability among vendors. Patrick Dubois at has written a great overview of them.Īll of these approaches are very creative, but they are essentially hacks of existing technologies that were not designed for low-latency video streaming. Several technical solutions for real-time video without Flash have been proposed, such as HTTP chunked encoding, WebRTC and Websockets. No matter what your opinion of horse racing (or Flash), this kind of regression in functionality is bad for the Web.Ĭurrent Proposed Solutions Can’t Get Us There Very soon, when Flash is gone, you will no longer be able to stream those races in true realtime, which has ramifications. For example, imagine that you are a website that has been happily streaming horse races using Flash and RTMP for the past ten years. ![]() This is a step backward for the platform, as it makes formerly viable use cases like (truly) live sports, breaking news and gaming impossible. This effectively means that there is no real-time video protocol for the web. Moreover, it is unlikely to ever be supported in browsers due to its reputation as outdated technology, not to mention Adobe’s strange “open specification” RTMP license and choice to exclude the encrypted variant of the protocol from the spec, which is a nonstarter as the web moves to encrypted transports by default. Their latency is so low, it is measured in milliseconds instead of seconds.įor many years, if you wanted to deliver real-time video to web browsers, there was only one way to do it: Flash.īut Flash is a dying technology, and RTMP (the protocol that Flash uses for real-time video) is not supported in any web browser. Real-time live video protocols, by comparison, are designed to operate with extremely low latency (i.e., the gap in time between when an event happens and the viewer sees it). In the case of Apple’s HLS, their own guidelines mandate at least three segments of six seconds each, effectively putting each viewer about 20 seconds behind “real” time. Both require a certain amount of video data to be buffered in the player to guard against network rebuffering and other playback glitches. HLS and DASH, the two leading streaming protocols in use on the web, can operate in a “live” mode, but they are not real-time protocols. Live video is streamed to viewers as an event happens, as opposed to on-demand video, which is prerecorded and streamed to viewers whenever they choose. Perspectives on the digital video world from JW Player’s SVP of Technologyįirst, let’s clarify the difference between live and real-time video delivery.
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |