[FFmpeg-devel] [PATCH 1/3] lavu: Add AVSphericalMapping type and frame side data

Vittorio Giovara vittorio.giovara at gmail.com
Tue Nov 15 17:57:13 EET 2016

On Mon, Nov 14, 2016 at 8:55 PM, Michael Niedermayer
<michael at 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
>> <michael at 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.

More information about the ffmpeg-devel mailing list