[whatwg] More YouTube response

[Aryeh Gregor]

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
that JavaScript can handle?  What did they do?

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

> 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
to implement.

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

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