Mux

Video: Broadcasting WebRTC over Low Latency Dash

Posted on by Russell Trafford-Jones


Using sub-second WebRTC with the scalability of CMAF: Allowing panelists and presenters to chat in real-time is really important to foster fluid conversations, but broadcasting that out to thousands of people scales more easily with CMAF based on MPEG DASH. In this talk, Mux’s Dylan Jhaveri (formerly CTO, Crowdcast.io) explains how they’ve combined WebRTC and CMAF to keep latencies low for everyone.

Speaking at the San Francisco VidDev meetup, Dylan explains that the Crowdspace webpage allows you to watch a number of participants talk in real-time as a live stream with live chat down the side of the screen. The live chat, naturally, feeds into the live conversation so latency needs to be low for the viewers as much as the on-camera participants. For them, WebRTC is used as this is one of the very few options that provides reliable sub-second streaming. To keep the interactivity between the chat and the participants, Crowdcast decided to look at ultra-low-latency CMAF which can deliver between 1 and 5 second latency depending on your risk threshold for rebuffering. So the task became to convert a WebRTC call into a low-latency stream that could easily be received by thousands of viewers.

 

 
Dylan points out that they were already taking WebRTC into the browser as that’s how people were using the platform. Therefore, using headless Chrome should allow you to pipe the video from the browser into ffmpeg and create an encode without having to composite individual streams whilst giving Crowdcast full layout control.

After a few months of tweaking, Dylan and his colleagues had Chrome going into ffmpeg then into a nodejs server which delivers CMAF chunks and manifests (click to learn more about how CMAF works). In order to scale this, Dylan explains the logic implemented in a CDN to use the nodejs server running in a docker container as an origin server. Using HLS they have a 95% cache hit rate and achieve 15 seconds latency. The tests at the time of the talks, Dylan explains, show that the CMAF implementation hits 3 seconds of latency and was working as expected.

The talk ends with a Q&A covering how they get the video out of the headerless Chrome, whether CMAF latency could be improved and why there are so many docker containers.

Watch now!
Speaker

Dylan Jhaveri Dylan Jhaveri
Senior Software Engineer, Mux
Formerly CTO & Co-founder, Crowdcast.io

From WebRTC to RTMP

Posted on by Russell Trafford-Jones

Continuing our look at the most popular videos of 2020, in common with the previous post on SRT, today we look at replacing RTMP for ingest. This time, WebRTC is demonstrated as an option. With sub-second latency, WebRTC is a compelling replacement for RTMP.
 

 
Read what we said about it the first time in the original article, but you’ll see that Nick Chadwick from Mux takes us through the how RTMP works and where the gaps are as it’s phased out. He steps through the alternatives showing how even the low-latency delivery formats don’t fit the bill for contribution and shows how WebRTC can be a sub-second solution.

RIST and SRT saw significant and continued growth in use throughout 2020 as delivery formats and appear to be more commonly used than WebRTC, though that’s not to say that WebRTC isn’t continuing to grow within the broadcast community. SRT and RIST are both designed for contribution in that they actively manage packet loss, allow any codecs to be used and provide for other data to be sent, too. Overall, this tends to give them the edge, particularly for hardware products. But WebRTC’s wide availability on computers can be a bonus in some circumstances. Have a listen and come to your own conclusion.

Watch now!
Speaker

Nick Chadwick Nick Chadwick
Software Engineer,
Mux

Video: The Future of SSAI on OTT Devices

Posted on by Russell Trafford-Jones

Server-Side AD Insertion sounds like a sure-fire way to insert ads without ad-blockers noticing, but it’s not without problems – particularly on OTT devices plugged into the living room TV. As people are used to watching broadcast television on the TV, some of those expectations of broadcast TV are associated with whatever they watch on TV. The quick channel changing, low latency and constant quality are expected even if the viewer is watching a mini OTT streaming device plugged into HDMI input 2.

Phil Cluff from Mux looks at the challenges that devices other than computers throw up when using SSAI at this talk from Mile High Video. In general, OTT devices don’t have much memory or CPU power which renders Client-Side ad insertion impractical. SSAI can be achieved by manipulating the manifest or by rewriting timestamps on video segments. The latter damages the ability to cache chunks, so Phil explores the challenges of the former technique. On the surface, just swapping out some chunks by changing the manifest sounds simple looking at games consoles, smart TVs, streaming boxes and set-top boxes. Unsurprisingly streaming boxes like Apple TV and Roku boxes support the features needed to pull off SSAI fairly well. TVs fair less well, but those relying on Android tend to have workable solutions, explains Phil. The biggest hurdle is getting things working on set-top boxes of which there are thousands of variations, few of which support DRM and DASH well.

Phil examines the rollout of smart TVs finding that most are more than 3 years old which typically means they are on old firmware supporting features that existed when the TV was released but nothing more recent…such as supporting manifest manipulation. With this bleak picture, Phil attempts to ground us saying that we don’t need to deliver ads on all devices. Most services are able to find a core set of devices which form 80% or more of their viewership which means that supporting ads on devices outside of that core is unlikely ever to be profitable. And if it’s not profitable, is there any need to ever show ads on that device? Initially, it doesn’t feel right to deliver without ads to some devices, but if you look at the numbers, you may well find that your development time will never be paid back. An alternative solution is to deliver ads to these people by getting them to watch on Chromecasts you provide instead of on their STB which is a more common option than you may expect.

Phil finishes his talk looking at the future which includes a HbbTV spec specifically aimed around SSAI and a continued battle to find a reliable way to delivering and recording beacons for SSAI.

Watch now!
Speaker

Phil Cluff Phil Cluff
Streaming Architect,
Mux

Video: RTMP: A Quick Deep-Dive

Posted on by Russell Trafford-Jones

RTMP hasn’t left us yet, though, between HLS, DASH, SRT and RIST, the industry is doing its best to get rid of it. At the time RTMP’s latency was seen as low and it became a defacto standard. But as it hasn’t gone away, it pays to take a little time to understand how it works

Nick Chadwick from Mux is our guide in this ‘quick deep-dive’ into the protocol itself. To start off he explains the history of the Adobe-created protocol to help put into context why it was useful and how the specification that Adobe published wasn’t quite as helpful as it could have been.

Nick then gives us an overview of the protocol explaining that it’s TCP-based and allows for multiple, bi-directional streams. He explains that RTMP multiplexes larger, say video, messages along with very short data requests, such as RPC, but breaking down the messages into chunks which can be multiplexed over just the one TCP connection. Multiplexing at the packet level allows RTMP to be asking the other end a question at the same time as delivering a long message.

Nick has a great ability to make describing the protocol and showing ASCII tables accessible and interesting. We quickly start looking at the header for chunks explaining what the different chunks are and how you can compress the headers to save bit rate. He also describes how the RTMP timestamp works and the control message and command message mechanism. Before answering Q&A questions, Nick outlines the difficulty in extending RTMP to new codecs due to the hard-coded list of codecs that can be used as well as recommending improvements to the protocol. It’s worth noting that this talk is from 2017. Whilst everything about RTMP itself will still be correct, it’s worth remembering that SRT, RIST and Zixi have taken the place of a lot of RTMP workflows.

Watch now!
Speaker

Nick Chadwick Nick Chadwick
Software Engineer,
Mux