On Mon, Nov 14, 2016 at 8:55 PM, Michael Niedermayer <mich...@niedermayer.cc> wrote: > On Mon, Nov 14, 2016 at 04:55:36PM -0500, Vittorio Giovara wrote: >> On Sun, Nov 13, 2016 at 11:57 AM, Michael Niedermayer >> <mich...@niedermayer.cc> wrote: >> > On Sun, Nov 13, 2016 at 10:18:18AM +0100, Michael Niedermayer wrote: >> >> On Sat, Nov 12, 2016 at 10:05:22PM -0500, Vittorio Giovara wrote: >> >> [...] >> >> > So I really do not see a use case for using int64 here. >> >> >> >> then you can use int32, less than int32 is too little if for example >> >> you wnat the precission to be sufficient to know where a tele lens >> >> points with pixel precission and have a bit precission headroom >> >> Hi Michael, thanks for keeping me in CC. >> I understand the problem, but this is a solution for a issue that is >> non-existent. > > The problem of difficut to test code is real and existing in general. > Encoders&muxers using floats/doubles can not be tested as completely as > Encoders&muxers not using floats unless they by chance give binary > identical results on all platforms.
That's not the problem you referred to in the previous email. > Muxers&encoders would use/write the rotation side data > > Similarly ffprobe would at some point print this data, the text > printout of doubles has a good chance to not match exactly between > platforms. ffprobe does that in 2/3, but right now it's limited to int. >> There is no application or usecase for "pixel perfect" >> precision, the rendering of a spherical video will distort the video >> surface in order to map the flat surface to a sphere, and it is >> impossible to predict where this operation will move pixels to. I >> believe this is why this specification describes the initial >> orientation as rotation degrees rather than pixel offsets. > > I referred to pixels only to show that 32bit floats are insufficiently > precisse in some cases. I still don't like it, but I'll just export the original 16.16 fixed point value and let the user deal with it then. Thanks for the reviews. -- Vittorio _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
