- From: Conrad Parker <conrad@metadecks.org>
- Date: Wed, 17 Feb 2010 12:05:50 +0900
On 17 February 2010 02:27, Tim Hutt <tdhutt at gmail.com> wrote: > 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. Perhaps, but why are you suggesting that HTML is the correct place to offer that information? In the case of embedding videos from a separate video hosting site there are two content authors involved: the hosting site with the actual video files, and the HTML author. If the hosting site chooses to provide new encodings of a file to meet demand then this would require changes in the embedding HTML, but this is unlikely to happen as it is published by a different content producer. For handling bitrate selection (and bitrate adaptation) I think it's more useful to provide a resource description file, under control of the video host, as the video source URL. The mechanism for selecting the media to load, and for adapting to changes in available bandwidth over time, are then up to the media type -- as is the case with current adaptive streaming schemes. Bitrate information is important, particularly for popular videos which are embedded all over the web. However I don't think HTML is the correct place for providing that bitrate information. Conrad.
Received on Tuesday, 16 February 2010 19:05:50 UTC