On Wed, 2013-01-09 at 17:02 +0100, Hendrik Leppkes wrote: > Personally, i also think timestamps as integers are fine, as thats how > they are stored in files, and how most external API i ever worked with > expects it.
Having the exponent of the double change between different timestamps in the same track is generally not useful (if the largest pts values present become too inaccurate, then it doesn't help much that smaller values have more accuracy). Thus it's in principle possible to select a fixed scale that works well - generally optimal is something like a denominator of MAX_INTEGER/MAX_TIMESTAMP_IN_THIS_TRACK. But choosing this optimal fixed precision requires knowing the appropriate scale in advance. Thus, in practice doubles are simpler to use: they automatically select the appropriate scale to use, and having "only" 53 bits for the mantissa instead of full 64 doesn't matter for most applications. Though just selecting a small enough fixed scale, common for all uses, with 64-bit timestamps works OK in practice too (like Matroska stores everything as integer nanoseconds). Making timestamps doubles rather than integers doesn't really lose anything; you can still feed in integers if you want, and they behave the same as long as there are no operations other than copies, subtractions or additions within the same time base. I doubt you'd need integers larger than 53 bits. OTOH doubles make calculations simpler to write, and allow writing filters than manipulate timestamps without worrying about timebases at every step. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
