Re: [mediacapture-screen-share-extensions] Auto-pause capture when user switches captured content (#4)

@jan-ivar:
> With the optimization @youennf proposed, forgetting `stop()` seems like an existing problem.
>
> Having apps explicitly `stop()` tracks they're done is the web model today, which makes its side-effects well-established, predictable, and pilot errors easy to diagnose and fix.

It makes sense for the application to be responsible to stop a track that it has requested, but in this case the UA throws an extra track on the application that that the application doesn’t want. It seems wrong to me to force application writers to stop this extra track that they never asked for.

> I'm not convinced introducing custom stopping-policies into the mix simplifies that responsibility.

There is no new custom stopping policy. The surface track is bound to a specific surface, and it ends when the user switches away from that surface, since no more media will be delivered from that surface. 

It’s the same behavior as when the user stops the capture of a surface.

> Ah, I missed earlier you said the event would fire for all new surfaces _"including the initial one"_! Having apps immediately stop tracks from getDisplayMedia() does look weird indeed.
> 
> I like the session vs surface behaviors, but why do web developers need to pick between two types of tracks?

If we consider the following two classes of applications:
- **Capture-interacting applications** that need to react to surface-switching or interact with surface-specific APIs.
- **Capture-agnostic applications** that just want to capture what the user wants and don’t care what it is.

What I tried to achieve with this proposal was to have tracks bound to individual surfaces for capture-interaction applications while retaining the ease of use of the injection model for capture-agnostic applications. I believe the pure switch-track model is the easiest and least error-prone model for capture-interacting applications.

Overall, I think I’ve seen three different solutions to the stopping problem so far:
1. Let the session track be a proxy track for the surface tracks so it doesn’t need to be stopped independently.
1. Let session tracks and surface tracks be independent and let the application ask for the types of tracks it wants to receive
1. Let session tracks and surface tracks be independent, provide both to the application and let the application stop the one it doesn’t want (unless @youennf’s optimization applies).

I think option 1 and 2 are interesting to explore, while option 3 looks less attractive.

@youennf:
> The `onsourceswitch` or `onnewsource` approach seems sufficient to me to support both switch and injection models.

I think they can be, but I don’t think we have yet found an API-shape that we all agree on, so that’s why I explore other options.

> The small feedback I would give is that having these as events might not be great. A callback might be better instead so that there is only one receiver that is responsible to deal with it, for instance closing the new stream/tracks.
> 
> Something like `captureController.processSourceSwitch(stream => { ... });` or `captureController.processSourceSwitch(null);`

I’m fine with this.


-- 
GitHub Notification of comment by tovepet
Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share-extensions/issues/4#issuecomment-2373957275 using your GitHub account


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

Received on Wednesday, 25 September 2024 12:32:53 UTC