Re: [whatwg] Video : Slow motion, fast forward effects
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
Re: [whatwg] Video : Slow motion, fast forward effects
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 go backward at various speed Yes. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Scripted querying of video capabilities
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 can try to play a stream and use script to detect if
it fails to play.
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 develop their own interface.
In fact, QuickTime already has enough query capabilities for Wikimedia's
purposes. Here is part of the JavaScript code I wrote to embed QuickTime:
// Detect XiphQT (may throw)
var xiphQtVersion = false, done = false;
try {
xiphQtVersion = videoElt.GetComponentVersion('imdc','XiTh', 'Xiph');
done = true;
} catch ( e ) {}
if ( done ) {
window.clearInterval( this_.qtTimers[params.id] );
if ( !xiphQtVersion || xiphQtVersion == '0.0' ) {
// ... show error message no XiphQt ...
}
// Disable autoplay on back button
this_.setParam( videoElt, 'AUTOPLAY', 'False' );
}
It works very well, but it's the sort of thing that I'd rather not have
to implement a dozen times for a dozen incompatible scriptable interfaces.
--
Tim Starling
Wikimedia Foundation
Re: [whatwg] Scripted querying of video capabilities
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 PROTECTED]
http://hsivonen.iki.fi/
Re: [whatwg] Workers feedback
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 absence of any arguments either way, my default would be put it all
on the global object; clashes are manageable, the Window object does it
that way, and there are enough things that we kinda want to put on the
global scope anyway (the core worker stuff) that it's not a clear that the
gain is huge.
I've tried to simplify the MessagePort interface as follows:
* messages are now queued, and won't be delivered until either the
'start()' method on the port is called, or the 'onmessage'
attribute is set to some value.
* messages are now queued, instead of a port becoming inactive when its
other side is suspended.
Can you explain the rationale for these two changes?
It makes it a lot simpler to use. Before, you ran the risk of the port
becoming unavailable as you posted to it, now it'll just get sent later.
Before, you had to wait for hte onload on the port before sending
messages, now it'll just work.
* I've made the worker receive its first port as a property of the global
object (port) instead of having to listen to the 'connect' event
(though the connect event still fires, so you can do shared
workers).
I liked it the way you had it, before. I'd rather the first connection
to a worker wasn't a special case, either for the worker or for the
worker's creator.
If it's not a special case, in the simple case you have to listen to an
event just to get the port, which seems excessive. For example this in
the old model:
var port;
onconnect = function (event) {
port = event.port;
}
...becomes this in the current model:
// don't have to do anything!
(It also means that workers by default have a lifetime of the creator even
if they don't do anything. I guess we don't need this anymore given the
new lifetime stuff, though.)
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.
It seems that designing the API to add extra steps is a bad thing
generally speaking. :-)
I think that 'load', 'error', and 'unload' could go on the worker. As
far as I can tell, the only thing 'load' and 'error' are used for is
telling the creator of a worker that the worker loaded or failed to
load. In that case, it seems wrong to throw them on MessagePort, since
MessagePorts are also used for many other things.
I also still think that Workers could have their own sendMessage. The
messages sent to this would be delivered to the worker as 'message'
events targeted at WorkerGlobalObject (eliminating the need for
onconnect?). This would make Workers and postMessage very similar to
Window and postMessage, which seems nice to me.
How's this for a compromise:
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 MessagePorts.
Would that work for you?
The main reason I used 'unload' and 'close' is consistency with how
the rest of the platform works. (With a Window, you call
window.close() to invoke window.onunload.) I can change that if people
want, though I do think consistency is worth keeping here.
I think the concept of a port becoming inactive is interesting in all
the cases MessagePorts are used, so this should stay. In fact, should it
be called 'oninactive'?
Well at this point a port only becomes inactive (and fires unload) when
the close() method is called or when the other side is owned by a document
that gets discarded.
Incidentally, I noticed that unload isn't called when it stops being an
active needed worker (i.e. when its users are all discarded). Should we
fire unload in that case too? I'm thinking the Closing orphan workers
step should fire unload at the worker.
On Mon, 4 Aug 2008, Aaron Boodman wrote:
So for example, I would be for moving over a subset of the navigator and
location objects as-is (these seem to work well), but against moving
over the document.cookie interface (it works poorly).
I agree with porting some subset of 'navigator' over, though since the
relevant parts of 'navigator' aren't defined even for HTML5 yet, I haven't
yet done this. There's an issue marker in the spec about this. What bits
would you like defined?
The ones that are most often used for browser detection are most important,
so:
- appName
- appCodeName
- appVersion
- platform
- userAgent
I know the whole business of browser detection
Re: [whatwg] Video : Slow motion, fast forward effects
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 HTML5 spec also allow playbackRate to be negative value. ie to support go backward at various speed Yes. Would you expect the audio to be played backwards too? 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'? Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] Video : Slow motion, fast forward effects
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 playback, even if the codec would allow it easily (which is not the case for MPEG, VC-1, Theora, Dirac, your favorite codec here). An interesting case would also be how to handle playback speeds smaller than 1x in the streaming case, given that you cannot possibly have an infinite buffer of input data. Streaming mostly forces a playback speed of +1x in all cases. Maik
Re: [whatwg] Scripted querying of video capabilities
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.
FourCC and MIME are not mutually exclusive, see RFC 2361.
-- Tim Starling
Re: [whatwg] Video : Slow motion, fast forward effects
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 changing the playback rate doesn't make sense. Throwing NOT_SUPPORTED_ERR must be better than just ignoring it, but the question is if script authors will remember to check for exceptions when setting the attribute... Philip On Thu, 2008-08-07 at 10:28 +0200, Maik Merten wrote: 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 playback, even if the codec would allow it easily (which is not the case for MPEG, VC-1, Theora, Dirac, your favorite codec here). An interesting case would also be how to handle playback speeds smaller than 1x in the streaming case, given that you cannot possibly have an infinite buffer of input data. Streaming mostly forces a playback speed of +1x in all cases. Maik -- Philip Jägenstedt Opera Software
Re: [whatwg] Setting the title attribute
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| element http://www.w3.org/html/wg/html5/#the-head0. 2. The children of the |title| element http://www.w3.org/html/wg/html5/#the-title1 (if any) must all be removed. 3. A single |Text| node whose data is the new value being assigned must be appended to the |title| element http://www.w3.org/html/wg/html5/#the-title1. Steps 1 and 2 can fire mutation events and cause the title element to become null again. I suppose if that happens, the algorithm should stop, but the spec should say so. 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 changes to the title element or attribute can simply be considered a separate operation. / Jonas
Re: [whatwg] Video : Slow motion, fast forward effects
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 gstreamer backend does have it however. Chris. -- http://www.bluishcoder.co.nz
Re: [whatwg] Scripted querying of video capabilities
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 I asked if the MIME stuff is really the best match for frameworks.
FourCC and MIME are not mutually exclusive, see RFC 2361.
RFC 2361 doesn't seem to provide a method for describing both video
codec and audio codec for a resource. The same parameter (codec) is
used for both audio and video codec information but I cannot understand
how a resource that contains both video and audio should be labeled.
RFC 4281 seems to provide a parameter codecs that is a comma separated
list of used codecs. The detail required (MUST) for the codecs
parameter seems quite high and I'm afraid that this parameter will not
be correctly used in real world, unfortunately. In theory, this would
seem a good way to provide the information needed for a resource.
Well, I was thinking of an interface which would list the codecs, rather
than the overall file types. But it could be done either way. By file type:
if ( video.supportsType( 'application/ogg;codecs=vorbis,theora' ) ) {
...
}
By codec/container:
if ( 'application/ogg' in video.supportedTypes
'video/theora' in video.supportedTypes
'audio/vorbis' in video.supportedTypes )
{
...
}
The first one looks easier in this application, and allows for multiple
backends with different allowed combinations of container and codec. The
second one allows for complete enumeration of client capabilities.
Obviously you couldn't provide an interface to enumerate every possible
combination of container, audio codec and video codec.
The reason this is needed, as opposed to using multiple source tags,
is because inevitably, some clients will support certain formats via
object (or in our special case, applet) and not via video.
Querying the browser's video capabilities allows JS to decide what
sort of embedding method to use. It's an essential migration feature.
-- Tim Starling
Re: [whatwg] Scripted querying of video capabilities
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 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 I asked if the MIME stuff is really the best match for frameworks.
FourCC and MIME are not mutually exclusive, see RFC 2361.
RFC 2361 doesn't seem to provide a method for describing both video
codec and audio codec for a resource. The same parameter (codec) is
used for both audio and video codec information but I cannot understand
how a resource that contains both video and audio should be labeled.
RFC 4281 seems to provide a parameter codecs that is a comma separated
list of used codecs. The detail required (MUST) for the codecs
parameter seems quite high and I'm afraid that this parameter will not
be correctly used in real world, unfortunately. In theory, this would
seem a good way to provide the information needed for a resource.
Well, I was thinking of an interface which would list the codecs, rather
than the overall file types. But it could be done either way. By file type:
if ( video.supportsType( 'application/ogg;codecs=vorbis,theora' ) ) {
...
}
By codec/container:
if ( 'application/ogg' in video.supportedTypes
'video/theora' in video.supportedTypes
'audio/vorbis' in video.supportedTypes )
{
...
}
The first one looks easier in this application, and allows for multiple
backends with different allowed combinations of container and codec. The
second one allows for complete enumeration of client capabilities.
Obviously you couldn't provide an interface to enumerate every possible
combination of container, audio codec and video codec.
The reason this is needed, as opposed to using multiple source tags,
is because inevitably, some clients will support certain formats via
object (or in our special case, applet) and not via video.
Querying the browser's video capabilities allows JS to decide what
sort of embedding method to use. It's an essential migration feature.
-- Tim Starling
Re: [whatwg] Workers feedback
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 them over time. The 'name' option is just one such case. Here are a few others: - 'language' for non-JS workers (e.g. 'text/python' or 'application/llvm') - 'isContent' to pass a string or Blob instead of a url - 'lifetime' for running beyond the lifetime of a page - etc. I'd say other options are likely to be just as 'important' as name, so I wouldn't special-case that parameter. A 'WorkerOptions' parameter supports naming, but future expansion as well. FWIW, Chris's suggestion is also fine with me. In general, I like these options objects since they are easily extensible. The language should be done via an HTTP Content-Type. isContent can be done using data: URLs instead, if this is really needed. If we want to do something with a different lifetime I think we want to do it with a much clearer API entry point than an option burried in an argument. So I'm not really convinced about this. I would be interested in other viewpoints, though. I think you are missing the point. I'll try to rephrase it: It is short-sighted to expect you can fully spec something as large as workers. This is a significant new concept, and we are only scratching the surface. So why back ourselves into a corner? Let's be smart about the API design, and allow for future flexibility. I don't see any downsides to the approach outlined above. If you have something specific in mind, please let us know.
Re: [whatwg] Video : Slow motion, fast forward effects
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 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 changing the playback rate doesn't make sense. Well, it would be better to implement the requested playback rate (and direction) as long as you can and then rebuffer when necessary. Doing that well requires extra sophistication in the buffering code, but the client might just be trying to scrub a bit, which would fit within a normal seek buffer. Even with live streams, if you try to pull faster than realtime you'll just buffer-wait, and if you're going slower you'll fill whatever space you have, then have to drop and restart. If all you have is a jitter buffer, then sure. -r
Re: [whatwg] Workers feedback
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 solution. So here is a list of a few reasons: I prefer that the createWorker function returns an actual Worker object. I think that is what you would expect from an API with such a name. Otherwise we should call it something like createAWorkerAndReturnAMessagePort. We shouldn't trick people into thinking that they have a worker when they really have a MessagePort, even if the two APIs happen to mostly align. One way to fix this and still keep MessagePorts would be to return a Worker object that has a .port property, but that has other problems, see below. To add to the above point, while the MessagePort API currently aligns with the proposed Worker API, this seems likely to change in the future, for example to test if a worker is shared between multiple frames. I in general am not a big fan of the MessagePort API, the whole cloning and dying thing is really ugly. I don't think there is much we can do about that, but because of it I think we should only use the API when it's strictly needed, which seems to be only in fairly complex usecases. I am aware that returning a MessagePort basically means that you write your code the same way in the trivial cases, but I dislike designing a complex API and telling the users don't pay attention to the full API of the object you are using, just think of it as something else and it'll work fine. Exposing a MessagePort as a permanent property, like the global 'port' property, has the downside that that object can potentially die if the MessagePort is ever passed through postMessage somewhere. This leaves the user with a permanent property containing a dead useless object. Not exposing it as a permanent property forces things like the onconnect event and returning a MessagePort from createWorker. 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 them over time. The 'name' option is just one such case. Here are a few others: - 'language' for non-JS workers (e.g. 'text/python' or 'application/llvm') - 'isContent' to pass a string or Blob instead of a url - 'lifetime' for running beyond the lifetime of a page - etc. I'd say other options are likely to be just as 'important' as name, so I wouldn't special-case that parameter. A 'WorkerOptions' parameter supports naming, but future expansion as well. FWIW, Chris's suggestion is also fine with me. In general, I like these options objects since they are easily extensible. I do sort of prefer the idea of keeping the give me a worker that is potentially shared with other windows API separate. In fact I think we should call it createSharedWorker or some such. But allowing optional arguments at the end seems like a good idea. Not sure if that requires specific action right now or not though. / Jonas
Re: [whatwg] Video : Slow motion, fast forward effects
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 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 Yes. Would you expect the audio to be played backwards too? I think that's extra credit and optional. As you say, even with audio coded in independent frames you have to flip the samples, which is a pain. For audio with forward dependencies, correct decoding means decoding forwards and then flipping whole chunks of timeline (though AAC doesn't suffer too badly if you don't do this, by the way). 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'? Indeed, on I/P/B video, showing all the frames is also painful. I think that the spec. should say that degraded playback (e.g. I frames only) or no playback (non-reversed audio) may occur... -- David Singer Apple/QuickTime
Re: [whatwg] Workers feedback
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. Jonas?
In the absence of any arguments either way, my default would be put it all
on the global object; clashes are manageable, the Window object does it
that way, and there are enough things that we kinda want to put on the
global scope anyway (the core worker stuff) that it's not a clear that the
gain is huge.
I don't feel very strongly about this right now. It's something we
started debating at mozilla and I think we'll debate it a bit more
before coming to a conclusion. I'm fine with putting it in the global
scope for now. Sorry, i didn't mean to ask for an immediate action on
this yet.
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.
It seems that designing the API to add extra steps is a bad thing
generally speaking. :-)
Though in the vast majority of cases only the first step is needed. A
second step is only needed in the very complex use cases of:
* Having sibling workers talk directly to each other.
* Having a worker talk directly to a frame from a different origin.
* Having a worker shared across different instances of the app.
I think that 'load', 'error', and 'unload' could go on the worker. As
far as I can tell, the only thing 'load' and 'error' are used for is
telling the creator of a worker that the worker loaded or failed to
load. In that case, it seems wrong to throw them on MessagePort, since
MessagePorts are also used for many other things.
I also still think that Workers could have their own sendMessage. The
messages sent to this would be delivered to the worker as 'message'
events targeted at WorkerGlobalObject (eliminating the need for
onconnect?). This would make Workers and postMessage very similar to
Window and postMessage, which seems nice to me.
How's this for a compromise:
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 MessagePorts.
Would that work for you?
I thought about that, but what happens if you pass such an object to
postMessage? Throws an exception? Only the parts of the API that is a
MessagePort dies?
One solution I thought about is to have a base interface such as:
interface MessagePort {
void postMessage(...);
attribute EventListener onmessage;
...
}
Then have
interface Worker : MessagePort {
bool isShared();
worker specific stuff
}
interface PipePort : MessagePort {
attribute Window ownerWindow;
Pipe specific stuff
}
And then make the APIs that we want to allow passing around pipe-ends
take a PipePort object.
The result is basically that workers are separate objects from what's
returned for (new MessagePipe()).port1, but they share some API.
- Should import() accept an array of URLs, so that the UA can fetch
them in parallel if it has the ability to do that?
We could do that if you like. Is it needed?
With the connection limits being upped in all the browsers, I think this
would be a good thing to have from the beginning.
Fair enough. Should they be run in whatever order they load in or should
they be run in the order given on the aguments?
Yes. Another thing is that this function should probably return void and
always throw if something goes wrong. I doubt that having the server
return a 404 is expected enough that just returning 'false' will keep
the program executing fine.
/ Jonas
Re: [whatwg] Video : Slow motion, fast forward effects
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 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 Yes. Would you expect the audio to be played backwards too? I think that's extra credit and optional. As you say, even with audio coded in independent frames you have to flip the samples, which is a pain. For audio with forward dependencies, correct decoding means decoding forwards and then flipping whole chunks of timeline (though AAC doesn't suffer too badly if you don't do this, by the way). Honestly, this seems useless enough that the spec should just say that when playback is less than 0 sound should be turned off. I'd hate to see engineers working on this just because the spec says it should work that way. / Jonas
Re: [whatwg] Scripted querying of video capabilities
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 very different way. I'm not sure you can always get a definitive answer to the question if I gave you a file with this (extended) MIME type, could you play it? and I am fairly sure that asking the implementation to enumerate all the types it could support would be hard. But this kind of query is really useful on a 'portal' page -- entry points to sites. A script can detect that you need to download oh, say, Theora, in order to see the videos in the rest of the site, and shows a frame or page that would help you load it. :-) -- David Singer Apple/QuickTime
Re: [whatwg] Video : Slow motion, fast forward effects
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 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 Yes. Would you expect the audio to be played backwards too? I think that's extra credit and optional. As you say, even with audio coded in independent frames you have to flip the samples, which is a pain. For audio with forward dependencies, correct decoding means decoding forwards and then flipping whole chunks of timeline (though AAC doesn't suffer too badly if you don't do this, by the way). Honestly, this seems useless enough that the spec should just say that when playback is less than 0 sound should be turned off. I'd hate to see engineers working on this just because the spec says it should work that way. I'm sorry if I wasn't clear: I agree. If you want your implementation to shine, or be used heavily for audio scrubbing, or something, go ahead and implement. But it should not be required. (For extra credit) -- David Singer Apple/QuickTime
Re: [whatwg] Video : Slow motion, fast forward effects
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 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 Yes. Would you expect the audio to be played backwards too? I think that's extra credit and optional. As you say, even with audio coded in independent frames you have to flip the samples, which is a pain. For audio with forward dependencies, correct decoding means decoding forwards and then flipping whole chunks of timeline (though AAC doesn't suffer too badly if you don't do this, by the way). Honestly, this seems useless enough that the spec should just say that when playback is less than 0 sound should be turned off. I'd hate to see engineers working on this just because the spec says it should work that way. I don't think turning sound off is a good idea. This feature would be used to implement scrubing. Like what you see in Non-Linear Editors... for making movies, etc. (I.e., grabbing the position handle of the player, and moving it forwards and backwards through the video, and varying speeds, to find what you are looking for.) In those types of applications, the audio is on. And it is important for usability, for the video editor to hear the sound. -- Charles Iliya Krempeaux, B.Sc. http://ChangeLog.ca/
Re: [whatwg] Video : Slow motion, fast forward effects
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. This feature would be used to implement scrubing. Like what you see in Non-Linear Editors... for making movies, etc. (I.e., grabbing the position handle of the player, and moving it forwards and backwards through the video, and varying speeds, to find what you are looking for.) In those types of applications, the audio is on. And it is important for usability, for the video editor to hear the sound. If it's important to the user, they should use a browser which implements it. -- David Singer Apple/QuickTime
Re: [whatwg] Workers feedback
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 MessagePorts.
I thought about that, but what happens if you pass such an object to
postMessage?
It would just get cloned as usual.
The only things that a Worker object would have that a regular MessagePort
wouldn't is the onload and onerror things, and they're only relevant until
the point where you have a connection, so losing them when you clone the
port is fine.
One solution I thought about is to have a base interface such as:
interface MessagePort { ... }
Then have
interface Worker : MessagePort {
bool isShared();
worker specific stuff
}
interface PipePort : MessagePort {
attribute Window ownerWindow;
Pipe specific stuff
}
ownerWindow is gone. There's no pipe-specific stuff that wouldn't also
apply to a worker. There's no worker-specific stuff once the channel has
been established.
What's the use case for isShared()? What does it do?
I really don't like this idea of making Workers less generic. There's no
need for it as far as I can tell, and all it does is make things less
powerful while actually increasing implementation complexity.
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 would resolve the issue of what looks like a
constructor not returning an object representing what it constructs?
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML 5 : Misconceptions Documented
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 dynamic properties work like this afaik. But I
think it would have to involve a pseudo-method for the hasOwnProperty
check (which in is based on).
hasOwnProperty is ECMAScript-specific.
Yes it is.
The Web IDL includes specific requirements for how to map an interface
specified in Web IDL to ECMAScript. So, indeed, that would be the part of
the Web IDL spec that would be the best place to define this.
Since Maciej is probably considered to be an EcmaScript expert and I
am not, and since he had stated that 'in' calls 'hasOwnProperty', and
even continued to argue the claim, it is necessary and appropriate to
demonstrate proof that the 'in' does not call 'hasOwnProperty'.
The following example shows that no implementation calls
hasOwnProperty with use of 'in' operator.
If an implementation were to do that, that would be a bug.
There should be an alert on the second button and no alert on the
first. After both buttons have been clicked once, there should be a
green PASS.
!DOCTYPE HTML
html lang=en
head
titlehasOwnProperty/title
style type=text/css
#fail { background: red; }
#pass { background: #0f0; }
.res { display: none; font-weight: 700; }
/style
/head
body
script type=text/javascript
var rec = {}, failed;
var mo = {
name : Maciej,
title : unknown
};
Object.prototype.hasOwnProperty = function(p) {
if(p == unknown) {
document.getElementById('fail').style.display='inline-block';
failed = true;
}
alert('calling hasOwnProperty: '+ p);
};
function testIn(){
rec['name'] = true;
checkPass();
'name'in mo;
}
function testHasOwnProperty(p){
rec['title'] = true;
checkPass();
mo.hasOwnProperty('name');
}
function checkPass(){
if(rec['name'] rec['title'] !failed)
document.getElementById('pass').style.display='inline-block';
}
/script
button onclick=testIn()testIn()/button
button onclick=testHasOwnProperty();
testHasOwnProperty;/button
div id=fail class=resFAIL/div
div id=pass class=resPASS/div
/body
/html
=
Result in IE8b1, FF3, Webkit, Op9, Saf2.04
* alert on second button,
* PASS
the 'in' operator does not call 'hasOwnProperty'.
'hasOwnProperty' is EcmaScript specific. Whether or not ordinally
indexed properties should be 'own' properties is not a place for IDL
to decide.
Garrett
Regards,
Maciej
Re: [whatwg] HTML 5 : Misconceptions Documented
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 to this, because nearly all bindings with special dynamic properties work like this afaik. But I think it would have to involve a pseudo-method for the hasOwnProperty check (which in is based on). hasOwnProperty is ECMAScript-specific. Yes it is. The Web IDL includes specific requirements for how to map an interface specified in Web IDL to ECMAScript. So, indeed, that would be the part of the Web IDL spec that would be the best place to define this. Since Maciej is probably considered to be an EcmaScript expert and I am not, and since he had stated that 'in' calls 'hasOwnProperty', and even continued to argue the claim, it is necessary and appropriate to demonstrate proof that the 'in' does not call 'hasOwnProperty'. The following example shows that no implementation calls hasOwnProperty with use of 'in' operator. The more accurate way to put it would be that the 'in' operator performs the same check at ever item in the prototype chain (including the original object) that the original value of hasOwnProperty performs on only the object itself. You are correct that replacing hasOwnProperty either on an object or in its prototype chain will have no effect on operation of the 'in' operator. 'hasOwnProperty' is EcmaScript specific. Whether or not ordinally indexed properties should be 'own' properties is not a place for IDL to decide. It is just as relevant to specify whether a property is an own property as it is to specify whether it is visible to the 'in' operator. Both are edge cases that may affect interoperability but likely won't (since most authors will just get the property, and not check for presence). Visibility to the 'in' operator seems to observable difference on which you base your distinction between 'having a getter' and 'having a real property'. Regards, Maciej
Re: [whatwg] Workers feedback
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.
Re: [whatwg] pushState
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 think the URL argument is the best part of this feature. I don't want to lose it! -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
[whatwg] HTML 5 : Misconceptions Documented
(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 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 dynamic properties work like this afaik. But I think it would have to involve a pseudo-method for the hasOwnProperty check (which in is based on). hasOwnProperty is ECMAScript-specific. Yes it is. The Web IDL includes specific requirements for how to map an interface specified in Web IDL to ECMAScript. So, indeed, that would be the part of the Web IDL spec that would be the best place to define this. Since Maciej is probably considered to be an EcmaScript expert and I am not, and since he had stated that 'in' calls 'hasOwnProperty', and even continued to argue the claim, it is necessary and appropriate to demonstrate proof that the 'in' does not call 'hasOwnProperty'. The following example shows that no implementation calls hasOwnProperty with use of 'in' operator. The more accurate way to put it would be that the 'in' operator performs the same check at ever item in the prototype chain (including the original object) that the original value of hasOwnProperty performs on only the object itself. You are correct that replacing hasOwnProperty either on an object or in its prototype chain will have no effect on operation of the 'in' operator. What you're sort of describing is called [[HasProperty]] in the specification. In terms of the specification, it is not related to hasOwnProperty. [[HasProperty]] is internal and works differently. | 8.6.2.4 [[HasProperty]](P) | | When the [[HasProperty]] method of O is called with property name P, | the following steps are taken: | 1. If O has a property with name P, return true. | 2. If the [[Prototype]] of O is null, return false. | 3. Call the [[HasProperty]] method of [[Prototype]] with property | name P. | 4. Return Result(3). [[HasProperty]](P) doesn't call ToString(P). [[HasFeature]] an internal mechanism. hasOwnProperty is not internal; it's part of Object.prototype: | 15.2.4.5 Object.prototype.hasOwnProperty(V)\ | | When the hasOwnProperty method is called with argument V, the | following steps are taken: | | 1. Let O be this object. | 2. Call ToString(V) | 3. If O doesn't have a property with the name given by Result(2), | return false. | 4. Return true. | | NOTE Unlike [[HasProperty]] (8.6.2.4), this method does not consider | objects in the prototype chain. 'hasOwnProperty' is EcmaScript specific. Whether or not ordinally indexed properties should be 'own' properties is not a place for IDL to decide. It is just as relevant to specify whether a property is an own property as it is to specify whether it is visible to the 'in' operator. Both are edge cases that may affect interoperability but likely won't (since most authors will just get the property, and not check for presence). Visibility to the 'in' operator seems to observable difference on which you base your distinction between 'having a getter' and 'having a real property'. Why should IDL include discussion of the prototype chain? How can you define the prototype chain for other languages? How can you declare properties on an object where the property name is not a valid identifier? There is no prototype chain in Java. The closest thing would be static class variables. That still doesn't get around the problem of having properties with the name '0', '1', et c. Those are not valid identifiers in Java namedNodeMap.0 Would not compile. You can't have invalid identifiers in Java. The alternative would be to not pretend or try to force other languages to behave like EcmaScript, but to recognize EcmaScript for what it is and allow that behavior in that binding; allow property access using [], as it is implemented in browsers. This would require nothing more than a simple explanation in the binding. Garrett Regards, Maciej
Re: [whatwg] Setting the title attribute
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 changes to the title element or attribute can simply be considered a separate operation. Yeah, this pretty much what Hixie said on IRC. Suits me. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Video : Slow motion, fast forward effects
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 Cc: Biju [EMAIL PROTECTED]; Dave Singer; whatwg@lists.whatwg.org; Chris Double; Ian Hickson; Jonas Sicking Subject: Re: [whatwg] Video : Slow motion, fast forward effects On Aug 7, 2008, at 12:23 PM, Charles Iliya Krempeaux wrote: 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 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 Yes. Would you expect the audio to be played backwards too? I think that's extra credit and optional. As you say, even with audio coded in independent frames you have to flip the samples, which is a pain. For audio with forward dependencies, correct decoding means decoding forwards and then flipping whole chunks of timeline (though AAC doesn't suffer too badly if you don't do this, by the way). Honestly, this seems useless enough that the spec should just say that when playback is less than 0 sound should be turned off. I'd hate to see engineers working on this just because the spec says it should work that way. I don't think turning sound off is a good idea. This feature would be used to implement scrubing. Like what you see in Non-Linear Editors... for making movies, etc. (I.e., grabbing the position handle of the player, and moving it forwards and backwards through the video, and varying speeds, to find what you are looking for.) In those types of applications, the audio is on. And it is important for usability, for the video editor to hear the sound. But those applications are not naïvely playing the sound at the current playback rate; they are grabbing little snippets of audio samples from the current playhead position, and playing them at normal rate. I don't think the spec should go into this much detail about what happens to audio when rate != 1. Simon
Re: [whatwg] Scripted querying of video capabilities
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 develop their own interface. Sure. But the interface has to be able to say I don't know. And then we're relying on authors to do the right thing if they get that answer ... which is always a worry. In fact, QuickTime already has enough query capabilities for Wikimedia's purposes. Probing for a particular component is a different problem from listing all supported codecs, which is what I thought you were asking for. I suppose we could hardcode a list of well-known components along with the codecs they support and then probe for them to estimate what codecs are supported. But, yuck. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Workers feedback
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 all MessagePorts.
I thought about that, but what happens if you pass such an object to
postMessage?
It would just get cloned as usual.
This seems to be exactly the same thing as what the spec says now, just
with a different name.
The only things that a Worker object would have that a regular MessagePort
wouldn't is the onload and onerror things, and they're only relevant until
the point where you have a connection, so losing them when you clone the
port is fine.
One solution I thought about is to have a base interface such as:
interface MessagePort { ... }
Then have
interface Worker : MessagePort {
bool isShared();
worker specific stuff
}
interface PipePort : MessagePort {
attribute Window ownerWindow;
Pipe specific stuff
}
ownerWindow is gone. There's no pipe-specific stuff that wouldn't also
apply to a worker. There's no worker-specific stuff once the channel has
been established.
I think it's much overly optimistic to think that we will never want to
add port specific stuff to the port object, or worker specific stuff to
the worker object. I just don't have that high confidence in that we can
design these interfaces perfectly in the first version, nor phantom the
features that people will want in future versions.
I really don't like this idea of making Workers less generic. There's no
need for it as far as I can tell, and all it does is make things less
powerful while actually increasing implementation complexity.
Why is it making them less generic?
One need listed is the ability to in the future add properties that make
sense on one interface but not the other. You are already listing
onerror and onload as not really making sense on a generic MessagePort.
Why does it make things less powerful?
So far it seems like implementors are commenting on wanting this change,
so implementation complexity doesn't seem like a real concern.
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 would resolve the issue of what looks like a
constructor not returning an object representing what it constructs?
That only addresses one of the comments listed in my last mail.
/ Jonas
