[FFmpeg-devel] [PATCH] pkt_pts reordering
Mon Jan 10 17:01:16 CET 2011
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
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*...
More information about the ffmpeg-devel