- From: Philip Jägenstedt <philipj@opera.com>
- Date: Wed, 21 Jul 2010 21:46:45 +0200
- To: "Paul Ellis" <paul@ellisfoundation.com>
- Cc: "Ron Reiter" <ron.reiter@gmail.com>, "Daniel Hendrycks" <kondo8@hotmail.com>, "public-html-comments@w3.org" <public-html-comments@w3.org>
On Wed, 21 Jul 2010 21:01:08 +0200, Paul Ellis <paul@ellisfoundation.com> wrote: > On Wed, Jul 21, 2010 at 11:45 AM, Philip Jägenstedt > <philipj@opera.com>wrote: > >> On Wed, 21 Jul 2010 20:22:44 +0200, Paul Ellis >> <paul@ellisfoundation.com> >> wrote: >> >> On Wed, Jul 21, 2010 at 3:49 AM, Philip Jägenstedt <philipj@opera.com >>> >wrote: >>> >>> On Wed, 21 Jul 2010 00:20:37 +0200, Paul Ellis >>> <paul@ellisfoundation.com >>>> > >>>> wrote: >>>> >>>> Any solution that requires creating another window and opening a new >>>> >>>>> document would create a lot of issues that would not compare >>>>> favorably >>>>> with >>>>> any current popular web video plugin (Flash, Silverlight, etc). It >>>>> would >>>>> not >>>>> be a very seemless transition. The <video> resource from the parent >>>>> page >>>>> may >>>>> have downloaded hundreds of MB of data and then the new window would >>>>> make >>>>> a >>>>> new separate request for the same resource. Certainly the browsers >>>>> could >>>>> try >>>>> to aggressively cache video content for these situations but even >>>>> that >>>>> wouldn't work in all cases (any HTTP connection that doesn't allow >>>>> byte >>>>> range requests, e.g. HTTP 1.0), and it probably would not work very >>>>> well >>>>> for >>>>> resource constrained devices such as smartphones and tablets. This >>>>> type >>>>> of >>>>> hand-off would have to happen every time the user switched between >>>>> fullscreen and embedded mode as well. >>>>> >>>>> >>>> Browsers can and do cache resources that don't support byte ranges. >>>> About >>>> the topic at hand, I think the experience we want is to click a >>>> button or >>>> select "fullscreen" in the context menu, causing an element to go to >>>> fullscreen, still with the possibility of rendering some content on >>>> top >>>> of >>>> it, for custom controls and the like. >>>> >>>> >>> I suppose I wasn't clear in what I meant. Clearly browsers can cache >>> resources that don't support byte ranges. I was pointing out that if a >>> new >>> connection is made for a resource that has previously only been >>> partially >>> downloaded/cached, then the browser would not be able to resume the >>> download. It must start downloading the resource from the beginning. >>> >> >> This also isn't the case, we can and do cache just part of the resource >> and >> reuse that as long as it stays in the cache. I don't know what other >> browsers do. > > > You could still use the cached portion, but to get beyond the partially > cached portion the browser will have to re-download all of the data that > has > already been cached. So if a video has previously been 50% > downloaded/cached > and a new request is made for that video to resume playback at 50% of the > way into the video then the the only way the video can resume playback > is to > start a download from the beginning of the file. Right, for a server that doesn't support byte ranges, that's what will happen. > I know that it would seem like an edge case that sites would want to > stream > video using HTTP 1.0 or with range requests disabled but it has been my > experience working on the DivX Web Player that it is much more common > than > you would expect. The direction being proposed in the Mozilla wiki for > fullscreen would work fine in this scenario. My comments were directed at > the original post in this thread. OK, let's leave it at that :) -- Philip Jägenstedt Core Developer Opera Software
Received on Wednesday, 21 July 2010 19:47:29 UTC