Re: [whatwg] [whartwg] Video processing ability for MediaStreamTrack
Hi, all, Thanks for Anne's feedback. After irc with Anne, we got some consensus. 1. addVideoProcessor() doesn't need to check duplicates due to it will create a new MST. So the worker will append to the new created MST. It means every MST will contain only one video processor. I will explicitly point it out in next version. 2. It is a typo. 3. The event need a constructor and use Exposed. I will change it later. 4. outputImageBitmap=null = My bad. I will fix it later. 5. The ImageBitmap is immutable. It is not ImageData. So this might not an issue. 6. Also Anne suggests me to write down the algorithms including a. dispatch event, b. how to use outputImageBitmap... will add those into next version. BR, CTai 2015-08-11 13:59 GMT+08:00 Anne van Kesteren ann...@annevk.nl: On Fri, Aug 7, 2015 at 8:56 AM, Chia-Hung Tai c...@mozilla.com wrote: http://chiahungtai.github.io/mediacapture-worker/ Given that removeVideoProcessor() does not take arguments, should addVideoProcessor() not check for duplicates? VideoProcessEventThe looks like a typo. The events don't define constructors. They probably should. You should also use IDL [Exposed=] syntax to indicate they are available in workers. (Or dedicated workers, anyway.) The outputImageBitmap=null syntax is wrong. You want to remove =null there and define the default in prose. You also want to define the processing model a bit more carefully I think. E.g., it seems to be that for processing the event instance is modified and then once the dispatch flag is unset that data is copied somehow. But how is it copied? Is it a structured clone transfer that detaches the buffer? -- https://annevankesteren.nl/
Re: [whatwg] [whartwg] Video processing ability for MediaStreamTrack
On Fri, Aug 7, 2015 at 8:56 AM, Chia-Hung Tai c...@mozilla.com wrote: http://chiahungtai.github.io/mediacapture-worker/ Given that removeVideoProcessor() does not take arguments, should addVideoProcessor() not check for duplicates? VideoProcessEventThe looks like a typo. The events don't define constructors. They probably should. You should also use IDL [Exposed=] syntax to indicate they are available in workers. (Or dedicated workers, anyway.) The outputImageBitmap=null syntax is wrong. You want to remove =null there and define the default in prose. You also want to define the processing model a bit more carefully I think. E.g., it seems to be that for processing the event instance is modified and then once the dispatch flag is unset that data is copied somehow. But how is it copied? Is it a structured clone transfer that detaches the buffer? -- https://annevankesteren.nl/
Re: [whatwg] [whartwg] Video processing ability for MediaStreamTrack
I'm incredibly excited to see this moving forward.
[whatwg] [whartwg] Video processing ability for MediaStreamTrack
Hi, all, This is Chia-hung Tai from Mozilla. I would like to discuss a extension specification[1] based on Media Capture and Stream. This specification is based on a project called FoxEye[2]. You can check the use cases in [3]. I already sent an email to public-webrtc mailing list[4]. But it is pending due to some arguments about should we add new working item in an overloaded WG. I am waiting WebRTC WG chairs' respond. But I would like to keep moving on the spec. And there is plenty of WebWorker and ImageBitmap expertise subscribed this mailing list. Looking forward to hearing from your opinion. This specification extends the Media Capture and Streams specification to allow JavaScript developers to process video frame data in workers on the web applications. I already implement a prototype based on the spec[1]. And get positive feedbacks from Mozilla DOM peers. I think it should be standardized. You can see the demo in [4]. Thanks [1]: http://chiahungtai.github.io/mediacapture-worker/ [2]: https://wiki.mozilla.org/Project_FoxEye [3]: https://wiki.mozilla.org/Project_FoxEye#Use_Cases [4]: https://lists.w3.org/Archives/Public/public-webrtc/2015Jul/0074.html [5]: https://www.youtube.com/watch?v=prybkXsTGXY BR, CTai
