Βι¶ΉΤΌΕΔ 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.
![](https://ichef.bbci.co.uk/images/ic/400xn/p0fd61qv.png)
Introducing the Internet Engineering Task Force
The Internet Engineering Task Force () 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: , and more recently 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.
Βι¶ΉΤΌΕΔ 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, which is particularly important to Βι¶ΉΤΌΕΔ 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 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 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 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 , or ) 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 Βι¶ΉΤΌΕΔ R&D based on a simplification of the older , 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 Βι¶ΉΤΌΕΔ 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.
An addition to the SMPTE ST 2110 standards family, , 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!
- -
- Βι¶ΉΤΌΕΔ R&D - Cloud-Fit Production
- Βι¶ΉΤΌΕΔ R&D - High Speed Networking: Open Sourcing our Kernel Bypass Work
- Βι¶ΉΤΌΕΔ R&D - Beyond Streams and Files - Storing Frames in the Cloud
- Βι¶ΉΤΌΕΔ R&D - IP Studio
- Βι¶ΉΤΌΕΔ R&D - IP Studio: Lightweight Live
- Βι¶ΉΤΌΕΔ R&D - IP Studio: 2017 in Review - 2016 in Review
- Βι¶ΉΤΌΕΔ R&D - IP Studio Update: Partners and Video Production in the Cloud
- Βι¶ΉΤΌΕΔ R&D - Running an IP Studio
- Βι¶ΉΤΌΕΔ R&D - Building a Live Television Video Mixing Application for the Browser
- Βι¶ΉΤΌΕΔ R&D - Industry Workshop on Professional Networked Media
- Βι¶ΉΤΌΕΔ R&D - IP Studio at the UK Network Operators Forum
- Βι¶ΉΤΌΕΔ R&D - Industry Workshop on Professional Networked Media
-
Automated Production and Media Management section
This project is part of the Automated Production and Media Management section