On Fri, 21 Jan 2011 23:11:56 +0100, Glenn Maynard gl...@zewt.org wrote:
On Fri, Jan 21, 2011 at 4:40 PM, Philip Jägenstedt phil...@opera.com
wrote:
I'm fine with any terminology, as long as it allows implementations to
seek
to some other time than currentTime if it's (much) faster to do so.
On Sat, 22 Jan 2011 02:19:10 +0100, Chris Pearce ch...@pearce.org.nz
wrote:
On 22/01/2011 7:31 a.m., Gregory Maxwell wrote:
It's usually the decoding, not the file access that kill you. Firefox
seeking on low resolution clips is very snappy index or not. But try a
1080p clip encoded with a
On Sat, Jan 22, 2011 at 4:23 AM, Philip Jägenstedt phil...@opera.com wrote:
Should there be any consistency requirements for fast seeking?
Suppose you have a format that's high-bitrate but cheap to decode.
Accurately seeking is fast if the data is already buffered, but slow
if not, since it's
On Thu, 20 Jan 2011 19:16:21 +0100, Zachary Ozer z...@longtailvideo.com
wrote:
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
On Sat, 22 Jan 2011 11:01:26 +0100, Glenn Maynard gl...@zewt.org wrote:
On Sat, Jan 22, 2011 at 4:23 AM, Philip Jägenstedt phil...@opera.com
wrote:
Should there be any consistency requirements for fast seeking?
Suppose you have a format that's high-bitrate but cheap to decode.
Accurately
On Fri, 14 Jan 2011 10:01:38 +0100, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
There are two sections - the first one concerns the WebVTT format and
the second one the track specification.
Thanks for compiling all of this feedback, Silvia! As usual, my inline
replies are sometimes
On Wed, Jan 19, 2011 at 12:05 PM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 19 Jan 2011 11:59:12 +0100, Anton Kovalyov an...@disqus.com wrote:
make it happen. Of course, the data will be completely anonymous and it has
to be related to WHATWG's main focus. Results will be published
It seems the needs for a seek bar are different from the api usage of
setting video.currentTime. As people mention rules of 'least surprise'
are important. If you set currentTime to 3.453 you expect it to return
something very close to 3.453 ..
Why not have a separate api for seek bars that just
On 22/01/2011 11:57 p.m., Philip Jägenstedt wrote:
I agree that there must exist a buffering strategy between
strategy=metadata and strategy=auto, but it's not clear that this must
be exposed as a preload state. The only difference between
preload=metadata and preload=state3 would be that
Doesn't Google have a much grater dataset?
I recall a 20%-research covering usage of MSHTML and/or MSIE specific
extensions (in specific, extensions for disabling Microsoft
(anti-)features), but I can't find it.
On Sat, Jan 22, 2011 at 5:57 AM, Philip Jägenstedt phil...@opera.com wrote:
I agree that there must exist a buffering strategy between strategy=metadata
and strategy=auto, but it's not clear that this must be exposed as a preload
state. The only difference between preload=metadata and
11 matches
Mail list logo
