[mediacapture-main] Garbage collection of live tracks (#910)

eladalon1983 has just created a new issue for https://github.com/w3c/mediacapture-main:

== Garbage collection of live tracks ==
Consider this snippet:
```js
async function ClumsyFunc(constraints) {
  const stream = await navigator.mediaDevices.getUserMedia(constraints);
  if (SomeCondition()) {
    HandOff(stream);
  }
  // Oops! Dropped last reference on the floor. What a mess...
}
```

What happens now? Should the stream and its tracks be eligible for garbage collection? If so, there are user-facing side-effects.
* Camera/mic hardware indicator goes off.
* User agent indicators disappear.
* OS-level indicators disappear.

Note that getDisplayMedia has similar issues. In some implementations (Chromium), an application could even heuristically observed GC this way, because tab-sharing adds an infobar that affects the viewport's size, and when it disappears the viewport changes back.

So should GC of live tracks be disallowed? Allowed? Encouraged?

Arguments for allowing GC:
* Less CPU and battery consumption.
* Frees up other apps to use the same hardware with a different configuration.
* Inform the user of reality - nobody is reading their mic/camera/screen anymore.

Argument for disallowing GC:
* The app **should have** stopped the track first. Relying on GC creates an unpredictable user experience. By suppressing GC, we'll expose the bug and motivate the app devs to fix it, which is better for users - our top constituency.
* Garbage-collecting live tracks allows apps to heuristically observe GC (see above).

Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/910 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 17 October 2022 09:53:01 UTC