On Thu, 20 Jan 2011 01:14:12 +0100, Glenn Maynard gl...@zewt.org wrote:
On Wed, Jan 19, 2011 at 8:22 AM, Philip Jägenstedt
phil...@opera.comwrote:
If the available bandwidth exceeds the bandwidth of the resource, some
kind
of throttling must eventually be used. There are mainly 2 options
On Jan 20, 2011, at 9:14 AM, Philip Jägenstedt wrote:
(Since there is some overhead with each HTTP request, one must make sure
that they are not unreasonably small.)
When HTTP byte ranges are used to achieve bandwidth management, it's hard
to talk about a single downloadBufferTarget that
On Thu, 20 Jan 2011 04:20:09 +0100, Matthew Gregan kine...@flim.org
wrote:
Hi,
The media seek algorithm (4.8.10.9) states that the current playback
position should be set to the new playback position during the
asynchronous
part of the algorithm, just before the seeking event is fired.
On Thu, Jan 20, 2011 at 3:14 AM, Philip Jägenstedt phil...@opera.comwrote:
However, it'd be great if all implementors could agree on the same
interpretation of states. Specifically, this isn't required by the spec but
would still be helpful to have consistency in:
* effective state can only
On Jan 20, 2011, at 12:46 AM, Philip Jägenstedt wrote:
On Thu, 20 Jan 2011 04:20:09 +0100, Matthew Gregan kine...@flim.org wrote:
Hi,
The media seek algorithm (4.8.10.9) states that the current playback
position should be set to the new playback position during the asynchronous
part of
On Thu, Jan 20, 2011 at 3:14 AM, Philip Jägenstedt phil...@opera.comwrote:
* effective state can only increase to higher states, never go from e.g.
metadata to none (it makes no sense)
What if my bandwidth situation improves (moving from 3g to WiFi, for example)?
At that point, perhaps I should
On 10/22/2010 10:09 PM, Jonas Sicking wrote:
On Fri, Oct 22, 2010 at 11:15 AM, Erik Arvidssona...@chromium.org wrote:
On Oct 22, 2010 2:00 AM, Anne van Kesterenann...@opera.com wrote:
Yeah, I don't mind moving these features to libraries. Anyone implemented
them apart from Opera?
Neither
There seems to be no provision in the spec for a behavior Firefox and IE (and
now WebKit-based browsers, too) have. If window.print() is called during page
load, then its action is delayed until loading is finished.
The WebKit bug that changed this most recently is
On 2011-01-20 19:16, Zachary Ozer wrote:
== New Proposal ==
I like this. It seems you laid out everything to ensure a balanced
buffer, kinda like a moving window buffer which I pointed out earlier.
So as far as I can see, your proposal looks pretty solid, unless there
are any implementation
We never make any promises about when we'll get something into an
official release, but I think we'd start playing around with it in our
development version once a reference implementation was publicly
available.
--
Zachary Ozer
Developer, LongTail Video
w: longtailvideo.com • e:
On Thu, Jan 20, 2011 at 1:16 PM, Zachary Ozer z...@longtailvideo.com wrote:
On Thu, Jan 20, 2011 at 4:19 AM, Glenn Maynard gl...@zewt.org wrote:
I think that pausing shouldn't affect read-ahead buffering behavior. I'd
suggest another preload value, preload=buffer, sitting between metadata
and
11 matches
Mail list logo
