[FFmpeg-devel] [PATCH] pkt_pts reordering

[Uoti Urpala]

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