[whatwg] HTML 5 : The Youtube response

On Wed, Jun 30, 2010 at 5:02 PM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> Why doesn't the server just stop sending when the user hits the limit,
> maybe adding some filler frames to tell the user why the video ended?
> Pay-per-minute/pay-per-byte are very unimportant use-cases right now
> anyway, though. ?The overwhelming majority of video that people watch
> on the web is downloaded free, and that's what we need to focus on
> now.

If the server stops sending (via HTTP) at some limit unknown to the UA
(via HTTP) there is no defined behavior that would allow the UA to
handle this without client side scripting and even that seems bleak.

How do you propose the server "just stop sending"?  I've tried a few
different methods and none of them really work.

Client: "Range:0-", Server: "Status:206" "Content-Range:
bytes=0-99/10000" - HTTP spec doesn't define what to do here, only
Chrome will continue to fetch.

Client: "Range:0-", Server: "Status:206" "Content-Length: 10000" (then
only send 100 bytes) and disconnect - This is telling the client
misinformation, but the UAs I tested don't come back to fetch where
the disconnect occurred. I also tried this without Ranges using 200
responses.

I considered that I could use javascript to tell the browser to keep
seeking to the next second just as the second approaches but aside
from introducing a very noticeable delay there is no way to telling
the UA to only fetch the next X bytes.  So when the server responds
with less data than the client range requested (Range: 100000-) UAs
will handle this in the ways described above.  Chrome will send
additional requests while other browsers will stop playing or not seek
to the new location at all based on previous short range responses
(since they think they already fetched the entire document).

Even when the video is free as in beer it isn't necessarily free in
the liberty sense.  Content distributors need to control what the UA
fetches and the rate at which they attempt to fetch it (keeping it
near realtime to control ad distribution and deter wholesale
theft/copying).

The suggestions I am making would also be useful for free videos as it
could be used to relieve server congestion.  We are dealing with
100mb+ video files that each carry a real world dollar value in server
time, bandwidth, and production value.  The distribution schemes have
to change from how 10k html and 60k images were handled.

Received on Wednesday, 30 June 2010 15:05:12 UTC