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