CEA-608 and CEA-708 Compared: How Broadcast Captions Travel With the Picture

The two standards at a glance

Both standards started under the Electronic Industries Alliance and later passed to the Consumer Electronics Association, now the Consumer Technology Association, so you will see EIA-608, CEA-608 and CTA-608 used for the same family, and likewise for 708. The core differences:

Era

608: analog NTSC television. 708: digital television, such as ATSC broadcasts

Where the data lives

608: line 21 of the vertical blanking interval. 708: caption data packets inside the encoded video stream

Capacity

608: two bytes per video field, very little room. 708: considerably more bandwidth

Layout

608: a fixed grid of roughly 32 columns by 15 rows. 708: up to eight windows that can be positioned and sized

Characters

608: basic Latin plus a small set of accented and special characters. 708: a broader character set

Appearance

608: a few colours, italics and underline. 708: fonts, sizes, colours, opacity and edges, with viewer overrides on most decoders

Services

608: four caption channels (CC1 to CC4) and text services. 708: many more caption services, with a 608 compatibility stream

Neither is better in the abstract. 608 is crude but universally understood by caption tools; 708 is more capable but its extra features only matter if your authoring and playback chain uses them.

CEA-608: captions from the analog era

In analog NTSC video, a few lines at the top of each frame carried no picture. Line 21 was set aside for caption data, and a decoder in the television turned those bytes into text on screen. Each field could carry just two bytes, so captions had to be compact: a character set built around English with a limited set of extra characters for languages such as Spanish and French, and a grid of about 32 characters per row.

608 offers three display modes that still shape caption conventions today:

• Pop-on: a full caption is built off screen and displayed at once, then cleared. Typical for prerecorded programmes.
• Roll-up: text scrolls up line by line in a window of two to four rows. Typical for live news and sport.
• Paint-on: characters appear one by one in place. Less common.

Field 1 carries CC1 and CC2, field 2 carries CC3 and CC4. A common arrangement puts the main language on CC1 and a second language, often Spanish in the US, on CC3, though broadcasters set their own practice.

CEA-708: captions for digital television

Digital television removed the analog blanking lines, so captions moved into the compressed video stream itself. 708 was designed with that extra room in mind. Instead of one fixed grid, a caption service can define windows anywhere on screen, each with its own size, justification and scroll direction. Text can use different font styles, sizes, colours and background opacity, and most digital decoders let viewers override those choices in their caption settings.

708 also carries a 608 compatibility stream inside the same data, so equipment that only understands 608, or analog outputs from a set-top box, can still show captions. In practice many workflows still author captions to 608 rules and carry them inside 708 data, which means the richer 708 features often go unused. That is a choice made by the broadcaster and its tools, not a limit of the standard.

How captions ride inside the video signal

The key idea for both standards is that the captions are part of the video, not a file beside it. In analog video, the caption bytes were literally in the picture signal. In digital video, 708 data is placed in user-data or SEI messages attached to video frames, so each frame carries the caption bytes due at that moment. Containers such as MPEG transport streams and MXF, and some MP4 and MOV workflows, keep that data with the video.

This has consequences. A caption encoder, hardware or software, has to insert the data while the video is encoded or passed through. Any later step that re-encodes the video may drop the caption data unless the tool is set to preserve it. And the player has to include a 608 or 708 decoder; there is no separate track to toggle in a file browser. Some streaming formats, HLS among them, can carry embedded 608 data in the video so broadcast captions survive into online simulcasts.

Caption files used to author embedded captions

Captions are rarely typed into a video signal directly. They are prepared as files and then encoded:

• SCC (Scenarist Closed Caption) holds 608 caption data as hexadecimal byte pairs with SMPTE timecode. It is a long-standing interchange format for 608 captions.
• MCC (MacCaption) holds caption data packets that can carry both 708 and 608, also against timecode.
• Many caption tools import plain text or SRT and output SCC or MCC, applying the 32-character row limit, the chosen display mode and caption channel.

The wider landscape of subtitle and caption files, including TTML and EBU STL, is covered in the guide to subtitle file formats. When converting from plain subtitles to SCC, expect to re-break lines, because a cue written for a web player can easily exceed the 608 row length.

Why web video uses separate caption files

On the web, the video and its captions are usually separate resources. A browser player loads the video, then loads one or more WebVTT files referenced by track elements; platforms such as YouTube accept uploaded SRT or VTT files. This approach has practical advantages:

• Captions can be corrected or replaced without touching or re-encoding the video.
• Many languages can sit beside one video, each as its own file.
• Text files can use Unicode, so scripts far outside 608's character set work, subject to fonts.
• Appearance is controlled by the player and the viewer's settings rather than by bytes in the stream.
• Search engines, editors and translators can read the captions directly.

The trade-off is that the file and the video can be separated, renamed or mismatched, which embedded captions avoid. Captions that a viewer switches on, whether embedded or sidecar, are closed captions; the distinction from text burned into the picture is explained in open vs closed captions.

Choosing by situation

• Delivering a programme to a US broadcaster or cable network: follow their spec, which commonly asks for 608 and 708 data embedded in the master or an SCC or MCC file.
• Publishing on your own website or a video platform: use WebVTT or SRT sidecar files.
• Delivering to a streaming distributor: read the delivery spec; many ask for TTML-based files such as IMSC, some still accept SCC.
• Archiving broadcast recordings: keep the embedded caption data and extract a text file as well, so the words remain searchable.
• Simulcasting live TV online: embedded 608 or 708 in the stream may be the simplest path, since it is already being generated.

Limits and pitfalls of embedded captions

• Transcoding strips them. Many export presets silently discard 608 and 708 data; check the output with a caption-aware inspector.
• The 608 grid is narrow. Long lines must be re-segmented, and characters outside the set are replaced.
• 708 styling is unevenly rendered. Decoders and viewer overrides mean your chosen fonts and colours may never appear as authored.
• Timecode and frame rate must match. An SCC file timed for 29.97 fps drop-frame against a 25 fps master will drift.
• Platform rules change. Caption requirements for television and for online video that previously aired on TV vary by country and change over time; check the current official source or regulator guidance, and treat this as general information rather than legal advice.

Where mydubly fits: separate files, not embedded captions

mydubly produces separate SRT and VTT files, not embedded broadcast captions. It does not write 608 or 708 data, SCC or MCC files, and the translated video it assembles contains no subtitle track of any kind. Each subtitle file has one numbered, single-line cue per recognized speech segment, in the spoken language or the target language, with no positioning, styling, sound tags or speaker labels.

That makes a mydubly SRT a reasonable starting draft for broadcast captions, not a finished deliverable. To use it for 608-style captions you would review the text, convert it in caption software, re-break lines to the row limit, and add the speaker identification and sound descriptions that broadcast conventions usually expect; the gap between speech-only subtitles and full captions is explained in captions vs subtitles. For accessibility use, captions should always be checked by a person. The subtitle generator page shows what the files contain, and how to add subtitles to a video covers attaching them to web players and platforms.

Next step: read the spec before you author

If you are delivering to television, get the current caption spec from the broadcaster first; it decides between 608, 708, SCC, MCC or embedded data, and between pop-on and roll-up. If you are publishing online, a reviewed WebVTT or SRT file is usually all you need. Either way, start from accurate, reviewed text, because no format fixes wrong words.