Main content

Video Factory: Updating the creation and distribution systems for on demand video

Kiran Patel

Executive Product Manager

Tagged with:

In my last post, I told you about the improvements made by the Media Services team with Video Factory, as we took over all video creation and delivery for iPlayer and other BBC Digital Products. I ended by saying we were not done making things better.

One of our original goals for Video Factory - aside from keeping things working and making it faster and better value for money - was to review and refresh the transcode profiles for the video we create, as well as changing our distribution architecture so we could become more efficient with storage, more flexible when making changes and more resilient by being able to use multiple distribution partners.

With the old workflow, we published video by creating 23 media files, each containing an audio and video component. These were stored and delivered separately. Some distribution protocols relied on special services from third parties. As a result, we were not efficient in storage or workflow and also less resilient.

The video profiles had also grown over the years in a piecemeal way as new devices came out and support was needed. This resulted in a mix that was not optimized for re-use across devices and did not offer the best experience on all devices.

We decided to make big changes.

The new video profiles have been designed from scratch. This meant we had the opportunity to not only improve the quality of the video, but also make the entire set work better together. Different devices get the best video for them, while still reusing assets between devices in the most efficient way.

The Media Services team worked closely with BBC R&D to define 14 video profiles and 5 audio profiles that can be combined to make ABR (Adaptive Bit-Rate) sets for all supported devices, from mobile phones connected over a cellular network, which gets 56Kbit/s stream to ensure video will continue to play even with slow connections, to computers and connected TVs, which will now get up to 5Mbit/s 720p video at 50fps.

The HD stream will also become adaptive set, so HD will play if your connection is fast enough, but the video will reduce quality and continue to play rather than buffering or stop if your connection speeds fluctuate. This way you always get the best quality video that can be played.

BBC R&D will publish more details about the details and design process of the new video and audio profiles in a blog coming soon.

A key to making this work was a switch to chunked HTTP video formats. We already use these for our live streams and with this change all new content will only be available via chunked HTTP distribution. That is HDS (HTTP Dynamic Streaming), to replace the current RTMP for Flash based players, HLS (HTTP Live Streaming) for iOS and other connected devices.

The distribution model was the other thing we changed. This was a much bigger deal. Switching from 23 separate files to a single multi-tracked file. This single file is then reference to create all the media variants we need to support the different combinations of ABR sets and distribution protocol. As a result, we store a single media file and can have over 30 variant combinations derived from it. Each variant will offer tailored ABR set in specific distribution protocol - for example, mobile phones connected on Wi-Fi as HLS, or for desktop computers wanting HD with a Flash player.

Our transcode workflow changed from creating and publishing separate assets, to transcoding all the video and audio components and creating and publishing a single asset also with data about all the variant combinations. This provided new levels of flexibility that means we can create new variants and distribute in new ways, without having to re-transcode media. We can now just add or re-write data about all existing content and it can work in a new way.

The reason we can store a single file and still serve out so many variants from that file is the addition of a dynamic packaging and caching layer. What this means is that content for a specific type of device is created on first request and distributed. Subsequent requests are fulfilled from a cached version, either in our delivery chain, or by the CDNs (Content Delivery Networks) that deliver the video to the audience. More detail on this will follow in a blog post from the Media Distribution team.

One of the big benefits all this work provides is the ability to start distributing content as DASH (Dynamic Adaptive Streaming over HTTP). Collaboration between BBC R&D and Media Services, as well as with our packaging software provider (Unified Streaming) and the engineering teams that build the BBC’s TV and Mobile products and the Media Player team, means we can soon start offering streams as DASH on supported connected TV devices, some mobiles and as an opt-in on desktops via HTML5. More details on DASH will also come in future blogs posts.

We're not finished yet. This phase of work may be coming to an end, but we've created a platform to build on that means we can continue to improve and innovate on the both quality of the video and the ways it can be distributed. We are also working to bring all the video across BBC Digital into the fold, so not just catch-up programmes on iPlayer, but all clips and live events too. Then improvements that Video Factory has made and will continue to make can benefit all video on BBC Digital products.

Tagged with: