[whatwg] HTML5 video <source> dimensions and bitrate

[Zachary Ozer]

On Thu, Aug 12, 2010 at 10:03 PM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com> wrote:
> 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.

[It's Friday, so this is a bit more lighthearted than usual]

Completely correct. I was thinking of FMS (RTMP with dynamic
streaming) and in a momentary lapse of reason [1], wrongly believed
that the server would automatically switch bitrates when the client
hit a certain threshold of dropped frames. It's at least somewhat
ironic given that one of my favorite function names of all time is the
Flash 10 Netstream's play2() [2], which is the flux capacitor of Flash
bitrate switching: it makes dynamic streaming possible [3].

It would still be nice if the <video> made dropped frame information
available, but that's probably not in the cards.

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

Currently no, but perhaps in the future.

> 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.

Agreed. Right now we only support MRSS, but SMIL and m3u8 would all
work as well. Given that SMIL is a W3C format, it seems to be the
logical choice, no?

  [1] http://en.wikipedia.org/wiki/A_Momentary_Lapse_of_Reason
  [2] http://help.adobe.com/en_US/AS3LCR/Flash_10.0/flash/net/NetStream.html
  [3] http://www.imdb.com/title/tt0088763/quotes?qt0416300