On Wed, 21 Jul 2010 21:01:08 +0200, Paul Ellis <[email protected]>
wrote:
On Wed, Jul 21, 2010 at 11:45 AM, Philip Jägenstedt
<[email protected]>wrote:
On Wed, 21 Jul 2010 20:22:44 +0200, Paul Ellis
<[email protected]>
wrote:
On Wed, Jul 21, 2010 at 3:49 AM, Philip Jägenstedt <[email protected]
>wrote:
On Wed, 21 Jul 2010 00:20:37 +0200, Paul Ellis
<[email protected]
>
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
