On Tue, 06 Jul 2010 16:33:47 +0200, Marques Johansson <marq...@displague.com> wrote:

On Tue, Jul 6, 2010 at 10:12 AM, Philip Jägenstedt <phil...@opera.com>wrote:

On Tue, 06 Jul 2010 15:19:35 +0200, Marques Johansson <
marq...@displague.com> wrote:

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.


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.

Opera hasn't implemented support for the preload attribute yet, I'm not sure what the status of other browsers are. I suspect that once all browsers have more conservative bandwidth management, the problem will be solved.

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).

The demuxers and decoders are several layers away from the actual HTTP requests and responses, so I think the problem could be reproduced with either Ogg or WebM depending on chance.

Opera doesn't handle the case where the server returns the wrong amount of data very well. Fortunately, I've seen no live servers doing this yet.

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.

Thanks, I've noted this in our bug tracking system.

--
Philip Jägenstedt
Core Developer
Opera Software

Reply via email to