- From: Zachary Ozer <zach@longtailvideo.com>
- Date: Fri, 13 Aug 2010 12:05:43 -0400
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
Received on Friday, 13 August 2010 09:05:43 UTC