W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > June 2019

Re: [mediacapture-record] Why is start 5.3 in the specification? (#168)

From: guest271314 via GitHub <sysbot+gh@w3.org>
Date: Thu, 06 Jun 2019 21:49:34 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-499680896-1559857773-sysbot+gh@w3.org>
@alvestrand 

> Recording multiple tracks was intended to be possible from day one. Many formats handle multiple tracks.

That intention should not be abandoned. Or state clearly to abandon all hope of multiple tracks

https://searchfox.org/mozilla-central/source/dom/media/MediaRecorder.cpp#778
```
      // When MediaRecorder supports multiple tracks, we should set up a single
      // MediaInputPort from the input stream, and let main thread check
      // track principals async later.
```

> When it was pointed out that a lot of container formats couldn't handle increasing the number of channels mid-recording, we were left with two choices:
> 
> - Make the behavior dependent on container format (unpalatable)
> - Make the behavior consistent, but not very useful (ie stop).
> The WG chose the latter.

From a novice front-end perspective (within the context of the use case of not stopping `MediaRecorder` when `src` of `<video>` changes), with no experience coding in C or C++, reading the source code appears to allow for changing the source of the principal media resource using array indexes (`MediaStream.selectTrack()`). Does the functionality need to be more complex than that? 

> I am not aware of any change in the landscape of container formats that seems to indicate that varying the number of tracks is a generally available option. If you know of such changes, please provide references.

Again, from a novice front-end perspective with little experiece reading (https://gist.github.com/guest271314/f942fb9febd9c197bd3824973794ba3e ; https://gist.github.com/guest271314/17d62bf74a97d3f111aa25605a9cd1ca) and no experience writing media containers, given that the decoder/encoder/writer must write in sequential, linear order, it should not make any difference what the input media is.  Each media container (and codec) that `MediaRecorder` supports must write the data; e.g., `<timecode>0.026</timecode>` to output from 0 to _N_ in sequential order, no matter whether the media track changes or the input decoded `<timecode>0.026</timecode>`, if applicable, is not sequential with reference to the data being recorded and written? 

-- 
GitHub Notification of comment by guest271314
Please view or discuss this issue at https://github.com/w3c/mediacapture-record/issues/168#issuecomment-499680896 using your GitHub account
Received on Thursday, 6 June 2019 21:49:35 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 6 June 2019 21:49:36 UTC