On Tue, May 09, 2023 at 10:44:50AM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2023-05-08 16:15:42)
> > On Sun, May 07, 2023 at 03:32:46PM +0200, Anton Khirnov wrote:
> > > H.264 and mpeg12 parsers need to be adjusted at the same time to stop
> > > using the value of AVCodecContext.ticks_per_frame, because it is not set
> > > correctly unless the codec has been opened. Previously this would result
> > > in both the parser and lavf seeing the same incorrect value, which would
> > > cancel out.
> > > Updating lavf and not the parsers would result in correct value in lavf,
> > > but the wrong one in parsers, which would break some tests.
> > > ---
> > >  libavcodec/h264_parser.c      |  4 ++--
> > >  libavcodec/mpegvideo_parser.c |  2 +-
> > >  libavformat/avformat.c        |  9 ++++++---
> > >  libavformat/demux.c           | 29 +++++++++++++++++++----------
> > >  libavformat/internal.h        |  3 +++
> > >  5 files changed, 31 insertions(+), 16 deletions(-)
> > 
> > Doesnt this sort of change need a major ABI bump ?
> > it sounds like lavc and lavf interdepend here both ways
> 
> No, we do not guarantee bug compatibility.
> 
> Libavformat seeing ticks_per_frame=1 for codecs that set it to 2 upon
> being opened is a bug. Same for the parser.
> 
> It just so happens that libavformat AND its internal parser instance see
> the same incorrect value and this cancels out in cases that are tested
> by FATE (it would break if we had more thorough tests for repeating
> single fields).

This patch seems to change tbr
./ffmpeg -i fate-suite//h264/lossless.h264
Stream #0:0: Video: h264 (High 4:4:4 Predictive), yuv420p(progressive), 640x480, 25 fps, 60 tbr, 1200k tbn
vs.
Stream #0:0: Video: h264 (High 4:4:4 Predictive), yuv420p(progressive), 640x480, 25 fps, 120 tbr, 1200k tbn

with 
./ffmpeg -i fate-suite//h264/lossless.h264  -f framecrc -

The output uses 1/60 thats odd because if every frame can be represented in
1/60 then tbr is 1/60 or more course
OTOH if tbr is finer than 1/60 then not every frame can be represented in 1/60

maybe iam missing something but the new value seems worse and also
not consistent with what ffmpeg actually uses

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.