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

Tomas Härdin git at haerdin.se
Mon Mar 31 18:24:09 EEST 2025


mån 2025-03-10 klockan 09:57 -0400 skrev Devin Heitmueller:
> On Mon, Mar 10, 2025 at 5:57 AM Tomas Härdin <git at haerdin.se> wrote:
> 
> > > 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
> 
> Yeah, I didn't have a particularly positive experience with
> libcaption, despite the fact that I know it's what a number of
> projects use (including OBS).  Everytime I look at that code I spot a
> whole pile of things they are doing wrong.  Probably the most obvious
> is that they don't properly do rate control for the 608/708 tuples to
> embed in the stream, so the resulting stream won't work properly with
> many decoders/transcoders.  This was actually one reason I wrote the
> vf_ccrepack filter in ffmpeg, to deal with cases where somebody used
> libcaption to embed CC into a TS.  The ccrepack filter puts the
> caption tuples into.a queue and then re-embeds them at the appropriate
> rate given the target framerate.

Did you report this to libcaption's devs?

/Tomas


More information about the ffmpeg-devel mailing list