[whatwg] More YouTube response
Simetrical+w3c at gmail.com
Wed Jul 7 13:16:04 PDT 2010
On Tue, Jul 6, 2010 at 5:19 PM, Marques Johansson <marques at displague.com> wrote:
> I tested cutting off the HTTP connection and browsers didn't handle this.
You mean they didn't stop playing the video and trigger an error event
> and found that browsers do not attempt to refetch the data or continue with
> a 206 for the next block.
Right, they stop playing and raise an error. This is correct if the
user has used up all their video allotment and is not allowed to view
> Shouldn't something like this be be worked into the protocol or the language
> instead of having to break the stream at a higher level?
No, because it's not a big enough use-case to get its own special
HTML-level features. Browser implementers have more important things
> prefetch="metadata" is the plan - but how far forward will the browser
> attempt to buffer? When will the browser stop buffering and start playing? I
> think the server/service/html/http side of things should have some say. I
> wouldn't want to see browser X seek 10 seconds ahead while browser Y fetches
> 60 seconds in advance.
The best way to give authors this level of control might be to expose
more functions or events to script, so the script can decide exactly
when to fetch more bytes and how much.
> As I stated before - this didn't pan out for me - I will happily test other
It didn't pan out because you weren't doing what I suggested. You
were cutting off the connection even when the user still had the right
to view more bytes. I suggested you only cut the connection when the
user is actually not allowed to view more video, in which case they'd
get an error, as they should. (This will only work if you can
persuade the browser not to buffer significantly ahead of the current
More information about the whatwg