Re: Intent to ship WebRTC RTCRtpReceiver contributing and synchronization sources
Answers can be found inline. -Nico On 12/7/17 12:45 PM, Boris Zbarsky wrote: On 12/6/17 3:22 PM, Nico Grunbaum wrote: It is in nightly now, and we intend to ship these interfaces in 59. Chrome shipped a partial implementation[3] of getContributingSources() in 59. Edge has partial support[4] for getContributingSources(). OK. Neither of those ships getSynchronizationSources(), right? Correct those are not shipping in Chrome or Edge yet. Chrome has issued an intent to ship: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/I39cDWKyMJo . I have not found any such signals with regards to Edge. Testing: WPT are disabled, as the tests are themselves not functional[5] and there is ongoing spec discussion as how to fix them[6]. Do we have other (non-wpt) tests for this running in our CI? Yes, we have coverage via mochitests. Have we done any checking of how interoperable what we're proposing to ship is with what the other UAs have shipped? No, not yet, and I agree with your statements below on why this is important to complete. I just filed a few issues on the spec here, because some parts of it are not making sense to me: * https://github.com/w3c/webrtc-pc/issues/1688 * https://github.com/w3c/webrtc-pc/issues/1689 * https://github.com/w3c/webrtc-pc/issues/1690 For the first two, it's a question about the API shape that is being specified. For the last one, it's an issue where the spec is not clear enough to implement interoperably, from what I can tell, and testing to see what various shipping implementations do might be interesting. Yes, the last one in particular is an interesting point and an open issue https://github.com/w3c/webrtc-pc/issues/1497. I looks to be an 2018 interim topic. There also appears to be discussion of this issue on the Chrome bug for getContributingSources, https://bugs.chromium.org/p/chromium/issues/detail?id=625208#c11 FWIW Our implementation makes sure that timestamp field is comparable to Date.now() so that it will also be comparable to timestamps in getStats(), https://www.w3.org/TR/webrtc/#dom-rtcstats-timestamp . -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship WebRTC RTCRtpReceiver contributing and synchronization sources
Thank you for the link to the template Boris. Intent to ship WebRTC RTCRtpReceiver contributing and synchronization sources Summary: RTCRtpReceiver's[1] getSynchronizationSources() method allows WebRTC applications to monitor volume levels of call participants without having to use the costly getStats()[2] call. RTCRtpReceiver's getContributingSources() method enables WebRTC applications to monitor the volume level of participants whose audio is being mixed upstream if the mixer includes this data in the RTP extension headers. It is in nightly now, and we intend to ship these interfaces in 59. Chrome shipped a partial implementation[3] of getContributingSources() in 59. Edge has partial support[4] for getContributingSources(). Bug to turn on by default: https://bugzilla.mozilla.org/show_bug.cgi?id=1363667 Link to standard: https://w3c.github.io/webrtc-pc/#rtcrtpreceiver-interface Testing: WPT are disabled, as the tests are themselves not functional[5] and there is ongoing spec discussion as how to fix them[6]. [1] https://w3c.github.io/webrtc-pc/#dom-rtcrtpreceiver [2] https://w3c.github.io/webrtc-pc/#dom-rtcrtpreceiver-getstats() [3] https://bugs.chromium.org/p/chromium/issues/detail?id=703122&desc=2 [4] https://msdn.microsoft.com/en-us/library/mt502507(v=vs.85).aspx [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1419900 [6] https://github.com/w3c/webrtc-pc/pull/1668#issuecomment-346951615 -- Nico Grunbaum On 12/6/17 5:42 AM, Boris Zbarsky wrote: Would you mind filling out the other parts of the intent templates at https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Intent_to_Implement and https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Intent_to_Ship ? At the very least, what is the status in other implementations and what is the testing situation? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to ship WebRTC RTCRtpReceiver contributing and synchronization sources
Background: RTCRtpReceiver's[1] getSynchronizationSources() method allows WebRTC applications to monitor volume levels of call participants without having to use the costly getStats()[2] call. RTCRtpReceiver's getContributingSources() method enables WebRTC applications to monitor the volume level of participants whose audio is being mixed upstream if the mixer includes this data in the RTP extension headers. We intend to ship these interfaces in 59, and they are on nightly now. Tracking: https://bugzilla.mozilla.org/show_bug.cgi?id=1363667 [1] https://w3c.github.io/webrtc-pc/#dom-rtcrtpreceiver [2] https://w3c.github.io/webrtc-pc/#dom-rtcrtpreceiver-getstats() Cheers, Nico Grunbaum -. --. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: More ThinkStation P710 Nvidia tips (was Re: Faster gecko builds with IceCC on Mac and Linux)
For rr I have an i7 desktop with a base clock of 4.0 Ghz, and for building I use icecc to distribute the load (or rather I will be again when bug 1412240[0] is closed). The i9 series has lower base clocks (2.8 Ghz, and 2.6Ghz for the top SKUs)[1], but high boost clocks of 4.2 Ghz. If I were to switch over to an i9 for everything, would I see a notable difference in performance in rr? -Nico [0] https://bugzilla.mozilla.org/show_bug.cgi?id=1412240 Build failure in libavutil (missing atomic definitions), when building with clang and icecc [1] https://ark.intel.com/products/series/123588/Intel-Core-X-series-Processors On 10/27/17 7:50 PM, Robert O'Callahan wrote: BTW can someone forward this entire thread to their friends at AMD so AMD will fix their CPUs to run rr? They're tantalizingly close :-/. Rob ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
