Re: [whatwg] VIDEO Timeupdate event frequency.
On Sat, Sep 11, 2010 at 2:20 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Sat, Sep 11, 2010 at 11:03 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Fri, Sep 10, 2010 at 4:01 PM, Robert O'Callahan rob...@ocallahan.org wrote: I think an ideal API for video frame processing would involve handing video frames to a Worker for processing. Mm, yeah, probably. But then you'd need to be able to do canvas on workers, and hand the data back... This is a complex problem. Most of the usecases I've seen just do get/putImageData, so it might make sense to just provide raw frame data to the Worker and not introduce a canvas dependency. Yes, I think that makes sense, though I would not restrict it to image data, but include audio data (when we have the API for it). Dragging image data through a canvas just to get to the pixels is actually really annoying. If we could set a newFrame event on a video for a worker and the event data contains the video image with associated audio information, that would be the best. So... no newframe event for now, leave timeupdate as it is, and fix this in the future? I think so. Another factor is that a lot of the video effects people have been using canvas for can actually be done with SVG filters, which can be GPU-accelerated and are compatible with asynchronous compositing. So it might be wise to focus on use-cases for video processing that aren't amenable to SVG filters (or extensions thereof), and understand what their requirements are. Things like object segmentation, face recognition, object tracking in video, or anything with frequency analysis in audio come to mind. Workers seem like heaven-made for these anyway, though right now with the canvas indirection it isn't really optimal. Cheers, Silvia.
Re: [whatwg] Video with MIME type application/octet-stream
On 2010-09-11 03:40, Silvia Pfeiffer wrote: [snip...] And yeah, this kinda stretched beyond the scope of HTML5 specs, but you'd be swatting two flies at once, solving the sniffing issue with video and audio, but also the sniffing issue that every OS has had for the last couple of um... decades?! (poke your OS/Filesystem colleagues and ask them what they think of something like this.) Then again, HTML5 is kinda a OS in it's own right, being a app platform (not to mention supporting local storage of databases and files even), so maybe it's not that far outside the scope anyway to define something like this? -- Roger Rescator Hågensen. Freelancer - http://EmSai.net/ Is there a link to your BINID proposal? From reading this I wonder: Would it entail having to re-write all existing files with an extra identifier at the start? Silvia. http://www.emsai.net/projects/binid/details/ (it really need to be rewritten as it's way to wordy and repetitive to explain something so simple, I was planning to rewrite the document later this fall but...) And to answer your question, unfortunately yes, but that is the only way to solve the issue. Some current fileformats would allow such a binary id header to be added without any issues (as they scan past ID3v2 or similar meta information anyway). Most existing software would have no issues adding a check for such a binary id, in the long run it will save CPU cycles also. Certain streaming/transfer protocols could be updated too, and this is where video and audio could leap ahead. The thing is as I said, is that a browser could easily strip off the binary id before passing it on, so a codec or a OS filesystem or local software would be completely unaware, but in time they too would support it (hopefully). A serverside script (PHP or Python for example) could easily add the binary id to the start of a file or stream when sent to the browser, or even added to the file during transcoding. so even if the server or .htaccess is set to only application/octet-stream proper file format identification would be still possible by browser only checking the binary id header. -- Roger Rescator Hågensen. Freelancer - http://EmSai.net/
Re: [whatwg] VIDEO Timeupdate event frequency.
On 2010-09-11 05:23, Eric Carlson wrote: On Sep 10, 2010, at 8:06 PM, Biju wrote: On Fri, Sep 10, 2010 at 7:05 AM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: Incidentally: What use case did you have in mind, Biju ? I was thinking about applications like https://developer.mozilla.org/samples/video/chroma-key/index.xhtml ( https://developer.mozilla.org/En/Manipulating_video_using_canvas ) Now it is using setTimeout so if processor is fast it will be processing same frame more than on time. Hence wasting system resource, which may affect other running process. Perhaps, but it only burns cycles on those pages instead of burning cycles on *every* page that uses avideo element. If we use timeupdate event we may be missing some frames as timeupdate event is only happen every 200ms or 250ms, ie 4 or 5 frames per second. Even in a browser that fires 'timeupdate' every frame, you *will* miss frames on a heavily loaded machine because the event is fired asynchronously. And we know there are videos which a have more than 5 frames per second. So use a timer if you know that you want update more frequently. Hmm! Once you get up to around 60FPS (1000ms/60=16.6...) you are getting close to 15ms per frame, and unless the OS is running at a smaller timer period that is all the precision you can get. I believe Windows Media Player is using 5ms periods, and the smallest period advisable on a modern Windows system is 2ms, 1ms is most likely not consistently achievable on any typical OS (there will be fluctuations) that is not a real time OS (few end user OS are these days) This would have to be synced to the display refresh rate instead. (no point processing frames that are not displayed/skipped anyway), I can't recall any browsers exposing vsync. (does any?) -- Roger Rescator Hågensen. Freelancer - http://EmSai.net/
[whatwg] Form controls disabled IDL attribute and disabled state
Hi, With HTML4 (at least before fieldset.disabled), form controls disabled IDL attribute was a simple way to set and get the disabled state because the disabled state and the disabled content attribute were exactly the same thing. Now, with fieldset.disabled, disabled IDL attribute has no longer the same meaning. It's now only reflecting the content attribute and not the disabled state. Nothing in the API let the author knows the disabled state so the only solution is to look at the entire parent chain until a fieldset with the disabled attribute is found [1]. I can understand why when getting the disabled IDL attribute, this is not returning the state but the content attribute but I think there is a lack in the API and it might be nice for authors to have a simple way to know the state of the element [2]. This could be done with the IDL attribute returning the state instead of the content attribute or another attribute returning the state. Feedbacks welcome :) [1] if the fieldset has no disabled attribute, it still might be a child of another fieldset which has a disabled attribute. [2] some tricks might be to use query selector and check if the element has the :disabled pseudo-class applying but that's only a workaround. -- Mounir
[whatwg] :enabled and :disabled pseudo-classes should apply on fieldset elements
Hi, The current state of the specifications do not mention fieldset elements for the :enabled and :disabled pseudo-classes but fieldset can be disabled so I guess it might be convenient to have these pseudo-classes applied to them. Opera applies :disabled and :enabled to fieldset elements and Mozilla might do the same. Thanks, -- Mounir
Re: [whatwg] Form controls disabled IDL attribute and disabled state
On Sat, Sep 11, 2010 at 3:57 PM, Mounir Lamouri mounir.lamo...@gmail.com wrote: Hi, With HTML4 (at least before fieldset.disabled), form controls disabled IDL attribute was a simple way to set and get the disabled state because the disabled state and the disabled content attribute were exactly the same thing. Now, with fieldset.disabled, disabled IDL attribute has no longer the same meaning. It's now only reflecting the content attribute and not the disabled state. Nothing in the API let the author knows the disabled state so the only solution is to look at the entire parent chain until a fieldset with the disabled attribute is found [1]. I can understand why when getting the disabled IDL attribute, this is not returning the state but the content attribute but I think there is a lack in the API and it might be nice for authors to have a simple way to know the state of the element [2]. This could be done with the IDL attribute returning the state instead of the content attribute or another attribute returning the state. First of all, I think setting the .disabled IDL has to map to setting the content attribute. I can't think of any other sane behavior (other than not having a setter at all, but that wouldn't be backwards compat) Second, it seems confusing to me to have the getter and setter not match. I.e. to get vs. set entirely different things. This results in weird situations like foo.disabled = false; x = foo.disabled; // x is now true and foo.disabled = !foo.disabled // This might be a no-op The result of these two statements is that I think that the spec for .disabled should not be changed. This leaves the question of if we should expose the computed disabled state thorough some other property. I don't really feel strongly about this, but as with any feature, we should ask what the use case is. / Jonas
Re: [whatwg] Form controls disabled IDL attribute and disabled state
On 9/11/10 6:57 PM, Mounir Lamouri wrote: [2] some tricks might be to use query selector and check if the element has the :disabled pseudo-class applying but that's only a workaround. Why? Something like matchesSelector is an api on the element itself that does what you want; do we really need another api for it? -Boris
