quality, bitrate and filesize can all be calculated from those metrics
and it can all be done automatically. So, if you give a list of
<source> elements and those metrics are provided by the browser
through the IDL, the switching that you're asking for will be made
possible.

On Fri, Feb 24, 2012 at 4:22 PM, Rodger Combs <[email protected]> wrote:
> While they're useful, I don't see how those bugs add the functions I 
> proposed. Am I missing something, or are you just asking for input on a 
> related topic? If so, I think those seem pretty nice.
>
> On Feb 23, 2012, at 11:09 PM, Silvia Pfeiffer wrote:
>
>> I'd be curious what you think about the proposal at
>> http://wiki.whatwg.org/wiki/Video_Metrics which is being addressed
>> through bugs https://www.w3.org/Bugs/Public/show_bug.cgi?id=14970 and
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=12399 .
>>
>> Regards,
>> Silvia.
>>
>> On Wed, Feb 22, 2012 at 11:06 AM, Rodger Combs <[email protected]> 
>> 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.
>

Reply via email to