- From: jan-ivar via GitHub <sysbot+gh@w3.org>
- Date: Thu, 04 May 2017 21:45:17 +0000
- To: public-media-capture-logs@w3.org
@taylor-b I believe the change was a side-effect of us merging in a newer upstream version of webrtc.org; unintentional on our part. WebRTC [already has language](http://w3c.github.io/webrtc-pc/#rtcrtpsender-interface) that senders may "MAY ... rescale or resample" media. This means stats don't conclusively reveal mediacapture mute behavior. The MAY also means the sender behavior is implementation-dependent (like a lot of things observable through stats). As for observing the stream directly, [this works](https://jsfiddle.net/jib1/cfcoqdwz/) in Firefox and Chrome, though through different non-standard means. On OSX I got: `mozPaintedFrames` in Firefox goes to 0 fps on mute. `webkitDecodedFrameCount` in Chrome appears unfazed by mute (hovers around 21-30 fps). The spec isn't clear about what `track.getSettings.frameRate` should show for a muted track. Firefox currently shows 30fps for me, regardless of mute. It seems to me we generally haven't been standardizing media output. What's a case where doing so would help interop? -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/441#issuecomment-299318112 using your GitHub account
Received on Thursday, 4 May 2017 21:45:24 UTC