Live Streaming Archives – Page 11 of 29

Video: Integrating CMAF Into A VOD Workflow

Posted on 20th February 2020 by Russell Trafford-Jones

CMAF is often seen as the best hope for streaming to match the latency of broadcast. Fully standards based, many see this as the best route over Apple’s LL-HLS. Another benefit of it over LL-HLS is that it’s already a completed standard with growing support.

This talk from Tomas Bacik starts by explaining CMAF to us. Standing for the Common Media Application Format, it’s based on the standardised ISOBMFF container format and whilst CMAF isn’t by default low-latency, it is flexible enough to deliver just that. However, as Tomas from CDN77 points out, there are other major benefits in terms of its use of the Common Encryption format, reduces storage fees and more.

MPEG DASH is a commonly found streaming format based on ISO BMFF. It has always had the benefit of supporting other codecs such as HEVC and AV1 over HLS which is an AVC-only specification. CMAF is an extension of MPEG DASH which goes one step further in that it can deal with both HLS-style manifest files (.hls) as well as MPEG DASH format (.mpd) inheriting, of course, the multi-codec ability of DASH itself.

Next is central theme of the talk, looking at VoD workflows showing how CMAF fits in and, indeed, changes workflows for the better. CMAF directly impacts packaging, storage and CDN which is where we focus now. Given that some devices can play HLS and some can play DASH, if you try to serve both, you will double your requirements of packaging, storage etc. Dynamic packaging allows for immediately repackaging your chunks into either HLS or DASH as needed. Whilst this reduces the storage requirements, it increases processing and also increases the time to first byte. As you might expect, using CMAF throughout, Tomas explains in this talk, allows you to package once and store once which solves these problems.

Tomas continues by explaining the DRM abilities of CMAF including AES-CBC and finishes by taking questions from the audience.

Watch now!
See Streamflow’s blog post supporting the talk
Speakers

Tomas Bacik
VP of Product Development, Streamflow by CDN77
CDN77

Video: Three Roads to Jerusalem

Posted on 6th February 2020 by Russell Trafford-Jones

With his usual entertaining vigour, Will Law explains the differences to the three approaches to low-latency streaming: DASH, LHLS and LL-HLS from Apple. Likening them partly to religions that all get you to the same end, we see how they differ and some of the reasons for that.

Please note: Since this video was recorded, Apple has released a new draft of LL-HLS. As described in this great article from Mux, the update’s changes are

“Delivering shorter sub-segments of the video stream (Apple call these parts) more frequently (every 0.3 – 0.5s)

Using HTTP/2 PUSH to deliver these smaller parts, pushed in response to a blocking playlist request

Blocking playlist requests, eliminating the current speculative manifest request polling behaviour in HLS

Smaller, delta rendition playlists, which reduces playlist size, which is important since playlists are requested more frequently

Faster rendition switching, enabled by rendition reports, which allows clients to see what is happening in another playlist without requesting it in its entirety”[0]

Read the full article for the details and implications, some of which address some points made in the talk.

Furthermore, THEOplayer have released this talk explaining the changes and discussing implementation.

Anyone who saw last year’s Chunky Monkey video, will recognise Will’s near-Oscar-winning animation style as he sets the scene explaining the contenders to the low-latency streaming crown.

We then look at a bullet list of features across each of the three low latency technologies (note Apple’s recent update) which leads on to a discussion on chunked transfer delivery and the challenges of line-rate delivery. A simple view of the universe would say that the ideal way to have a live stream, encoded at a constant bitrate, would be to stream it constantly at that bitrate to the receiver. Whilst this is, indeed, the best way to go, when we stream we’re also keeping one eye on whether we need to change the bitrate. If we get more bandwidth available it might be best to upgrade to a better quality and if we suddenly have contested, slow wifi, it might be time for an emergency drop down to the lowest bitrate stream.

When you are delivered a stream as individual files, you can measure how long they take to download to estimate your available bandwidth. If a file can be downloaded at 1Gbps, then it should always arrive at 1Gbps. Therefore if it arrives at less than 1Gbps we know that there is a bandwidth restriction and can make adjustments. Will explains that for streams delivered with chunked transfer or in real time such as in LL-HLS, this estimation no longer works as the files simply are never available at 1Gbps. He then explains some of the work that has been undertaken to develop more nuanced ways of estimating available bandwidth. It’s well worth noting that the smaller the files you transfer, the less accurate the bandwidth estimation as TCP takes time to speed up to line rate so small 320ms-length video segments are not ideal for maximising throughput.

Continuing to look at the differences, we next look at request rates with DASH at 20 requests per second compared to LL-HLS at 720. This leads naturally to an analysis of the benefits of HTTP/2 PUSH technology used in LL-HLS and the savings that can offer. Will explores the implications, and some of the problems, with last year’s version of the LL-HLS spec, some of which have been mitigated since.

The talk concludes with some work Akamai has done to try and establish a single, common workflow with examples and a GitHub repository. Will shows how this works and the limitations of the approach and finishes with a look at the commonalities in approaches.

[0] From “Low Latency HLS 2: Judgment Day” https://mux.com/blog/low-latency-hls-part-2/

Watch now!
Speakers

Will Law
Chief Architect,
Akamai

Video: Online Streaming Primer

Posted on 31st January 2020 by Russell Trafford-Jones

A trip down memory lane for some, a great intro to the basics of streaming for others, this video from IET Media looks at the history of broadcasting and how that has moved over the years to online streaming posing the question whether, with so many people watching online, is that broad enough to now be considered broadcast?

The first of a series of talks from IET Media, the video starts by highlighting that the recording of video was only practical 20 years after the first television broadcasts then talks about how television has moved on to add colour, resolution and move to digital. The ability to record video is critical to almost all of our use of media today. Whilst film worked well as an archival medium, it didn’t work well, at scale, for recording of live broadcasts. So in the beginning, broadcasting from one, or a few, transmitters was all there was.

Russell Trafford-Jones, from IET Media, then discusses the advent of streaming from its predecessor as file-based music in portable players, through the rise of online radio and how this naturally evolved into the urge to stream video in much the same way.

Being a video from the IET video, Russell then looks at the technology behind getting video onto a network and over the internet. He talks about cutting the stream into chunks, i.e. small files, and how sending files can create a seamless stream of data. One key advantage of this method is Adaptive BitRate (ABR) meaning being able to change from one quality level, to another which typically means changing bitrate to adapt to changing network conditions.

Finishing by talking about the standards available for online streaming, this talk is a great introduction to streaming and an important part of anyone’s foundational understanding of broadcast and streaming.

Watch now!

This video was produced by IET Media, a technical network within the IET which runs events, talks and webinars for networking and education within the broadcast industry. More information

Speakers

Russell Trafford-Jones
Exec Member, IET Media
Manager, Support & Services, Techex
Editor, The Broadcast Knowledge

Webinar: Securing Live Streams

Posted on 27th January 2020 by Russell Trafford-Jones

Piracy in France cost €1.2bn in 2017 and worldwide the loss has been valued up to US$52 billion. Even if these numbers are inflated, over-counted or similar, it’s clear there is a lot of money at stake in online streaming. There are a number of ways of getting to protect your content, encryption, Digital Rights Management (DRM) and tokenisation are three key ones and this webinar will examine what works best in the real world.

All these technologies used together don’t always stop piracy 100%, but they can significantly impact the ease of pirating and the quality of the final material.

Date: Thursday January 30th – 10a.m. PT / 1p.m. / 18:00 GMT

It’s important to understand the difference between encryption and Digital Rights Management. In general DRM relies on encryption, whereby encryption is a way of making sure that decodable video only lands in the hands of people who have been given the encryption key. This means that people who are snooping on traffic between the video provider and consumer can’t see what the video is and can be accomplished in a similar way to secure web pages which are secured against eavesdroppers. The problem with encryption is, however, that it doesn’t intrinsically decide who is allowed to decode the video meaning anyone with the decryption key can video the content. Often this is fine, but if you want to run a pay-TV service, even ignoring content, it’s much better to target customer by customer who can video the video. And this is where DRM comes in.

DRM is multi-faceted and controls the way in which consumers can view/use the content as much as whether they can access it to start with. DRM, for instance, can determine that a display device can show the work, but a recorder is not allowed to make a recording. It can also determine access based on location. Another aspect of DRM is tracking in the form of insertion of watermarks and metadata which mean that if a work is pirated, there is a way to work back to the original subscriber to determine the source of the leak.

Tokenisation is a method in which the player requests access to the material and is passed a token, by means of a response from the server after it has checked if the player is allowed access. Because of the way this token is created, it is not possible for another player to use it to access the content which means that sharing a URI won’t allow another user access to the video. Without some form of access control, once one subscriber has received a URI to access the video, they could pass that to another user who could also then access it.

What’s the best way to use these technologies? What are the pros and cons and what are the other methods of securing media? These questions and more will be discussed in this Streaming Video Alliance webinar on January 30th.

	Peter Cossack Vice President Cybersecurity services, Irdeto
	Kei Foo Director of Advanced Video Engineering, Charter Communications
	Orly Amsalem Product Manager, AI/ML based video security and anti-piracy solutions , Synamedia
	Marvin Van Schalkwyk Senior Solutions Architect, FriendMTS
	Jason Thibeault Executive Director, Streaming Media Alliance

Subscribe to get daily updates