WHIP, the WebRTC HTTP Ingest Protocol, was developed by Millicast to solve the biggest pain point with adopting WebRTC as a serious, professional, robust contribution protocol: Media Ingest.
Implementing the open source WHIP library in your software or hardware encoder is all you need to support the entire WebRTC stack (like webrtc.org) on the sender side.
With the contribution piece solved, the burden of WebRTC support now falls on the server side.
To date, the open source Meedoze WebRTC Media Server, Janus WebRTC Server and Millicast WebRTC PaaS have implemented WHIP. If you are interested in more technical details about the Medooze implementation, or the Janus implementation, you can read those great blog posts by their respective authors.
On the client side, Millicast created an OBS fork that has a complete implementation that makes it easy to evaluate the workflow. View the OBS > Millicast > Browser workflow video below that uses WHIP end-to-end:
A ticket within the GStreamer project has also been opened by one of the developers. There is also an implementation for FFMPEG developed by our very own Sergio Murillo.
WHIP offers both software and hardware encoders a free and easy solution to implement support for WebRTC once and for all, without compromise.
WebRTC is Growing Up
From the broadcasting industry perspective, WebRTC was not “complete”. It lacked a standard signaling protocol to make it work as many other protocols before it.
From the web industry perspective, it was a wanted feature that would allow the protocol to be used for vastly different use cases than originally anticipated or designed for, but neither the web nor the broadcasting community had been interested in developing that functionality.
Until COVID-19 that is…
In the broadcasting industry, RTMP is ubiquitous for live streaming and especially for media ingest across media platforms and social media (Facebook Live, YouTube live, Vimeo, Twitch).
With the pandemic forcing people to stay at home and businesses to reinvent themselves to provide interactive feeds and remote experience that would mimic real life experience, the “live” segment has enjoyed a surge in interest.
What audiences want is the same “vibe” that they would have in real life, instant interaction with performers and the audience. That requires something better than “live”, that requires Real-Time.
Some protocols, like FTL, have tried to adapt it to bypass the problem. Some others, like SRT, have tried to reimplement resiliency and adaptability on top of different protocols to end up with something better than RTMP, but all of these have failed as a standard.
Some, like Amazon, or FFMPEG, are peeling down WebRTC to raw RTP, which maintain the real-time and resiliency features, at the cost of encryption, interoperability and other interesting features that WebRTC brings to the table.
WHIP removes the barrier WebRTC had with the lack of standard signaling protocol that has historically made it too hard to support as a software solution, and difficult for hardware encoders to implement WebRTC.
WHIP enables WebRTC to retain its technical advantages over older real-time protocols like RTMP and RTSP when it comes to resiliency over bad network conditions, adaptability, end-to-end encryption, security and new codec support.
WebRTC is also a web standard, which makes writing client applications for it much easier, as it is available natively in billions of devices worldwide.
It’s time to implement WHIP and take advantage of WebRTC end-to-end, as it was meant to be, natively on every device.
Contact us for help on implementing WHIP, and sign up for a free trial of Millicast to start using WebRTC to stream globally, at scale, in under 200ms.
Author: Ryan Jespersen from Millicast
