On Fri, Aug 13, 2010 at 1:17 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 Tue, Aug 10, 2010 at 8:26 PM, Silvia Pfeiffer<br>
<<a href="mailto:silviapfeiffer1@gmail.com">silviapfeiffer1@gmail.com</a>> wrote:<br>
> It's good to have thought this through. I agree, this isn't a workable<br>
> solution, since the whole bandwidth switching logic is introduced into the<br>
> browsers, when in fact it should happen in the media framework with<br>
> information from the network stack without a need for the Web page to even<br>
> be aware of this. After all, it's really different versions of the same<br>
> resource that we are dealing with. That's also what happens in adaptive HTTP<br>
> streaming solutions of Apple, MS, Adobe and MPEG-4.<br>
<br>
</div>Absolutely - though these types of solutions are generally out of the<br>
reach of the average publisher. Even in that case, the server would<br>
(probably) want information about dropped frames from the client.<br></blockquote><div><br>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.<br>

<br>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.<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;">
<div class="im"><br>
> So, to generalise this, I agree there should be a solution such as what<br>
> Chris Double is suggesting with an additional resource describing what files<br>
> can be switched between and then JavaScript doing the switching. This could<br>
> eventually also be introduced into HTML5, if it's done with the same<br>
> additional resource format for all video formats. In this case, would you<br>
> still require an additional attribute?<br>
<br>
</div>We do this currently with SMIL files, which have all the necessary<br>
information.</blockquote><div><br>Microsoft Smooth Streaming also uses a SMIL variant. Is yours compatible?<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

 In that case the only thing I could imagine be necessary<br>
is some sort of flag to indicate that the file listed as the src isn't<br>
the actual file to be played, but rather a list of resources.<br></blockquote><div><br>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.<br>

<br>Cheers,<br>Silvia.<br></div></div><br>