Â鶹ԼÅÄ

Background

Broadcasters first experimented with subtitles in the 60s as a service to improve the accessibility of programmes. Special editions of programmes with burnt-in subtitles were broadcast late at night. While welcomed, the late-night timing wasn't ideal. Broadcasters needed a method of providing subtitles on any program without impacting those who didn't want or need them.

The Â鶹ԼÅÄ introduced Teletext in 1974, long before the world wide web existed. Ceefax, the Â鶹ԼÅÄ’s Teletext service, transmitted pages of text providing news, sport, travel and weather information, quizzes, and tv listings. In 1979, it was used to broadcast the first optional subtitles which could be laid over television programmes. Ceefax remained in use for terrestrial TV until 2012 when it was replaced as part of the UK’s switch to digital video broadcasting (DVB).

The transition away from Teletext to more modern technologies has been a mixed picture. DVB transmits subtitles as images meaning it isn’t limited by the Teletext character set. Hybrid broadcast broadband TV (HbbTV) can also provide subtitles using the XML-based Timed Text Markup Language (TTML). TTML can carry metadata alongside subtitles and richer formatting. Â鶹ԼÅÄ iPlayer has used TTML since 2007. But Sky still uses Teletext for delivery of subtitles to viewers, and live production workflows at the Â鶹ԼÅÄ and other broadcasters still use the Teletext-based OP-47 format.

Beyond the world of subtitles, broadcasters have started using IP technologies as part of their production processes. The family of standards and are replacing the specialist SDI cabling and data format. SDI bundles audio, video, and data together in one data stream whereas SMPTE 2110 allows these to be separated out for flexibility and to make more efficient use of infrastructure. However, while formats exist in 2110 for transmitting compressed and uncompressed video and audio, and for signals to switch tally lights in studios on/off, there is no specification for how subtitles should be carried natively in 2110 systems. Without a specialist format to do this, subtitles must use a fall-back mechanism. In IP workflows, we currently use Teletext wrapped in OP-47 wrapped in the SDI ancillary data format wrapped in the ... This complicated fall-back is fine as a way to quickly get a system working that can carry subtitles, but it's only a stop-gap.

A New Format

Our work to replace our live subtitling workflow is part of a long-running industry effort to modernise subtitles. In 2003, the was formed with the goal of creating an XML-based subtitling format. and, more recently, - a flexible format that draws heavily on the formatting capabilities of HTML and CSS. Also, TTML is not just designed to transport subtitles. It can carry metadata about the people/characters speaking, describe animated overlays like news tickers, and reference audio description content.

TTML has already started to make its way into our workflows:

• As mentioned earlier, Â鶹ԼÅÄ iPlayer has used an early variant of TTML since 2007. Today, we use .
• Our subtitling partners now deliver EBU-TT subtitle files alongside the legacy STL format for pre-recorded content.
• With the Digital Production Partnership, we've produced the X5 and X6 formats for media exchange. These use for subtitles.
• MPEG CMAF also uses IMSC for online distribution and SMPTE IMF for files in the mastering process.
• has been created for live contribution with using WebSockets. This is primarily intended for streaming subtitles from live subtitlers and from playout system to distribution encoder(s).

To transport live subtitles within the broadcast facility, we wanted a method of carrying TTML alongside SMPTE 2110 media. We decided to create an RTP payload format so that we could make use of existing software for managing and monitoring other types of media. That's where RFC 8759 - RTP Payload for Timed Text Markup Language (TTML) - comes in. It allows us to move beyond the stop-gap of Teletext over RFC 8331. RFC 8759 is a modern format that unlocks the enhanced flexibility offered by IP-based transport.

Where Next?

Creating this standard is only one step towards completely replacing Teletext and the stop-gap approach mentioned earlier. This RTP payload format is very permissive by design. It allows for the use of any TTML profile, both broadcast specific or relevant to a completely different field. For manufacturers to produce interoperable equipment and software that makes use of it, a standard for broadcasters is required. That's why we intend to work with SMPTE (Society of Motion Picture and Television Engineers) to create a specification that references and restricts RFC 8759 to television production use cases. We can then work with manufacturers and developers to introduce these standards into their products. Once our production chains have transitioned to TTML, we can move beyond the restrictions of the 1970s that are still embedded in our subtitles.

And Finally...

Interpreting standards can take time. To help developers get started quickly, we've also released . This makes use of we have open-sourced for encoding and decoding the RTP bit-streams in the Python programming language. These libraries are minimal at the moment, so we invite the community to submit pull requests to expand and improve them.

Additionally, we have created for examining/debugging TTML RTP streams. All are available on GitHub. how they have added support for RFC 8759 to their .