On Sat, Aug 14, 2010 at 2:05 AM, Zachary Ozer <span dir="ltr"><<a href="mailto:zach@longtailvideo.com">zach@longtailvideo.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div class="im">On Thu, Aug 12, 2010 at 10:03 PM, Silvia Pfeiffer<br>
<<a href="mailto:silviapfeiffer1@gmail.com">silviapfeiffer1@gmail.com</a>> wrote:<br>
> As far as I am aware, the adaptive HTTP streaming approaches work with an<br>
> ordinary HTTP server such as Apache, so do not need anything special on the<br>
> server. It's more about authoring the right set of resources. The publisher<br>
> has to create a set of video copies at different bandwidth and maybe even<br>
> resolutions carefully such that switching between them can happen at<br>
> specific points. Then he puts them on the server together with a manifest<br>
> file that links to these resources and states what they provide and when<br>
> switching can happen. So, wile authoring is challenging, no new server<br>
> software is used and it also wouldn't listen to any information that the<br>
> client would want to send.<br>
><br>
> However, the big challenge is to support the switching between resources on<br>
> the client. And the client needs a gather as much information as possible<br>
> about the quality of the playback to make the switching decision. Switching<br>
> is then simply a different HTTP request. It would be nice if we had such<br>
> switching functionality available for HTML5 video.<br>
<br>
</div>[It's Friday, so this is a bit more lighthearted than usual]<br>
<br>
Completely correct. I was thinking of FMS (RTMP with dynamic<br>
streaming) and in a momentary lapse of reason [1], wrongly believed<br>
that the server would automatically switch bitrates when the client<br>
hit a certain threshold of dropped frames. It's at least somewhat<br>
ironic given that one of my favorite function names of all time is the<br>
Flash 10 Netstream's play2() [2], which is the flux capacitor of Flash<br>
bitrate switching: it makes dynamic streaming possible [3].<br></blockquote><div><br>LOL - that made my Saturday. :-)<br> <br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


It would still be nice if the <video> made dropped frame information<br>
available, but that's probably not in the cards.<br>
<div class="im"><br>
> Microsoft Smooth Streaming also uses a SMIL variant. Is yours compatible?<br>
<br>
</div>Currently no, but perhaps in the future.<br>
<div class="im"><br>
> Yes, that sounds like a sensible approach. It's also what Apple do when they<br>
> use Live Streaming: they put the m3u8 file into the @src element. It would<br>
> be nice if that was all we would need to enable adaptive HTTP streaming. It<br>
> might be good to standardise on a baseline file format for the manifest<br>
> though - unless we want to support all types of files that people will come<br>
> up with to do adaptive HTTP streaming.<br>
<br>
</div>Agreed. Right now we only support MRSS, but SMIL and m3u8 would all<br>
work as well. Given that SMIL is a W3C format, it seems to be the<br>
logical choice, no?<br></blockquote><div><br>All of SMIL is a bit much for the little need that there is. But a small subpart similar to what MS Smooth Streaming does isn't out of the books. It's something that should be investigated IMO. Just like we are investigating the different subtitle formats that can be used.<br>

<br>Sharing your experiences here and your new file format when you have something to show would be a start, IMHO.<br><br>Cheers,<br>Silvia.<br><br></div></div>