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