2011/1/14 Silvia Pfeiffer
> 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 making use of multiple langu
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
On Thu, Jan 20, 2011 at 4:20 PM, Matthew Gregan 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
> value immediately
On Sun, Jan 23, 2011 at 12:03 AM, Philip Jägenstedt wrote:
> 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 indeed
> be bad if
On Sat, Jan 22, 2011 at 10:04 AM, Philip Jägenstedt wrote:
> 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
> strong argume
On Sat, Jan 22, 2011 at 7:31 AM, Gregory Maxwell 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
> twiddling your thumbs
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 need
On 8/10/2010 5:22 PM, Charles Pritchard wrote:
On Aug 10, 2010, at 4:09 PM, Ian Hickson 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 more features, so
On Sun, Jan 23, 2011 at 6:32 AM, Philip Jägenstedt wrote:
> 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. Maybe
> that's p
On Sun, 23 Jan 2011 12:13:15 +0100, Glenn Maynard wrote:
On Sun, Jan 23, 2011 at 5:24 AM, Philip Jägenstedt
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 pla
On Sun, Jan 23, 2011 at 5:24 AM, Philip Jägenstedt
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 actual problem
On Sun, 23 Jan 2011 00:06:30 +0100, Glenn Maynard wrote:
On Sat, Jan 22, 2011 at 5:57 AM, 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 diff
On Sat, 22 Jan 2011 22:09:32 +0100, Bjartur Thorlacius
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.
They do, but we do
13 matches
Mail list logo
