mån 2025-03-10 klockan 09:57 -0400 skrev Devin Heitmueller: > On Mon, Mar 10, 2025 at 5:57 AM Tomas Härdin <g...@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 _______________________________________________ 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".
