Skip to content

DisplayWidth/Height in the presence of cropping elements

Hello,

this is both a bug report and a feature request. They are tightly linked, so I'll only open one issue for both.

  1. mkvmerge does not correctly handle the default values of DisplayWidth and DisplayHeight. I have uploaded Crop.Test.No.Explicit.Container.Aspect.Ratio.mkv to your server. It's videoparameters are as follows:
|  + Video track
|   + Pixel width: 1280
|   + Pixel height: 720
|   + Pixel crop top: 80
|   + Pixel crop bottom: 80

So the DisplayUnit has its default value of 0 and therefore the default values of DisplayWidth and DisplayHeight is PixelWidth - PixelCropLeft - PixelCropRight and similar for height. In the above case, DisplayWidth is 1280 and DisplayHeight is 560.

But if one remuxes this file, the result is:

|  + Video track
|   + Pixel width: 1280
|   + Pixel height: 720
|   + Display width: 1280
|   + Display height: 720
|   + Pixel crop top: 80
|   + Pixel crop bottom: 80

So the crop values aren't taken into account when deriving the display dimensions.

  1. As you know, the majority of players don't honour the Matroska cropping flags and this not going to change anytime soon so that files should be compatible with both types of players (those that honour the flags and those that ignore them). The fact that the display dimensions specify the target dimensions after the cropping has taken place complicates this. The easy solution of using a pixel aspect ratio is unfortunately not possible due to the fact that the Matroska specs don't allow setting the aspect ratio via the pixel aspect ratio.

But there is another way. It uses the default values of the display dimensions. If one has non-anamorphic content, one can simply leave the display dimensions away (provided DisplayUnit has its default value of 0) and the default values ensure that both a compliant as well as a non-compliant player will play this with the proper pixel aspect ratio. If one has anamorphic content, one can nevertheless cut either bars or pillars, but usually not both away: If one wants to crop vertically (i.e. crop top and/or bottom bars away), one doesn't include a DisplayHeight element. As the cropping takes places only vertically, the DisplayWidth element for both types of players is the same (i.e. a compliant player will first crop the two-dimensional pixelarray with dimensions wxh to wx(h-crop) and then scale this to DisplayWidth x (h-crop), whereas an incompliant player will simply scale the array to DisplayWidth x h and in both instances it will give the same pixel aspect ratio).

Both methods relied on the absence of the display elements to work. Unfortunately, mkvmerge seems to always write DisplayWidth and DisplayHeight values. So if one has such a file suitable for both compliant as well as incompliant players and remuxes it, the new file will not be suitable for both types of players. This could be averted if the display dimension were not written when they agree with their default values. If this is too drastic (because broken implementations could rely on the presence of these elements) then one could do without writing these values if there are also crop values (as long as the relevant display dimension coincides with its default value).

  1. The help text for the crop parameters currently doesn't mention that one should also modify the display dimensions when one edits the cropping parameters. Maybe one should add a note for this.

Gruß Andi