I think the Right Solution is to make MediaRecorder have a method that allows you to specify which tracks go with what number in the container-dependent ordering.
Not only does the number of channels need to be adjusted, though also, to merge the two files the developer needs to map which next track to append to the current track. For only two tracks that can be simple, for multiple tracks in arbitrary order, the task can become meticulous.
This change will also provide uniformity for all implementations, for example, the ability to merge a WebM file output by Chromium/Chrome and a webm file output by Firefox, setting aside for the moment that Chrome sets audio_sampling_frequency to 48000, while Firefox sets the property to 44100.
This change means a method such as
To the degree deemed to be controlling or relevant at this specification, track order language is found at https://w3c.github.io/mediacapture-main/
However, after filing this issue at that specification, was referred to the mediacapture-record specification as owner of the context https://github.com/w3c/mediacapture-main/issues/611.
If a
MediaStream
contains both audio and video then the order described at the first sentence should be applied.The reason for the change is for post-record editing, which becomes tedious when the order of the tracks is arbitrary.
Consider two
webm
files output byMediaRecorder
at ChromiumNot only does the number of channels need to be adjusted, though also, to merge the two files the developer needs to map which next track to append to the current track. For only two tracks that can be simple, for multiple tracks in arbitrary order, the task can become meticulous.
This change will also provide uniformity for all implementations, for example, the ability to merge a WebM file output by Chromium/Chrome and a
webm
file output by Firefox, setting aside for the moment that Chrome setsaudio_sampling_frequency
to48000
, while Firefox sets the property to44100
.