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

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)

From: guest271314 via GitHub <sysbot+gh@w3.org>
Date: Mon, 22 Jul 2019 23:23:01 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-513991313-1563837780-sysbot+gh@w3.org>
@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](https://bugs.chromium.org/p/chromium/issues/detail?id=980822) 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](https://bugzilla.mozilla.org/show_bug.cgi?id=1562862)  and a precursor bug [[Rethink] Support mkv|matroska|video/x-matroska in Firefox](https://bugzilla.mozilla.org/show_bug.cgi?id=1422891).

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 https://github.com/w3c/mediacapture-main/issues/611#issuecomment-513991313 using your GitHub account
Received on Monday, 22 July 2019 23:23:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:22:25 UTC