W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2010

[whatwg] More YouTube response

From: Marques Johansson <marques@displague.com>
Date: Tue, 6 Jul 2010 10:33:47 -0400
Message-ID: <AANLkTini3AdVUQm8cV___L6tKEfxe8sPD-ZunyNeV_cK@mail.gmail.com>
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.

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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100706/85c87eb6/attachment.htm>
Received on Tuesday, 6 July 2010 07:33:47 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:24 UTC