On 09/01/13 18:20, Uoti Urpala wrote: > 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.
So it is quite codec dependent now and should be made a bit more generic. > 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. so pointer, int64 and double. I doubt we want int128 > 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. Since other people dislike doubles 64bit time stamps in timebase units (as it is) could be a good compromise? lu _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
