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. 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. > 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. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
