[FFmpeg-devel] [PATCH] avpacket: RFC for ABI bump additions

[Lynne]

Jan 23, 2021, 21:42 by cus at passwd.hu:

>
>
> On Sat, 23 Jan 2021, Lynne wrote:
>
>> Jan 23, 2021, 21:04 by cus at passwd.hu:
>>
>>>
>>>
>>> On Sat, 23 Jan 2021, Lynne wrote:
>>>
>>>> This is an RFC about the upcoming additions to the AVPacket structure
>>>> (whose size is still part of the ABI, so we need to plan for any changes).
>>>>
>>>> The current RFC patch adds 3 fields:
>>>>     - "void *opaque;" for the user to use as they wish, same as AVFrame.opaque
>>>>     - "void *opaque_ref;" for more permanent and propagating user data, same as AVFrame.opaque_ref
>>>>
>>>
>>> These seem legit.
>>>
>>>>     - "AVRational time_base;" which will be set to indicate the time base of the packet's timestamps
>>>>
>>>
>>> Why? It seems redundant and it will not be clear when to use to use stream/bsf/etc time base and when embedded AVPacket timebase. So I don't think this is a good idea.
>>>
>>
>> I'd like to switch to using this to avoid the dance you have to do with
>> avformat init, where you have to give it your packet's time_base in the stream time_base
>> then init, which then sets the time_base in the same field you provided your time_base,
>> and then you have to rescale the timestamps of packets to that timebase.
>>
>
> That is by design as far as I know, you set the timebase to your requested time base, if the format supports that then you are happy, if not, then you convert.
>

You can still keep the mechanism, since it's init time, but what's
the problem with letting lavf convert the timestamps for you if they don't
match? It wouldn't break any behavior apart from what's currently 
improper API usage. And it would make the API much more usable, as
most users just want to mux at the FFMIN(muxer_max_tb, incoming_stream_tb)
rather than a specific timebase.