Video: Cloud Services for Media and Entertainment: Production and Post-Production

Posted on by Russell Trafford-Jones

My content producers and broadcasters have been forced into the cloud. Some have chosen remote controlling their on-prem kit but many have found that the cloud has brought them benefits beyond simply keeping their existing workflows working during the pandemic.

This video from SMPTE’s New York section looks at how people moved production to the cloud and how they intend to keep it there. The first talk from WarnerMedia’s Greg Anderson discussing the engineering skills needed to be up to the task concluding that there are more areas of knowledge in play than one engineer can bring to the table from the foundational elements such as security, virtulisation nad networking, to DevOps skills like continuous integration and development (CI/CD), Active Directory and databases.

The good news is that whichever of the 3 levels of engineer that Greg introduces, from beginner to expert, the entry points are pretty easy to access to start your journey and upskilling. Within the company, Greg says that leaders can help accelerate the transition to cloud by allowing teams a development/PoC account which provides a ‘modest’ allowance each month for experimentation, learning and prooving ideas. Not only does that give engineers good exposure to cloud skills, but it gives managers experience in modelling, monitoring and analysing costs.

Greg finishes by talking through their work with implementing a cloud workflow for HBO MAX which is currently on a private cloud and on the way to being in the public cloud. The current system provides for 300 concurrent users doing Edit, Design, Engineering and QC workflows with asset management and ingest. They are looking to the public cloud to consolidate real estate and standardise the tech stack amongst many other drivers outlined by Greg.

Scott Bounds Architect at Microsoft Azure talks about content creation in the cloud. The objectives for Azure is to allow worldwide collaboration, speed up the time to market, allow scaling of content creation and bring improvements in security, reliability and access of data.

This starts for many by using hybrid workflows rather than a full switch to the cloud. After all, Scott says that rough cut editing, motion graphics and VFX are all fairly easy to implement in the cloud whereas colour grading, online and finishing are still best for most companies if they stay on-prem. Scott talks about implementing workstations in the cloud allowing GPU-powered workstations to be used using the remote KVM technology PCoIP to connect in. This type of workflow can be automated using Azure scripting and Terraform.

John Whitehead is part of the New York Times’ Multimedia Infrastructure Engineering team which have recently moved their live production to the cloud. Much of the output of the NYT is live events programming such as covering press conferences. John introduces their internet-centric microservices architecture which was already being worked on before the pandemic started.

The standard workflow was to have a stream coming into MCR which would then get routed to an Elemental encoder for sending into the cloud and distributed with Fastly. To be production-friendly they had created some simple-to-use web frontends for routing. For full-time remote production, John explains they wanted to improve their production quality by adding a vision mixer, graphics and closed captions. John details the solution they chose which comprised cloud-first solutions rather than running windows in the cloud.

The NYT was pushed into the cloud by Covid, but it was felt to be low risk and something they were considering doing anyway. The pandemic forced them to consider that perhaps the technologies they were waiting for had already arrived and ended up saving on Capex and received immediate returns on their investment.

Finishing up the presentations is Anshul Kapoor from Google Cloud who presents market analysis on the current state of cloud adoption and the market conditions. He says that one manifestation of the current crisis is that new live-events content is reduced if not postponed which is making people look to their archives. Some people have not yet done their archiving process, whilst some already have a digital archive. Google and other cloud providers can offer vast scale in order to process and manage archives but also machine learning in order to process, make sense and make searchable all the content.

The video ends with an extensive Q&A with the presenters.

Watch now!
Speakers

Greg Anderson Greg Anderson
Senior Systems Engineer,
WarnerMedia
Scott Bounds Scott Bounds
Media Cloud Architect,
Microsoft
John Whitehead John Whitehead
Senior Engineer, Multimedia Infrastructure Engineering,
New York Times
Anshul Kapoor Anshul Kapoor
Business Development,
Google Cloud

Video: The Future of Online Video

Posted on by Russell Trafford-Jones

There are few people who should build their own CDN, contends Steve Miller-Jones from Limelight Networks. If you want to send a parcel, you use a parcel delivery service. So if you want to stream video, use a content delivery network tuned for video. This video looks at the benefits of using CDNs.

John Porterfield welcomes Steve to YouTube channel JP’sChalkTalks and starting with a basic outline of CDNs. Steve explains that the aim of the CDN is to re-deliver the same content as many times as possible by itself without having to go back to a central store, or even back to the publisher to get the video chunk that’s been requested. If your player is a few seconds behind someone else’s who lives in the same geography, then the CDN should be able to deliver you those same chunks almost instantly from somewhere geographically close to you.

Steve explains that in the Limelight State of Online Video 2020 Annual Report rebuffering remains the main frustration with streaming services and, remaining at approx 44% for the last 3 years when taken as a global average. Contrary to popular belief, the older generation is more tolerant of rebuffering than younger viewers.

As well as maintaining a steady feed, low-latency is remaining important. Limelight is able to deliver CMAF down to around a 3-second latency or WebRTC with sub-second latency. To go along with this sub-second video streaming, Limelight also offer sub-second data sharing between players which Steve explains is a important feature allowing services to develop interactivity, quizzes, community engagement and many other business cases.

Lastly Steve outlines the importance of Edge computing as a future growth area for CDNs. The first iteration of cloud computing was a success by taking computing into central locations and away from individual businesses. This worked well for many for financial reasons, because it freed organisations up from managing some aspects of their own infrastructure and enabled scaling of services. However, the logic of what happened next was always done in this one central place. If you’re in Australia and the cloud location is in the EU, then that’s a long wait until you get the result of the decision that needs to be made. Edge computing allows small parts of logic to live in the closest part of a CDN to you. This could well mean that the majority of a service’s infrastructure is in the US, but some of the CDN be it CloudFront, Limelight or another will be in Australia itself meaning pushing as much of your services as you can to the edge will result in significant improvements in speed/latency reduction.

Watch now!
Speakers

Steve Miller-Jones Steve Miller-Jones
VP Strategy & Industry,
Limelight Networks
John Porterfield John Porterfield
Technology Evangelist,
JP’sChalkTalks YouTube Channel

Video: Providing better video experiences for the next billion users

Posted on by Russell Trafford-Jones

What’s the best way for a billion people all on mobile networks to have a universally great streaming experience? It’s not trivial, and no service is perfect, but Facebook set out to find out what problems existed and find ways to fix them. This video explains their approach and solutions.

Denise Noyes from Facebook spoke at Demuxed 2020 about their work in India over the year. For Facebook, India is unique for this research as it represents such a large number of people almost universally using Android phones and mobile data. Not only does this allow them to understand the low-bitrate performance of video, but the Android penetration level simplifies comparisons.

The problems that Denise and her colleagues identified were gaps in the bitrate ladders where the ABR ladder either wasn’t well optimised or didn’t go low enough. There were also some ABR logic/decisions that were seen to be causing problems along with server delays from the CDN and internal congestion within the app. The research looked at ‘average bad sessions per user’ rather than the overall number of bad sessions which would be skewed by how many videos people generally watched.

Covid had a bearing on the research as this was being conducted by in-person interviews within India. These teams had to come home but the relevance of the research was acutely highlighted by the networks in other countries which worsened in response to the rising amount of traffic making them closer to the Indian example.

Denise’s team worked with colleagues throughout the company to create improvements across the whole network and delivery stack. On the encoding front, they decreased the lowest encoding level to 100kbps. This doesn’t look amazing, as seen by the metric score, but it’s better than buffering and can be watchable dependent on content. The GOP size was also increased from 2 seconds to 5. Longer GOP sizes are known to deliver improved bitrate, in this case up to 8%, but there is a tradeoff to pay in latency and how frequently you can move up/down the ABR ladder. Facebook found that the tradeoffs were worth the improvement for the viewers.

Denise introduces FB-MOS, Facebook’s objective model of the MOS objective metric. The lower the number, the worse the video looks. Facebook have used the fact that encoding resolution ‘A’ at, say, 400kbps and 200kbps can look better than encoding resolution ‘A’ at 400kbps and using a lower resolution ‘B’ for the 200kbps encode. This has lead to the ABR having 360p at two bitrates and 480p at two bitrates.

That FB-MOS score comes in handy for avoiding the lowest rungs of the ABR ladder. As their MOS score is quite low, the player will only choose it if it really has no choice otherwise, it will prefer to settle on a higher quality version if it isn’t able to go up the ladder. Ironically, they have also implemented logic to limit who gets the highest bandwidth streams since most users would prefer to spend less on data than get that disproportionately low improvement in quality.

In playback, Denise explains that they have reduced the impact of occasional anomalies on the bandwidth estimation and adjusted prefetching to prefetch the first chunk of all videos it would like to prefetch before getting the next chunk. This has reduced the chance that someone is able to choose a video which hasn’t yet been buffered and hence have to wait for it to start.

Lastly Denise covers the work done at the network layer seeing a move from HTTP/2 to QUIC. We see how the removal of head-of-line blocking has helped and that, not only has this the move to QUIC seen an overall improvement in performance but as congestion increased, QUIC traffic has shown a disproportionate improvement.

Denise concludes highlighting that this work across the network stack with wide collaboration has not only delivered the desired results but is a vital approach for any company looking to make marked improvements in customer experience.

Watch now!
Speaker

Denise Noyes Denise Noyes
Software Developer,
Facebook

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