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

[Anton Khirnov]

Quoting Nicolas George (2023-12-04 16:25:52)
> Anton Khirnov (12023-12-01):
> > I can definitely say it is broken and I already told you why. But if you
> > want something more specific:
> > * the output of your example with the current master changes depending
> >   on the number of decoder frame threads; my patch fixes that
> > * in fate-filter-overlay-dvdsub-2397 subtitles appear two frames too
> >   early; again, my patch fixes that
> 
> Ok, some cases are broken. Fine, this is a hard task, some cases are
> impossible. That does not allow you to break cases that are currently
> working.

Nothing is being broken. Your highly contrived and currently broken
testcase buffers a bounded number of extra frames in order to stop being
broken. If that extra buffering is an actual problem for someone, it can
be easily avoided by opening the file twice.

> > IIUC your suggestion was to send heartbeat packets from demuxer to
> > decoder, then have the decoder forward them to filtergraph.
> > 
> > That is EXACTLY what I'm doing in the final patch, see [1]. It also does
> > not address this problem at all, because it is caused by the heartbeat
> > processing code making decisions based on
> > av_buffersrc_get_nb_failed_requests(), which fundamentally depends on
> > what frames previously arrived on the video input.
> 
> Then fix it. I have given you a command that currently works and
> produces valid output:

As I said before, your command does NOT work. Its output changes
unpredictably depending on unrelated parameters.

> make sure it still works with your changes.

After my changes it actually does work reliably.

I maintain that your demand to "fix" your testcase (i.e. reduce its
memory consumption) is highly unreasonable – unless you specify how
exactly that is supposed to be accomplished while preserving
determinism.

-- 
Anton Khirnov