- From: Andreas Pehrson via GitHub <sysbot+gh@w3.org>
- Date: Wed, 15 Mar 2017 10:30:47 +0000
- To: public-media-capture-logs@w3.org
@miguelao I think that goes semantically against the API. You hand it a MediaStream so you expect it to be able to handle it. Otherwise the API should take an array of tracks, as that is really nothing more than "a bag of tracks" (and it doesn't solve issues like the one below). I have been hinting in a couple of places about making blobs individually playable MSE-style, as I see that solving a number of issues, including handling track changes gracefully as the most prominent one. The reason I keep pushing for it is that I haven't heard any good arguments against it. If you have some I'd love to hear them. Take for example an api that gives you a MediaStream, that inherently from that api will change its track set. A good candidate for this is media element capture, [1]. That api gives you a MediaStream, and if the application changes the selected VideoTrack, the one VideoStreamTrack in that MediaStream will be replaced with a new one. This is painfully difficult to record. You could record all tracks separately and remux on a server somewhere, but then you need to solve syncing. You could record audio and video together and start a new recording whenever there's a track set change, then stitch it together in a remuxing step afterwards. However if video changes, that results in a gap in audio. And so on. We need something better. [1] https://w3c.github.io/mediacapture-fromelement/#html-media-element-media-capture-extensions -- GitHub Notification of comment by Pehrsons Please view or discuss this issue at https://github.com/w3c/mediacapture-record/issues/4#issuecomment-286702238 using your GitHub account
Received on Wednesday, 15 March 2017 10:30:53 UTC