The pandemic has shone a light on CDNs as they are the backbone of much of what we do with video for streaming and broadcast. CDNs aim to scale up in a fast, sophisticated way so you don’t have to put in the research to achieve this yourself. This panel from the Content Delivery Summit sees Dom Robinson bringing together Jim Hall from Fastly with Akamai’s Peter Chave, Ted Middleton from Amazon and Paul Tweedy from BBC Design + Engineering.
The panel discusses the fact that although much video conferencing traffic being WebRTC isn’t supported, there are a lot of API calls that are handled by the CDN. In fact, over 300 trillion API calls were made to Amazon last year. Zoom and other solutions do have an HLS streaming option that has been used and can benefit from CDN scaling. Dom asks whether people’s expectations have changed during the pandemic and then we hear from Paul as he talks a little about the BBC’s response to Covid.
THE CTA’s Common Media Client Data standard, also known as CTA 5004, is a way for a video player to pass info back to the CDN. In fact, this is so powerful that it can provide highly granular real-time reports for customers but also enables hints to be handed back from the players so the CDNs can pre-fetch content that is likely to be needed. Furthermore, having a standard for logging will be great for customers who are multi-CDN and need a way to match logs and analyse their system in its entirety. This work is also being extended, under a separate specification to be able to look upstream in a CDN workflow to understand the status of other systems like edge servers.
The panel touches on custom-made analytics, low latency streaming such as Apples LL-HLS and why it’s not yet been adopted, current attempts in the wild to bring HLS latency down, Edge computing and piracy.
Whenever there’s a step change in technology, we need early adopters and moving to SMPTE’s ST 2110 is no exception. Not only do early adopters help show that the path ahead is good, but they often do a lot to beat down the bushes and make the path easier to pass for all that follow. For larger companies whose tech refresh or building move comes at a time when the industry is facing a major technology change, there comes a time when whilst the ground may not be firm ahead, the company can’t justify investing in technology that would soon be out of date or in technology which won’t support the needs of the company in several years’ time. This is just the situation that BBC Cymru Wales found themselves in when it was time to move out of their old property into a purpose-built national HQ in the heart of Cardiff.
In this video from the IP Showcase, Mark Patrick and Dan Ashcroft guide us through ‘whys’ and the ‘hows’ of the relocation project. It’s important to remember that this project was long in the making with the decision on location taking place in 2014 with the technology decisions taking place in 2016 and 2017. The project took an open approach to the IP/SDI question and asked for RFP responses to include a fully-SDI and a fully-IP option. It was clear during the selection process that IP was the way to go not because the solution was cheaper in the short term, but because it was much more future-proof and the costs would come down over time giving a much better total cost of ownership. Don’t forget that the initial costs of HD video equipment were much higher than those now. For more on the pros and cons of SDI, watch ‘Is IP really better than SDI?‘ by Ed Calverly.
Mark and Dan talk through the thinking for the IP choice and their decision to pick a vendor who would be their partner in the project. The theory being that given the standards were still very young, it would be important to work closely to ensure success. In addition to Grass Valley equipment, they chose a Cisco network with Cisco SDN control and operational control by BNCS. The talk references architectures we’ve featured on The Broadcast Knowledge before with Arista’s Gerard Phillips discussing the dual-network spine-leaf architecture chosen and noting the difficulty they had incorporating the Dante network into the 2110 infrastructure and their choice of a third network purely for control traffic.
We often hear about the importance of PTP in a SMPTE ST 2110 network for live production because it is vital to keep all the essences in sync. For more information about the basics of ST 2110 check out this talk by Wes Simpson. PTP is both simple and complex so Mark explains how they’ve approached distributing PTP ensuring that the separate networks, amber and blue, can share PTP grandmasters for resilience.
Has UHD been slow to roll out? Not so, we hear in this talk which explains the work to date in standardising, testing and broadcasting in UHD by the BBC and associated organisations such as the EBU.
Simon Thompson from BBC R&D points out that HD took decades to translate from an IBC demo to an on-air service, whereas UHD channels surfaced only two years after the first IBC demonstration of UHD video. UHD has had a number of updates from the initial resolution focused definition which created UHD-1, 2160p lines high and UHD-2 which is often called 8K. Later, HDR with Wide Colour Gamut (WCG) was added which allowed the image to much better replicate the brightnesses the eye is used to and almost all of the naturally-occurring colours; it turns out that HD TV (using REC.709 colour) can not reproduce many colours commonly seen at football matches.
In fact, the design brief for HDR UHD was specifically to keep images looking natural which would allow better control over the artistic effect. In terms of HDR, the aim was to have a greater range than the human eye for any one adpation state. The human eye can see an incredible range of brightnesses, but it does this by adapting to different brightness levels – for instance by changing the pupil size. When in a fixed state the eye can only access a subset of sensitivity without further adapting. The aim of HDR is to have the eye in one adaptation state due to the ambient brightness, then allow the TV to show any brightness the eye can then hold.
Simon explains the two HDR formats: Dolby’s PQ widely adopted by the film industry and the Hybrid Log-Gamma format which is usually favoured by broadcasters who show live programming. PQ, we hear from Simon, covers the whole range of the human visual system meaning that any PQ stream has the capability to describe images from 1 to 10,000 Nits. In order to make this work properly, the mix needs to know the average brightness level of the video which will not be available until the end of the recording. It also requires sending metadata and is dependent on the ambient light levels in the room.
Hybrid Log-Gamma, by contrast, works on the fly. It doesn’t attempt to send the whole range of human eye and no metadata needed. This lends itself well to delivering HDR for live productions. To learn more about the details of PQ and HLG, check out this video.
Simon outlines the extensive testing and productions done in UHD and looks at the workflows possible. The trick has been finding the best way to produce both an SDR and an HDR production at the same time. The latest version that Simon highlights had all the 70 cameras being racked in HDR by people looking at the SDR down-mix version. The aim here is to ensure that the SDR version looks perfect, as it still serves over 90% of the viewership. However, the aim is to move to a 100% HDR production with SDR being derived off the back of that without any active monitoring. The video ends with a look to the challenges yet to be overcome in UHD and HDR production.
With European CDN spend estimated to reach $7bn by 2023, an increase in $1.2 in only three years, it’s clear there is no relenting in the march towards IP. In fact, that’s a guiding principle of the BBC’s transmission strategy as we hear from this panel which brings together three broadcasters, beIN, Globo and the BBC to discuss how they’re using CDNs at the moment and their priorities for the future.
Carlos Octavio introduces Globo’s massive scale of programming for Brazil and Latin America. Producing 26,000 hours of content annually, they aim to differentiate themselves as much with the technology of their offerings as with the content. This thirst for differentiation drives their CDN strategy. Brazil is a massive country, so covering the footprint is hard. Octavio explains that they have created their own CDN to support Globo Play which is based on 4 tiers from their two super PoPs in Rio and Sao Paolo down to edge caches. Octavio shows that they are able to achieve the same response times as the major CDN companies in the region. For overflow capacity, Globo uses a multi-CDN approach.
Bhavesh Patel talks about the sports and news output of beIN, both of these being bursty in nature. Whilst traffic for sporting events can forecast, with news this is often not possible. This, plus the wide variability of customers’ home bandwidth are drivers in choosing which CDNs to partner with. Over the next twelve months, Bhavesh explains, beIN’s focus will move to bring down latency on their system as a whole, not on a service by service level. They are also expecting to continue to modify their ABR ladders to follow viewers as they continue their shift from second screens to 60 inch TVs.
The BBC’s approach to distribution is explained by Paul Tweedy. Whilst the BBC is still well known as a linear, public broadcaster, it has been using online distribution for 25 years and continues to innovate in that space. Two important aspects to their strategy are being on as many devices as practical and ensuring the quality of the online experience meets or is comparable to the linear services. The BBC has been using multiple CDNs for many years now. What changes is the balance and what they use CDNs for. They cover a lot of sports, explains Paul, which leads to short-term scaling difficulties, but long term scaling difficulties are equally on his mind due to what the BBC calls the ‘glide path to IP’. This is the acknowledgement that, at some point, it won’t be financially viable to run transmitters and IP will be the wise way to use the licence fee on which the BBC depends. Doing this, clearly, will demand IP delivery of many times what is currently being used. Yesterday’s article on multicast ABR is one way in which this may be mitigated and fits into a multi-CDN strategy.
Looking at today’s streaming services, Paul and his colleagues aim to get analytics from every player on every device wherever possible. Big data techniques are used to understand these logs along with server-side, client-to-edge and edge-to-origin logs. This information along with sports schedules can lead to capacity planning, though many news events are much less easy to plan. It’s these unplanned, high-peak events which drive the BBC’s build up of internal monitoring tools to help them understand what is working well under load and what’s starting to feel the strain so they can take action to ensure quality is maintained even through these times of intense interest. The BBC manage their capacity with their own CDN, called BIDI, which provides for the baseline needs and allows an easier-to-forecast budget. Mulitple, third-party CDNs are, then, the key to providing the variable and peak capacities needed.
As we head into the Q&A Limelight’s Steve Miller-Jones outlines the company’s strengths including their focus on adding abilities on top of a ‘typical’ CDN. For instance, running applications on the CDN which is particularly useful as part of edge compute and their ability to run WebRTC at scale which not many CDNs are built to do. The Q&A sees the broadcasters outlining what they particularly look out for in a CDN and how they leverage AI. Globo anticipate using AI to help them predict traffic demand, beIN see it providing automated highlights whilst the BBC see it enabling easier access to their deep archives.
Head of Architecture and Analytics,
Global Digital Director,
beIN MEDIA GROUP
Lead Architect, Online Technology Group,
BBC Design + Engineering
Vice President of Product Strategy,
Subscribe to get daily updates
Views and opinions expressed on this website are those of the author(s) and do not necessarily reflect those of SMPTE or SMPTE Members.
This website is presented for informational purposes only. Any reference to specific companies, products or services does not represent promotion, recommendation, or endorsement by SMPTE