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. This implies
the following behaviour:
0. Initial load state (currentTime reports 0)
On Wed, Jan 19, 2011 at 8:22 AM, Philip Jägenstedt wrote:
> If the available bandwidth exceeds the bandwidth of the resource, some kind
> of throttling must eventually be used. There are mainly 2 options for doing
> this:
>
> 1. Throttle at the TCP level by not reading data from the socket (not a
On Wed, Jan 19, 2011 at 11:14 AM, Zachary Ozer wrote:
> Two ideas just struck me:
>
> == Network API calls ==
>
> What if, instead of trying to solve this problem, we leave it up to
> the publishers. The current behavior would be unchanged, but we could
> add explicit bandwidth management API call
On Wed, 19 Jan 2011 17:14:23 +0100, Zachary Ozer
wrote:
Two ideas just struck me:
== Network API calls ==
What if, instead of trying to solve this problem, we leave it up to
the publishers. The current behavior would be unchanged, but we could
add explicit bandwidth management API calls, ie
Two ideas just struck me:
== Network API calls ==
What if, instead of trying to solve this problem, we leave it up to
the publishers. The current behavior would be unchanged, but we could
add explicit bandwidth management API calls, ie startBuffer() and
stopBuffer(). This would let developers / s
On Wed, 19 Jan 2011 10:42:01 +0100, Aryeh Gregor
wrote:
On Mon, Jan 17, 2011 at 6:41 PM, Jeroen Wijering
wrote:
We are getting some questions from JW Player users that HTML5 video is
quite wasteful on bandwidth for longer videos (think 10min+). This
because browsers download the entire m
On Wed, 19 Jan 2011 11:59:12 +0100, Anton Kovalyov
wrote:
I work as a front-end engineer at Disqus. We are pretty popular
commenting widget installed on around 500k websites throughout the world
and visited by 300mln+ unique visitors per month. I am working on a
project to gather some stat
Hello,
I work as a front-end engineer at Disqus. We are pretty popular commenting
widget installed on around 500k websites throughout the world and visited by
300mln+ unique visitors per month. I am working on a project to gather some
statistical data from the pages where our code is running to he
On Mon, Jan 17, 2011 at 6:41 PM, Jeroen Wijering
wrote:
> We are getting some questions from JW Player users that HTML5 video is quite
> wasteful on bandwidth for longer videos (think 10min+). This because browsers
> download the entire movie once playback starts, regardless of whether a user
>
On Mon, 17 Jan 2011 22:41:17 +0100, Robert O'Callahan
wrote:
One solution that could work here is to honour dynamic changes to
'preload',
so switching preload to 'none' would stop buffering. Then a script could
do
that, for example, after the user has paused the video for ten seconds.
Th
On Wed, 19 Jan 2011 05:01:14 +0100, Rob Coenen
wrote:
I'm really happy to see that Chromium has landed a fix for frame-accurate
seeking, making SMPTE timecode compliant operations with HTML5 video
possible.
The fix for Firefox is underway (
https://bugzilla.mozilla.org/show_bug.cgi?id=626273
11 matches
Mail list logo
