On Wed, 2013-01-09 at 16:58 +0100, Luca Barbato wrote: > On 09/01/13 16:46, Uoti Urpala wrote: > > 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. > > And just mpeg2 ?
Probably others too. The postprocessing filters need to know how accurately the data in each macroblock was stored; inaccurately stored blocks are filtered more heavily. > > 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. > > union or pointer? Union, so that it's not necessary to separately allocate memory to store the value of each timestamp. Handling allocated memory properly would also require some kind of mechanism to let libavcodec communicate when a frame is being dropped and the opaque value will never be returned with any output frame; without that it'd be almost impossible to avoid some memory leaks, as you couldn't know when or whether you could safely free the memory allocated for packets libavcodec is not returning any output for. > > 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. > > Rationals feel better maybe? No, rationals suck. The denominators blow up if you need to do anything nontrivial with them. Doubles work much better in practice - as long as the calculations produce values which are reasonable rationals, you can recover those exactly from the double values if you want; and when the results are not nice rational values, doubles still work very well without causing any problems for most practical uses, while representing the values as rationals fails hard. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
