Broadcast subtitle formats: TTML, EBU-TT-D, IMSC1, STL and SCC

You choose a format by destination

Three worlds coexist. Linear broadcasting, with its playout systems, master control rooms and teletext, relies on old, compact formats. Distribution over IP, via DASH, HLS or HbbTV, uses XML profiles derived from TTML. The web and post-production, finally, often make do with SRT and WebVTT.

In every case, the rule that prevails is the recipient's delivery specification: it sets the format, but also the exact profile, frame rate, character set and styling constraints. The table below gives the landmarks; the delivery specification decides.

TTML and the EBU-TT family

TTML (Timed Text Markup Language) is the W3C's XML format for timed text, published in 2010 and extended by TTML2 in 2018. It is still sometimes called DFXP, the name of its first profile. TTML is very rich: positioning, styles, regions, metadata. That richness is also its weakness, since two players can render the same file differently. Hence profiles, which freeze a subset of it.

The European Broadcasting Union (EBU) has defined two. EBU-TT Part 1 (EBU Tech 3350) is used for production, exchange and archiving. EBU-TT-D (EBU Tech 3380, published in 2015) is the lightweight profile for distribution to the public over IP. It is the format the DVB-DASH standard (ETSI TS 103 285) mandates for subtitles, and the one HbbTV 2.0 TV sets must be able to play.

IMSC1, the streaming profile

IMSC1 (TTML Profiles for Internet Media Subtitles and Captions) is the TTML profile standardised by the W3C in 2016 for online video, in two variants: text and image. It constrains positioning, typography and colours so that rendering does not depend on the player. The CMAF format (ISO/IEC 23000-19) adopts it for subtitle tracks, and Apple has supported it in HLS since 2017. Versions 1.1 and 1.2 followed.

IMSC1 and EBU-TT-D are close: version 1.0.1 of EBU-TT-D even adopted two IMSC features to improve compatibility. But every platform publishes its own requirements. Netflix, for example, asks for TTML1 and currently accepts IMSC 1.1 for Japanese only. Hence the importance of reading the delivery specification rather than assuming.

EBU STL, the broadcasters' legacy format

EBU STL (EBU Tech 3264, 1991) belongs to the other world: binary files, teletext and playout. An STL file starts with a General Subtitle Information block (GSI, 1,024 bytes: programme, language, character set, frame rate), followed by one 128-byte TTI block per subtitle, holding the in and out timecodes, the position and 112 bytes of text.

Its fixed-length fields limit styling, but STL remains very common in exchanges between broadcasters, subtitling houses and playout systems. The mapping between STL and EBU-TT is itself standardised (EBU Tech 3360), which eases migrations.

SCC, the North American case

SCC (Scenarist Closed Caption) carries CEA-608 captions, the closed captioning standard inherited from line 21 of the North American analogue signal. It does not encode readable text but hexadecimal byte pairs, the commands meant for the TV set's decoder, grouped into lines that each start with an SMPTE timecode at 29.97 frames per second. Unreadable outside its ecosystem, it remains unavoidable whenever a delivery targets a US or Canadian broadcaster.

Conversion pitfalls

Moving from one format to another is common, and that is where errors creep in:

• Frame rate. STL and SCC count in frames, TTML and its profiles often in media time. A European programme at 25 frames per second delivered as SCC requires every timecode to be recalculated at 29.97.
• Character set. STL declares its character table in the GSI block: get the table wrong and accented characters turn into symbols.
• Styling. Going from a rich format to a poor one, positions and colours are lost. The reverse does not create them: an SRT file converted to TTML remains unstyled.
• Colours in subtitles for the deaf and hard of hearing. In France, the quality charter drawn up by the CSA (now Arcom) in 2011 encodes information by colour: white for a visible speaker, yellow off screen, red for sound cues, magenta for music, cyan for thoughts or voice-over, green for a foreign language. Only formats that carry colour, such as TTML profiles or STL, preserve it.
• Line length. Teletext limits a line to 40 characters: a subtitle designed for the web may need to be re-segmented.
• The exact profile. A valid TTML file is not necessarily a valid EBU-TT-D or IMSC1 file: validate it against the profile requested.

What OnAirText does

OnAirText transcribes your TV and radio streams live and produces subtitles directly in the expected format, from the same stream and with no intermediate conversion step: EBU-TT-D, TTML, IMSC1, STL and SCC for professional broadcasting, SRT and WebVTT for the web and editing. Professional broadcast formats are available from the Pro plan.

Frequently asked questions

What is the difference between EBU-TT and EBU-TT-D?

EBU-TT Part 1 (EBU Tech 3350) is a rich format designed for production, exchange between professionals and archiving. EBU-TT-D (EBU Tech 3380) is a lightweight subset of it, intended for distributing subtitles to the public over IP, notably via DVB-DASH and HbbTV.

Is an IMSC1 file accepted where EBU-TT-D is requested?

Not automatically. The two TTML profiles are close and a simple document can satisfy both, but each has its own constraints. Validate the file against the exact profile the recipient requires.

Can an STL file be converted to TTML?

Yes. The mapping between STL and EBU-TT is described in the EBU Tech 3360 specification. The points to watch are the character set declared in the GSI block and the timecode frame rate.

Which format for subtitles for the deaf and hard of hearing in France?

Arcom's quality charter sets rules for readability, placement and colours, not a file format. The format depends on the broadcaster's delivery specification; it simply has to be able to carry colours, which TTML profiles and STL do, and SRT does not.