- From: guest271314 via GitHub <sysbot+gh@w3.org>
- Date: Tue, 26 Mar 2019 16:30:29 +0000
- To: public-webrtc-logs@w3.org
@Pehrsons Do you mean re-record the recorded media fragments? There are several approaches that have considered and tried. The concept is briefly outlined at https://github.com/w3c/mediacapture-main/issues/575. https://github.com/guest271314/ts-ebml provides assistance "remux"ing recorded webm files. https://github.com/guest271314/whammy and https://github.com/guest271314/webm-writer-js provide a means to write images to a webm file created "on the fly", though without support for adding/including audio. If there were a means to write the Matroska or Webm file directly using human-readable format https://github.com/Matroska-Org/matroska-specification/issues/129, https://github.com/Matroska-Org/ebml-specification/issues/156 the image and audio chunks could be written "on the fly" to a single file. What this feature request basically asks for is some form of a flag, or property at options passed to `MediaRecorder` to NOT change `state` to inactive when a single `<video>` or `<audio>` element being captured changes `src`. Beyond the basic feature request, for the ability of `MediaRecorder` to record multiple tracks in sequence even if a track that is e.g., at index 1 of an array passed to `MediaStream` is ended before the track at index 0, then write the data to the resulting webm file. Instead of using several different API's (`AudioContext`, `canvas`) to try to achieve the expected result of concatenating several audio and/or video fragments (or full videos) while simultaneously trying to synchronize audio and video. The functionality is essentially possible using `canvas` and `AudioContext`, though could be far simpler if `MediaRecorder` was extended to handle multiple video and audio tracks. In the absence of changing or extending `MediaRecorder` specification then the feature request is for a webm writer - which provides a means to concatenate _video_ data, similar to what is possible using `.decodeAudioData()` and `OfflineAudioContext()` and/or concatenating `AudioBuffer`s (see https://github.com/w3c/mediacapture-main/issues/575) - using human-readable structure, e.g., `XML` that is then written to `EBML` (https://github.com/vi/mkvparse), where the API is `Promise`-based (the media at index N might be read before media at index 0) though the mechanism "awaits" completion of all input media before writing the output: single webm file. -- GitHub Notification of comment by guest271314 Please view or discuss this issue at https://github.com/w3c/mediacapture-record/issues/166#issuecomment-476732810 using your GitHub account
Received on Tuesday, 26 March 2019 16:30:31 UTC