Re: [mediacapture-main] Remove "The relative order of the tracks in the set is User Agent defined and the API will never put any requirements on the order.", et al. (#611)

@youennf This specification is controlling as to track order, not `MediaRecorder`, correct? `MediaRecorder` specification authors could simply refer to the current language of this specification and state that  "the API will **never** put any requirements on the order."  As mentioned at OP the order the tracks appear in the actual WebM file is arbitrary, as demonstrated by the output of `mkvmerge -J`. 

Consistent track order is one part of the issue. As yet have not found or been successful with a workaround to set the `audio_sampling_frequency` at Chromium to any value, thus the default `48000` is always set. 

Chrome authors have deviated from the spirit of the WebM specification leading to this issue Issue [980822: MediaRecorder can generate invalid webm files]( being filed by a Firefox developer

> I will put this to the Media working group agenda at the next TPAC

stemming from this Firefox bug [Webm support for h.264 codec](  and a precursor bug [[Rethink] Support mkv|matroska|video/x-matroska in Firefox](

Essentially this issue is attempting to provide a venue to arrive at a tentative "consensus" as to whether specification authors and implementers of `MediaStream` and resulting WebM files are actually interested in producing consistent output that is, to an appreciable, "interoperable". Chrome authors of `MediaRecorder` had no issue implementing `h264` (openh264) and `avc1` codecs in a WebM container; Firefox developers are evidently not in accord with that decision, hence the Chromium issue. Have not tried Safari implementations, here.

While the topic is at hand the relevant stakeholders _could_ actually make an effort to agree upon 1) consistent track order; 2) which codecs could optionally be used, or explicitly not be used in a WebM container; 3) which `audio_sampling_frequency` should be used; 4) and if none of the above can be agreed upon by specification authors and implementers, then at least provide a _means_ for front-end users to agree upon how _they_ will proceed and implement the methods necessary for front-end developers to set track order, `audio_sampling_frequency`, for the purpose of interoperability. 

GitHub Notification of comment by guest271314
Please view or discuss this issue at using your GitHub account

Received on Monday, 22 July 2019 23:23:04 UTC