Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×

The current state of WebRTC

Jonas Birmé, VP of research and development, Eyevinn Technology, takes a look at how WebRTC will help companies achieve lower latency than that achieved with HTTP streaming

WebRTC is the technology for real-time streaming online with broad support across browsers but is still not widely used for real-time streaming of professionally produced content as there are still a few gaps in the ecosystem that need to be bridged. Bridging these gaps with standard solutions will maximise interoperability and streamline development and adoption.

Initiatives to bridge these gaps exist, and Millicast introduced WebRTC HTTP Ingest Protocol (WHIP) in 2020, while DASH-IF formed a public taskforce that published a report in March 2022 with examples of use cases where a combination of MPEG-DASH and WebRTC would be required. In June 2022 independent consultants Eyevinn Technology proposed an Egress protocol called WebRTC HTTP Playback Protocol (WHPP) which was later replaced by WebRTC HTTP Egress Protocol (WHEP), introduced by the same IETF working group that drafted WHIP. In September 2022 Cloudflare announced Cloudflare Stream in open beta to support WebRTC based streaming using WHIP and WHEP.

WebRTC is a well-established set of standards for real-time communication, supported across all browsers. Designed for ultra-low latency communication it powers video conference services like Google Meet and Microsoft Teams. A conference service provides the participants with the application, and the signaling protocol between application and backend is proprietary to the conference service provider. In broadcast streaming you have instead an ecosystem of producers, distributors and players, and open standard protocols between the producer and distributor (ingest) and between distributors and player (egress). As the main use case for WebRTC has been video conferencing the need for this type of interoperability has not been necessary.

To adopt WebRTC into the broadcast streaming world this interoperability gap is the fundamental part that needs to be solved first. A proposal to solve this issue the ingest-side was introduced by Millicast (now Dolby.io) in 2020, an HTTP-based protocol for the exchange of SDP messages between the sender and the receiver, WebRTC HTTP Ingestion Protocol (WHIP). As all modern browsers support WebRTC this protocol would also enable people to go live directly from a web browser without having to install a native application.

While WHIP fills the ingest issue, the gap on the egress and playback side remains. In an initiative by Eyevinn Technology to develop a prototype for how standardised WebRTC-based streaming could be achieved, a similar HTTP-based protocol was proposed called WebRTC HTTP Playback Protocol (WHPP). This protocol specified a standard for the exchange of SDP messages between the WebRTC media server and the receiver. With this protocol in place the gap both on the ingest- and egress-side could be filled, and any player implementing this protocol could consume a stream from any WHPP-compatible WebRTC distribution platform. A couple of months later the IETF working group behind WHIP presented a draft for WebRTC HTTP Egress Protocol (WHEP) which seems to be the standard to be adopted for playback.

The first company to provide a standardised end-to-end WebRTC based broadcast distribution was Cloudflare who in September 2022 announced the support for WHIP and WHEP on Cloudflare Stream. And the Swedish CDN vendor GlobalConnect announced in October that they are adopting WHIP and WHEP for their WebRTC based distribution platform.

DASH-IF identified use cases where integration and interoperability points between MPEG-DASH and WebRTC are necessary. For example, a complex real-time live event with multiple synchronised streams using WebRTC representations with multiple adaptation sets for different camera angles, or a real-time live event using WebRTC while ad periods are delivered with MPEG-DASH.

With the fundamentals of standardised signaling in place further work is needed to support Digital Rights Management (DRM), captions and subtitles and advanced audio and video codecs. To overcome the gaps in these areas will require the browser vendors to also be engaged in these initiatives. 

Live events with interactivity, betting, and in-stadium experiences require lower latency than what can be achieved with HTTP Streaming. The efforts mentioned in the article will enable the of use WebRTC-based distribution for these use cases in a standardised way.