- From: Andreas Pehrson via GitHub <sysbot+gh@w3.org>
- Date: Mon, 19 Oct 2020 07:53:11 +0000
- To: public-webrtc-logs@w3.org
> If audioBitsPerSecond and videoBitsPerSecond are not specified, it is up to the User-Agent to specific these values. > This might usually be platform specific and may depend on the actual encoder being used. My intention when writing the text referred to here was to have the UA choose bitrates as a fallback in case the application didn't specify any. If bitrates are important to the application's use case it should specify them. Having the UA be too smart about choosing bitrate (e.g., "This might usually be platform specific and may depend on the actual encoder being used") opens up a fingerprinting surface. I can see how a particular encoder's default is specific to that encoder, but what this is about in my mind is a UA default that the encoder gets configured with, whether it agrees that is the default or not. > These values may only be available asynchronously as encoders may leave in a different thread/process. If needed I'm sure that could be worked around in the spirit of https://github.com/w3ctag/design-reviews/issues/439 > It seems it would be useful to be able to update audioBitsPerSecond and videoBitsPerSecond like done for mimeType, before the start event of MediaRecorder is started. Note that mimeType is only set async because of the changes for passthrough codecs, i.e., the codec for data received from a peer connection is only known once data has been received. The track however exists and can be recorded before that. -- GitHub Notification of comment by Pehrsons Please view or discuss this issue at https://github.com/w3c/mediacapture-record/issues/205#issuecomment-711789089 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 19 October 2020 07:53:13 UTC