Re: [FFmpeg-devel] [PATCH] lavc: Replace 181 magic number with ITU_T_T35_COUNTRY_CODE_US

["Tomas Härdin" <git@haerdin.se>]

tis 2025-03-04 klockan 10:13 -0500 skrev Devin Heitmueller:
> On Tue, Mar 4, 2025 at 4:02 AM Tomas Härdin <git@haerdin.se> wrote:
> 
> > > Even if the captions are intended to
> > > serve other countries, the country code will stay the same (defining
> > > the country code for individual languages goes in the PMT).
> > 
> > How is one supposed to mux multiple subtitle languages in MPEGTS +
> > H.264 anyway? This isn't clear at all from what I've read. Country
> > codes, as opposed to language codes, being used in the 708 SEI makes it
> > worse. And what of other container formats that have no PMT?
> 
> So unlike with DVB/teletext, the caption data streams are not provided
> on separate ES streams.

Just an aside: I've had potential clients ask about decoding teletext
from the video essence itself, for stuffing into MXF's VBI thing. Here
in Sweden subtitles are still done with teletext. I wouldn't be
surprised if some broadcasters use both teletext and 708

> They are embedded in the video stream, and
> the CEA-708 standard supports multiple languages within that payload
> (depending on specifically which form is used, it can be up to six or
> up to 64).  The actual languages assigned to the different streams
> within the 708 payload are specified either in the PMT via the "ATSC
> Caption" descriptor, or in the ATSC PSIP data.

Great, than I know where to look next (:

> Muxing together captions from different sources is pretty painful,
> since you have to parse/decompose the 708 stream and recombine streams
> from different sources (and then update the PMT).  I have code which
> does it but haven't made any effort to open source it, and I'm not
> confident it could easily be done within ffmpeg due to limitations in
> the ffmpeg framework.

It is indeed painful. With the client I'm doing this with we use
libcaption to do this, outside of FFmpeg, precisely because FFmpeg's
"model" is wholly unsuited for stuffing subs into encoded video essence
streams. But even libcaption is rather lackluster, and does not support
setting the channel index of each 608 stream. Not hard to modify
libcaption to gain this feature, but still

> It's also worth noting that the Caption descriptor as defined in the
> standard does not let you specify the language of individual CTA-608
> channels within a 708 stream (which is what most people care about).
> The only way to specify the language for the 608 channels (e.g.
> CC1-CC4) is via XDS bytes within the 608 stream, which almost nobody
> does nowadays.  I ran a scan across my network of thousands of
> channels from different commercial hardware encoders, and couldn't
> find a single one that specified the 608 language in XDS (if I found
> cases where it was, I was prepared to submit patches to VLC to show
> the language in the subtitle dropdown menu).

So everyone just uses a single CC channel (or pair) within each 608
stream? I'd probably do that too tbh, if I were already doing 708. From
what I remember of 608 it's meant to be bilingual at most, carrying
English and Spanish subs for the North-, Middle- and South American
market.

/Tomas
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".