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

From: Nicolas George <george@nsup.org>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 13/13 v3] fftools/ffmpeg: convert to a threaded architecture
Date: Wed, 6 Dec 2023 13:55:53 +0100
Message-ID: <ZXBvWQiV3p2LztDL@phare.normalesup.org> (raw)
In-Reply-To: <170170963341.8914.15256032845632094107@lain.khirnov.net>

Anton Khirnov (12023-12-04):
> Which of these are you saying is correct?

I do not know? Do you think I am able to reverse MD5 mentally? I am
flattered, but I am sorry to confess I am not.

Why do you not look at the resulting videos to judge for yourself? But
to do that, you will need to remember (or learn two things):

First, most people do not have that many CPU threads available, and if
they do they will spend them on encoding more than decoding.

Second, and most important: for subtitles, in many many cases, a few
frames of shift do not matter because the timing in the source material
is not that accurate.

So the answer to your question is: probably most of the ones generated
with a sane number of threads are correct, in the sense that the result
is within the acceptable accuracy of subtitles sync and useful for the
user.

Of course, if the use case is one where perfect accuracy is necessary,
users need to revert to a slower and more bulky procedure (like you
suggested: open the file twice, which might require storing it entirely)
to get it.

So really, what you pretend is not breaking anything is really removing
one of the options currently available to users in the compromise
between speed, latency and accuracy.

So I demand you stop pretending you are not breaking anything, stop
pretending it is currently broken, just so you can move forward without
bothering to search for a solution: that starts to feels like laziness
and it always felt like rudeness because I spend a lot of effort in
getting this to work in the cases where it can.

> The only bug that's been established to exist so far is in your
> heartbeat code, which produces random output as per above.

As I explained many times, this is not a bug.

> Buffering is by itself not a bug, otherwise you'd have to say the lavf
> interleaving queue is a bug.

Once again, buffering thousands of frames and crashing because out of
memory when the current code succeeds and produces an useful result is a
regression and the patch series cannot be applied until that regression
is fixed.

> So for the last time - either suggest a specific and practical way of
> reducing memory consumption or stop interfering with my work.

The specific and practical way is to let the current logic in place.
There might be a few tweaks to make it more accurate, like looking into
this comment:

    /* subtitles seem to be usually muxed ahead of other streams;
       if not, subtracting a larger time here is necessary */
    pts2 = av_rescale_q(pts, tb, ifp->time_base) - 1;

But first, we need you to stop behaving as if my previous efforts did
not mater just because it does not overlap with your narrow use cases.

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