- From: guest271314 via GitHub <sysbot+gh@w3.org>
- Date: Tue, 17 Sep 2019 00:07:29 +0000
- To: public-webrtc-logs@w3.org
@Pehrsons > Consider recording a stream from HTMLMediaElement.captureStream(). You could pipe an audio track through webaudio to be in full control of its lifetime. Then even when a video track from the media element ended before you managed to replace it with another (which if you managed to do it in time, would chop off a bit of the track's end), you can still do that after-the-fact. Or with a gUM track in case a user killed it through the browser's chrome. That approach is possible with both audio and video. The concept of this code is an _infinite_ media stream initialized to `#000000` video frames and audio silence (utilizing `AudioWorklet`, `Worker`, and `canvas.captureStream()`) where `MediaStreamTrack`s can be added to the `MediaStream` at any time. When there is a "gap" between track additions or swaps the initial audio or video track is used for that respective track data. The entire procedure should be capable of being recorded by `MediaRecorder` with the separate capability to seek backwards or forwards for infinity given ["an idealized computer with unlimited resources"](https://en.wikipedia.org/wiki/Kurt_Gödel#Incompleteness_theorem) (for brevity citing Wikipedia), though during testing the code the tab inevitably crashes (there should be some means to reduce or memory usage for the APIs used) https://plnkr.co/edit/Axkb8s?p=info. The original issue proposing using the same or similar language to WebRTC `RTCRtpSender.replaceTrack()`. Ideally, neither a track not currently having data, nor the source `<video>` pausing, nor the track or `MediaStreamTrack` ending should be the cause of `MediaRecorder` stopping. `#000000` video frames and audio silence can be recorded by default until the user explicitly executes `stop()`. -- GitHub Notification of comment by guest271314 Please view or discuss this issue at https://github.com/w3c/mediacapture-record/pull/186#issuecomment-532004468 using your GitHub account
Received on Tuesday, 17 September 2019 00:07:31 UTC