[mediaqueries] definition of video width and height

[frivoal]

The definition of the video-width media feature (same thing for video-height) includes this:

For continuous media, this is the width of the viewport (as described by CSS2, section 9.1.1 [[!CSS21]]) including the size of a rendered scroll bar (if any). For paged media, this is the width of the page box (as described by CSS2, section 13.2 [[!CSS21]]).

That text comes from the definition of width, but I don't think it is relevant here: I don't think there currently exists such a thing as a paginated media with a dedicated video plane (or a paginated video plane being itself paginated).
On the other hand, we should add a mention that this is about the size of the entire video plane, not the layout-dependent portion of it that is being clipped and composited with the rest of the page.

Therefore, I suggest deleting the sentence quoted above, and instead, inserting the following one:

This represents the width of the entire video plane, and does not depend on layout. Any masking or clipping controlled by the web page is not taken into account.

[nigelmegitt]

I'm not sure what you mean by "video plane" here @frivoal ? I'm not sure there's a good W3C resource that defines the terms properly, which is awkward because there's a crucial difference between the decoded video size and the viewport size. (This has a big impact on subtitle/caption positioning, by the way.)

Encoded video size != Decoded video size != viewport size.

Let's ignore encoded video for the time being, because we're probably not really interested in it. Instead, think about decoded video, and call that the "video" as opposed to the rectangular area displaying that video, let's call that the "viewport".

For example, the video might have an aspect ratio of 4:3 and be shown in a viewport with aspect ratio 16:9. There are any number of ways to arrange for this, but looking at just three approaches that are used:

1. show the full height of the video, and put (maybe black) bars on either side.
   • video width < viewport width
   • video height == viewport height.
2. fill the viewport with the video, chopping off the top and bottom of the video.
   • video width == viewport width
   • video height > viewport height.
3. zoom the video somewhat so that there are still bars on either side, but they're smaller, and there is still some content chopped off the top and bottom, but not as much.
   • video width < viewport width
   • video height > viewport height

How does this affect captions/subtitles?

(not sure how on-topic this is for this issue but it seems likely to be relevant)

I mentioned this really affects subtitle and caption positioning. The typical reason why captions are positioned relative to video, for accessibility, is to avoid having them obscure some part of the video that is important for understanding/experiencing the video. There is a general problem with specs like WebVTT that position captions only relative to the viewport, because the caption author doesn't know how big the viewport is, they only have access to the video.

If we can arrange it, caption positions should be authored relative to the video, in terms of proportional size and position, and then if there's some way to fix up a mismatch between the video aspect ratio against which they were authored, and the presented video aspect ratio, then we have some hope of player code doing something sensible.

By the way, the IMSC activeArea feature is designed to allow the caption file to signal something to the player so the player can make some sensible decisions. One possible decision is to set the limits of scaling of the video to deal with examples like those shown above so that relative positioning of captions can be made.

[svgeesus]

@nigelmegitt commented

I'm not sure what you mean by "video plane"

That is crucial to understanding why we have two parallel sets of properties.

In dome devices, such as 4k and 8k televisions, there is not one framebuffer but two and they have different properties:

• a video plane, which is typically 4k resolution, 10bit per component, P3-ish gamut and HDR capable
• a graphics plane, which may be full HD resolution, 8 bits per component, sRGB gamut and SDR.

There is some sort of hardware compositing for the output of the two framebuffers

They cover the same screen area, so the graphics plane is lower resolution