RTMP

Video: CMAF and DASH-IF Live ingest protocol

Posted on by Russell Trafford-Jones

Of course, without live ingest of content into the cloud, there is no live streaming so why would we leave such an important piece of the puzzle to an unsupported protocol like RTMP which has no official support for newer codecs. Whilst there are plenty of legacy workflows that still successfully use RTMP, there are clear benefits to be had from a modern ingest format.

Rufael Mekuria from Unified Streaming, introduces us to DASH-IF’s CMAF-based live ingest protocol which promises to solve many of these issues. Based on the ISO BMFF container format which underpins MPEG DASH. Whilst CMAF isn’t intrinsically low-latency, it’s able to got to much lower latencies than standard HLS and LHLS.

This work to create a standard live-ingest protocol was born out of an analysis, Rufael explains, of which part of the content delivery chain were most ripe for standardisation. It was felt that live ingest was an obvious choice partly because of the decaying RTMP protocol which was being sloppy replaced by individual companies doing their own thing, but also because there everyone contributing, in the same way, is of a general benefit to the industry. It’s not typically, at the protocol level, an area where individual vendors differentiate to the detriment of interoperability and we’ve already seen the, then, success of RMTP being used inter-operably between vendor equipment.

MPEG DASH and HLS can be delivered in a pull method as well as pushed, but not the latter is not specified. There are other aspects of how people have ‘rolled their own’ which benefit from standardisation too such as timed metadata like ad triggers. Rufael, explaining that the proposed ingest protocol is a version of CMAF plus HTTP POST where no manifest is defined, shows us the way push and pull streaming would work. As this is a standardisation project, Rufael takes us through the timeline of development and publication of the standard which is now available.

As we live in the modern world, ingest security has been considered and it comes with TLS and authentication with more details covered in the talk. Ad insertion such as SCTE 35 is defined using binary mode and Rufael shows slides to demonstrate. Similarly in terms of ABR, we look at how switching sets work. Switching sets are sets of tracks that contain different representations of the same content that a player can seamlessly switch between.

Watch now!
Speaker

Rufael Mekuria Rufael Mekuria
Head of Research & Standardisation,
Unified Streaming

Video: 2019 What did I miss? – SRT

Posted on by Russell Trafford-Jones

We’re looking at the most popular posts of 2019 now as The Broadcast Knowledge takes a break over the holiday season. Twitch’s Alex Converse had one of the most visited posts of the year in his video detailing how SRT works. It’s a great technical resource for developers and engineers wanting to understand more than just the highlights of SRT. Did it do well because it was Alex? Because the San Francisco’s Video Tech meet up is a well known part of Demuxed’s community for ‘engineers working with video’ or because its title? Any or all of these could be true and it wouldn’t invalidate it’s usefulness or its popularity. So if you haven’t already, read more about it here, or click play below.

Another SRT talk of interest this year you may want to catch up on was the IBC SRT Open Source Technical panel which looked at the general SRT features and looked at the pros and cons against SRT. The panel looked at a case study with Red Bee Media and South American broadcaster Globo and the use of RTP and SRT together. Read more detail here or click here to watch for free

Speaker

Alex Converse Alex Converse
Streaming Video Software Engineer,
Twitch

Video: SRT – How the hot new UDP video protocol actually works under the hood

Posted on by Russell Trafford-Jones

In the west, RTMP is seen as a dying protocol so the hunt is on for a replacement which can be as widely adopted but keep some of it’s best parts including relatively low latency. SRT is a protocol for Secure, Reliable Transport of streams over the internet so does this have a role to play and how does it work?

Alex Converse from Twitch picks up the gauntlet to dive deep into the workings of SRT to show how it compares to RTMP and specifically how it improves upon it.

RTMP fails in many ways, two to focus on are that the spec has stopped moving forward and it doesn’t work well over problematic networks. So Alex takes a few minutes to explain where SRT has come from, the importance of t being open source and how to get hold of the code and more information.

Now, Alex starts his dive into the detail reminding us about UDP, TS Packets and Ethernet MTUs has he goes down. We look at how SRT data packets are formed which helps explain some of the features and sets us up for a more focussed look.

SRT, as with other, similar protocols which create their resilience by retransmitting missing packets, need to use buffers in order to have a chance to send the missing data before it’s needed at the decoder. Alex takes us through how the sender and receiver buffers work to understand the behaviour in different situations.

Fundamental to the whole protocol is packet the packet acknowledgement and negative acknowledgements which feature heavily before we discuss handshaking as we start our ascent from the depths of the protocol. As much as acknowledgements provide the reliability, encryption provides the ‘secure’ in Secure Reliable Transport. We look at the approach taken to encryption and how it relates to current encryption for websites.

Finally, Alex answers a number of questions from the audience as he concludes this talk from the San Francisco Video Tech meet-up.

Watch now!

Speaker

Alex Converse Alex Converse
Streaming Video Software Engineer,
Twitch

Video: From WebRTC to RTMP

Posted on by Russell Trafford-Jones

With the demise of RTMP, what can WebRTC – its closest equivalent – learn from it? RTC stands for Real-Time Communications and hails from the video/voice teleconferencing world. RTC traditionally has ultra-low latency (think sub-second; real-time) so as broadcasters and streaming companies look to reduce latency it’s the obvious technology to look at. However, RTC comes from a background of small meetings, mixed resolutions, mixed bandwidths and so the protocols underpinning it can be lacking what broadcast-style streamers need.

Nick Chadwick from MUX looks at the pros and cons of the venerable RTMP (Real Time Messaging Protocol). What was in it that was used and unused? What did need that it didn’t have? What gap is being left by its phasing out?

Filling these increasing gaps is the focus of the streaming community and whether that comes through WebRTC, fragmented MP4 delivered over web sockets, Low-Latency HLS, Apple’s Low-Latency HLS, SASH, CMAF or something else…it still needs to be fulfilled.

Nick finishes with two demos which show the capabilities of WebRTC which outstrip RTMP – live mixing on a browser. WebRTC clearly has a future for more adventurous services which don’t simply want to deliver a linear channel to sofa-dwelling humans. But surely Nick’s message is WebRTC needs to step up to the plate for broadcasters, in general, to enable them to achieve < 1-second end-to-end latency in a way which is compatible with broadcast workflows.

Watch now!
Speaker

Nick Chadwick Nick Chadwick
Software Engineer,
Mux