W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2012

Re: [whatwg] <source>s in <video> by quality as well as codec

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 5 Jun 2012 21:54:23 +0000 (UTC)
To: Rodger Combs <rodger.combs@gmail.com>
Message-ID: <Pine.LNX.4.64.1206052153120.378@ps20323.dreamhostps.com>
Cc: whatwg@lists.whatwg.org
On Tue, 21 Feb 2012, Rodger Combs wrote:
> I propose that <source> add a quality, bitrate, or filesize attribute to 
> allow the UA to decide between multiple streams by choosing the maximum 
> quality file that it can download within a reasonable amount of time 
> (e.g. it will download faster than it will play) or based on a user 
> preference (e.g. prefer SD quality, or always use HD when provided). It 
> should also be possible to retrieve a list of the <source>s the UA can 
> play in JS, and switch between them by user action (either a JS call for 
> a custom UI or a dropdown in the builtin UI), loading the new file and 
> switching to it with minimal skipping. This way, a site like YouTube, 
> which presents several files in various bitrates and codecs, can allow 
> the user to choose to use a higher quality without having to force an 
> src attribute on the video, and a mobile UA that roams from 3G to WiFi 
> or moves close to a base station can increase the quality of its stream. 
> I think it fits in well with the purpose of the source element. This is 
> certainly open for modification, but I think it's a good concept in 
> essence.

If this is for a site like YouTube, I think an adaptive network channel 
would be a more effective solution (i.e. one where the download adapts in 
real time to changing network conditions, with the endpoints negotiating 
with each other regarding what to transmit).

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 5 June 2012 21:54:51 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:43 UTC