Video: Reinventing Intercom with SMPTE ST 2110-30

Posted on by Adam K

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

Posted on by Russell Trafford-Jones

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

Webinar: Multicast ABR opens the door to a new DVB era

Posted on by Russell Trafford-Jones

Now available on demand

With video delivery constituting the majority of traffic, it’s clear there’s a big market for it. ON the internet, this is done with unicast streaming where for each receiver, the stream source has to send another stream. The way this has been implemented using HTTP allows for a very natural system, allied Adaptive Bit Rate (ABR), which means that every when your network capacity is constrained (by the network itself or bandwidth contention), you can still get a picture just at a lower bit rate.

But when extrapolating this system linear television, we find that large audience place massive demands on the originating infrastructure. This load on the infrastructure drives its architects to implement a lot of redundancy making it expensive to run. Within a broadcaster, such loads would be dealt with by multicast traffic but on the internet, Multicast is not enabled. For an IPTV system where each employee had access via a program on their PC and/or a set-top-box on their desk, the video would be sent by multicast meaning that it is the network that was providing the duplication of the streams to each endpoint, not the source.

By combining existing media encoding and packaging formats with the efficiency of point-to-multipoint distribution to the edge of IP-based access networks, it is possible to design a system for linear media distribution that is both efficient and scalable to very large audiences, while remaining technically compatible with the largest possible set of already-deployed end user equipment.

This webinar by Guillaume Bichot which is in place of his talk at the cancelled DVB World 2020 event explains DVB’s approach to doing thus that; combining multicast ordination of content with delivery of an ABR feed, called DVB-mABR.

Video broadcast has been digitised since it’s initial broadcasts in the 30s, and more than once. In Europe, we have seen IP carriage (IPTV) services and most recently the hybrid approach where broadband access is merged into transmitted content with the aim of delivering a unified service to the viewer called HbbTV. Multicast ABR (mABR) defines the carriage of Adaptive Bit Rate video formats and protocols over a broadcast/multicast feed. Guillaume explains the mABR architecture and then looks at the deployment possibilities and what the future might hold.

mABR comprises a multicast server at the video headend. This server/transcaster, receives standard ABR feeds and then encapsulates it into multicast before sending. The decoder does the opposite, removing any multicast headers revealing the ABR underneath. It’s not uncommon for mABR to be combined with HTTP unicast allowing the unicast to pick up the less popular channels but for the main services to benefit from multicast.

Guillaume explores these topics plus whether mABR saves bit rate, how it’s deployed and how it can change in the future to keep up with viewers’ requirements.

Watch now on demand!
Speaker

Guillaume Bichot Guillaume Bichot
Principal Engineer, Head of Exploration
Broadpeak

Video: Let’s be hAV1ng you

Posted on by Russell Trafford-Jones

AV1 is now in use for some YouTube feeds, Netflix also can deliver AV1 to Android devices so we are no longer talking about “if AV1 happens” or “when AV1’s finished”. AV1 is here to stay, but in a landscape of 3 new MPEG codecs, VVC, EVC and LCEVC, the question moves to “when is AV1 the right move?”

In this talk from Derek Buitenhuis, we delve behind the scenes of AV1 to see which AV1 terms can be, more-or-less, mapped to which MPEG terms. AV1 is promoted as a royalty-free codec, although notably a patent pool has appeared to try and claim money from users. Because it’s not reusing ideas from other technologies, the names and specific functions of parts of the spec are both not identical to other codecs, but are similar in function.

Derek starts by outlining some of the terms we need to understand before delving in further such as “Temporal Unit” which of course is called a TU and is analogous to a GOP. Then he moves on to highlight the many ways in which previous DCT-style work has been extended meaning the sizes and types of DCT have been increased, and the prediction modes have changed. All of this is possible but increases computation.

Derek then highlights several major tools which have been added. One is the prediction of the Chroma from the Luma signal. Another is the ‘Constrained Direction Enhancement Filter’ which improves the look of diagonal hard edges. The third is ‘switch frames’ which are similar to IDR frames or, as Derek puts it ‘a fancy P-frame.’ There is also a Multi-Symbolic Arithmetic Codec which is a method of guessing a future binary digit which, based on probability, allows you to encode a subset of the number but just enough to ensure that the algorithm will come out with the full number,

After talking about the Loop Restoration Filter Derek then critiques a BBC article which drew, it seems, incorrect conclusions based on not enabling the appropriate functions needed for good compression and also suggesting that there was not enough information provided for anyone else to replicate the experiment. Derek then finishes with MS-SIM plots of different encoders.

Watch now!
Download the slides.
Speaker

Derek Buitenhuis Derek Buitenhuis
Senior Video Encoding Engineer,
Vimeo