[FFmpeg-devel] [FFmpeg-cvslog] fftools/ffmpeg: always use the same path for setting InputStream.[next_]dts

[Anton Khirnov]

Quoting Michael Niedermayer (2023-05-04 14:12:58)
> On Tue, May 02, 2023 at 09:31:35AM +0000, Anton Khirnov wrote:
> > ffmpeg | branch: master | Anton Khirnov <anton at khirnov.net> | Wed Apr 26 10:51:38 2023 +0200| [129c7bf53fbe2be4f5483ecf6fc036ff9caf05cf] | committer: Anton Khirnov
> > 
> > fftools/ffmpeg: always use the same path for setting InputStream.[next_]dts
> > 
> > Currently those are set in different ways depending on whether the
> > stream is decoded or not, using some values from the decoder if it is.
> > This is wrong, because there may be arbitrary amount of delay between
> > input packets and output frames (depending e.g. on the thread count when
> > frame threading is used).
> > 
> > Always use the path that was previously used only for streamcopy. This
> > should not cause any issues, because these values are now used only for
> > streamcopy and discontinuity handling.
> > 
> > This change will allow to decouple discontinuity processing from
> > decoding and move it to ffmpeg_demux. It also makes the code simpler.
> > 
> > Changes output in fate-cover-art-aiff-id3v2-remux and
> > fate-cover-art-mp3-id3v2-remux, where attached pictures are now written
> > in the correct order. This happens because InputStream.dts is no longer
> > reset to AV_NOPTS_VALUE after decoding, so streamcopy actually sees
> > valid dts values.
> > 
> > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=129c7bf53fbe2be4f5483ecf6fc036ff9caf05cf
> > ---
> > 
> >  fftools/ffmpeg.c                          | 34 +++++--------------------------
> >  tests/ref/fate/cover-art-aiff-id3v2-remux | 34 +++++++++++++++----------------
> >  tests/ref/fate/cover-art-mp3-id3v2-remux  | 22 ++++++++++----------
> >  3 files changed, 33 insertions(+), 57 deletions(-)
> 
> Causes assertion failures
> 
> Assertion pkt->duration >= 0 failed at fftools/ffmpeg.c:1502
> Aborted (core dumped)
> 
> ill send you the file privately

Should be fixed by the TAK patchset I just sent.

-- 
Anton Khirnov