Skip to content

Subtitles and teletext

A broadcast signal carries text in two forms: European teletext (subtitles on a page, usually 888) and American CEA-608/708 captions inside the video stream. A headend has two different questions about them: do they survive to the output and is a separate track needed.

Both live on the Processing tab of the stream card.

Transit is the default

By default the station does nothing to the text: the teletext PID and the captions inside the video leave the output exactly as they arrived. In the form that reads as:

  • Teletext — Pass through inside MPEG-TS (no subtitle track);
  • Captions, output mode — Inside the video (passthrough).

For delivery to a network that is the right behaviour: a receiver and a TV set decode the text themselves, and any interference would be an extra cost and an extra risk. The transit survives remuxing and repacking into another transport.

When extraction is needed

Extraction is needed when what stands behind the station is not a receiver but a player: no OTT player decodes teletext. If an OTT copy leaves the station, subtitles will reach the viewer only as a text track.

  • Teletext — Extract subtitle pages as tracks: each subtitle page becomes a WebVTT track. Inside the MPEG-TS the teletext keeps travelling: extraction adds a track, it does not take one away.
  • Captions — three modes: Inside the video (passthrough), As a track instead of embedded (extract) and Both inside the video and as a track (both).

Multiple languages come for free: broadcasters often put one subtitle page per language, and each becomes a separate track with no second input and no manual work.

The extract mode cuts captions out of the MPEG-TS

In the As a track instead of embedded mode the captions are cut out of the video on every output, MPEG-TS included: pushes over UDP, RTP and SRT, TS segments and HTTP output. A text track has no way to travel inside MPEG-TS, so a transport stream consumer is left with no subtitles at all. If the signal is taken over MPEG-TS — and on a headend that is the usual case — choose both.

Teletext extraction costs low latency

A subtitle cue is only known when it closes: until the page changes, the duration of the line is undecided. So a stream with a text track is served as ordinary segments, without LL-HLS parts. For delivery to a network that changes nothing, but it lengthens the edge of the OTT copy by a few seconds — one more reason not to enable extraction where the signal only passes through the station.

What is visible per stream

Under the selector the panel lists the teletext pages found in the stream. Two independent things are known about each, and they must not be confused:

  • announced — the broadcaster declared the page in the service tables, with its language and purpose;
  • on air — the page actually arrived in the stream.

Hence the states you will see next to a page: announced but never seen (the broadcaster is silent), on air but not announced (the broadcaster forgot to update the tables — such pages are extracted on equal terms), or both at once.

The language is shown together with its provenance, because they are not equally trustworthy: announced in the PMT is a fact, inherited from the track is a reasonable guess from a single-language track.

The list is filled in from the air and is meaningful only on a running stream.

The archive

Captions are decoded and written into the archive in every mode, so the output mode can be changed later — the subtitles will show up on already recorded archive as well. Extracted teletext tracks land in the archive together with the video.

What next