[whatwg] Quality Values for Media Source Elements

[Silvia Pfeiffer]

On Mon, Dec 14, 2009 at 6:59 PM, Hugh Guiney <hugh.guiney at gmail.com> wrote:
>
> On Mon, Dec 14, 2009 at 12:12 AM, Eric Carlson <eric.carlson at apple.com> wrote:
>>  Certainly! WebKit evaluates the query in the 'media' attribute if it believes it can handle the MIME type. If the query evaluates to true, it uses that <source> element. If it evaluates to false it skips it, even though it could (in theory) open the movie. For example, one of our layout tests [1] has the following :
>>
>> <video controls>
>>    <source src=content/error.mpeg media="print">
>>    <source src=content/error2.mpeg media="screen and (min-device-width: 80000px)">
>>    <source src=content/test.mp4 media="screen and (min-device-width: 100px)">
>> </video>
>>
>>  The test fails if the video element is instantiated with anything but "test.mp4".
>
> This seems extremely useful. How many media features are implemented?
>
> Currently, though, the CSS3 Media Query spec doesn't cover enough
> metadata to make this as useful as it could be.
>
> On Mon, Dec 14, 2009 at 1:54 AM, Silvia Pfeiffer
> <silviapfeiffer1 at gmail.com> wrote:
>> Indeed it seems to me the solution to the "quality" problem should
>> then be done through the media attribute. I am not sure yet how to,
>> because we have no definition for what a "low quality" or "high
>> quality" video is other than some form or SD vs HD and lower
>> resolution vs higher resolution and lower bandwidth vs higher
>> bandwidth.
>
> Well, we could certainly define them as they'd be defined *today*, but
> as HD becomes more and more commonplace it will effectively stop being
> "high definition", even if the name sticks. And, what one person
> considers "low quality", another person may consider "high quality",
> and vice-versa, depending on the capabilities of their machine and the
> type of content they're used to seeing. Which is why it doesn't make
> sense to specify absolutes, and why I proposed using relative values.
>
> If we're to be more granular though, the biggest barrier to
> implementation is the fact that, as you said, video is
> multi-dimensional: there are MANY different factors that can affect
> quality, viewing preference, and/or playback compatibility. Here is a
> non-comprehensive list off the top of my head:
>
> * Aspect Ratio (or Width and Height)
> * Pixel Aspect Ratio (or Relative Pixel Width and Relative Pixel Height)
> * Display Aspect Ratio (or AR / W & H and PAR / PW & PH)
> * Content Aspect Ratio (or Content Width and Content Height)
> * Sample Rate (or Rate and Scale)
> * Bit Rate
> * Frame Type or Picture Type, i.e. spatial/temporal compression technology
> * Frame Scan Type (Progressive / Interlaced)
> * Field Order (None / Top Field First / Bottom Field First)
> * Colorimetry
> * Codec
> * Container Format
> * Telecine Pattern
> * Dimensionality (2D, 3D, Panoramic, etc.)
> * Audio Channels
> * Audio Sample Rate
> * Audio Bit Rate
> * Audio Codec
>
> Even if all of this metadata were converted to media features, most
> people wouldn't even know what most of it means. There is a tremendous
> amount of misinformation out there about video technology; when it's
> accurate it is almost always confusing. Even as a digital video
> professional, I often have to explain a lot of these concepts to my
> peers. So unless HTML authors are also fairly technical people with
> video backgrounds, chances are most of it wouldn't end up being used.
>
> Still though, implementing even just a subset of these would improve
> media selection by a lot.
>

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. 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.

Cheers,
Silvia.