[FFmpeg-devel] Captions SCC

[Devlist Archive]

>
> 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.

On Fri, Feb 7, 2025 at 11:44 AM Soft Works <
softworkz-at-hotmail.com at ffmpeg.org> wrote:

>
>
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> > Devlist Archive
> > Sent: Friday, February 7, 2025 8:31 PM
> > To: FFmpeg development discussions and patches <ffmpeg-
> > devel at ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] Captions SCC
> >
> > >
> > > The cc_fifo mechanism is actually implemented within the various
> > > filters which change the framerate (deinterlacing, framerate
> > > conversion, interlacing), so no extra command line arguments are
> > > required.  There are some edge cases though that don't properly
> > handle
> > > it, and those mainly relate to cases such as the captions crossing
> > > back/forth between SEI and dedicated caption tracks (e.g. MP4 with
> > a
> > > caption track, the subcc output, etc).
> > >
> >
> > Ok, based on this information I am going to make a bug report ticket
> > for
> > the particular type of mp4 files I am using because while some
> > caption data
> > is passed, it is garbled and the transcoding process is producing
> > errors.
> > I was not aware that some work had been done to try to solve the
> > frame rate
> > conversion issue already as the behaviour of ffmpeg implies that it
> > doesn't
> > try to compensate for those changes for the file types I am working
> > with.
> > There are also bugs in the subcc function that seem to be affecting
> > display
> > time and other metadata.
> >
> > I assume that it would be more efficient and better to fix the
> > existing 608
> > only data path before trying to expand things to include 708?
> >
> > Zach
>
>
> Unfortunately, there's no bug which could be "fixed".
> For a proper solution, a CEA-608 ENcoder is required.
> And more - like already said.
>
> sw
>
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>