[whatwg] Quality Values for Media Source Elements

[Hugh Guiney]

Hey all,

So, in my first foray into preparing Theora/Vorbis content, for use
with <video>, I realized that I wasn't sure with what settings to
encode my materials. Should I:

A.) Supply my visitors with the best possible quality at the expense
of loading/playback speed for people on slower connections

B.) Just account for the lowest common denominator and give everyone a
low quality encode

or

C.) Go halfway and present a medium quality encode acceptable for
"most people"?

A. is not legacy-proof, B. is not future-proof, and the C. is neither.
C. may sound like the most sensible solution, but even if I were to
put up something that worked for "most people" *right now*, as
computers become more capable and connections become faster, more
visitors are going to want higher-quality videos, meaning I'd have to
stay on top of the relevant trends and update my pages accordingly.

Ideally, I would like to be able to simply encode a few different
quality variations of the same file and serve each version to its
corresponding audience.

There are a few ways I could do this. One of the most obvious ways
would be to present different versions of the site, e.g. one for "slow
connections" and one for "fast connections" and have the user pick via
a splash page before entering, as was popular in '90s. But this is
almost certainly a faux pas today: it puts a wall between the user and
my content, and requires me to maintain two different versions of the
site. Hardly efficient.

Another way would be to itemize each version of the file in a list,
with details next to them such as frame and file size, so the user
could pick accordingly. While this would probably be fine for
downloads, it completely defeats the point of embedded media.

Alternatively, I could devise a script that prompts users for their
connection speed and/or quality preference, which (assuming they know
it) would then go through the available resources on the server and
return the version of the file I'd have allocated to that particular
response. But that would require either branching for every file
alternative of every video on my site in the script—or specifying the
quality in some other way that can be programmatically exploited;
perhaps using microdata, but then I'd be stuffing the fallback content
with name-value pairs, which isn't particularly accessible.

Or, I could invent my own HTTP header and try to get everyone to use
it. Which is a lot to do for something like this, and isn't guaranteed
to work.

None of these options seem particularly viable to me. Right now, the
HTML5 spec allows UAs to choose between multiple versions of a media
resource based on type. In the interest of making media more
accessible to users of varying bandwidth and processing power, and
easier to maintain for authors, I propose allowing the relative
quality of each resource to be specified for multiple-source media.

You will notice that in Flash animations, there is a context menu
option to change the rendered quality between "High", "Medium", and
"Low". Each setting degrades or upgrades the picture, and requires
less or more computing power to process respectively. Additionally,
some Flash video authors elect to construct their own quality
selection UI/scripting within the video itself, allowing them to have
a finer degree of control over the presentation of the image.

Similarly, YouTube has the ability to switch between standard quality,
high quality, and high definition videos based on users' preferences.
In the "Playback Setup" section of "Account Settings", you will find
the following options:

"Video Playback Quality
Choose the default setting for viewing videos
* Choose my video quality dynamically based on the current connection speed.
* I have a slow connection. Never play higher-quality video.
* I have a fast connection. Always play higher-quality video when it's
available."

If HTML video is to compete with Flash, or become implemented on as
wide a scale as YouTube <http://www.youtube.com/html5>, it makes sense
to allow for some sort of quality choice mechanism, as users will have
come to expect that functionality.

This could be done by allowing an attribute on <source> elements that
takes a relative value, such as (or similar to) those specified in
HTTP <http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.9>.
This attribute could be called "quality" or "qvalue" or just "q" (my
personal preference would be it that order decreasing), and be used as
such:

<video controls>
  <source src='video-hd.ogv' quality='1.0' type='video/ogg;
codecs="theora, vorbis"'>
  <source src='video-hq.ogv' quality='0.5' type='video/ogg;
codecs="theora, vorbis"'>
  <source src='video-sd.ogv' type='video/ogg; codecs="theora, vorbis"'>
</video>

In this case, video-hd.ogv (a high definition encode) would be the
author's preferred version, video-hq.ogv (a high quality standard
definition encode) would be less preferred than video-hd.ogv, but more
preferred than video-sd, and video-sd (a standard definition encode)
would be less preferred than both, since it lacks a quality attribute
and would thus be the equivalent of specifying "quality='0.001'".

The UA could then have a playback setup that would allow the user to
specify how it should handle content negotiation for multiple-source
media. This could be based solely on the quality attribute if
provided, or if @type is also provided, also based on what
content-type the user prefers.

Please let me know what you think of this.

Thank you,
Hugh