Matroska video pixel height and width with PixelCrop options

[bendikro]

For a Matroska file with video width 1920 and height 1080, mediainfo reports:

Width               : 1 920 pixels
Height              : 1 080 pixels

But for the same file with the pixel crop attributes (PixelCropBottom, PixelCropTop, PixelCropLeft, PixelCropRight) set to 134,134,4,2, mediainfo reports the following:

Width               : 1 914 pixels
Original width      : 1 920 pixels
Height              : 812 pixels
Original height     : 1 080 pixels

This is confusing (and misleading), as the width and height reported differs between two video files where the actual width and height of the video are exactly the same. It would be much better to always report the same width, and instead have a "cropped width/height", like this:

Width               : 1 920 pixels
Cropped width       : 1 914 pixels
Height              : 1 080 pixels
Cropped height      : 812 pixels

[JeromeMartinez]

This is confusing (and misleading),

Right, Original_ stuff is intended for incoherencies report.

two video files where the actual width and height of the video are exactly the same.

the video are not exactly same, as there is a "transformation" indicating that the output is not the encoded width/height.

It would be much better to always report the same width, and instead have a "cropped width/height", like this:

The fix will be the inverse, because MediaInfo is intended for showing the output details. Similar to what we do with MXF, i.e.:

Width               : 1 914 pixels
Stored width        : 1 920 pixels
Height              : 812 pixels
Stored height       : 1 080 pixels

do you have samples to share? It would make our fix quicker.

[bendikro]

the video are not exactly same, as there is a "transformation" indicating that the output is not the encoded width/height.

What I mean is that the video data in the Matroska files are identical, not the decoded video if the media player actually crops the video according to the crop fields. But players like VLC and Mplayer seem to ignore the crop fields, which means in those cases the video displayed is actually identical as well.

Since the video data is stored with 1920 x 1080 pixels, and the crop options are only four 4-byte integer values indicating to the player how much of the video can be cropped away, I don't get why the Width reported by mediainfo should differ between two files with identical video data.

No crop option: https://easyupload.io/yjxxmr Cropping set to 0,0,0,0: https://easyupload.io/kj60cj Cropping set to 100,100,10,10: https://easyupload.io/4xs25b

The fix will be the inverse, because MediaInfo is intended for showing the output details. Similar to what we do with MXF, i.e.: Width : 1 914 pixels Stored width : 1 920 pixels Height : 812 pixels Stored height : 1 080 pixels

Ah, ok, then I've misunderstood . I though Mediainfo was supposed to give information about the video file content, not how the decoded video may be displayed depending on how the video player handles the crop fields.

With your suggested solution, I'm pretty sure there will still be confusion about what that really means. "But is the width 1920 or 1914?" The answer is that the video data width really is 1920, contrary to what mediainfo would report, but if the players hadn't ignored the crop values, the displayed video width would've been 1914.

It's not at all obvious what Width and Stored width actually means. I'd say it's better if mediainfo makes it clear that these are crop values that are only suggestions to the players (which in many cases are ignored. Can you point me to a media player that doesn't ignore the crop fields?).

Another suggestion would be:

Width               : 1 920 pixels
Display width       : 1 914 pixels
Height              : 1 080 pixels
Display height      : 812 pixels

[JeromeMartinez]

I don't get why the Width reported by mediainfo should differ between two files with identical video data.

You say the reason few words before this sentence, it is because the container indicates to crop. If the crop is not intended, the best thing to do is to avoid to store crop metadata in Matroska.

and the crop options are only four 4-byte integer values indicating to the player how much of the video can be cropped away [...] I though Mediainfo was supposed to give information about the video file content, not how the decoded video may be displayed depending on how the video player handles the crop fields.

Specs don't say "can" or "may", see e.g. PixelCropBottom "The number of video pixels to remove at the bottom of the image".

I'm pretty sure there will still be confusion about what that really means.

But what matter is the intended player behavior, and with a crop command the intended behavior is to displayed cropped video.

The answer is that the video data width really is 1920, contrary to what mediainfo would report

MediaInfo would be reporting both, and it is not "contrary", it is just that you don't agree with the definition of what we report.

I'd say it's better if mediainfo makes it clear that these are crop values that are only suggestions to the players

In that case we could report all as suggestion, a player can play a 30 fps stream at 15 or 60 fps, we keep showing 30 fps as "frame rate" and not "frame rate if the player obeys to the indicated frame rate".

Can you point me to a media player that doesn't ignore the crop fields?).

No idea, not our business, we report the stored information based on specs, that's all. We focus on specs, and if crop is not intended, crop info must not be stored in the file. Actually, it is similar to not showing "1088" for height of AVC or HEVC, we show "1080" for 1080p content even if the sampled (the really stored pixels, so all about bitrate and performance constraints in specs) height is 1088 pixels (AVC and HEVC use 16 pixel macroblocks, 1080 is impossible without cropping, but you expect 1080 and not 1088 because players do the crop).

Or similar to show "48 kHz stereo" of xHE-AAC even if some players decode only 24 kHz mono (x2 sampling rate and x2 channel is optional and supported only if the player supports that), we don't show "24 kHz mono but 48 kHz stereo if your player is full featured", we show "48 kHz stereo".

MediaInfo provides information about how it should be handled with a full featured player and how it is expected to be displayed, and here it will also show the Stored width/height because it is useful for knowing the needed decoding performance.

But players like VLC and Mplayer seem to ignore the crop fields,

Issue to report to the corresponding projects (poke @robUx4).

It's not at all obvious what Width and Stored width actually means.

We definitely need to provide more information, on our todo-list but not a priority of our sponsors. Here, consider "Width" as your "Display width" (the intended player behavior for a full featured player supporting completely the spec), and "Stored width", the content stored in the bitstream (but after stream format crop), is provided if not same as "Display width".

---

Thank you for the sample files, the current behavior is definitely not the expected one.

[bendikro]

Specs don't say "can" or "may", see e.g. PixelCropBottom "The number of video pixels to remove at the bottom of the image".

That is a good point. The standard does not make this optional or open for interpretation, so clearly all the media players ignoring this are at fault for not obeying the crop fields.

MediaInfo would be reporting both, and it is not "contrary", it is just that you don't agree with the definition of what we report.

It's just that when all players ignore the crop values, it is (or looks like) a de facto optional field, and to "the common user" it looks like the real video width/height is the uncropped width/height.

We focus on specs, and if crop is not intended, crop info must not be stored in the file. Actually, it is similar to not showing "1088" for height of AVC or HEVC, we show "1080" for 1080p content even if the sampled (the really stored pixels, so all about bitrate and performance constraints in specs) height is 1088 pixels (AVC and HEVC use 16 pixel macroblocks, 1080 is impossible without cropping, but you expect 1080 and not 1088 because players do the crop).

Or similar to show "48 kHz stereo" of xHE-AAC even if some players decode only 24 kHz mono (x2 sampling rate and x2 channel is optional and supported only if the player supports that), we don't show "24 kHz mono but 48 kHz stereo if your player is full featured", we show "48 kHz stereo".

MediaInfo provides information about how it should be handled with a full featured player and how it is expected to be displayed, and here it will also show the Stored width/height because it is useful for knowing the needed decoding performance.

Hmm...ok, you've convinced me.

I guess this is the old battle between standards and implementations, and how they're often incorrectly implemented. And because of the incorrect implementations, people start to expect the incorrect behvior!

Thank you for the sample files, the current behavior is definitely not the expected one.

No problem

[kieranjol]

Just to follow up on this, the corresponding cropping metadata in QuickTime, the clean aperture (clap) atom is read and displayed with the correct cropping in QuickTime Player. I know that there’s reports on the VLC issue tracker (I either wrote or +1’d them) that was looking for VLC to have the functionality to display cropped video in both MOV and MKV. So there’s a good chance in the future that VLC might be able to respect these values, even if it’s optional, so the argument that VLC ignores the cropping so mediainfo should ignore it may not always be valid.

On Sun 21 May 2023 at 16:12, Bendik @.***> wrote:

Closed #1771 https://github.com/MediaArea/MediaInfoLib/issues/1771 as completed.

— Reply to this email directly, view it on GitHub https://github.com/MediaArea/MediaInfoLib/issues/1771#event-9296150425, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAITFPQZGJQ5XF4PX5PJWEDXHIWEFANCNFSM6AAAAAAYJJKKB4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[JeromeMartinez]

the corresponding cropping metadata in QuickTime, the clean aperture (clap) atom

Now I am the one less convinced, because we have a "Clean aperture" width/height, and we show it in dedicated "clean aperture" fields because I understood that clean aperture is "An image’s clean aperture is a region of video that’s free from transition artifacts caused by the encoding of the signal" but Apple doc says also "This is the region of video to display".

I was doing the difference between "clean aperture" and "crop", clean aperture being an hint and crop and order, is it relevant to do the difference? If not, Matroska crop could go in the "clean aperture" part rather than width/height.

@robUx4 would you say that Matroska crop is intended to be similar to MOV clean aperture?

I reopen the ticket because whatever is the choice, current behavior is wrong.

[JeromeMartinez]

I also wonder if it is similar to MXF display width/height, e.g. in MXF there is a 720x608 frame and display height is 576, 32 lines are for out of band lines (line 21 CC, VITC, etc), and I don't see that as similar to clean aperture.

[robUx4]

I am not familiar enough with the clean aperture thingy (although I remember it was mentioned in another discussion a long time ago).

As for VLC it should crop the video properly. That's something that is a bit hit and miss right now. It depends if you decode in software/hardware, what platform you're on, etc. The best way to solve this is to open an issue here or find if there's already one, and provide some debug logs and if possible a sample file. But in short it should work and if it doesn't, it's a bug that we need to fix.

I don't know if the MOV clean aperture is supported in VLC. It may not be implemented, but it should eventually.