> From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > Kieran Kunhya via ffmpeg-devel > Sent: Monday, January 27, 2025 10:40 AM > > While this is a very valid concern for some kinds of frame side > data, it > > does not apply to CC data. It's either in every frame or none. If a > > provider generally broadcasts CC, then it's always present in every > frame, > > even during programs for which no CC is available - it's always > there. Like > > I mentioned at the top, we're using the properties field from the > codec > > (via codec_par) and there hasn’t been a single case reported where > the CC > > detection this way would have been incorrect. > > > > This isn't true, CC data is sparse. > I have no opinions about the rest of the text. > > Kieran
Hi Kieran, I found it 😊 It's in EIA-708-A from 1999 as well as in the latest successor spec ANSI/CTA-708-E S-2023 from chapter 4.1 (1999): "for DTV and DTVCC specific (Le., ATSC A/53) caption encoding, the DTV Closed-Captioning channel is a continuous 9600 bps stream allocated from the DTV signal capacity" (the latest version adds more variations) and chapter 4.2 (1999): "Pre-Allocated Bandwidth" "The DTVCC Transport Channel is a fixed, pre-allocated stream which exists in all DTV-system bit streams, even though captions may not be present. This ever-present bandwidth (which includes NTSC and DTVCC caption data) allows encoders to easily insert caption data into the DTV bit-stream at the point of origin and at multiple down-stream encoding points without having to perform complex picture data processing and bandwidth reallocation" Maybe you just mixed it up with DVB subtitles which are actually sparse? sw _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
