OTT

Video: Managing Unplanned Media Transitions in DASH Live Streaming

Posted on by Russell Trafford-Jones

In live sports, a cut to or from ads can happen at a moment’s notice. Whilst not an issue for over-the-air broadcast, when you’re streaming it can be tough to get the ‘switch’ message out to the client in time. Server-side ad insertion is usually achieved by manipulating a manifest for a customer. This allows insertion of ads without having to encode the video into the programme video and allows for personalisation.

David Romrell from CommScope starts by giving an overview of how SSAI works and where players can get tripped up by going a little ahead. This talk looks at how to deal with unexpected breaks, for instance when play finishes abruptly, and for early recalls where, say, something interesting happens on pitch and the break is abandoned. There is in-band signalling of events possible within MPEG dash, but this will only work when the player hasn’t gone ahead of time so it’s not to be relied upon in this scenario.

Players can ‘go ahead’ because of the MPD (Media Presentation Description). David walks us through the anatomy of an MPD showing how it lays out a template for extrapolating the chunk name for future chunks. It also provides a heartbeat for how often the client needs to check for an updated playlist known as the MUP. This minimum update period needs to be set to balance between allowing the client some autonomy and being able to make moment-to-moment changes.

David walks through a scenario with an early return showing how a player may get confused and, at best, cause a bandwidth spike and a double hit on the CDN. At worst, the stream will rebuffer and jump. To avoid this, we see 4 options offered by David. One is to issue new periods the moment they’re known about. Even if the media list is empty, this at least signals that there’s a change coming up. This method works but the less warning there is, the less effective it is. A second idea is to ensure that ads aren’t advertised ahead of the packager which stops the player going ahead and downloading content early. The last two, we look at in more detail.

Using and @availabilityStartTime (AST) are looked at in a little more detail. The UTCTiming technique adapts the to the timing presented by the packager and pauses the ads clock which works well other than for clients which ignore this indicator. Lastly, adjusting the AST shifts the downloading times is a simplistic constant shift which doesn’t adapt to the packager rate.

David concludes saying there is plenty of flexibility for implementation in DASH, that UTCTiming or AST shift can deliver the consistent client experience we are looking for but that the lower the latency, the more severe the trade-offs in these unplanned scenarios.

Watch now!
Download the presentation
Speaker

Dave Romrell David Romrell
Engineering Fellow,
Advance Research Group,
CommScope

Video: Early Live Trials of VVC & EVC for OTT Delivery

Posted on by Russell Trafford-Jones

Much of 2020 was spent looking forward to the release of VVC, EVC and LC-EVC. A trio of MPEG standards fitting different use cases across this industry and beyond. Now they’ve all been released, it’s time to filter through finding which are the right fit for your workflows.

In this video, Thibaud Biatek from ATEME looks at using EVC and VVC for online streaming. EVC, is the Essential Video Codec, and VVC stands for the Versatile Video Codec. If you’d like to know more about the codecs themselves, check out this video talking about all of them. The driver for new codecs highlighted in the video is that internet traffic is over 70% video. But taking a step back, we need to remember that these codecs all come delivering more than just compression savings. Some, like LCEVC bring easier compression on embedded systems and easier decoding for AI applications. VVC represents the state of the art in compression techniques and EVC offers a totally royalty-free encoding option which is missing from all other MPEG codecs.

MPEG are very open that VVC is the same fundamental design as MPEG 2 was, it’s the techniques in each functional block which have improved in both quantity and ability that marks the difference. As such, Thibaud notes that you can create the same base code for an EVC codec as for VVC, thus you only need one software library to deliver an encode for both codecs. If you look at partitioning the screen into blocks, we see that VVC does everything EVC does but ads the ability to have diagonals. Screen Content Coding (SCC) is a speciality of VVC which adds it as a standard capability, unlike HEVC which had it optional. EVC also has SCC but only contains Intra Block Copy to implement it; VVC has three more on top of IBC.

Thibaud outlines how ATEME have done their initial implementations of VVC and EVC. Though they are not yet full implementations, they are seeing notable improvements over HEVC, particularly for VVC’s encoding of 8K which is attributed to the larger block sizes allowed in partitioning. He then takes us through the trials to date which have involved UHD VVC over satellite to the current test which is a real-time VVC encode to a CMAF ladder of 720p, 1080p and 2160p. In partnership with Akamai, this was then distributed as CMAF to the end-user which was using IETR’s openVVC decoder.

Watch now!
Speaker

Thibaud Biatek Thibaud Biatek
Reasearch & Innovation Engineer
ATEME

Video: Broadcast in the cloud!

Posted on by Russell Trafford-Jones

Milan Video Tech’s back with a three takes on putting broadcast into the cloud. So often we see the cloud as ‘for streaming’. That’s not today’s topic; we’re talking ingest and live transmissions in the cloud. Andrea Fassina from videodeveloper.io introduces the three speakers who share their tips for doing cloud well by using KPIs, using the cloud to be efficient, agile & scale and, finally, running your live linear channels through the cloud as part of their transmission path.

First up is Christopher Brähler from Akamai who looks at a how they helped a customer becomes more efficient, be agile and scale. His first example shows how using a cloud workflow in AWS, including many AWS services such as Lambda, the customer was able to reduce human interaction with a piece of content during ingest by 80%. The problem was that every piece of content took two hours to ingest, mainly due to people having to watch for problems. Christopher shows how this process was automated. He highlights some easy wins by front-loading the process with MediaInfo which could easily detect obvious problems like incorrect duration, codec etc. Christopher then shows how the rest of the workflow used AWS components and Lamda to choose to transcode/rewrap files if needed and then pass them on to a whole QC process. The reduction was profound and whilst this could have been achieved with similar MAM-style processing on-premise, being in the cloud allows the next two benefits.

The next example is how the same customer was able to quickly adjust to a new demand on the workflow when they found that some files were arriving and weren’t compatible with their ingest process due to a bug in a certain vendor’s software which was going to take months to fix. Using this same workflow they were able to branch out, using MediaInfo to determine if this vendor’s software was involved. If it was it would be sent down a newly-created path in the workflow that worked around the problem. The benefit of this being in the cloud touches on the third example – scalability. Being in the cloud, it didn’t really matter how much or little this new branch was used. When it wasn’t being used, the cost would be nothing. If it was needed a lot, it would scale up.

The third example is when this customer merged with another large broadcaster, The cloud-based workflow meant that they were able to easily scale up and put a massive library of content through ingest in a matter of two or three months, rather than a year or more than otherwise would be the case on dedicated equipment.

Next up is Luca Moglia from Akamai who’s sharing with his experience on getting great value out of cloud infrastructure. Security should be the basis of any project whether it’s on the internet or not, so it’s no surprise that Luca starts with the mandate to ‘Secure all connections’. Whilst he focuses on the streaming use case, his points can be generalised to programme contribution. He splits up the chain into ‘first mile’ (origin/DC to cloud/CDN), ‘middle mile’ (cloud/CDN to edge) and last mile which is the delivery from the edge to the viewer. Luca looks at options to secure these segments such as ‘AWS Connect’ and other services for Azure & GCP. He looks at using private network interconnections (PNIs) for CDNs and then examines options for the last mile.

His other pieces of advice are to offload as mich ‘origin’ as you can, meaning to reduce the load on your origin server by using an Origin Gateway but also a Multi-CDN strategy. Similarly, he suggests offloading as much logic to the edge as is practical. After all, the viewer’s ping to the edge (RTT) is the lowest practical, so having two-way traffic is best there than deeper into the CDN as the edge is usually in the same ISP.

Another plea is to remember that CMAF is not just there to reduce latency, Luca emphasises all the other benefits which aren’t only important for low-latency use cases such as being able to use the same segments for delivering HLS and DASH streams. Being able to share the same segments allows CDNs to cache better which is a win for everyone. It also reduces storage costs and brings all DRM under CENC, a single mechanism supporting several different DRM methods.

Luca finishes his presentation suggesting looking at the benefits of using HTTP/2 and HTTP/3 to reduce round trips and, in theory, speed up delivery. Similarly, he talks about the TCP algorithm BBR which should improve throughput.

Last to speak is Davide Maggioni from Sky Italia who shows us how they quickly transitioned to a cloud workflow for NOWTV and SKYGO when asked to move to HD, maintain costs and make the transition quickly. They developed a plan to move the metadata enrichement, encryption, encoding and DRM into the cloud. This helped them reduce procurement overhead and allowed them to reduce deployment time.

Key to the project was taking an ‘infrastructure as code’ approach whereby everything is configured by API, run from automated code. This reduces mistakes, increases repeatability and also allowed them to, more easily, deploy popup channels.

Davide takes us through the diagrams and ways in which they are able to deploy permanent and temporary channels showing ‘mezzanine’ encoding on-premise, manipulation done in the cloud, and then a return to on premise ahead of transmission to the CDN.

Watch now!
Speakers

Christopher Brähler Christopher Brähler
Director of Product Management,
SDVI Corporation
Davide Maggioni Davide Maggioni
OTT & Cloud Process and Delivery,
Sky Italia
Luca Moglia Luca Moglia
Media Solutions Engineer,
Akamai
Andrea Fassina Andrea Fassina
Freelance Developer,
https://videodeveloper.io

Video: Player Optimisations

Posted on by Russell Trafford-Jones

If you’ve ever tried to implement your own player, you’ll know there’s a big gap between understanding the HLS/DASH spec and getting an all-round great player. Finding the best, most elegant, ways of dealing with problems like buffer exhaustion takes thought and experience. The same is true for low-latency playback.

Fortunately, Akamai’s Will Law is here to give us the benefit of his experience implementing his own and helping customers monitor the performance of their players. At the end of the day, the player is the ‘kingpin’ of streaming, comments Will. Without it, you have no streaming experience. All other aspects of the stream can be worked around or mitigated, but if the player’s not working, no one watches anything.

Will’s first tip is to implement ‘segment abandonment’. This is when a video player foresees that downloading the current segment is taking too long; if it continues, it will run out of video to play before the segment has arrived. A well-programmed player will sport this and try to continue the download of this segment from another server or CDN. However, Will says that many will simply continue to wait for the download and, in the meantime, the download will fail.

Tip two is about ABR switching in low-latency, chunked transfer streams. The playback buffer needs to be longer than the chunk duration. Without this precaution, there will not be enough time for the player to make the decision to switch down layers. Will shows a diagram of how a 3-second playback buffer can recover as long as it uses 2-second segments.

Will’s next two suggestions are to put your initial chunk in the manifest by base64-encoding it. This makes the manifest larger but removes the round-trip which would otherwise be used to request the chunk. This can significantly improve the startup performance as the RTT could be a quarter of a second which is a big deal for low-latency streams and anyone who wants a short time-to-play. Similarly, advises Will, make those initial requests in parallel. Don’t wait for the init file to be downloaded before requesting the media segment.

Whilst many of points in this talk focus on the player itself, Will says it’s wise for the player to provide metrics back to the CDN, hidden in the request headers or query args. This data can help the CDN serve media smarter. For instance, the player could send over the segment duration to the CDN. Knowing how long the segment is, the CDN can compare this to the download time to understand if it’s serving the data too slow. Perhaps the simplest idea is for the player to pass back a GUID which the CDN can put in the logs. This helps identify which of the millions of lines of logs are relevant to your player so you can run your own analysis on a player-by-player level.

Will’s other points include advice on how to avoid starting playing at the lowest bandwidth and working up. This doesn’t look great and is often unnecessary. The player could run its own speed test or the CDN could advise based on the initial requests. He advises never trusting the system clock; use an external clock instead.

Regarding playback latency, it pays to be wise when starting out. If you blindly start an HLS stream, then your latency will be variable within the duration of a segment. Will advocates HEAD requests to try to see when the next chunk is available and only then starting playback. Another technique is to vary your playback rate o you can ‘catch up’. The benefit of using rate adjustment is that you can ask all your players to be at a certain latency behind realtime so they can be close to synchronous.

Two great tips which are often overlooked: Request multiple GOPs at once. This helps open up the TCP windows giving you a more efficient download. For mobile, it can also help the battery allowing you to more efficiently cycle the radio on and off. Will mentions that when it comes to GOPs, for some applications its important to look at exactly how long your GOP should be. Usually aligning it with an integer number of audio frames is the way to choose your segment duration.

The talk finishes with an appeal to move to using CMAF containers for streaming ask they allow you to deliver HLS and DASH streams from the same media segments and move to a common DRM. Will says that CBCS encrypted content is now becoming nearly all-pervasive. Finally, Will gives some tips on how players are best to analyse which CDN to use in multi-CDN environments.

Watch now!
Speaker

Will Law Will Law
Chief Architect,
Akamai