On Sat, 22 Jan 2011 22:09:32 +0100, Bjartur Thorlacius
svartma...@gmail.com wrote:
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 Sun, 23 Jan 2011 00:06:30 +0100, Glenn Maynard gl...@zewt.org wrote:
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
On Sun, Jan 23, 2011 at 5:24 AM, Philip Jägenstedt phil...@opera.com
wrote:
I do think that in the basic case of a user pressing play on a video
player, it's good to be able to make that respond instantly rather
than waiting for a round-trip to begin playing.
Have you found this to be an
On Sun, 23 Jan 2011 12:13:15 +0100, Glenn Maynard gl...@zewt.org wrote:
On Sun, Jan 23, 2011 at 5:24 AM, Philip Jägenstedt phil...@opera.com
wrote:
I do think that in the basic case of a user pressing play on a video
player, it's good to be able to make that respond instantly rather
than
On Sun, Jan 23, 2011 at 6:32 AM, Philip Jägenstedt phil...@opera.comwrote:
But presumably you want some kind of guarantee that the video will be able
to keep playing without waiting for the network, right? So if you don't use
preload=auto, you'll at least need preload=playthrough or similar.
On 8/10/2010 5:22 PM, Charles Pritchard wrote:
On Aug 10, 2010, at 4:09 PM, Ian Hicksoni...@hixie.ch wrote:
Adding more features to TextMetrics is on the cards for a future version
of the canvas API, but at the moment I'm waiting until more of the spec is
reliably implemented before adding
On 24/01/2011 12:32 a.m., Philip Jägenstedt wrote:
Hmm. To get this effect without preload=buffer, you could set
preload=auto,
watch the buffered attribute to see when some data is actually
downloaded,
then set it to preload=metadata to stop autoloading. That's a minor
hack,
and would
On Sat, Jan 22, 2011 at 7:31 AM, Gregory Maxwell gmaxw...@gmail.com wrote:
Basically, as the decoding speed approaches realtime the seeking time
approaches what you'd get by seeking to the prior keyframe and playing
up to the current point, except with the exact seeking you sit around
On Sat, Jan 22, 2011 at 10:04 AM, Philip Jägenstedt phil...@opera.comwrote:
Since, as you say, the behavior is currently inconsistent, there is still
time to agree on something that makes sense and have everyone implement
that. I think the best default is keyframe seeking and haven't seen any
On Sun, Jan 23, 2011 at 12:03 AM, Philip Jägenstedt phil...@opera.comwrote:
Ah, thanks for clarifying. It might be a bit odd for the spec to forbid
being too clever, but I think that in practice always seeking to the same
point is much easier, so that's what would be implemented. It would
On Thu, Jan 20, 2011 at 4:20 PM, Matthew Gregan kine...@flim.org wrote:
This doesn't seem to be required by the current wording of the spec (in
fact, it seems to be incorrect behaviour), but I think this behaviour is
more intuitive, as it seems unusual that currentTime returns to the old
On Jan 23, 2011, at 21:40 , Glenn Maynard wrote:
The most important unresolved use case is: how to allow limiting the amount
of prebuffered data, while also having a mechanism to disable that limit
when there isn't enough bandwidth.
The problem isn't so much the lack of bandwidth, as the
2011/1/14 Silvia Pfeiffer silviapfeiff...@gmail.com
Required attributes in WebVTT files should be the main language in use
and the kind of data found in the WebVTT file - information that is
It should be possible to specify language per-cue, or better, per block of
text mid-cue. Subtitles
13 matches
Mail list logo
