On date Wednesday 2023-03-01 15:33:51 +0100, Anton Khirnov wrote: > Quoting Stefano Sabatini (2023-03-01 01:05:29) [...] > > BTW, I noticied this as part of debugging transcode.c (which looks > > broken at the moment), since the timebase is read as 0/1 from the > > decoder context, it would be a valid value when reading from the > > AVStream (but this information is not copied by > > avcodec_parameters_to_context). In decode_filter_video.c this is > > indeed "fixed" by copying the timebase directly from the AVStream. > > > > Is this expected? Shouldn't the timebase be copied to the decoder > > context? > > Historically, AVCodecContext.time_base for decoding was NOT (as one > might expect) the timebase of input packets, set by the user. It was > instead the inverse of the framerate stored in codec-level headers, > which was called "codec timebase" by some documents. > > Since that was massively confusing for pretty much everyone, I added > AVCodecContext.framerate for exporting the framerate from the decoder, > and deprecated the use of AVCodecContext.time_base for decoding > entirely. After the recent major bump, time_base should not be used at > all in any way when decoding. > > The timebase of input packets should instead be stored in > AVCodecContext.pkt_timebase. I suppose after some time has passed we > might want to merge its functionality into time_base.
Makes sense, for the time being I understand the correct solution is to use pkt_timebase. Thank you. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
