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

[Andreas Rheinhardt]

Lynne:
> 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

What is undocumented?

> timebase field are you supposed to use from lavf? The global
> context's? The stream's? The codecparameter's? This

Global context? You mean AVFormatContext? It does not contain a timebase
at all; the timestamps and durations contained in it are in
microseconds. And AVCodecParameters also hasn't a timebase either. Only
the stream has one.

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