Define videoWidth to use the container's presentation size only for aspect ratio #13106

What is the issue with the HTML Standard?

The natural width and height of a video are defined as:

the dimensions of the resource in CSS pixels after taking into account the resource's dimensions, aspect ratio, clean aperture, resolution, and so forth, as defined for the format used by the resource.

Both MP4 and WebM can declare a presentation size that differs from the coded size. ISO BMFF (ISO/IEC 14496-12:2015, 8.3.2.3) says of tkhd width and height:

For all other tracks, they specify the track's visual presentation size. These need not be the same as the pixel dimensions of the images, which is documented in the sample description(s); all images in the sequence are scaled to this size, before any overall transformation of the track represented by the matrix.

Matroska (RFC 9559) defines DisplayWidth (with DisplayUnit 0, pixels) as:

Width of the video frames to display. Applies to the video frame after cropping (PixelCrop* Elements).

So for a 320x240 video declaring 160x120, the spec seems to require videoWidth 160. Browsers instead report 320 once frames are decoded, using the declared size only for aspect ratio, except for AV1 in MP4 in Firefox. videoWidth at loadedmetadata → after frames are presented:

(Chrome also shows 160 at loadedmetadata for the WebM case with MSE.) A WebM DisplayWidth/DisplayHeight of 640x240 (a different aspect ratio) gives 640x240 in all three.

Options:

1. Align with browsers: natural dimensions are the decoded size after aspect ratio correction, with the container's declared size only contributing the aspect ratio. The coded size is already known at loadedmetadata (MP4 sample entry width/height, WebM PixelWidth/PixelHeight), so report that from the start, as Chrome does (except for WebM with MSE). This changes Firefox for AV1 in MP4, and the loadedmetadata value in Firefox (except for H.264), Safari, and Chrome for WebM with MSE.
2. Keep the spec as-is: honor the declared size, as the format specs say. Safari and Firefox (except for H.264) already report it at loadedmetadata, but this changes what they report after the first frame, and changes Chrome throughout. Maybe a compat risk, if content has declared sizes that browsers have been ignoring.

I think 1 is better.

Tests: web-platform-tests/wpt#63960