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

[Anton Khirnov <anton@khirnov.net>]

Quoting Paul B Mahol (2023-12-21 12:53:58)
> On Thu, Dec 7, 2023 at 6:26 PM Paul B Mahol <onemda@gmail.com> wrote:
> 
> >
> >
> > On Wed, Dec 6, 2023 at 2:38 PM Nicolas George <george@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.
> >
> 
> I found out if I increase queue size of thread for frames/packets in
> fftools/ from 1 to >1 it increases speed in decoding by 10%.
> Looks like other numbers greater than 2 do not make much any difference.
> 
> Still current state is sub-optimal.

It most likely is, but I expect the optimal value would depend on the
specific configuration. More testing welcome.

-- 
Anton Khirnov
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".