On Fri, Feb 7, 2025 at 2:52 PM Devlist Archive <devl...@rlb.org> wrote: > > > > > Unfortunately, there's no bug which could be "fixed". > > For a proper solution, a CEA-608 ENcoder is required. > > And more - like already said. > > > Is a CEA-608 encoder actually required for a frame rate change, or is it > possible to just redistribute the packets of the 608 stream in a manner > that does not involve loss or reordering of data? Part of the problem is > that each of the encoders need to not reorder captions packets or properly > handle things when frame reordering happens during the encode. The > behaviour of ffmpeg is to include captions tracks that contain corruption, > so I would say that there is a bug even if the solution requires a CEA-608 > encoder because the functionality is presented in a broken manner.
And encoder itself should be required. The ccfifo/ccrepack stuff in principle does what is needed, but it's implemented as a video filter, embedded into various modules in the raw domain that work on AVFrames, and it's in the decklink output. We would need to have a BSF which operates on subtitle AVPackets, and it's likely the video framerate would have to be explicitly specified (unless we're able to determine it in the MP4 muxer and automatically instantiate the BSF with the correct parameters). Devin -- Devin Heitmueller, Senior Software Engineer LTN Global Communications o: +1 (301) 363-1001 w: https://ltnglobal.com e: devin.heitmuel...@ltnglobal.com _______________________________________________ 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".
