[FFmpeg-devel] [PATCH] avpacket: RFC for ABI bump additions

[Marton Balint]

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