> -----Original Message-----
> From: Marth64 <mart...@proxyid.net>
> Sent: Thursday, January 30, 2025 6:07 AM
> To: Soft Works <softwo...@hotmail.com>
> Cc: FFmpeg development discussions and patches <ffmpeg-
> de...@ffmpeg.org>; Kieran Kunhya <kieran...@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
_______________________________________________
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".

Reply via email to