- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Fri, 22 Jan 2021 12:25:55 +0000
- To: public-webrtc-logs@w3.org
Making MediaStream transferable sounds like it could work well for mic/camera access (your use case is interesting, @zenhack). But I don't think it would work well in general. Take performance for example. Transferring 4k frames over IPCs would not be nice. Making MediaStreams transferrable is a much bigger scope project than what I'm suggesting. There are plenty of other implementation concerns which make me **suspect** Chrome would not be able to support this in the near future. (The general case, that is. Mic/camera - maybe?) I'd prefer continue pursuing our initially suggested API for the purpose of cropping at the moment. > However, if the canvas becomes tainted, then the principal becomes the null origin, which would have to carry across also. I think transferring a MediaStream is only interesting when it's done with its "contents" (the right term eludes me atm). For anything else, the recipient might as well just create their own MediaStream and configure it with everything else the original MediaStream had, since all other parts that I can think of are probably serializable and can be posted between frames already. Or am I overlooking something? > Capturing DOM elements isn't exactly simple though: what about when cross-origin content is overlaid I am not suggesting DOM-element-capture, in large part due to the problems of occluded content. My suggestion deals with **cropping** a capture of the entire tab to the **coordinates** specified by a div. With that approach, the pixels captured end up identical to those the local user is seeing. -- GitHub Notification of comment by eladalon1983 Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/158#issuecomment-765363065 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 22 January 2021 12:25:56 UTC