On Wed, 09 Jan 2013 17:46:47 +0200, Uoti Urpala <[email protected]> wrote: > On Tue, 2013-01-08 at 15:34 +0100, Anton Khirnov 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 apparrently also useful when there is no pts > > int64_t pkt_pts; > > int64_t pkt_dts; > > int64_t reordered_opaque; > > What do you mean by "lavc-specific" here? Something that should possibly > be available but in a data structure other than AVFrame? >
I mean that the meaning of those fields is very strongly coupled to the way decoding is done in lavc. When a frame is used on its own outside of lavc, "frame timestamp" still has a well-defined meaning. OTOH pkt_pts and pkt_dts do not. > Having the decoder reorder pts info is of course necessary to support > decoding with pts timestamps at all. Filters also need some mechanism to > handle timestamps. > > Currently mplayer2 uses type-punning to place timestamps in the > reordered_opaque field (as it's badly designed to only support int64_t, > while timestamps are doubles). Making it an union supporting more basic > types would be preferable. I'm considering adding a frame side data type for this. > > Having just a "pts" field would cause problems at least if libavcodec > would treat it as having any semantics other than blindly copied data. > It shouldn't be assumed to contain integers that can be meaningfully > used in any arithmetic operations for example. > > Having timestamp-adjusting filters in libavfilter (for example a > deinterlace filter that splits fields and thus adds new frames with new > timestamps) will also present problems with timestamps. Having the > timestamps be integers will make it hard to feed values in from > applications, and cumbersome and possibly inaccurate for the filters to > manipulate them. Doubles would be more practical. As others have pointed out, bringing doubles vs rationals bikeshed into this is entirely orthogonal to what i'm trying to achieve. This patchset is complicated enough as it is. -- Anton Khirnov _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
