W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2010

[whatwg] HTML5 video <source> dimensions and bitrate

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Wed, 11 Aug 2010 10:26:51 +1000
Message-ID: <AANLkTi=xp+BdBWKouXR-opzaxsf6tvAgLdadf+ws7JAd@mail.gmail.com>
On Wed, Aug 11, 2010 at 2:35 AM, Zachary Ozer <zach at longtailvideo.com>wrote:

> On Mon, Aug 9, 2010 at 8:05 PM, Silvia Pfeiffer
> <silviapfeiffer1 at gmail.com> wrote:
> > Have you looked at the @media attribute? I would suggest to put them
> there.
> > As that's not currently specified in media queries, you might want to
> > demonstrate how it could work and make a proposal to extend the media
> > queries.
>
> I thought about suggesting something like bitrate a bandwidth to media
> queries. The syntax would look something like:
>
> <video width=720>
> <source src="video-480.mp4" media="(width:480px) and (min-bitrate:2mbps)">
> <source src="video-720.mp4" media="(width:720px) and (min-bitrate:4mbps)">
> <source src="video-1080.mp4" media="(width:1080px) and
> (min-bitrate:20mbps)">
> </video>
>
> The problem is that the user agent would have to then know what
> bitrate can be supported between you and that source. User agents
> don't currently keep track of this information (so far as I'm aware),
> and even if they did, it's highly variable based on your location, the
> website you're visiting, etc.
>
> Additionally, while media queries do help content producers specify
> which resource would be selected for a device under ideal
> circumstances, it doesn't really allow for degradation. However, if
> you look at what's out there today, it's pretty common to allow users
> to switch to a degraded experience as needed.
>
> I can think of a few solutions that might make sense here:
>
>  * Allow source sub-elements / groupings and provide a call to switch
> between elements of a group. Ideally, this would look something like:
>
> <video width="720px">
> <sourcegroup type="video/mp4" media="screen and (device-aspect-ratio:
> 16/9)">
> <source src="video-1080.mp4"
> meta="width:1920px;height:1080px;bitrate:20mbps;">
> <source src="video-720.mp4"
> meta="width:1280px;height:720px;bitrate:4mbps;">
> </sourcegroup>
> <sourcegroup type="video/mp4" media="screen and (device-aspect-ratio:
> 4/3)">
> <source src="video-480.mp4" meta="width:640px;height:480px;bitrate:2mbps;">
> </sourcegroup>
> <sourcegroup type="video/ogv">
> <source src="video-480.ogv" meta="width:640px;height:480px;bitrate:2mbps;">
> <source src="video-720.ogv"
> meta="width:1280px;height:720px;bitrate:4mbps;">
> <source src="video-1080.ogv"
> meta="width:1920px;height:1080px;bitrate:20mbps;">
> </sourcegroup>
> </video>
>
>  * Have user agents keep track of information about dropped frames.
> Publishers could then list multiple valid sources in order of rank.
> When the dropped frame rate increased, either the user agent or a bit
> of JavaScript could remove that source and re-run the resource
> selection algorithm.
>


It's good to have thought this through. I agree, this isn't a workable
solution, since the whole bandwidth switching logic is introduced into the
browsers, when in fact it should happen in the media framework with
information from the network stack without a need for the Web page to even
be aware of this. After all, it's really different versions of the same
resource that we are dealing with. That's also what happens in adaptive HTTP
streaming solutions of Apple, MS, Adobe and MPEG-4.

So, to generalise this, I agree there should be a solution such as what
Chris Double is suggesting with an additional resource describing what files
can be switched between and then JavaScript doing the switching. This could
eventually also be introduced into HTML5, if it's done with the same
additional resource format for all video formats. In this case, would you
still require an additional attribute?

Cheers,
Silvia.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100811/475f7a17/attachment-0001.htm>
Received on Tuesday, 10 August 2010 17:26:51 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:59 UTC