- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Tue, 10 Dec 2024 00:54:36 +0000
- To: public-webrtc-logs@w3.org
> We are not talking same navigable but same surface. In the case of tab capture, the surface is [(the rendered form of) a navigable](https://w3c.github.io/mediacapture-screen-share/#dfn-browser). > Let's say I am doing a recording of the screen with microphone. Recording is done via MSTP in a worker. The web application wants to chapterize the recording to easily navigate to specific parts of the recording. > > Changing of surface is a good event as input for chapterization. > Getting the ID of the surface is nice as it can help user skipping to the next time user is sharing the same surface (say user is switching between two different screens, or two windows...). I'm not sure how realistic that use case is. It seems to make a lot of assumptions, like the user having several screens or windows of reasonably similar dimensions (to produce a recording with a consistent resolution). Maybe with tab capture and different tabs of the same window which would all having the same resolution. But even then, it's not clear what should constitutes a "chapter": - if I source switch to a document in a different tab I get a chapter - if I navigate to a different website within the same tab, I don't get a chapter If we're serious about solving this use case, a better approach might be to relax `track.label` to update to reflect the currently loaded document. This would allow for per-origin chapters for instance. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/308#issuecomment-2529939460 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 10 December 2024 00:54:37 UTC