[FFmpeg-devel] [PATCH 13/13 v3] fftools/ffmpeg: convert to a threaded architecture

[Paul B Mahol]

On Wed, Dec 6, 2023 at 2:38 PM Nicolas George <george at nsup.org> wrote:

> James Almer (12023-12-06):
> > I honestly can't believe you're arguing this.
>
> Yet I do, so I suggest you think a little harder to understand why I do.
>
> > And being condescending will not help your case.
>
> Can you tell that to Anton too please?
>
> > If i request -bitexact, i want bitexact output, regardless of running on
> a
> > core i3 or a Threadripper. There's nothing more to it.
>
> I had not noticed the -bitexact on the test command line. I will grant
> the change is acceptable if bit-exact is requested.
>
> > Calling random output that happens to be "acceptable" within the
> subjective
> > expectations of the user as useful sounds to me like you're trying to
> find
> > an excuse to keep buggy code with unpredictable results around, just
> because
> > it's been there for a long time.
>
> Well, you are wrong, and what I explained is the real reason: most
> subtitles are not timed that accurately. The subtitles on HBO's Last
> Week Tonight, for example, can randomly lag or be early by several
> seconds. Even serious subtitles, like the ones for scripted shows on
> Netflix/Amazon/Crunchyroll/whatever vary by a few tenths of seconds,
> i.e. several frames.
>
> And I have used this code. And I look carefully at subtitles. If the
> result was lower quality than the source material, I would have noticed
> and I would have endeavored to fix it. There never was need.
>
> Now, can Anton claim similar experience working with subtitles from the
> real world? Most of this discussions points to the answer being no.
>
> > So, like Anton has asked several times, suggest a way to keep
> deterministic
> > and bitexact output without exponentially increasing memory consumption
> due
> > to buffering.
>
> I will spend time and effort searching for a solution when we agree to
> work together.
>
> “Do this or I will break your code” is an unacceptable behavior, whether
> it is directed at me or at Paul or at anybody else, and I do not spend
> effort when unacceptable behavior is tolerated.
>
>
>From 3.4 version of ffmpeg to 6.1 version demuxing  truehd (-c:a copy)
files dropped by factor of 2x speed.
But simple transcode from doc/examples is still several times faster than
that.

I bet using mutexes and condition variables is far from perfect solution or
fftools/ code is buggy.

This is similar to -lavfi sources dropouts in performance but more used by
users of truehd/any small packets format.


> --
>   Nicolas George
> _______________________________________________
> 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".
>