[whatwg] Video source selection based on quality
Mikko Rantalainen
mikko.rantalainen at peda.net
Fri Feb 19 06:31:30 PST 2010
David Singer wrote:
> I am by no means convinced that automatic selection of sources other
> than that based on the most obvious, automated, criteria, is wise or
> needed. We have had for many years, in QuickTime, this facility, and
> quite a few sites opted not to use it and allow the user a manual
> choice instead.
Was it ever investigated *why* they opted not to use it? Perhaps the
automatic selection was somehow incorrectly implemented instead of being
just a bad idea?
> For example, bit-rate is important when watching a streaming movie
> (it has to arrive in time), but many users wanting to watch a trailer
> loaded over HTTP apparently choose to put up with longer downloads in
> order to watch higher resolution content.
These are two different use cases and preferably the user is able to
inform their UA which one they prefer. Most of the time I'd rather get a
streaming movie unless I specifically know that I want the best quality
no matter how long I have to wait (the latter case being a special case).
I think it's important the get the default stream correctly selected but
allow for manual override for those special cases. Forced automatic
detection is even worse than forced manual selection.
> Offering the user a 'quality' based selection is, in a sense,
> pointless; why not show the user the best quality (all other things
> being equal)? The answer is that they aren't - that bitrate
> (sometimes) matters.
I'd suggest two somewhat simple parameters for a movie to describe the
quality: actual average bitrate and virtual average MPEG2 bitrate. I'll
explain these below.
The actual average bitrate is simple, it's the duration of the binary
file divided by the length of the movie in seconds. I don't care if this
is Mbps or kBps as long as we have some clear definition. This is needed
for the streaming case: UA shouldn't automatically select a movie for
streaming that has higher average bitrate than the current data
connection can transfer.
The virtual average MPEG2 bitrate is a bit more complex. This should be
the approximated bitrate of MPEG2 movie with similar resolution and
quality. This could be considered as the quality parameter. MPEG2 is
pretty well known and it's bitrate pretty nicely correlates with the
resulting image quality regardless of the actual encoder used. Higher
end codecs usually allow lower bitrate with similar quality. For
example, for a given H.264 movie the virtual MPEG2 bitrate parameter
should be about 2x or 4x the actual bitrate. The multiplier could be
static for each codec or it could be computed for real by encoding the
actual video with MPEG2 encoder.
Rationale: if we forget about different codecs for a moment and just
think about MPEG2, I claim that the bitrate is a better meter for the
quality than e.g. the image resolution in pixels (module the case where
the user of the encoder uses absurdly high bitrates for low resolution).
For example, a 1920x1080p MPEG2 movie is not really high quality if it
has bitrate of 1Mbps. On the other hand, a 720x576p MPEG2 movie is high
quality if it has bitrate of 20Mbps. So it makes sense to base the
quality to the bitrate of MPEG2 movie. And the output of more complex
codec with better compression can be compared to MPEG2 movie of similar
quality. Once we have a baseline (MPEG2) we can express other stuff
compared to that. As a bonus, it seems that processing power required to
decompress video seems to be somewhat related to resulting image
quality. As a result, the virtual MPEG2 bitrate can be understood as
processing requirement, too. It would, of course, be possible to
introduce a third parameter that would describe the processing
requirements as a virtual MPEG2 bitrate: if a codec required 10x the
processing power of MPEG2 to decompress, then this parameter should be
set to 10x the actual bitrate.
--
Mikko
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100219/cbfade16/attachment-0001.pgp>
More information about the whatwg
mailing list