On Sat, 23 Jan 2021, Lynne wrote:

Jan 23, 2021, 21:42 by c...@passwd.hu:



On Sat, 23 Jan 2021, Lynne wrote:

Jan 23, 2021, 21:04 by c...@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
_______________________________________________
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".

Reply via email to