On Fri, Oct 4, 2019 at 6:54 AM Tom Ritter wrote:
> It's a bit hard for me to tell from the description - are these values
> dependent on a user's hardware, performance of the user's computer, or
> a user-chosen setting? If so we would want to support
> resistFingerprinting.
>
The spec allows the UA to base them on anything it sees fit, if the
application leaves it
to the UA to decide. Our implementation uses fixed and application-provided
values, per below.
There are three different modes of configuring these values for an
application, and here's how we set them:
1) Application did no configuration at all: we use hardcoded values:
2.5Mbps for video and 128kbps for audio
2) Application configured audio and video respectively: we use the provided
values
3) Application configured a total bitrate: Our implementation has a fixed
algorithm for this -- its only inputs
is the number of tracks and kinds of tracks, and the total bitrate
configured is distributed according to a
weighting where a video track gets 20 times as high a bitrate as audio, and
they're capped within fixed limits.
(see https://phabricator.services.mozilla.com/D41585#C1663069NL43 for the
limits, and
https://phabricator.services.mozilla.com/D41585#C1663069NL212 for the
algorithm)
Given this, I don't see the need for explicit resistFingerprinting support.
-tom
>
> On Thu, Oct 3, 2019 at 9:54 PM Andreas Pehrson
> wrote:
> >
> > As of Oct 4th I intend to land and ship the audioBitsPerSecond and
> > videoBitsPerSecond attributes of MediaRecorder on all platforms. We've
> > shipped MediaRecorder since Firefox 29.
> >
> > *Summary*: The audioBitsPerSecond and videoBitsPerSecond attributes of
> > MediaRecorder reflect what an application has configured the
> MediaRecorder
> > to use (and which we already ship support for doing). In case it was
> > configured with a total (audio+video) bitrate, or if it was not
> configured
> > at all, these attributes reflect what the UA has chosen to configure the
> > MediaRecorder with.
> >
> > After starting a recording, these are again updated to reflect the
> current
> > configuration of the MediaRecorder, since tracks are now known and the UA
> > may have recalculated the chosen bitrates based on the number and kind of
> > tracks that are being recorded.
> >
> > At the same time I'm making our MediaRecorder implementation largely
> > spec-compliant. There's work in bug 1514158 as well as bug 1512175, where
> > the former is focusing on these attributes and the latter focuses on mime
> > type handling. We landed spec clarifications for both of these recently.
> >
> > *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1514158
> >
> > *Standard*:
> >
> https://w3c.github.io/mediacapture-record/MediaRecorder.html#dom-mediarecorder-videobitspersecond
> > Clarifications were made to the spec to make this more interoperable.
> These
> > were approved by Google.
> https://github.com/w3c/mediacapture-record/pull/175
> >
> > *Platform coverage*: All
> >
> > *Preference*: There is no special pref for these attributes
> >
> > *DevTools bug*: There is no generic devtools support for MediaRecorder
> >
> > *Other browsers*:
> > Chrome shipped (since 49, bug:
> > https://bugs.chromium.org/p/chromium/issues/detail?id=262211),
> > Safari shipped MediaRecorder but no attributes yet (behind an
> experimental
> > feature flag since TP73, bug:
> https://bugs.webkit.org/show_bug.cgi?id=85851)
> >
> > *web-platform-tests*: I'm adding one as part of bug 1514158:
> > https://phabricator.services.mozilla.com/D41584
> >
> > *Secure contexts*: No, MediaRecorder is historically not restricted to
> > secure contexts. However some APIs for getting access to the
> > MediaStreamTracks needed to create a recorder are.
> >
> >
> > Andreas Pehrson
> > ___
> > 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
