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. 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. As I said, I believe the use case of a rotation calls in the use of double, exactly as it happens for other rotation APIs in the codebase. Secondly I am against exporting the data as fixed point since that would be burden to the end user and would tie this API to the google specification too much. Finally I don't see what is wrong about these fields being platform-specific, the whole structure is bound to be platform specific, and the API mandates that a structure is used all the time. -- Vittorio _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
