[whatwg] HTML5 video <source> dimensions and bitrate
zach at longtailvideo.com
Fri Aug 13 09:05:43 PDT 2010
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 , 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() , which is the flux capacitor of Flash
bitrate switching: it makes dynamic streaming possible .
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?
More information about the whatwg