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

[Marton Balint]

On Sat, 23 Jan 2021, Lynne wrote:

> 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?

And why do you need per-AVPacket time bases for that if your packets are 
in a fixed timestamp anyway?

> It wouldn't break any behavior apart from what's currently 
> improper API usage. And it would make the API much more usable, as

I don't see why, you only gain that you don't have to call 
av_packet_rescale_ts() yourself.

> most users just want to mux at the FFMIN(muxer_max_tb, incoming_stream_tb)
> rather than a specific timebase.

The user should preferably mux audio in 1/sample_rate time base, video in 
1/frame_rate time base, and that's what ffmpeg.c does AFAIK.

Regards,
Marton