[whatwg] HTML5 video <source> dimensions and bitrate

[Silvia Pfeiffer]

On Fri, Aug 13, 2010 at 1:17 AM, Zachary Ozer <zach at longtailvideo.com>wrote:

> On Tue, Aug 10, 2010 at 8:26 PM, Silvia Pfeiffer
> <silviapfeiffer1 at gmail.com> wrote:
> > 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.
>
> Absolutely - though these types of solutions are generally out of the
> reach of the average publisher. Even in that case, the server would
> (probably) want information about dropped frames from the client.
>

As far as I am aware, the adaptive HTTP streaming approaches work with an
ordinary HTTP server such as Apache, so do not need anything special on the
server. It's more about authoring the right set of resources. The publisher
has to create a set of video copies at different bandwidth and maybe even
resolutions carefully such that switching between them can happen at
specific points. Then he puts them on the server together with a manifest
file that links to these resources and states what they provide and when
switching can happen. So, wile authoring is challenging, no new server
software is used and it also wouldn't listen to any information that the
client would want to send.

However, the big challenge is to support the switching between resources on
the client. And the client needs a gather as much information as possible
about the quality of the playback to make the switching decision. Switching
is then simply a different HTTP request. It would be nice if we had such
switching functionality available for HTML5 video.



>
> > 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?
>
> We do this currently with SMIL files, which have all the necessary
> information.


Microsoft Smooth Streaming also uses a SMIL variant. Is yours compatible?


> In that case the only thing I could imagine be necessary
> is some sort of flag to indicate that the file listed as the src isn't
> the actual file to be played, but rather a list of resources.
>

Yes, that sounds like a sensible approach. It's also what Apple do when they
use Live Streaming: they put the m3u8 file into the @src element. It would
be nice if that was all we would need to enable adaptive HTTP streaming. It
might be good to standardise on a baseline file format for the manifest
though - unless we want to support all types of files that people will come
up with to do adaptive HTTP streaming.

Cheers,
Silvia.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100813/529cfe84/attachment-0002.htm>