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

[Vittorio Giovara]

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.
-- 
Vittorio