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

Vittorio Giovara vittorio.giovara at gmail.com
Sun Nov 13 05:05:22 EET 2016

```On Sat, Nov 12, 2016 at 6:11 PM, Michael Niedermayer
<michael at niedermayer.cc> wrote:
> Hi
>
> On Sat, Nov 12, 2016 at 12:30:52PM -0500, Vittorio Giovara wrote:
>> On Sat, Nov 12, 2016 at 9:41 AM, James Almer <jamrial at gmail.com> wrote:
>> > On 11/11/2016 10:39 PM, Michael Niedermayer wrote:
>> >> On Fri, Nov 11, 2016 at 05:49:00PM -0500, Vittorio Giovara wrote:
> [...]
>> >>
>> >>> +    double yaw;   ///< Clockwise rotation around the up vector [-180, 180].
>> >>> +    double pitch; ///< Counter-clockwise rotation around the right vector [-90, 90].
>> >>> +    double roll;  ///< Counter-clockwise rotation around the forward vector [-180, 180].
>> >>
>> >> please use intXY (64 or 32 as preferred) so there are no platform
>> >> rounding dependancies
>>
>> These are rotation angles which are inherently floating point, and
>
> Theres nothing inherently floating point on an angle.

Err not sure where you get that from, but it is very common for
rotation to be represented in floating point, whether you express it
in degrees (and thus real numbers, which include fractional values
such as 90.5º, expressed as floating point in computing) and in
radians where you literally use PI (which is an irrational numerical
constant, again expressed as floating point in computing).

>> consistent with what other rotation-related APIs export (eg.
>> av_display_matrix_rotation_get()).
>
>> Besides using intXX would lose
>> precision that the original specification offers.
>
> int64_t has about a thousand times higher precission than a double
> for storing general -180°..+180° angles. This is because doubles have
> 11 bits for a exponent which is exactly the same value for most of the
> angles

How much precision is too precision? double values are extremely well
suited for the kind of angles they have to represent: 11 bits are way
more than enough to express values between 180 and -180, and the rest
can be used for the mantissa (bearing a value between 0 and
0.999999..) good enough.

So I really do not see a use case for using int64 here.
--
Vittorio
```

More information about the ffmpeg-devel mailing list