[FFmpeg-devel] [PATCH] frame: add a time_base field

Lynne dev at lynne.ee
Thu Sep 9 22:35:09 EEST 2021


9 Sept 2021, 21:15 by george at nsup.org:

> Lynne (12021-09-09):
>
>> No, you don't, there's nothing special about this!
>>
>
> There is no need for something special, it is an universal fact of
> programming that if several redundant pieces of information are supposed
> to be in sync, unless there are strong systems to keep them in sync,
> they will eventually get out of sync because of a code inconsistency.
>
> Avoiding redundancy is one of the most important principles of code
> hygiene.
>
> This is why I oppose this change, and this is why I propose to remove
> the time_base field in AVPacket.
>

It's a necessary piece of information pertinent to the correct
presenting of each frame. Moreover, it simplifies the API,
which new users are still finding difficult to use. Like for example
timebase negotiation in lavf, which requires a complicated dance
to perform, and is not documented anywhere. And which
timebase field are you supposed to use from lavf? The global
context's? The stream's? The codecparameter's? This
field eliminates any source of doubt which timebase to use.
And this isn't about the difference between frames and packets
either, frames can be wrapped as packets too.
Additionally, this will allows us to deal with stream switching and
stream splicing correctly without needing to reinitialize components.

Right now, all the arguments you've given are "it's redundant"
(it isn't, you __need__ a timebase to make sense of any timestamps,
and if a timebase isn't found in the frame but halfway across Jupiter,
it's simply missing), it's complicated (it isn't, it's a 10-line patch,
maximum), it's hard to keep in sync (it isn't, it's a frame field like
any other which will be printed by ffprobe and tested by FATE).
The only honest argument you stated has been an implicit "I don't
like this".


More information about the ffmpeg-devel mailing list