- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Fri, 20 Mar 2020 11:10:22 +0000
- To: public-webrtc-logs@w3.org
> 2\. when frozenness changes to frozen, it makes sense to mute all tracks with device sources From the page perspective, this is irrelevant since this will not be observable to the page. User agents could try to update the capture indicator, but I am not sure the spec should mandate anything here. > 2\. when frozenness changes to unfrozen, it makes sense to require some specific action (page in front? user interaction?) before unmuting. I would love to be able to converge there, but this is a difficult area. Also, I am not sure frozen is the right concept since this is mostly irrelevant/invisible to the user. Frozen is something that might be highly time/memory/cpu/battery dependent and only time seems somehow meaningful to the user. For instance on iOS, a page only capturing video will get video-capture-muted as soon as it goes in the background. It will probably then quickly become frozen. If the page is generating audio though, it might not become frozen. Should there be two different behaviours? Maybe, maybe bit. In both cases currently, Safari will restart video capture if page goes back to foreground. > 4\. when returning to a discarded context, there will be a "discarded" boolean - but I don't think anything else from the previous context survives? Agreed. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/668#issuecomment-601645876 using your GitHub account
Received on Friday, 20 March 2020 11:10:23 UTC