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.
Some devs (JEEB) wanted reception timestamps and original, overflowed
timestamps for MPEG-TS.
MPEG-TS with timestamps has many issues and I am afraid the introduction
of original/overflowed timestamps won't solve them:
- discontinuity - the discontinuity should be hidden from the output
timestamps, but the discontinuity should be detected based on the PCR of
the streams
- parsers - the parsers merge/split packets as they want, who knows what
will happen to the timestamps...
- overflows - ffmpeg's "infrastructure" for packet timestamp overflows
only handles a single wraparound, not multiple, so it is useless for
anything serious.
I'd be willing to add a reception timestamp as long as we add an additional
time_base field
and make it independent of the packet's pts field, since those timestamps are
usually on
highly precise system clock time bases, and reducing their precision would be
undesirable.
I don't know, I'd really like to see some actual benefit of these extra
timestamps before we agree to add specific fields for it. Until then, maye
just use side data?
I'm not sure about overflowed original timestamps or how they would help.
Perhaps we should introduce an AVBufferRef *internal_ref like with AVFrame to
store such single library-only data?
I guess you mean private_ref. This can be added, if for nothing else, then
for consistency. :)
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".
