[FFmpeg-devel] [PATCH] pkt_pts reordering

[Vladimir Pantelic]

Uoti Urpala wrote:
> On Mon, 2011-01-10 at 15:26 +0100, Vladimir Pantelic wrote:
>>  Luca Barbato wrote:
>>  >  On 01/10/2011 03:04 PM, Michael Niedermayer wrote:
>>  >>
>>  >>   whats the use case for non timestamp opaque?
>>  >
>>  >  I could think about some use case that would work better with a void
>>  >  pointer instead of a 64bit int but I might be wrong.
>>
>>  yes, a void* value would be better indeed now
>>
>>  The use case is to allow the user to carry frame private data from
>>  a pkt to decoded frame
>
> The current int64_t type for the opaque field is poorly chosen; at least
> it should be an union of int64_t/double/void *. Storing timestamps as
> doubles is one good use case which is not "non timestamp" but where
> libavcodec trying to do anything with the value interpreted as int64_t
> would be wrong. Another could be an application wanting to just create a
> map of the input->output reordering - you could use "pts" increasing by
> one for each packet for that, but wouldn't want libavcodec to do any
> interpretation based on that value.
>
> "void *" uses suffer from the problem that if you point to allocated
> memory you can't easily know when it could be freed in cases where the
> pointer will never be returned from libavcodec (there's no explicit
> "it's now known this value will never have any corresponding output
> frame").

The only thing needed is a way for the libav* users to attach
arbitrary and opaque data when decoding and get that back
again reordered correctly. libav* does not need to "interpret"
this data in any way, so void* is fine IMHO.

since the actual reordering of timestamps has shifted to pkt_pts,
we can use the existing reordered_opaque just as it is and maybe
convert it to void*...