[FFmpeg-devel] [PATCH 1/3] spherical: Add tiled equirectangular type and projection-specific properties

Vittorio Giovara vittorio.giovara at gmail.com
Wed Feb 15 16:23:01 EET 2017


On Wed, Feb 15, 2017 at 8:52 AM, James Almer <jamrial at gmail.com> wrote:
> On 2/14/2017 11:20 PM, Vittorio Giovara wrote:
>> On Tue, Feb 14, 2017 at 6:54 PM, James Almer <jamrial at gmail.com> wrote:
>>> On 2/14/2017 5:52 PM, Vittorio Giovara wrote:
>>>> On Fri, Feb 10, 2017 at 6:25 PM, Michael Niedermayer
>>>> <michael at niedermayer.cc> wrote:
>>>>> On Fri, Feb 10, 2017 at 04:11:43PM -0500, Vittorio Giovara wrote:
>>>>>> Signed-off-by: Vittorio Giovara <vittorio.giovara at gmail.com>
>>>>>> ---
>>>>>> This should help not losing details over muxing and allows
>>>>>> callers to get additional information in a clean manner.
>>>>>>
>>>>>> Please keep me in CC.
>>>>>> Vittorio
>>>>>>
>>>>>>  doc/APIchanges        |  5 +++++
>>>>>>  ffprobe.c             | 11 ++++++++--
>>>>>>  libavformat/dump.c    | 10 +++++++++
>>>>>>  libavutil/spherical.h | 56 +++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>  libavutil/version.h   |  2 +-
>>>>>>  5 files changed, 81 insertions(+), 3 deletions(-)
>>>>>
>>>>> breaks fate
>>>>>
>>>>> --- ./tests/ref/fate/matroska-spherical-mono    2017-02-10 23:43:51.993432371 +0100
>>>>> +++ tests/data/fate/matroska-spherical-mono     2017-02-11 00:24:10.297483318 +0100
>>>>> @@ -7,7 +7,7 @@
>>>>>  [/SIDE_DATA]
>>>>>  [SIDE_DATA]
>>>>>  side_data_type=Spherical Mapping
>>>>> -side_data_size=16
>>>>> +side_data_size=56
>>>>>  projection=equirectangular
>>>>>  yaw=45
>>>>>  pitch=30
>>>>> Test matroska-spherical-mono failed. Look at tests/data/fate/matroska-spherical-mono.err for details.
>>>>> make: *** [fate-matroska-spherical-mono] Error 1
>>>>
>>>> Ah I didn't notice, it is fixed in the next commit, but I'll amend this one too.
>>>>
>>>>
>>>> I didn't see any comment/discussion, should I assume it is ok?
>>>> Please CC, thank you.
>>>
>>> These are a lot of projection specific fields. It worries me as the
>>> spec may change in the future with new fields added or existing
>>> fields changing purpose. Not to mention the Mesh projection, which
>>> has like fifty specific fields of its own.
>>
>> Even if the spec change (which at this point would be a terrible
>> terrible thing to do) there are now files in the wild and software
>> that have adopted this draft, so we would have to support this anyway.
>
> If the spec changes, it will be the contents of the equi/cbmp/mesh.
> By exporting them raw as extradata, said changes in the spec would
> require no changes to our implementation.

If the spec changes in a non-backward compatible way, the API is the
least of our problems :-)
-- 
Vittorio


More information about the ffmpeg-devel mailing list