You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The relative order of the tracks in the set is User Agent defined and the API will never put any requirements on the order.
However, after filing this issue at that specification, was referred to the mediacapture-record specification as owner of the context w3c/mediacapture-main#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 by MediaRecorder at Chromium
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.
The text was updated successfully, but these errors were encountered:
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 w3c/mediacapture-main#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
.The text was updated successfully, but these errors were encountered: