[whatwg] Quality Values for Media Source Elements

[Hugh Guiney]

On Mon, Dec 14, 2009 at 4:08 AM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com> wrote:
> I would almost consider simply using "low quality" and "high quality"
> as quality distinguishers (and maybe "medium") and leave the actual
> choice of encoding to the hosting entity. Right now, may sites provide
> only two choices for Desktop: SD and HD, plus one for mobile. The
> device can be separated by the device-width as Eric described.

Except it can't—at least, not entirely. Since the size of a video
image is the result of multiplying the width and height by its pixel
aspect ratio, the pixel count of the video does not necessarily match
that of the device playing it back.

For instance, on a DVD, both "fullscreen" and widescreen movies are
stored at the same resolutions, but with different pixel aspect ratios
(i.e., the shape of the pixels are not necessarily a 1:1 square, as on
computers).

According to the D1 & DV standards, "fullscreen" pixels have a
width-to-height ratio of 4320/4739 (~0.9). So a 720x480 "fullscreen"
image on a square-pixel device would have to be displayed at ~656x480
pixels to retain its proper aspect ratio.

By the same standards, widescreen pixels are 5760/4739 (~1.2), so a
720x480 widescreen image would have to be displayed at ~875x480
pixels.

Therefore, "screen and (min-device-width: 720px)" would not work for
all 480i/p content. Either the PAR would have to be read from the file
itself—the storage of which differs from format to format—or the
author would have to specify it. Which is also problematic since not
everyone knows what PARs are, and even when they do, not everyone uses
the same pixel shape definitions: MPEG-4 says widescreen pixels are
40/33, which is *close* to the D1/DV definition but not quite: this
results in a ~873x480 square-pixel image. And due to rounding, there
is also a conventional habit of specifying a PAR of 6/5 (exactly 1.2),
resulting in 864x480. Apple on the other hand defines it as 32/27,
resulting in ~853x480. So even with the same source content, you may
be looking at as many as 4 different rendered sizes depending on the
device manufacturer. So if you specify the PAR according to one
standard, a device built according to another may not recognize it as
playable material, even though it is fully capable of playing it back.

Though this COULD potentially be solved by taking aspect ratio error
into account when processing the media query. So say for any specified
PAR that doesn't match a PAR the device can support exactly, if the
ratios turned out to be the same rounded to a certain decimal point,
that would count as a match and the device would simply render it
according to its standards. This *somewhat* defeats the point of
specifying PARs exactly, but at least it'd be "good enough" as the
difference would be too insignificant for most people to notice.

> SD and
> HD - while also changing between aspect ratio - are mostly a choice
> between lower bandwidth use and higher bandwidth use, which are taken
> as equivalent to low and high quality by users. Since there will
> likely be a higher bitrate HD version joining in the future, it will
> then turn into SD, HD and HD2 - which equates to low, medium, high.
> Over time, SD will fall aside and leave medium and high. Then, if
> another higher quality comes in, they can be redefined to low and
> medium.
>
> Thus, keeping these "fuzzy" specifiers, we stay future-proof and leave
> the actual choice of what "low" and "high" means to the respective
> hosting site, which will make the format choice according to current
> standards.
>
> I'd prefer giving actual levels ("low", "medium", and "high") rather
> than a number between 0 and 1, because they make it comparable between
> hosting sites. If I choose to have "low" on YouTube, I will likely
> want "low" on Dailymotion and Hulu, even if those sites decided to use
> completely different encoding parameters for their "low" and "high"
> quality versions.

I can agree with this proposal as far as quality = data rate is
concerned. As for any of the other criteria, they'd have to be
addressed differently.

On Mon, Dec 14, 2009 at 10:59 AM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> It depends on the application.  But in any event, HTML can never
> possibly do everything JavaScript does, so at some point the answer
> needs to be "use JavaScript".

Nor should it. But if you're doing something in JavaScript, there
*should* be a functional alternative in plain HTML when it's turned
off. That means if you've got an AJAX application, even with JS turned
off a user should still be able to interact with the server
synchronously. If you had all of your content negotiation in JS,
however, there could be no alternative, as the lack of one would have
been the reason to use JS in the first place.

> I don't follow.  If authors *were* willing to use content negotiation,
> to the contrary, there would be no need for <source>.  You could just
> write <video src=foo></video> in your markup, and configure your
> server to serve foo.mp4 or foo.ogg depending on the incoming HTTP
> headers.  But nobody wants to do that, so the configuration has to be
> done in HTML instead.

I don't know that nobody *wants* to do that; I think most of them
simply don't know how. But either way, if HTML is how people are going
to do it, why not stick with HTML the whole way through? Why introduce
JS into the equation, effectively splitting the feature set of one
technology between two different tools?

> It makes sense to reinvent the wheel if the wheel is square.  HTTP
> content negotiation is a square wheel.

I don't think it's a square wheel. A square wheel wouldn't work. HTTP
CN works. The fact that people are willing to do something in HTML,
but are unwilling to do the very same thing in HTTP, seems to suggest
a lack of understanding of HTTP and/or its capabilities. So
theoretically, the most cost-effective solution simply would be to
educate them about HTTP. But, we've got CN in HTML now, so unless that
gets nixed, the only sensible solution to meeting user's needs in this
area is to develop it further.

> Two or three different URLs with different versions of the resource
> would do it.  You don't even need JavaScript.  But if you do use
> JavaScript, it should be as simple as
>
> <a href=lower_quality.html
> onclick="document.getElementById('myvideo').src =
> 'lower-quality.ogg'">Lower-quality version</a>
>
> (disclaimer: not tested).

This is a nice interim solution, but it also forces the user to
download a resource which may not necessarily be the most appropriate
version for them.