- From: Hugh Guiney <hugh.guiney@gmail.com>
- Date: Sat, 12 Dec 2009 21:32:30 -0500
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
Received on Saturday, 12 December 2009 18:32:30 UTC