On Wed, 19 Jan 2011 05:01:14 +0100, Rob Coenen coenen@gmail.com
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 (
On Mon, 17 Jan 2011 22:41:17 +0100, Robert O'Callahan
rob...@ocallahan.org 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
On Mon, Jan 17, 2011 at 6:41 PM, Jeroen Wijering
jer...@longtailvideo.com 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,
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
On Wed, 19 Jan 2011 10:42:01 +0100, Aryeh Gregor
simetrical+...@gmail.com wrote:
On Mon, Jan 17, 2011 at 6:41 PM, Jeroen Wijering
jer...@longtailvideo.com wrote:
We are getting some questions from JW Player users that HTML5 video is
quite wasteful on bandwidth for longer videos (think
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 /
On Wed, 19 Jan 2011 17:14:23 +0100, Zachary Ozer z...@longtailvideo.com
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
On Wed, Jan 19, 2011 at 11:14 AM, Zachary Ozer z...@longtailvideo.comwrote:
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
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)
