Subject: Re: [Cellar] Display area clarification question

From: Steve Lhomme <[email-masked]>
Date: Sun, 6 Mar 2016 14:48:23 +0100

2016-02-29 15:27 GMT+01:00 Tobias Rapp <[email-masked]>:
> On 28.02.2016 15:31, Steve Lhomme wrote:
>>
>> 2016-02-28 12:11 GMT+01:00 Moritz Bunkus <[email-masked]>:
>>>
>>> Hey,
>>>
>>> it's true that we've never clarified this. I'm not even sure whether or
>>> not we've had a consensus on how to interpret the values.
>>
>>
>> Correct, but trust me, it was in my head the whole time ;) Although
>> the name PixelCrop* imply that it happens on Pixel*, unlike Display*
>> values.
>
>
> One could (in theory) invent similar DisplayCrop* elements that apply on top
> of DisplayWidth/Height values which could be used to describe
> letterboxed/pillarboxed material. This would be somehow similar to the AFD
> flag [1] in MPEG but globally on the stream/track.
>
>>> For me PixelCrop* applies directly to the PixelWidth/Height values. And
>>> Display* determines the intended size for displaying the video after the
>>> cropping parameters have been applied. So yes, your interpretation is
>>> the one I'm favoring as well.
>>
>>
>> Yes, the cropping happens on the pixels, the display size are just how
>> to display those remaining pixels.
>
>
> OK, have tried to make a patch, see attached file.
>
> Note that I have changed the default value of DisplayWidth/Height to take
> the cropping into regard. Not sure how critical this is regarding backwards
> compatibility. It affects files which have at least one PixelCrop* element
> value > 0 and no DisplayWidth/Height element.

Thanks. I applied the change but not in the specs yet. The default
values were not used in code (AFAIK).

> Best regards,
> Tobias
>
>
> Links:
> [1] https://en.wikipedia.org/wiki/Active_Format_Description
>
> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar
>

-- 
Steve Lhomme
Matroska association Chairman

---

From: Dave Rice <[email-masked]>
Date: Mon, 7 Mar 2016 00:03:59 -0500

> On Feb 26, 2016, at 6:27 AM, Tobias Rapp <[email-masked]> wrote:
> 
> Hello,
> 
> when archiving SD material lines of the vertical blanking interval (VBI) are sometimes stored at the top of the frame. For PAL the typical stored size is 608x720 pixels with the bottom 576x720 area containing the actual image content.
> 
> From looking at the Matroska specs this can be mapped into:
> 
> PixelWidth      = 720
> PixelHeight     = 608
> PixelCropBottom = 0
> PixelCropTop    = 32
> PixelCropLeft   = 0
> PixelCropRight  = 0
> 
> I guess that the definition of the display area (DisplayWidth, DisplayHeight) applies to the pixel frame size *after* cropping?
> 
> In that case it would be great if this would be made more explicit in the documentation of DisplayWidth and DisplayHeight. Also the defaults should reflect that (i.e. default DisplayWidth = PixelWidth - PixelCropLeft - PixelCropRight).

I tried to find some sample files that use PixelCrop* to see what the implementation was like, but unfortunately this feature appears to be rarely used.

I found some samples all written by "libDivXMediaFormat 3.0.0.0386” where all the PixelCrop* values are set to zero.

This sample appears to use PixelCrop* for non-defaults: http://archive.org/download/dl.icemusic.com/ArashFt.Aysel-AlwaysliveEurovisionSemiFinal2009.-WwW.Myicemusic-IR.mkv
PixelWidth: 720
PixelHeight: 576
PixelCropBottom: 4
PixelCropTop    = 0
PixelCropLeft   = 2
PixelCropRight  = 4
DisplayWidth = 1024
DisplayHeight = 576

The sample does have blank rows and columns on the left, right, and bottom edges so the cropping makes sense. Are there any display tools that use this feature?

When I play this sample in VLC, I see Display resolution set to 714x572, which is DisplayWidth - (PixelCropLeft + PixelCropRight) x DisplayHeight - (PixelCropBottom + PixelCropTop), but as far as I can tell the pxiels are still displayed rather than cropped.

ffplay from git-master plays the video at 720x576 (apparently not using PixelCrop* in any way).

Neither VLC or ffplay appear to actually crop the presentation, though with VLC it has an impact on the display size.

While studying sample files I found a few other issues with Display area.

I found 27 files, all from "WonderShare Matroska Muxer” that set DisplayWidth and DisplayHeight to 0 even though this is clearly invalid. Example: http://archive.org/download/gov.house.ogr.mark.20090310/gov.house.ogr.mark.20090310.mkv

I also see many files where DisplayWidth and DisplayHeight are set to very small values as if aspect ratios but with DisplayUnit unset (thus DisplayUnit defaults to Pixels). For instance http://archive.org/download/1937-Die-Schlacht-um-Miggershausen/1937-DieSchlachtUmMiggershausen12m28s.mkv by "libebml v0.7.7 + libmatroska v0.8.0” "mkvmerge v1.7.0 ('What Do You Take Me For') built on Apr 28 2006 17:20:19” uses a DisplayWidth of 4, DisplayHeight of 3, and unset DisplayUnit. If I understand the spec correctly, during playback the video should occupy four pixels by three pixels of the screen. Here’s another 4/3 example but with DisplayUnit specifically set to 0 (i.e. pixels): http://archive.org/download/3n-2zwd-1/az1.mkv (muxed by libDivXMediaFormat 3.4.1.0004).

In cases where I’ve seen DisplayUnit set to 3 (i.e. Display Aspect Ratio), the DisplayHeight and DisplayWidth are set to high numbers such as 1920x1080 or 1280x720 rather than 16x9.

I may try to rewrite some of the Display definitions to add clarity, please if you have any comments on these notes please let me know.

Best Regards,
Dave Rice

---

From: Steve Lhomme <[email-masked]>
Date: Sun, 13 Mar 2016 14:38:08 +0100

> When I play this sample in VLC, I see Display resolution set to 714x572, which is DisplayWidth - (PixelCropLeft + PixelCropRight) x DisplayHeight - (PixelCropBottom + PixelCropTop), but as far as I…

In VLC your mileage may vary depending on the vout you're using, and
thus the platform.
To make sure your vou respects cropping, make sure the
"offset_test.ogv" sample is displayed correctly:
https://wiki.xiph.org/TheoraTestsuite

There are also issues for players in general: if the codec specifies
cropping values, should the container values go on top of them or
simply replace them ? In VLC it's not handled properly. In the case of
Matroska it should replace the values from the codec. At least that
was originally the plan with 1080p MPEG2 that was coded in 1088
pixels. I think that's how mkvmerge handles it too.