[FFmpeg-devel] [PATCH 04/13] lavf: use AV_CODEC_PROP_FIELDS where appropriate

Anton Khirnov anton at khirnov.net
Tue May 9 11:44:50 EEST 2023


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

I could split this into two patches, the first of which would fix one of
the bugs, expose the other one, breaking some tests. Then the second
patch would fix the second bug, fixing the tests again. It seems better
to do it in a single step to avoid the noise.

-- 
Anton Khirnov


More information about the ffmpeg-devel mailing list