Skip to content

Closed captions of a broadcast channel

A broadcast channel almost always carries closed captions — they travel inside the picture itself, in per-frame side data, rather than as a separate track. A TV set plugged into cable or an antenna shows them. A subscriber watching the same channel in your app does not.

Catena decodes those captions and serves them as a separate WebVTT track that every OTT player understands. Nothing has to be added to the channel: the text comes from the very signal you already receive.

Why a provider needs it

  • Captions stop getting lost on the way to the subscriber. The broadcaster delivered them, your player failed to show them — and the complaint lands on you, not on the broadcaster.
  • Accessibility requirements. In the US, the CVAA requires captions to be preserved when broadcast material is distributed online; in Europe the European Accessibility Act asks for the same. The practical meaning is one and the same: if the captions were in the broadcast version, they must be in the app too.
  • Multiple languages for free. Broadcasters often put two or three language services into a single channel (English and Spanish in the US). Each becomes its own subtitle menu entry — with no second input and no manual work.
  • One input, every output. Decode once on ingest, deliver to the browser, to the app and to the TV set alike.

Which devices need the conversion

Embedded captions are readable by far from everything your subscribers watch on:

  • The browser — the most common failure. Web players (hls.js, dash.js, Shaka) push the picture through Media Source Extensions and do not parse embedded captions: CEA-708 is not read at all, CEA-608 partially at best. Without the conversion your web player and personal cabinet are left with no subtitles.
  • DASH delivery — regardless of the device. Embedded captions can formally be announced in DASH, but players do not look for them; only a separate track works.
  • Android apps and Smart TVs — hit and miss. The native Tizen and webOS players usually understand CEA-608 and stumble on CEA-708; ExoPlayer-based apps read 608 and not always 708, and read nothing at all in DASH.
  • Set-top boxes and in-house web players — almost never: parsing embedded captions would have to be written by hand.
  • WebRTC and low-latency outputs — embedded captions simply do not travel there.

Only a few handle them natively: Safari and iOS for HLS, Apple TV, Roku. That is why "the subtitles are there on my iPhone" says nothing about the rest of the device fleet.

How to enable it

Open the stream, the Basic settings tab, the Closed captions section. Catena lists the services that actually speak in the stream (CC1…CC4 for CEA-608, SERVICE1…SERVICE63 for CEA-708) and lets you pick the delivery mode:

  • Inside the video (default) — delivered exactly as received. Captions are announced as embedded, there is no separate track.
  • A subtitle track instead — captions are delivered as a WebVTT track and cut out of the video. The player shows exactly one menu entry.
  • Inside the video and as a track — both at once. Take it if the same channel also reaches subscribers over MPEG-TS.

The same section sets the language and the name of a service — they become the caption of the player's menu entry. Without them the caption is derived from the stream, and when no language is announced, from the service address.

The «track instead» mode and MPEG-TS

In this mode captions are cut out of the video on every output, MPEG-TS included: udp/rtp/srt push and .ts segments. A text track has nothing to travel in inside MPEG-TS, so a consumer of such an output is left with no subtitles at all. If the channel is pulled over MPEG-TS, choose "inside the video and as a track".

What the subscriber sees

The player gets an ordinary subtitle menu: one entry per speaking service, with its language and name. The text follows the speech and sits where it sat on air — lines at the bottom, not across people's faces.

Subtitles work in the archive as well: they are recorded regardless of the selected mode. That is why the mode can be switched on retroactively — subtitles will show up for already recorded programmes too.

If there are no subtitles

  1. The «Closed captions» section is empty. Then they are not visible in the stream. Make sure you are looking at a running stream: services are detected from the air, not from the configuration.
  2. A service is listed but there is no track in the player. Check the mode: in "inside the video" there is no track by definition.
  3. There is a track but no text. That is normal while the air is silent: empty subtitle windows are a valid state. If the text is missing during speech as well, send a fragment of the stream to support.
  4. Subtitles disappeared for some subscribers after switching to «a subtitle track instead». Those are almost certainly MPEG-TS consumers — go back to "inside the video and as a track".