W3C home > Mailing lists > Public > public-media-capture-logs@w3.org > May 2017

Re: [mediacapture-main] Algorithm to mute/disable tracks is unclear

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
Message-ID: <issue_comment.created-299318112-1493934316-sysbot+gh@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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:27:32 UTC