[whatwg] More YouTube response

[Philip Jägenstedt]

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

> On Tue, Jul 6, 2010 at 10:12 AM, Philip Jägenstedt  
> <philipj at opera.com>wrote:
>
>> On Tue, 06 Jul 2010 15:19:35 +0200, Marques Johansson <
>> marques at 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