Re: [FFmpeg-devel] [PATCH 02/13] fftools/ffmpeg_filter: make sub2video heartbeat more robust

[Anton Khirnov <anton@khirnov.net>]

Quoting Nicolas George (2023-11-27 10:40:18)
> Anton Khirnov (12023-11-23):
> > Avoid making decisions based on current graph input state, which makes
> > the output dependent on the order in which the frames from different
> > inputs are interleaved.
> > 
> > Makes the output of fate-filter-overlay-dvdsub-2397 more correct - the
> > subtitle appears two frames later, which is closer to its PTS as stored
> > in the file.
> > ---
> >  fftools/ffmpeg_filter.c                   | 3 +--
> >  tests/ref/fate/filter-overlay-dvdsub-2397 | 4 ++--
> >  tests/ref/fate/sub2video                  | 8 +++++---
> >  3 files changed, 8 insertions(+), 7 deletions(-)
> 
> Just as I warned you, it breaks the test case I suggested:
> 
> ./ffmpeg_g -xerror -i /tmp/dummy_with_sub.mkv -preset ultrafast -lavfi '[0:s]setpts=PTS+60/TB[s] ; [0:v][s]overlay' -y /tmp/dummy_with_hardsub.mkv
> 
> (/tmp/dummy_with_sub.mkv is created like I told a few days ago)
> thousands of frame queued, eventually failing on OOM.

You're offsetting two streams from the same file by 60 seconds, so you
should expect about 60s of buffering - that is 1500 frames at 25fps.
The maximum amount of frames I see buffered is 1602, which roughly
corresponds to the expected number.

So I don't think this demonstrates there actually is a problem.
Also note that the output timestamps look better after the patch than
before.

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