[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