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

[Paul B Mahol]

On Thu, Dec 7, 2023 at 6:26 PM Paul B Mahol <onemda at gmail.com> wrote:

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

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.