Using Opus audio in broadcasting Featured

The OBE C-100 platform is the first broadcast encoder/decoder to support Opus audio. But why are we doing this? This post explains some of the background behind implementing Opus for Broadcast Contribution.

A large proportion of broadcast contribution feeds (feeds delivered from a remote site to a main broadcast facility) are still delivered with MPEG-1 Layer II (MP2) audio. This has served us well since its standardisation in 1993 as a reliable, low-latency codec. However, it requires high bitrates (usually between 256 kbps and 384 kbps), which are unnecessarily high in this day and age. Some manufacturers offer AAC audio as an alternative but this requires royalty payments and purchasing additional encoder/decoder licences, not to mention the complexities between MPEG-2 AAC and MPEG-4 AAC (as well as HE-AACv1 and v2 variants). A decoder mismatch means that audio may play with reduced quality or may not even play at all. There is also a high algorithmic delay for many of the AAC variants making them not suitable for low latency communications:


Frame Size (samples)

Delay at 48kHz (ms)

MPEG-1 Layer 2













960 (20ms frame size)


 Broadcast Contribution Codecs and their total algorithmic delay (MPEG codecs from Ranjani H G and Ameet Kalagi). Note that AAC-LD/ELD is omitted because there appears to be no use in broadcast contribution.

This is where Opus comes in – it’s a low-delay, royalty-free audio codec designed for a wide range of audio applications and is used in Skype, WebRTC and on the Playstation 4. Compared to MP2 audio a similar quality can be reached with Opus at around 96 kbps to 128 kbps with quality staying acceptable even at 32kbps. However, we lacked a method for putting Opus audio in a standard MPEG Transport Stream and so at VideoLAN Dev Days 2013 a group from various companies and open source projects involved in Opus sat down to write a specification. The first stage was to register Opus with the SMPTE Registration Authority, so that Opus audio could unambiguously be identified in a transport stream. Existing contribution networks are DVB-based and so it was important that none of the added Service-Information (SI) required for Opus conflicted with existing standards. Therefore, the user-defined extensions in DVB-SI were selected as a basis for the specification: https://wiki.xiph.org/OpusTS. Recently, syncwords were added to the Opus in TS specification to allow fast recovery during TS packet loss.

Delivering Opus to the Home

Opus can also be used for sending signals to the home, though currently the bitstream lacks various features which are important for some use-cases. The most important is frame accurate channel map switching, allowing the number of audio channels to change during a broadcast, for example changing from 5.1 to stereo when moving from a film to advertising. There’s also a lack of metadata for features such as downmixing coefficients, which allows viewers watching on stereo equipment to hear a stereo downmix of a 5.1 broadcast. However, the current specification reserves plenty of space for these future additions. Processors on modern set-top-boxes are more than powerful enough to decode Opus so it’s unlikely that dedicated hardware is needed.

The OBE C-100 platform is the first broadcast encoder to support Opus audio and we hope that many more will join us. Patches exist for the Opus-in-TS draft specification for FFmpeg/Libav, VLC and will be making its way into the next version of OBE Community Edition.

As a test the first transmission was encoded with a development version of OBE and sent over the public internet (more on that another day) to the author’s home:


 Thanks to all those involved, notably Tim Terriberry from Xiph/Mozilla and Rafaël Carré from VideoLAN.

Last modified on Thursday, 28 August 2014 17:37