Skip to content

4.6.0 — In-band CEA-608 closed captions

Choose a tag to compare

@superuser404notfound superuser404notfound released this 27 Jun 05:26

In-band CEA-608 closed captions (#77)

A source whose only caption track is an embedded CEA-608 stream (eia_608, e.g. a QuickTime/MP4 c608 track) previously could not render. FFmpegBuild ships no ccaption decoder, so the side-demuxer EmbeddedSubtitleDecoder open failed and the track sat active-but-blank (subActive=true / subCues=0), selectable but producing no cues for the whole title. Such tracks now render.

How it works

The captions are decoded in-house and rendered through the existing host-overlay subtitle path, with no second demuxer, no second connection, and no change to any existing pipeline.

  • ClosedCaptionTap attaches a read-only observer to the segment producer's source demuxer (the connection the engine already reads). The producer keeps the eia_608 caption stream in its keep-set, hands each of its packets to the tap, then drops it (never muxed), so the loopback-HLS segment output is byte-for-byte identical to the no-CC path.
  • CCDataParser turns the bare cc_data triplet stream into (cc_valid|cc_type, b0, b1) triplets.
  • CEA608Decoder is an in-house line-21 state machine (pop-on, roll-up, paint-on, PAC row addressing, mid-row codes, and the basic / special / extended West-European character sets). Odd-parity validation, doubled-control suppression, and the character / PAC tables are validated against FFmpeg's ccaption_dec.c and covered by unit tests.

Because the tap owns the cue buffer and is re-threaded onto every producer (initial and restart), enabling CC mirrors the buffer instantly (no second demuxer open, no seek, no prewarm) and seeks / reloads / producer re-anchors re-feed it automatically. Cues publish on the same subtitleCues host-overlay path as every other side-decoded codec.

Scope and limitations

  • 608 field-1 / channel CC1 only. CEA-708 (DTVCC packet reassembly) and field 2 / channels CC2 to CC4 ride the same tap and are decode-side follow-ons.
  • Host-overlay rendering only (no native tx3g, so no PiP / AirPlay CC), the same limitation as the existing bitmap subtitle path.
  • Handles the demuxable caption track (eia_608 / c608). Captions carried only in the video bitstream SEI with no separate track are out of scope here.

The mov_text native rendition (#55) is untouched: CC is excluded from that path and rendered on the overlay like the bitmap codecs.

Credits

Implemented by @reckloon (PR #81). Externalise-subtitles direction by @DrHurt.

Full Changelog: 4.5.7...4.6.0