On Wed, Feb 15, 2017 at 8:52 AM, James Almer <jamr...@gmail.com> wrote: > On 2/14/2017 11:20 PM, Vittorio Giovara wrote: >> On Tue, Feb 14, 2017 at 6:54 PM, James Almer <jamr...@gmail.com> wrote: >>> On 2/14/2017 5:52 PM, Vittorio Giovara wrote: >>>> On Fri, Feb 10, 2017 at 6:25 PM, Michael Niedermayer >>>> <mich...@niedermayer.cc> wrote: >>>>> On Fri, Feb 10, 2017 at 04:11:43PM -0500, Vittorio Giovara wrote: >>>>>> Signed-off-by: Vittorio Giovara <vittorio.giov...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
