Research & Development

Posted by James Weaver, Alex Rawcliffe on

BBC R&D has been working with the Internet Engineering Task Force (IETF) to develop the technology standards needed for network-based production systems. This complements our existing work within the AMWA and SMPTE communities.

Introducing the Internet Engineering Task Force

The Internet Engineering Task Force (IETF) is one of the leading Internet standards bodies. It's an open community of people (including manufacturers, operators and researchers) who are focused on improving the technologies that power the Internet. If you can think of an Internet acronym, the IETF has probably had a hand in it: HTTP, DNS and more recently IPv6 are all particularly notable examples.

Internet standards matter because they agree a shared approach for a particular technology so that software and equipment from any manufacturer can interoperate. For example, the IETF HTTP standards helped to ensure you could use any browser to retrieve this web page.

IETF standards are created through a staged process which allows them to be refined and peer-reviewed:

  • The journey starts with a working document called an 'Internet Draft', which is simply a proposal written by a contributor for consideration by the IETF community.
  • Over time Internet Drafts are refined based on community feedback and may eventually be promoted to the IETF standards track, at which point they receive a new name: 'Request For Comments' (RFC) and a serial number. RFCs progress through several levels of maturity, beginning with Proposed Standard and ending with Internet Standard.

BBC R&D and RFC 8450

So why are we telling you this?

In the last few weeks the IETF has published a new proposed standard, RFC 8450: RTP Payload Format for VC-2 High Quality (HQ) Profile, which is particularly important to BBC R&D because we (James Weaver, Project R&D Engineer) wrote it, and it relates to several areas of research that have been ongoing here for a number of years now.

To give a little context: for some years now we have been working on a new approch to tranporting professional video for production purposes over IP networks, initially in our labs as part of the IP Studio project, and more recently with industry as part of the AMWA NMOS series of specifications.

This approach involves sending media as "mono-essence Flows" (i.e. single data streams each containing a single type of data such as audio or video ) over IP networks (such as the Internet) using standard transport mechanisms. The standard mechanism used for transporting audio and video streams in realtime across a network is a protocol called Realtime Transport Protocol which was standardised by the IETF in 2003.

RTP is the underlying protocol which enables a wide variety of different audio-visual stream transports, including SMPTE ST 2110 which has started to see a lot of traction in the professional video industry recently.

RTP is a flexible standard which can transport almost anything, but in order to transport a particular format of data a supplementary "payload format" is needed. RTP payload formats exist for a variety of common video and audio formats (such as Uncompressed Video, or H.264) but when new types of payload are developed, a new payload format document is needed to make them useable with RTP.

VC-2 Video Compression

VC-2 is an SMPTE standardised video compression format which was originally developed by BBC R&D based on a simplification of the older Dirac Codec, which uses a mathematical technique called the Discrete Wavelet Transform.

VC-2 is a low complexity codec: it doesn't reduce the size of video data as much as something like H.264, but instead it is designed to be implementable with extremely fast operations in hardware or software, conceivably reducing the time taken to encode or decode each frame of video to far less than the equivalent for more complex codecs.

This means it's well suited to use-cases which call for low-latency video streams, but where limited bandwidth is not the main concern. Many media production systems fit this requirement.

You can read more about BBC R&D's historical work on the VC-2 codec in our blog post from 2015.

As part of this activity, we've produced a number of tools for working with VC-2, which are available on Github:

VC-2 over RTP?

And so, since we have a video standard which is well suited to use in production networks and have long been advocating for the use of RTP to transport video in production networks, it made sense to write a new payload format for RTP which would allow VC-2 to be transported this way. RFC 8450 is that payload format.

In addition to writing the RFC, we've produced a Wireshark plugin which assists with analysis of RFC 8450 streams. It's available on Github:


An addition to the SMPTE ST 2110 standards family, ST 2110-22, is currently being developed which will allow 2110 to carry compressed media, using payload formats like RFC 8450. That's the final piece of the puzzle!

Tweet This - Share on Facebook

BBC R&D - Cloud-Fit Production

BBC R&D - High Speed Networking: Open Sourcing our Kernel Bypass Work

BBC R&D - Beyond Streams and Files - Storing Frames in the Cloud

BBC R&D - IP Studio

BBC R&D - IP Studio: Lightweight Live

BBC R&D - IP Studio: 2017 in Review - 2016 in Review

BBC R&D - IP Studio Update: Partners and Video Production in the Cloud

IBC 365 - Production and post prepare for next phase of cloud-fit technology

BBC R&D - Running an IP Studio

BBC R&D - Building a Live Television Video Mixing Application for the Browser

AMWA - Advanced Media Workflow Association

BBC R&D - Industry Workshop on Professional Networked Media

NMOS - Networked Media Open Specifications

BBC R&D - IP Studio at the UK Network Operators Forum

BBC R&D - Industry Workshop on Professional Networked Media

This post is part of the Automated Production and Media Management section