On 4/1/2020 6:18 PM, Michael Bradshaw wrote: >> On 4/1/2020 4:54 PM, Carl Eugen Hoyos wrote: >> If there already are devices that support it, it should not be optional. > > There are, but these boxes aren't technically standardized for mp4/mov > as far as I can tell. I'm reluctant (but not entirely opposed) to > enable something by default that isn't formally specified. > > On Wed, Apr 1, 2020 at 2:07 PM James Almer <jamr...@gmail.com> wrote: >> If anything, I'd rather have these boxes (clli and mdcv) written when >> strict_std_compliance <= experimental than adding a new muxer option. > > `-strict -2` might have other side effects though. Also I think adding > new muxer options are much more discoverable for users because you can > see how to enable clli/mdcv with `-h full`. The write_clli/write_mdcv > flags are meant to be temporary, anyway.
My main worry about adding options for each of these boxes is that, like with write_colr, they *will* be used in scripts by users regardless of what we put in the description, and in turn potentially become a PITA to remove. Your patch to write the colr box by default is an example of this. You didn't remove the option like one would expect, but made it "official" and left for users the ability to disable the atom's presence. It should instead be removed and the box always written if the conditions you listed in that patch are met, much like every other box in the container. And the experimental flag for containers shouldn't have any other effect when writing mp4 files, as it doesn't apply to for example encoders, so it should be fine for this purpose if we decide these boxes are not yet "standard" enough. > > On Wed, Apr 1, 2020 at 2:48 PM Jan Ekström <jee...@gmail.com> wrote: >> If we want to enable possibly-MIAF-specific things in normal MP4, then >> we could enable it by default already. > > If MIAF specifies both clli and mdcv and you can confirm we're writing > them correctly then I could be convinced to skip the experimental > phase in FFmpeg and just write them by default. I haven't bought a > copy of MIAF but I will if it'll help us sort this out. > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
