On Thu, Aug 7, 2008 at 1:49 AM, Ian Hickson [EMAIL PROTECTED] wrote:
playbackRate is the right way to do it, but maybe Firefox doesn't yet
support it.
So can I assume HTML5 spec also allow playbackRate to be negative value.
ie to support go backward at various speed
Thanks
~Biju
On Thu, 7 Aug 2008, Biju [EMAIL PROTECTED] wrote:
On Thu, Aug 7, 2008 at 1:49 AM, Ian Hickson [EMAIL PROTECTED] wrote:
playbackRate is the right way to do it, but maybe Firefox doesn't yet
support it.
So can I assume HTML5 spec also allow playbackRate to be negative value.
ie to support
Robert O'Callahan wrote:
That would be nice to have. Unfortunately DirectShow and Quicktime do
not seem to expose the ability to enumerate supported codecs, so it
might be hard to implement for some browsers.
As things stand, you can use source elements to offer different
formats, and you
On Aug 7, 2008, at 09:53, Tim Starling wrote:
xiphQtVersion = videoElt.GetComponentVersion('imdc','XiTh',
'Xiph');
This kind of FourCC use is exactly the kind of thing I meant earlier
when I asked if the MIME stuff is really the best match for frameworks.
--
Henri Sivonen
[EMAIL
On Wed, 6 Aug 2008, Aaron Boodman wrote:
I am opposed to the utils object. I don't see any precedent for this
anywhere, and it just feels ugly to me. I liked it the way you had it
before, with these APIs in a shared base interface.
Ok. I don't have an opinion on this. Jonas?
In the
On Thu, Aug 7, 2008 at 6:20 PM, Ian Hickson [EMAIL PROTECTED] wrote:
On Thu, 7 Aug 2008, Biju [EMAIL PROTECTED] wrote:
On Thu, Aug 7, 2008 at 1:49 AM, Ian Hickson [EMAIL PROTECTED] wrote:
playbackRate is the right way to do it, but maybe Firefox doesn't yet
support it.
So can I assume
Chris Double schrieb:
Given that codecs are often highly optimized for forward playback the
cost in memory can be excessive to go the other way. Could there be a
possibility to say 'reverse playback not supported'?
This may be needed anyway, given that with streaming media you can't
reverse
Henri Sivonen wrote:
On Aug 7, 2008, at 09:53, Tim Starling wrote:
xiphQtVersion = videoElt.GetComponentVersion('imdc','XiTh',
'Xiph');
This kind of FourCC use is exactly the kind of thing I meant earlier
when I asked if the MIME stuff is really the best match for frameworks.
I suggest that the spec allows raising the NOT_SUPPORTED_ERR exception
in response to any playback rate which it cannot provide for the current
configuration. With a netcast you couldn't support any playback rate
except 1.0 without first buffering all the data you want to play at a
faster rate, so
Robert O'Callahan wrote:
http://www.w3.org/html/wg/html5/#dom-tree
1. If the |title| element
http://www.w3.org/html/wg/html5/#the-title1 is null, then a
new |title http://www.w3.org/html/wg/html5/#title1| element
must be created and appended to the |head|
On Thu, Aug 7, 2008 at 4:58 PM, Biju [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
PS: On Firefox I tried changing playbackRate attribute by
Markup as well as script, but did not see any effect.
playbackRate is not yet supported by the Ogg backend. The build I have
on my site with the
Mikko Rantalainen wrote:
Tim Starling wrote:
Henri Sivonen wrote:
On Aug 7, 2008, at 09:53, Tim Starling wrote:
xiphQtVersion = videoElt.GetComponentVersion('imdc','XiTh',
'Xiph');
This kind of FourCC use is exactly the kind of thing I meant earlier
when
how would this work (say) for different avc profile levels and features (eg:
PAFF support) ?would we require video creators to know the specific
capabilities of every fourCC target ?
On Thu, Aug 7, 2008 at 4:23 AM, Tim Starling [EMAIL PROTECTED]wrote:
Mikko Rantalainen wrote:
Tim Starling
On Wed, Aug 6, 2008 at 11:53 AM, Chris Prince [EMAIL PROTECTED] wrote:
My current thinking is that the best API design for createWorker() is:
MessagePort createWorker(worker_body, [WorkerOptions])
The reason: workers are a powerful concept, and it's very likely we'll
want to extend
On Thu, Aug 7, 2008 at 1:57 AM, Philip Jägenstedt [EMAIL PROTECTED] wrote:
I suggest that the spec allows raising the NOT_SUPPORTED_ERR exception
in response to any playback rate which it cannot provide for the current
configuration.
That sounds reasonable. It is a special effect.
With a
Aaron Boodman wrote:
That's also one reason why I like having a separate Worker object and
having the two-step process of creating the worker, then sending it a
message. It means that creating a new channel to a worker is always
the same.
Hixie asked me on IRC why I didn't like the MessagePort
At 20:10 +1200 7/08/08, Chris Double wrote:
On Thu, Aug 7, 2008 at 6:20 PM, Ian Hickson [EMAIL PROTECTED] wrote:
On Thu, 7 Aug 2008, Biju [EMAIL PROTECTED] wrote:
On Thu, Aug 7, 2008 at 1:49 AM, Ian Hickson [EMAIL PROTECTED] wrote:
playbackRate is the right way to do it, but maybe
Ian Hickson wrote:
On Wed, 6 Aug 2008, Aaron Boodman wrote:
I am opposed to the utils object. I don't see any precedent for this
anywhere, and it just feels ugly to me. I liked it the way you had it
before, with these APIs in a shared base interface.
Ok. I don't have an opinion on this.
Dave Singer wrote:
At 20:10 +1200 7/08/08, Chris Double wrote:
On Thu, Aug 7, 2008 at 6:20 PM, Ian Hickson [EMAIL PROTECTED] wrote:
On Thu, 7 Aug 2008, Biju [EMAIL PROTECTED] wrote:
On Thu, Aug 7, 2008 at 1:49 AM, Ian Hickson [EMAIL PROTECTED] wrote:
playbackRate is the right way to do
I think this is a good idea, but one rapidly runs into the problems
talked about in the 'bucket' RFC, notably that there is not a
universal language for naming codecs (4ccs etc). But it's proved
useful in the past.
In general, the source fallbacks are also a way to 'probe' this,
albeit in a
At 12:11 -0700 7/08/08, Jonas Sicking wrote:
Dave Singer wrote:
At 20:10 +1200 7/08/08, Chris Double wrote:
On Thu, Aug 7, 2008 at 6:20 PM, Ian Hickson [EMAIL PROTECTED] wrote:
On Thu, 7 Aug 2008, Biju [EMAIL PROTECTED] wrote:
On Thu, Aug 7, 2008 at 1:49 AM, Ian Hickson [EMAIL
Hello,
On Thu, Aug 7, 2008 at 12:11 PM, Jonas Sicking [EMAIL PROTECTED] wrote:
Dave Singer wrote:
At 20:10 +1200 7/08/08, Chris Double wrote:
On Thu, Aug 7, 2008 at 6:20 PM, Ian Hickson [EMAIL PROTECTED] wrote:
On Thu, 7 Aug 2008, Biju [EMAIL PROTECTED] wrote:
On Thu, Aug 7, 2008 at
At 12:23 -0700 7/08/08, Charles Iliya Krempeaux wrote:
I don't think turning sound off is a good idea.
well, the alternative is throwing a Not_supported error and not even
showing the video. So, I still feel that for a/v movies, reversing
the sound should be permitted but not required.
On Thu, 7 Aug 2008, Jonas Sicking wrote:
We make the createWorker() methods return a Worker object, but the
Worker object _inherits_ from MessagePort. So effectively it is a
port, but we can move the onload and onerror stuff to the Worker
object instead of having them on all
On Wed, Aug 6, 2008 at 7:06 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Aug 6, 2008, at 7:17 AM, Thomas Broyer wrote:
On Wed, Aug 6, 2008 at 11:29 AM, Maciej Stachowiak wrote:
I think Web IDL should provide a formalism to cater to this, because
nearly
all bindings with special
On Aug 7, 2008, at 1:51 PM, Garrett Smith wrote:
On Wed, Aug 6, 2008 at 7:06 PM, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
On Aug 6, 2008, at 7:17 AM, Thomas Broyer wrote:
On Wed, Aug 6, 2008 at 11:29 AM, Maciej Stachowiak wrote:
I think Web IDL should provide a formalism to cater
Would it be better if instead of createWorker() we called the method
connectToWorker(), and it creates it as well if the worker is unnamed or
doesn't yet exist?
That sounds pretty good to me.
On Sun, 03 Aug 2008 22:47:24 +0200, Jonas Sicking [EMAIL PROTECTED] wrote:
Personally I think keeping the URL is fine. We can never entirely
prevent pages from having bugs. But instead encourage the safe
transitions, and always use safe-looking transitions in examples in the
spec.
FWIW, I
(put back on list, forgot to reply-all)
On Thu, Aug 7, 2008 at 2:16 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Aug 7, 2008, at 1:51 PM, Garrett Smith wrote:
On Wed, Aug 6, 2008 at 7:06 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Aug 6, 2008, at 7:17 AM, Thomas Broyer wrote:
On Thu, Aug 7, 2008 at 10:43 PM, Jonas Sicking [EMAIL PROTECTED] wrote:
Actually, if we make the changes discussed to the mutation events spec, we
can consider setting the title a compound operation. This means that
mutation events won't fire until the above algorithm is fully done, so any
The big VoDS (Broadbus/Motorola, SeaChange, Arroyo...) do not offer audio when
the play rate is anything other than +1.0.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Fraser
Sent: Thursday, 2008 August 07 18:52
To: Charles Iliya Krempeaux
On Thu, Aug 7, 2008 at 6:53 PM, Tim Starling [EMAIL PROTECTED]wrote:
DirectShow and QuickTime can add those interfaces at a later date. When
the backends develop this capability, there should be a standard way to
go the next step and expose it to JavaScript. Otherwise every
implementor will
Ian Hickson wrote:
On Thu, 7 Aug 2008, Jonas Sicking wrote:
We make the createWorker() methods return a Worker object, but the
Worker object _inherits_ from MessagePort. So effectively it is a
port, but we can move the onload and onerror stuff to the Worker
object instead of having them on
33 matches
Mail list logo
