<div><div><div class="gmail_quote">On Tue, Jul 6, 2010 at 10:12 AM, Philip Jägenstedt <span dir="ltr"><<a href="mailto:philipj@opera.com">philipj@opera.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div><div></div><div class="h5">On Tue, 06 Jul 2010 15:19:35 +0200, Marques Johansson <<a href="mailto:marques@displague.com" target="_blank">marques@displague.com</a>> wrote:<br><br></div></div>
Is preload="none" not enough? I can't imagine the actual bandwidth savings of more fine-grained control to be significant, probably any attempt by the browser to stop buffering after some time is good enough.</blockquote>

<div><br></div>I have been using preload="metadata" in my testing.  If the browser fetches the metadata then they should be able to seek through the video more easily and should have all the information they need to make partial requests with upper bounds.  Again - I have no HTML or HTTP way to suggest the UA only take X many bytes for now and come back later for more.<div>

<br></div><div>Since I see you are with Opera - I noticed that Opera will play ogg files in a different way than webm files.  The ogg handler will handle short 206 responses by making requests for the next range (client requests 0-10, server responds with a 206 status, bytes 0-5, client plays then fetches bytes 6-10).  The webm handler will only play the range that was sent in the initial 206 (client requests 0-10, server responds with a 206 status, bytes 0-5, client stops playing).</div>

<div><br></div><div>I also noticed that Opera will ignore no-cache headers on video content so a 206 fragment marked as no-cache can be rewinded and replayed without making additional requests.  Chrome refetches the data.  Looking at this as a pure HTTP matter I believe Chrome is taking the correct action.</div>

</div></div></div>