search

w3c / mediacapture-extensions

Extensions to Media Capture and Streams by the WebRTC Working Group
https://w3c.github.io/mediacapture-extensions/
Other
19 stars 15 forks source link

MediaStreamTrack and back/forward cache #10

Open youennf opened 4 years ago

youennf commented 4 years ago

Current browsers do not add pages that have MediaStreamTrack to the b/f cache. It would be good to get consensus on how we could end up doing so. A possibility is for local MediaStreamTracks to be ended when page enters the b/f cache. This would simulate capture failures, which can always happen.

youennf commented 4 years ago

Other specs defining tracks (like webrtc-pc) could also define their specific behavior. For remote webrtc-pc tracks, ending the tracks might also be a possibility.

henbos commented 4 years ago

When page caching has a definition we can simply say to end the track.

jan-ivar commented 3 years ago

A possibility is for local MediaStreamTracks to be ended when page enters the b/f cache.

Since this would presumably queue a task to fire the ended event on the document, would ended be fired before entering the b/f/ cache, or only on (potential) revival from it?

The latter seems appealing and most web compatible, since we've generally tried to avoid firing lots of events on navigation.

@youennf Happy to see progress on this in Safari in https://github.com/w3c/webrtc-extensions/issues/200. How does it work there?

youennf commented 3 years ago

In Safari, capture tracks are ended when going to page cache and the ended event is enqueued. It may only fire on revival. There is no specific handling for other tracks, it is up for the source object to do the page cache handling.