On Thu, Jan 10, 2013 at 8:28 AM, Vladimir Pantelic <[email protected]>wrote:
> Luca Barbato wrote: > >> On 09/01/13 17:28, Vladimir Pantelic wrote: >> >>> Luca Barbato wrote: >>> >>> ????: >>>>> // those are very lavc-specific, but quite useful so i'm unsure >>>>> // what to do about them. pkt_pts might potentially be >>>>> replaced by pts, >>>>> // since pts is currently not used for anything useful when >>>>> decoding >>>>> // but pkt_dts is apparently also useful when there is no pts >>>>> int64_t pkt_pts; >>>>> int64_t pkt_dts; >>>>> int64_t reordered_opaque; >>>>> >>>> >>>> I wonder who uses reordered_opaque, the other two have some uses indeed. >>>> >>> >>> I am using it. And I still find it useful to have a way to attach a user >>> provided >>> reference to a frame. >>> >> >> Are you happy with it? should we replace with an union type that can fit >> a pointer, a large int and a double? >> > > I'm happy with an opaque 64bit, but would not oppose a union. Me neither. FWIW, in my code i have an fixed size array (currently 64 items) of my own metadata struct. I then just use reordered_opaque as an index to this array and keep incrementing reordered_opaque for every new packet and let it wrap at 64. This obviously assumes that the decoder delay is always < 64 frames. But in reality that's of course not a problem. With this approach i don't have to worry about free()ing any allocated auxiliary struct when packets are flushed from the decoder, etc.
_______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
