Broadcast Subtitle Formats Explained: SCC, EBU-STL, and Graphics STL

The subtitle formats most people know — SRT, VTT, ASS — are consumer formats. They exist for media players, web browsers, and video-sharing platforms. None of them get on air.

Broadcast television uses a different set of formats, built for different constraints: frame-accurate SMPTE timing, regulatory compliance, binary encoding, and in some cases, pixel-level rendering control. These formats are SCC, EBU-STL, and Graphics STL.

Understanding them matters if you work anywhere in the chain between post-production and transmission.

SCC: North American Broadcast Standard

SCC (Scenarist Closed Captions) is the standard closed caption format for North American broadcast television. It encodes CEA-608 caption data — the same data that rides on line 21 of the analog video signal and in the digital VANC (Vertical Ancillary Data Space) of HD-SDI.

What SCC actually contains

An SCC file is a text file containing SMPTE timecodes paired with hexadecimal caption command words:

Scenarist_SCC V1.0

01:00:00:00 9420 9420 94ad 94ad 9470 9470 4c69 7665
01:00:02:15 9420 9420 94ad 94ad 9473 9473 6672 6f6d

Each hex pair is a CEA-608 command or character pair. The format encodes not just text but also positioning commands, style changes (italics, underline), channel selection, and display control (roll-up, pop-on, paint-on).

Key characteristics

When SCC is required

SCC is required — not optional — for any content that airs on US broadcast, cable, or satellite television. The FCC mandates closed captioning under 47 CFR 79.1, and SCC/CEA-608 is the encoding format that delivers it. If you are preparing content for North American broadcast delivery, you will produce SCC files.

The 32-character line limit is a hard constraint inherited from the CEA-608 character cell grid. Caption authors must write within this limit, which affects line breaking, abbreviation choices, and overall subtitle pacing.

EBU-STL: European Broadcast Standard

EBU-STL (European Broadcasting Union Subtitle Transfer Language) is the subtitle exchange format standardized by the EBU in Tech 3264. It is a binary format used across European television for subtitle delivery and playout.

What EBU-STL actually contains

An EBU-STL file has two sections:

1. General Subtitle Information (GSI) block — A 1024-byte header containing metadata: program title, translator name, country of origin, timecode format, character encoding table, and display parameters.
2. Subtitle Text Information (TTI) blocks — Each subtitle is a 128-byte binary record containing subtitle group/number, timecodes (in/out), cumulative status, and the text content encoded per the GSI character table.

The binary structure means EBU-STL files are not human-readable. You cannot open one in a text editor and make corrections the way you can with SRT.

Key characteristics

When EBU-STL is required

EBU-STL is the delivery format for terrestrial and satellite television across Europe. Broadcasters in the UK, Germany, France, Scandinavia, and across the continent accept or mandate EBU-STL for subtitle ingest. The format's teletext compatibility means it can drive both digital subtitle rendering and legacy teletext page insertion.

The GSI metadata block is often scrutinized by broadcast QC systems. Incorrect country codes, character encoding table selections, or timecode format declarations will cause rejection even if the subtitle text itself is correct.

Graphics STL: Image-Based Subtitle Rendering

Graphics STL is fundamentally different from text-based subtitle formats. Instead of delivering text that a player or broadcast system renders, Graphics STL delivers pre-rendered images — one per subtitle event — along with a manifest that specifies timing and file references.

What a Graphics STL bundle contains

A typical Graphics STL delivery is a directory (or ZIP archive) containing:

1. STL manifest — A text file listing timecode in/out pairs and image filenames
2. SST manifest — A Scenarist-format manifest with Color/Contrast directives and display parameters
3. Image files — One TIF or PNG per subtitle event, rendered at the target resolution

The STL manifest looks like this:

//##############################################################
// Script for Graphics STL
//--------------------------------------------------------------
// Video Standard: HD 16:9
// Timecode:       30fps DROP
//##############################################################
$SetFilePathToken   =   <<Graphics>>
$ColorIndex1    =   2
$ColorIndex2    =   0
$ColorIndex3    =   4
$ColorIndex4    =   0
$TextContrast   =   15
$Outline1Contrast   =   15
$Outline2Contrast   =   15
$BackgroundContrast =   0
01:00:05:12 ,   01:00:08:03 ,   <<Graphics>>Subtitles0000.tif
01:00:09:00 ,   01:00:12:15 ,   <<Graphics>>Subtitles0001.tif

Each image file is a palette-indexed bitmap — typically 4 colors: background, outline, anti-alias, and text body. The Scenarist Color/Contrast directives in the SST manifest tell the authoring system how to map these palette indices to on-screen colors and transparency levels.

Key characteristics

When Graphics STL is required

Graphics STL is used when text rendering cannot be left to the playback device. This includes:

• DVD authoring — DVD subtitle streams use bitmap overlays (VOBSUB), and Graphics STL is the standard Scenarist input
• Blu-ray authoring — PGS (Presentation Graphics Stream) subtitles are bitmaps
• Broadcast graphics — When the subtitle must render identically on every receiver regardless of font availability
• Regulatory scenarios — Some territories require pre-rendered subtitles for approval before broadcast

Why Browser-Based Tools Historically Could Not Handle These

Web-based subtitle tools have traditionally been limited to text formats (SRT, VTT, ASS) for three reasons:

1. Binary encoding. EBU-STL and SCC require generating or parsing binary data and hex-encoded command sequences. JavaScript historically had weak binary data handling, though ArrayBuffer, DataView, and Uint8Array have closed this gap.
2. Frame-accurate timing. Broadcast formats use SMPTE timecodes, not milliseconds. A tool that internally stores time as milliseconds cannot generate correct SMPTE timecodes for 29.97fps content without accumulating drift. This is a fundamental architecture problem, not a missing feature.
3. Image generation. Graphics STL requires rendering text to images — palette-indexed TIFF files with specific bit depth, resolution, and color conventions. This requires either a Canvas API pipeline (for browser) or an image processing library (for server-side).

How timecode.dev Handles All Three

The subtitle tool supports SCC and EBU-STL as both input and output formats, and Graphics STL as an output-only format. The architecture that makes this possible:

Frame-number-canonical timing. Every subtitle entry is stored as a SubtitleEntry with startFrame and endFrame — integer frame numbers, not milliseconds. When exporting to SCC or EBU-STL, SMPTE timecodes are derived directly from frame numbers via the timecodes engine. There is no millisecond intermediate. This eliminates the timing drift that disqualifies most web-based tools from broadcast work.

Binary encoding in the browser. EBU-STL's GSI and TTI blocks are assembled using ArrayBuffer and DataView, producing spec-compliant binary files. SCC's hex command encoding is generated from the text content and positioning data.

Canvas-based image rendering for Graphics STL. Each subtitle entry is rendered to an HTML Canvas element, then converted to a palette-indexed TIFF — 8-bit uncompressed, 72 DPI, with the standard 4-color Scenarist palette (background/outline/anti-alias/text). Both STL and SST manifests are generated automatically. The entire bundle is packaged as a ZIP archive.

All of this runs client-side. No subtitle data leaves the browser. No server-side rendering infrastructure is required.

Choosing Between Broadcast Formats

If you are delivering to a broadcaster, they will tell you which format they require. There is no ambiguity — each broadcaster's delivery spec names the format, timecode mode, and QC requirements explicitly.

If you are preparing assets for disc authoring, Graphics STL with TIF output is the standard Scenarist input. The subtitle tool generates Scenarist-compatible bundles with both STL and SST manifests, ready for import.

For converting between broadcast and consumer formats — for example, generating an SRT for web delivery from an SCC broadcast master — the frame-number-canonical architecture ensures timing integrity across the conversion. The SCC's SMPTE timecodes resolve to frame numbers, and the SRT's millisecond timestamps are derived from those same frame numbers. No drift accumulates.

Explore the full set of supported formats and conversions at the subtitle converter.