On Tue, 2013-01-08 at 15:34 +0100, Anton Khirnov wrote: > mpeg-specific crap, most probably useless => remove: > int8_t *qscale_table; > int qstride; > int qscale_type;
IIRC this information is required to support postprocessing MPEG2 properly at least. > // 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? 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. 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. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
