-->

In Search of Better Encoding Quality for WebRTC

Article Featured Image

Suffice it to say that Web­RTC is finally out of kindergarten and moving into the elementary grades. Which grade exactly? Well, that likely depends on which web browser you’re using and which server technology or platform your Web­RTC implementation uses.

The majority of my client projects to date use Web­RTC ingest (or publishing) via a web brow­ser, in which JavaScript application programming interfaces can capture audio and video from locally connected devices like a webcam and microphone. As such, the video quality of the live stream is relying on the browser vendor’s encoding implementation, which could utilize your GPU or CPU. (Tip: On Chrome, you can use the URL chrome://gpu to get stats on your local machine’s GPU capabilities as supported by Chrome.) Browser-based encoding for Web­RTC has limitations, specifically with variable frame sizes, frame rates, and bitrates while publishing. These variabilities can wreak havoc on server-side recordings or within video-switching software that is able to consume Web­RTC feeds.

Of these limitations, the video bit­rate is most troubling when it comes to high-quality video. I find that WebRTC streams published by current web browsers have an upper limit for video bitrate, usually around 2Mbps. In Chrome, you can monitor the outbound bandwidth by tapping the real-time reports generated by the URL chrome://webrtc-internals. Try it for yourself anytime you’re using a local capture of your webcam in a browser-based Web­RTC publishing session. You’ll likely see similar results, regardless of which frame rate and resolution you choose for the capture. If you push the same video content with a non-browser encoder solution, such as Millicast’s OBS Web­RTC software (a free download, based on the same code as the original OBS software), you can achieve much higher quality. This OBS variant can push to Millicast’s platform as well as any server running Janus Web­RTC Server, which is open source.

As an example, Figure 1 (below) shows the real-time bitrate graph of a Chrome-captured Web­RTC publishing session for a virtual webcam and mic driven by Telestream’s Wirecast into Millicast’s platform. Here, the video bitrate is averaging 2Mbps. 

Chrome encoded session

Figure 1. Chrome encoded session

Figure 2 (below) shows the same video content being streamed directly via Web­RTC into Millicast with its OBS Web­RTC software, which is using FFmpeg and x264 under the hood to encode the content in real time. (Note that OBS can also utilize the GPU for NVENC encoding.) The output settings for OBS were set to 8Mbps for the video bitrate, and the results in Figure 2 show an average 8Mbps bit­rate being utilized for Web­RTC playback.

OBS WebRTC encoded session

Figure 2. OBS WebRTC encoded session

It’s beyond the scope of this column to discuss the implications of simulcast Web­RTC on encoding performance within software solutions such as OBS, but bear in mind that both client- and server-side Web­RTC solutions can assume the role of providing tiered resolutions for adaptive streaming playback.

What do we do in the meantime if there isn’t an option to use a Web­RTC publisher for a Web­­RTC playout scenario? Many Web­RTC platform-as-a-service (PaaS) vendors and streaming server products will accept Real-Time Messaging Protocol (RTMP) ingest sessions and transcode AAC audio to Web­RTC-compatible Opus audio. As such, you can achieve higher-quality WebRTC playout streams by encoding with any existing RTMP encoding solution.

In one of last year’s columns (go2sm.com/web­rtcproblem), I highlighted the lack of a consistent signaling approach among Web­RTC ser­ver vendors and made a plea for Web­RTC vendors to implement a standard connection setup. I’ve since seen WHIP (Web­RTC HTTP Ingestion Protocol), a proposal from CoSMo Software’s Alex Gouaillard and Sergio Garcia Murillo. WHIP offers the potential to unify the next wave of real-time encoding solutions by providing an alternative and improvement to RTMP, allowing a wider range of audio and video codecs. Hopefully, popular products in the live video-switching software space, such as Wirecast, vMix, Vimeo Studio 6, Boinx Software’s mimoLive, and the master branch of OBS, will incorporate WHIP to give every web broadcaster the opportunity to work with Web­RTC. On the ingest side, I expect to see similar adoption by more WebRTC PaaS vendors and media server products.

Streaming Covers
Free
for qualified subscribers
Subscribe Now Current Issue Past Issues
Related Articles

Testing Wowza's Real-Time Streaming at Scale

Wowza's new ultra-low latency offering can deliver either an RTMP stream or a WebRTC stream, with WebRTC outperforming the legacy protocol

The Future Is Real Time, and It Starts Now

Where and how does "real time" fit into your workflows in this "COVID and beyond" era? Similar to global wars accelerating advan­ces in medicine such as plastic surgery, COVID has pushed all of us working in streaming media to rethink, innovate, optimise, and rebuild many components of our day-to-day responsibilities. 

Judging Apple's Advanced Video Quality Tool

As a metric, Apple's Advanced Video Quality Tool (AVQT) showed some bright spots, but it's hard to see it bumping VMAF or SSIMPLUS from real-world workflows without a lot more verification.

Companies and Suppliers Mentioned