[whatwg] Video source selection based on quality (was: <video> feedback)

On 16 February 2010 16:08, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Tue, Feb 16, 2010 at 10:33 AM, Tim Hutt <tdhutt at gmail.com> wrote:
>> It's up the UA.
>
> Imagine that you are a user-agent. Place these streams in order of "quality":
>
> 1. ?854x480 4:2:0 @ ?1mbit/sec. average rate.
> 2. 1280x720 4:2:0 @ ?1mbit/sec. average rate.
> 3. ?640x360 4:4:4 @ ?2mbit/sec. average rate.

My point exactly. There is no single 'quality' metric, so the best we
can do is give the user agent the relevant information and let it
decide.

> I don't think it's hard to imagine that in each of these cases there
> exists a real "quality" ranking which the creator of the videos could
> be well aware of, but that no user-agent could determine
> automatically.

No I think the user agent is in the best position to decide. Let's
think about this logically. The only factors affecting the choice are:

1. Hardware specs of the player.
2. Bandwidth of the network connection.
3. Data cost of the connection.

These are both best known by the UA (or the user for 3.). Consider the
following examples:

* A phone with hardware mpeg4 decoding (so it's not only video quality
that comes into the decision; codec too).
* A user with a slow computer (no 720p) but a very fast network
connection (this was me until recently).
* A user with a fast computer, but a monthly data cap.

In each case the UA (or the user) is in a much better position to
decide than the content author. There's probably no foolproof
preference function, but that doesn't mean we shouldn't try to make an
educated choice, and give the user the option to override it.

> Moreover, even the "switch to a lower rate if you are exhausting your
> buffer" isn't a necessary a good strategy when the 'lower rate' stream
> is one which places more buffer pressure.

Again, it will be the best option in 99% of cases, and all we'd be
doing is making a helpful suggestion to the user. Do you have a better
suggestion?

Received on Tuesday, 16 February 2010 09:27:34 UTC