Video: Buffer Sizing and Video QoE Measurements at Netflix

At a time when Netflix is cutting streaming quality to reduce bandwidth, we take a look at the work that’s gone into optimising latency within the switch at ISPs which was surprisingly high.

Bruce Spang interned at Netflix and studied the phenomenon of unexpected latency variation within the netflix caches they deploy at ISPs to reduce latency and bandwidth usage. He starts by introducing us to the TCP buffering models looking at how they work and what they are trying to achieve with the aim of identifying how big it is supposed to be. The reason this is important is that if it’s a big buffer, you may find that data takes a long time to leave the buffer when it gets full, thus adding latency to the packets as they travel through. Too small, of course, and packets have to be dropped. This creates more rebuffing which impacts the ABR choice leading to lower quality.

Bruce was part of an experiment that studied whether the buffer model in use behaved as expected and whist he found that it did most of the time, he did find that video performance varied which was undesirable. To explain this, he details the testing they did and the finding that congestion, as you would expect, increases latency more during a congested time. Moreover, he showed that a 500MB had more latency than 50MB.

To explain the unexplained behaviour such as long-tail content having lower latency than popular content, Bruce explains how he looked under the hood of the router to see how VOQs are used to create queues of traffic and how they work. Seeing the relatively simply logic behind the system, Bruce talks about the results they’ve achieved working with the vendor to improve the buffering logic.

Watch now!
Speakers

Bruce Spang Bruce Spang
PhD Student, Stanford

Video: Harness SSAI’s Superpowers

Server-side Ad Insertion (SSAI) is a great option for streaming services delivering video to a wide variety of devices and for those who need to avoid ad blockers. Whilst ad insertion can happen in the player, this mechanism can be interfered with allowing users to avoid ads. Whilst client-side ad insertion can much more easily create a unique stream for each client, dynamic SSAI can now do the same with a better user experience.

This panel from the OTT Leadership Summit at Streaming Media West 2019 brings together Disney, WarnerMerdia and Crunchyroll to share their experiences with SSAI. They discuss beaconing, ad standards, scaling, SCTE and more.

Beaconing goes hand in hand with ad playback providing metrics on what happened. When you perform certain actions, the player will reach out to a URL. This can be used to indicate such things as users skipping or pausing a video. The beacon information can then be used to verify how much of which ads were seen by whom and charge advertisers accordingly.

The panel moves on to discussing scaling using live sports as an example and cover questions to ask vendors to ensure you and they are ready for maximum scale. Bandwidth, is declared the biggest challenge, but a less obvious problem is that your upstream ad providers can’t always scale well. If you rely on calls from your server to others, then it’s vital to understand their scaling capacity and strategy. They discuss issues with losing beacons when operating at scale and the need for detailed logging and debugging in order to spot errors and reconcile the results.

Some time is next spent on VPAID and VAST 4 which are both messaging specifications to allow ad servers to tell applications which ads to play. The panel discusses the pros and cons in their use for SSAI where the stitcher needs to reach out to and ad server in real time to find out which ads to play.

At the end of the discussion, the panel takes questions from the floor but not before discussing SCTE Markers and ‘content conditioning’ which surrounds taking care of your source videos and encoder such that the two assets fit together properly at I-frame boundaries.

Watch now!
Speakers

Robert Jameson Robert Jameson
Technical Director, Media Enablement
Turner | WarnerMedia
Stephen Gray Stephen Gray
Director, Ad Tech Systems
Walt Disney Direct-to-Consumer & International
Michael Dale Michael Dale
VP Engineering,
Crunchyroll
Nadine Krefetz Nadine Krefetz
Consultant, Reality Software
Contributing Editor, Streaming Media

Video: Reinventing Intercom with SMPTE ST 2110-30

Intercom systems form the backbone of any broadcast production environment. There have been great strides made in the advancement of these systems, and matrix intercoms are very mature solution now, with partylines, IFBs and groups, wide range of connectivity options and easy signal monitoring. However, they have flaws as well. Initial cost is high and there’s lack of flexibility as system size is limited by the matrix port count. It is possible to trunk multiple frames, but it is difficult, expensive and takes rack space. Moreover, everything cables back to a central matrix which might be a single point of failure.

In this presentation, Martin Dyster from The Telos Alliance looks at the parallels between the emergence of Audio over IP (AoIP) standards and the development of products in the intercom market. First a short history of Audio over IP protocols is shown, including Telos Livewire (2003), Audinate Dante (2006), Wheatstone WheatNet (2008) and ALC Networks Ravenna (2010). With all these protocols available a question of interoperability has arisen – if you try to connect equipment using two different AoIP protocols it simply won’t work.

In 2010 The Audio Engineering Society formed the x192 Working Group which was the driving force behind the AES67. This standard was ratified in 2013 and allowed interconnecting audio equipment from different vendors. In 2017 SMPTE adapted AES67 as the audio format for ST 2110 standard.

Audio over IP replaces the idea of connecting all devices “point-to-point” with multicast IP flows – all devices are connected via a common fabric and all audio routes are simply messages that go from one device to another. Martin explains how Telos were inspired by this approach to move away from the matrix based intercoms and create a distributed system, in which there is no central core and DSP processing is built in intercom panels. Each panel contains audio mix engines and a set of AES67 receivers and transmitters which use multicast IP flows. Any ST 2110-30 / AES67 compatible devices present on the network can connect with intercom panels without an external interface. Analog and other baseband audio needs to be converted to ST 2110-30 / AES67.

Martin finishes his presentation by highlighting advantages of AoIP intercom systems, including lower entry and maintenance cost, easy expansion (multi studio or even multi site) and resilient operation (no single point of failure). Moreover, adaptation of multicast IP audio flows removes the need for DAs, patch bays and centralised routers, which reduces cabling and saves rack space.

Watch now!

Download the slides.

If you want to refresh your knowledge about AES67 and ST2110-30, we recomend the Video: Deep Dive into SMPTE ST 2110-30, 31 & AES 67 Audio presentation by Leigh Whitcomb.

Speaker

Martin Dyster
VP Business Development
The Telos Alliance

Video: Doing Server-Side Ad Insertion on Live Sports for 25.3M Concurrent Users

Delivering ads successfully is done by some services by having the client insert the different ads, and some by inserting the ads at the server end. The choice of which to use requires knowing your customers and how they are most likely to receive your streams. With the prevalence of ad blockers, businesses find the many customers never see the client-side inserted ads. Inserting ads at the server, therefore allows you to get around this as even the ads look like they are a continuation of the same video feed.

The downside of server-side ad insertion (SSAI), whilst rendering the ads unblockable, restricts the ads you can place. Theoretically, in client-side ad insertion, each user can have their own advert. With SSAI, to do that you would need to create a new stream per user which becomes much more computationally hungry. So the sweet spot comes in between the two where viewers are grouped into categories so that only a few tens of streams, for example, are needed to match ten demographics identified to advertisers. This is known as ‘dynamic SSAI’.

Ashutosh Agrawal took to the stage at the Demuxed SF 2019 conference to explain how Hotstar used dynamic SSAI to deliver targeted ads to their 25 million viewers. As an example of your understanding of your viewers driving your choice of ad-delivery technology, Ashutosh explains that close to 85% of their viewing is on mobile and much of that has marginal reception. In hostile network conditions, the requirement for the player to be downloading ads in the background doesn’t work well since the network can only just about support the live video, so a background download pushes the ABR quality down and could even create pausing and rebuffering. It’s for this reason that Hotstar decided that server-side was the way to go.

Ashutosh takes us through how Hotstar approached this large event. In India, cricket is a very popular game which lasts for up to 8 hours a day. This gives rise to a large number of breaks, over 100, which add up to over an hour’s advertising in total so it’s clear to see why this is a massive opportunity for optimisation. Static ad insertion reacts to SCTE 35 markers inserted. This can work well in the sense that for a 40 seconds SCTE marker, the platform can ad an approx 40-second ad or two 20 second ads. However, it isn’t flexible enough to deal with the times when there are far more people watching than that ad agency has paid for which means that Hotstar would end up delivering more viewers than necessary. It would be better for those viewers to see a different ad, triggered by SCTE 35.

As discussed above, doing SSAI for each person is a scalability and cost nightmare, so we quickly see that Targeted SSAI is the way forward. This allows different cohorts of users to be identified. Each cohort will receive its own virtual feed with their own adverts. We then see the architecture of the system showing how the CDN is used. For scaling, we see that they use a cache rather than a database.

Nginx then gets a namecheck as Ashutosh explains how they provide caching, including an nginx memory cache, to deal with up to 50% of the overall load, shared with the CDN if necessary. He then finishes with a look at the best practices they have learnt and what Ashutosh sees is the future for this technique.

Watch now!
Speaker

Ashutosh Agrawal Ashutosh Agrawal
Evangelist/Architect – CTO’s Office,
Hotstar