Why doesn't webcodecs run in the background
yangfangfang1204 opened this issue · comments
If the chrome page is minimized, webcodecs will stop calling back the output frame.
when i open the chrome , it will output frame quickly ?
so is it a bug ? or there are some dettings that allow webcodecs to run in the background ?
Can you file a bug at https://crbug.com/new with a reproduction case? I expect normal JavaScript throttling may kick in with some cases. We can leave this open in case we want to specify how background behavior should work in spec.
If the specification is to address this, I suggest it requires Web Codecs to function as normal, regardless of browsing context background status.
A tab's backgrounded state is a poor signal of user intent when the user multitasks between several applications and tabs. The user agent cannot assume it knows better than the user as to what the user wants to do. Encoding video is something routinely done in the background and is expected to consume the entire machine as much as practical to get the job done quickly. Users usually do something else while video encodes in the background. There are also realtime use cases where the user still wants to encode, even if the tab is in the background. (Think of a simple presentation stream, where a web cam and other application like PowerPoint are streamed together.)
We've been fighting a related throttling problem for ~7 years now on canvas capture stream with MediaRecorder, with little progress. The use cases enabled by these media APIs are all but destroyed due assumptions around user intent baked into the browser implementations. The implementation cannot assume to know more than the user. The specification should not limit capability by assuming all the use cases are known.
Somewhat related: this spec proposes notifying pages of lifecycle events, when a page is frozen/resumed:
https://wicg.github.io/page-lifecycle/
When determining how to handle codec reclamation, we looked into having a similar mechanism to the screen wake lock API, but for keeping codecs alive. However, having a lock preventing the codec from being reclaimed still wouldn't have prevented the page from being throttled/frozen overall.
I agree that it's desirable to have encoders keep running in the background. I don't know what overriding normal javascript background throttling would like.