-
Notifications
You must be signed in to change notification settings - Fork 171
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Matroska video pixel height and width with PixelCrop options #1771
Comments
Right,
the video are not exactly same, as there is a "transformation" indicating that the output is not the encoded width/height.
The fix will be the inverse, because MediaInfo is intended for showing the output details. Similar to what we do with MXF, i.e.:
do you have samples to share? It would make our fix quicker. |
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
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 Another suggestion would be:
|
You say the reason few words before this sentence, it is because the container indicates to crop.
Specs don't say "can" or "may", see e.g. PixelCropBottom "The number of video pixels to remove at the bottom of the image".
But what matter is the intended player behavior, and with a crop command the intended behavior is to displayed cropped video.
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.
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".
No idea, not our business, we report the stored information based on specs, that's all. 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.
Issue to report to the corresponding projects (poke @robUx4).
We definitely need to provide more information, on our todo-list but not a priority of our sponsors. Thank you for the sample files, the current behavior is definitely not the expected one. |
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.
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.
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!
No problem |
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 <#1771> as
completed.
—
Reply to this email directly, view it on GitHub
<#1771 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAITFPQZGJQ5XF4PX5PJWEDXHIWEFANCNFSM6AAAAAAYJJKKB4>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
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. |
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. |
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. |
For a Matroska file with video width 1920 and height 1080, mediainfo reports:
But for the same file with the pixel crop attributes (PixelCropBottom, PixelCropTop, PixelCropLeft, PixelCropRight) set to 134,134,4,2, mediainfo reports the following:
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:
The text was updated successfully, but these errors were encountered: