[whatwg] Quality Values for Media Source Elements

[Hugh Guiney]

On Sat, Dec 12, 2009 at 9:57 PM, Nils Dagsson Moskopp
<nils-dagsson-moskopp at dieweltistgarnichtso.net> wrote:
> What about a simple drop-down beside an embedded media resource ?

That would require either JS, so people with it turned off wouldn't
get the same benefit, or a form, in which case you need a server-side
script to handle it and a page refresh for every video.

You *could* prompt only once, store the preference server-side, and
apply it to all videos on the site. But let's say a user-agent
supports both codec X and codec Y. A user may want high-quality codec
X videos if they're available, but low-quality codec Y videos if
they're not, because codec Y slows down their computer at higher bit
rates. If you only have a codec Y-encoded version of your video,
giving them the "high quality" version, even if they've chosen that,
will hurt their browsing experience. You could indicate the codec in
text, but that's redundant information if it's already been specified
in @type; plus it's not going to be relevant to everyone as some
people don't even know what a codec is.

> Specifying a bit rate would be vastly more appropriate IMO.

Not everyone knows the bit rate of their video files. Most simple
video authoring tools prompt for as little as "Input Filename" and
"Output Filename" with a "Convert" button on the bottom. Using a
relative scale means that authors can infer a perceived quality based
on the image itself.

Bear in mind also that the same bit rates can result in
differently-perceived quality depending on the codec. A 4 Mb/s MPEG-4
may look better than a 4 Mb/s MPEG-2, etc. So comparing bit rate
values without also comparing type values and knowing ahead of time
what those values conjoined infer is pointless.

Additionally, some bit rates are variable, so they don't have a single
value to represent them unless you take the average.

On Sat, Dec 12, 2009 at 10:06 PM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> The usual tactic taken by popular video sites today is to provide
> multiple quality levels, serve one by default, and give the user an
> option to choose their preferred quality level.  For Flash video, you
> might use some kind of Flash script, while for HTML video, you'd use
> JavaScript and/or hyperlinks, but the effect is pretty much the same.
> HTML video seems to be precisely on par with Flash video in this
> regard right now.

With the exception that Flash does not need separate components to be
active to sustain that functionality. You can toggle quality in Flash
without any server- or client-side scripts at all. You may need
ActionScript in some cases, but that's an integral part of Flash,
whereas JavaScript, PHP, etc. are not integral parts of HTML.

> I don't think the proposed syntax is useful if you use a
> floating-point number with no fixed scale for quality.  Different
> sites would use the same number to mean different things, so users
> couldn't usefully specify a global preference.

But that is exactly how content negotiation in HTTP already works. You
can specify, server-side, that you prefer sending GIFs to JPEGs, so if
you have both and a user doesn't tell you what they want, they get a
GIF. If they explicitly state they want a JPEG though, then they get a
JPEG. It could be that some sites only encode low-quality JPEGs with
tons of artifacts that look horrible, but that's their fault, not the
negotiation system's. And, as stated, bit rates are even less
reliable.

> I'm not sure the benefit of permitting quality preferences to be set
> across all sites would end up being worth it.  Users are probably
> happy enough setting them per site, especially since different sites
> might have better or worse video for a given bitrate (or any
> artificial quality metric you might think up).

I for one would rather not go to such trouble. Can you imagine going
to every site you visit and specifying that you want XHTML instead of
HTML, rather than just specifying
"application/xhtml+xml;q=1.0,text/html;q=0.0," in your request
headers? I don't see why embedded media selection should be any
different from regular media selection.