[Matroska-devel] PixelCrop* interaction with resolution changes
Steve Lhomme via Matroska-devel
matroska-devel at lists.matroska.org
Mon Mar 28 14:01:17 CEST 2016
2016-03-15 2:42 GMT+01:00 Matthew Gregan via Matroska-devel
<matroska-devel at lists.matroska.org>:
> It's possible (with, for example, VP9) to produce a stream that changes
> resolution at keyframes. It's not clear how this should interact with
> PixelCrop* values specified in the header, since they are specified in terms
> of the original resolution (via the matching values in PixelWidth/Height).
Normally in Matroska you must not change resolution (audio or video)
in the same Segment. Now if this is an internal trick of the codec,
then it must stay inside the codec and still output frames as the
original output. If the playback framework handles that differently (I
know it's the case in VLC) then it must do the math between the
original cropping parameters and the new pixel size.
> From https://matroska.org/technical/specs/notes.html#Cropping:
> PixelXXX (size of the coded image)
> -> PixelCropXXX (size of the image to keep)
> -> DisplayXXX (resized cropped image)
> When the resolution changes mid-stream, the "size of the coded image"
> changes, which seems like it would invalidate any specified pixel cropping.
> Does it make sense to simply ignore the cropping values in this case, or is
> some other behaviour desired?
That's a good reason not to use this or that codec cropping values
should be internal to the codec and not known to the container. IMO if
a codec has such an internal feature, it should deal with it
internally, meaning the pixel padding needed for encoding should not
be put in the container, ever.
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel
Matroska association Chairman
More information about the Matroska-devel