[FFmpeg-devel] [PATCH] avpacket: RFC for ABI bump additions
Anton Khirnov
anton at khirnov.net
Sun Jan 24 18:05:16 EET 2021
Quoting Lynne (2021-01-23 20:10:46)
> 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
Generally in favor, but:
- do we really need both?
- ownership semantics should be specified more clearly, so there is no
ambiguity over who is allowed to set it. Something like:
whoever owns (i.e. is responsible for unreffing) the packet ref also
owns opaque_ref
> - "AVRational time_base;" which will be set to indicate the time base of the packet's timestamps
In favor - should reduce confusion and existing users can still rescale
timestamps manually before passing them to lavf. But then it should also be added to AVFrame.
And compatibility will be tricky - e.g. encoders setting this field will
break muxing in lavf (since current users all rescale manually).
>
> Some devs (JEEB) wanted reception timestamps and original, overflowed timestamps for MPEG-TS.
> 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.
This sounds like side data to me.
>
> 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 don't like treating the libraries specially, so -1 for me.
internal_ref should not exist either.
--
Anton Khirnov
More information about the ffmpeg-devel
mailing list