On Wed, Nov 16, 2016 at 6:29 PM, Michael Niedermayer
<mich...@niedermayer.cc> wrote:
> On Wed, Nov 16, 2016 at 05:38:20PM -0500, Vittorio Giovara wrote:
>> On Tue, Nov 15, 2016 at 8:52 PM, James Almer <jamr...@gmail.com> wrote:
>> > On 11/15/2016 10:39 PM, Michael Niedermayer wrote:
>> >> On Tue, Nov 15, 2016 at 11:56:48AM -0500, Vittorio Giovara wrote:
>> >> [...]
>> >>> +/**
>> >>> + * This structure describes how to handle spherical videos, outlining
>> >>> + * information about projection, initial layout, and any other view
>> >>> modifier.
>> >>> + *
>> >>> + * @note The struct must be allocated with av_spherical_alloc() and
>> >>> + * its size is not a part of the public ABI.
>> >>> + */
>> >>> +typedef struct AVSphericalMapping {
>> >>> + /**
>> >>> + * Projection type.
>> >>> + */
>> >>> + enum AVSphericalProjection projection;
>> >>> +
>> >>> + /**
>> >>> + * @name Initial orientation
>> >>> + * @{
>> >>> + * These fields represent the pose values that measure the rotation
>> >>> + * transformation (in degrees) to be applied to the projection.
>> >>
>> >>> + * They are exported as 16.16 fixed point.
>> >>
>> >> why waste 7 bits of precission ?
>> >
>> > 16.16 seems to be part of the spec
>> >
>> > https://github.com/google/spatial-media/blob/master/docs/spherical-video-v2-rfc.md
>>
>> Correct, there is no point in adding more precision that the
>> underlying layer can withhold.
>
> if people prefer storing
> angle * 180 * (1<<16) / PI (using about 25bits of 32bits)
> instead of
> angle * (1<<31 - 1) / PI (using 32bits)
>
> than iam happy with that too, ive a slight preferrance for using the
> full 32bits though
I'm ok with how it is now. I think it's a reasonable compromise.
> to me the
> "underlying layer" for rotations is not some spec but reality
"Reality" still need to be transmitted and described in binary format
agreed by each party ;-)
--
Vittorio
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
