[FFmpeg-devel] [PATCH] avformat/movenc: add write_clli flag to write clli atom

[Jan Ekström]

On Wed, Apr 1, 2020 at 11:07 PM James Almer <jamrial at gmail.com> wrote:
>
> On 4/1/2020 4:54 PM, Carl Eugen Hoyos wrote:
> > Am Mi., 1. Apr. 2020 um 21:39 Uhr schrieb Michael Bradshaw
> > <mjbshaw-at-google.com at ffmpeg.org>:
> >>
> >> On Wed, Apr 1, 2020 at 1:18 PM Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
> >>>
> >>> If this patch is a good idea (if it fixes playback visually on some devices -
> >>> do I understand that correctly?), it should not be optional imo.
> >>
> >> It won't be optional once it's standardized in ISO/IEC 14496-12. But I
> >> think it's good to have it be opt-in until it's standardized.
> >
> > If there already are devices that support it, it should not be optional.
> >
> > Carl Eugen
>
> If anything, I'd rather have these boxes (clli and mdcv) written when
> strict_std_compliance <= experimental than adding a new muxer option.

Decided to check the current state of clli, mdcv and cclv from the
MPEG documents I have accessible to myself. There is a document
regarding adding these to ISOBMFF ("Technologies under Consideration"
report from Jan. 2019 (w18240)), but the FDIS of the upcoming 14496-12
6th ed (w16163) or its already-decided amendments were elusive,
unfortunately.

If these boxes are contained within one of those FDIS documents, then
we can just make it not require non-strict compliance as effectively
the spec is just being balloted. Apparently Google defined these boxes
for their VP9 usage unofficially, but did not even register them over
at the MPEG-4 RA.

Quote from the Jan, 2019 document:
> We note that the VP9 project has already adopted, but not registered, similar boxes (with identical content) at <https://www.webmproject.org/vp9/mp4/#carriage-of-hdr-metadata>. The differences are (a) the four-character-codes and (b) Box vs. FullBox.
>
> There is not yet agreement to put the field semantics into the video CICP, and the duplication of the overall message semantics may need consideration.

That said, drafts of *MIAF* (https://www.iso.org/standard/74417.html)
specifically seem to have had it added. Yes, this is another addition
into the sphere of random ISOBMFF-likes, this time a fork of HEIF
apparently?

If we want to enable possibly-MIAF-specific things in normal MP4, then
we could enable it by default already.

Best regards,
Jan