Open cconcolato opened 1 year ago
in-stream cropping features that are optional, e.g. as metadata or sei, should be reflected at the container level (i.e. values should match) and if they don't the container should take precedence.
The container shall always take precedence, no?
The group discussed and wonders how real-world implementations would behave if the clap
would ask to crop a stream (512 px) with dimensions larger (e.g. 508px) than the cropped dimensions indicated by the in-stream structures (e.g. 500px).
We also note that ISOBMFF should not be dictating player behavior, but rather document the stream, as integration of decoder and cropping tool may be different from implementation to implementation.
We welcome further inputs on how to improve this text.
We may want to create conformance files to test various player behaviors.
The current semantics indicate:
I find the sentence "overriding structures specific to the video codec" unclear, especially for Clean Aperture. I see 2 use cases related to cropping:
clap
cannot override that behavior. b) The codec does not have that cropping feature. In that case, the clean aperture box can be used to signal the cropping, and obviously it overrides the codec output (i.e. the sample entry still documents the additional pixels).I think the ISOBMFF spec should be update to say that: