[FFmpeg-devel] [PATCH v2 00/11] fix broken CC detection and ffprobe fields (cover letter)

Soft Works softworkz at hotmail.com
Thu Jan 30 07:20:28 EET 2025


> -----Original Message-----
> From: Marth64 <marth64 at proxyid.net>
> Sent: Thursday, January 30, 2025 6:07 AM
> To: Soft Works <softworkz at hotmail.com>
> Cc: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>; Kieran Kunhya <kieran618 at googlemail.com>
> Subject: Re: [FFmpeg-devel] [PATCH v2 00/11] fix broken CC detection
> and ffprobe fields (cover letter)
> 
> > Which kind of recurrence pattern are you talking about?
> I am talking about really sparse pattern. e.g. nothing for a long
> time, then ads inserted or program changes, and embedded bit stream
> starts.
> It's not that often but it happens with SCTE-20, or sloppy DVD edits
> for example.
> 
> >  Even if it was just 98% reliable, those 2% could not serve as
> justification for why probing of the 98% takes twice or thrice the
> time.
> I do agree. Having the "fast but catches most" solution as an option
> would be useful. I had tried to put up 3 proposals and -
> analyze_frames was
> the only one that seemed to stick since it did not break API or make
> things awkward with dispositions.
> 
> For now, -analyze_frames helps to at least make the feature workable
> and has
> a utilitarian purpose for flexible CC probing needs.

For us, this is completely unusable. As mentioned, there are often thousands of files to probe and every few milliseconds matter. Sometimes probing is also done as part of a start playback request, and again it's not acceptable to increase the delay just why some people think that the data must not be shared between one lib and another - while the same people are implementing ways to their liking if they need it themselves.

There are many ways for transferring the that information, some good, some worse, to some extent also depending on point of views - that's all fine and I really don't care which way it should be. Just what's not acceptable IMO is to say: "No, you must not use this data, let ffprobe process the data twice".

So, this has to be worked out in some way. Do you want to submit something or shall I?

Thanks,
sw


More information about the ffmpeg-devel mailing list