profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/fippo/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

ESTOS/strophe.jingle 157

webrtc connection plugin for strophe.js

ESTOS/gowebrtc.js 26

gowebrtc.js, an implementation of the simplewebrtc API powered by xmpp

fippo/dump-webrtc-event-log 18

dumps chromes webrtc event log as json

fippo/dynamic-getUserMedia 9

Manipulate getUserMedia and enumerateDevices with an extension

DamonOehlman/travis-multirunner 7

A simple configuration for running (limited) multibrowser tests on travis ci

emcho/colibri 5

This specification defines an XMPP extension that allows real-time communications clients to discover and interact with conference bridges that provide conference mixing or relaying capabilities.

fippo/eslint-config-webrtc 2

eslint shareable config for WebRTC and ORTC

fippo/FLV.pmod 1

pike module for reading and writing FLV files

fippo/getdisplaymedia 1

an opinionated polyfill for navigator.getDisplayMedia. better approach now in adapter.js

fippo/aiortc 0

WebRTC and ORTC implementation for Python using asyncio

issue openedw3c/mediacapture-main

Document default settings applied to tracks created by getUserMedia

As discussed in https://github.com/w3c/mediacapture-main/issues/775, it seems beneficial to document which defaults are selected by User Agents. From a quick inspection, it seems that Chrome, Firefox and Safari agree on the following defaults: video: 640x480, 30fps audio: echoCancellation=true, noiseSuppression=true, autoGainControl=true

User Agents may use the same defaults, but at different point in the getUserMedia algorithm. It might be worth exploring whether we can say something about this as well.

created time in 4 minutes

issue commentw3c/mediacapture-main

what is the default channelCount

To define defaults, I think we should look at what browsers are currently doing and, where there is coincidence or near-coincidence, adopt those defaults in the spec.

I'll file an issue specifically for this. It seems channelCount differs between browsers, we can keep this issue to see whether we can reach consensus.

fippo

comment created time in 9 minutes

issue commentw3c/mediacapture-main

what is the default channelCount

So, to summarize, I agree with @youennf that "good and reliable defaults are extremely important" because experience has shown many times that when defaults change applications break, even if the default change was 100% spec compliant.

fippo

comment created time in an hour

issue commentw3c/mediacapture-main

what is the default channelCount

I don't see any contradiction in the spec having defaults and the user being able to override those defaults. The spec already says "User Agents are encouraged to default to using the user's primary or system default device for kind (when possible).", so it is already encouraging a default for the deviceId property.

To define defaults, I think we should look at what browsers are currently doing and, where there is coincidence or near-coincidence, adopt those defaults in the spec. Also, defaults don't always need to be hard-coded constants. For deviceId we're using a system-defined constant.

That said, even with defaults we will probably not achieve full compatibility across browsers since properties are correlated and different implementations have different capabilities. Still, if we can significantly improve it for the most common cases, I think that would be beneficial.

Experience shows that real-world applications rely on browser defaults and that is not going to change just because we emphasize in the spec that they shouldn't. This channelCount issue in Chrome is a good example. Chrome didn't really have a universal default as channelCount is correlated with other properties. If echoCancellation, noiseSuppression or autoGainControl was enabled, channelCount was always 1 because Chrome's audio processing implementation only supported mono output. When no processing was used, the channel count was the same as the hardware configuration. When Chrome upgraded its processing implementation to support more channels, the default for stereo microphones automatically changed to 2 in all cases and that automatically caused regressions for some applications relying on output always being mono.

fippo

comment created time in an hour

issue commentw3c/mediacapture-main

what is the default channelCount

For what it's worth, the Chromium's change in default channel count was accidental and there is a revert in progress. This will make implementing https://github.com/w3c/webrtc-extensions/issues/63 a smoother transition, whether or not we can agree on a standardized default channel count here.

fippo

comment created time in 3 hours

issue commentw3c/mediacapture-main

what is the default channelCount

E.g. going to Audio MIDI Setup and choosing my Logitech BRIO makes it the default microphone on macOS and Firefox, and now {audio: true} gives you channelCount 2 instead of 1.

Very interesting. Thanks for checking.

I think the user specifying default device makes sense because you don't want to default to that old camera or microphone that is collecting dust behind your computer, you want your shiny new device that is in your face.

However when it comes down to what "technical details" to open a particular device in, like which resolution or number of channels to use when recording, I'm not sure I see the value in letting the user/OS override what the browser does by default. The browser and/or application should know better than a normal user, especially when the application will in most use cases be streaming the content to a VC server.

This means there is no one default channelCount. That's what we should document. If your app assumes there is, then your app is broken.

If the concern is that deciding defaults now is not forward-looking, we can always revisit what the defaults should be later. At the end of the day, if an implementation changes their defaults from one version to the next that is a change in behavior, whether or not there's a spec change behind it.

Jan-Ivar, you've said in the past that "predictability trumps usefulness", but in this case it seems that unspecified defaults is neither useful or predictable.

Or am I missing something, what is the usefulness in not knowing what you get?

fippo

comment created time in 4 hours

PR closed w3c/mediacapture-main

Update to latest ReSpec version editorial

Automated changes by create-pull-request GitHub action

+274 -273

0 comment

1 changed file

dontcallmedom

pr closed time in 5 hours

PR closed w3c/webrtc-pc

Update to latest ReSpec version Editorial Editors can integrate

Automated changes by create-pull-request GitHub action

+274 -273

1 comment

1 changed file

dontcallmedom

pr closed time in 5 hours

pull request commentw3c/webrtc-pc

Update to latest ReSpec version

overtaken by #2626

dontcallmedom

comment created time in 5 hours

pull request commentw3c/webrtc-pc

Improve markup for events definitions

with #2626 merged, this now is ready to merge

dontcallmedom

comment created time in 5 hours

push eventw3c/webrtc-pc

henbos

commit sha c5671b87d04ccd65b125ce08fbfe86b121705f38

Update to latest ReSpec version

view details

Dominique Hazael-Massieux

commit sha a925dcb2b337c40f85e29a97cd46681f95f146ea

Merge pull request #2626 from w3c/respec-26.0.2 Update to latest ReSpec version

view details

push time in 5 hours

PR merged w3c/webrtc-pc

Update to latest ReSpec version Editorial

Automated changes by create-pull-request GitHub action

+293 -292

0 comment

1 changed file

dontcallmedom

pr closed time in 5 hours

create barnchw3c/webrtc-pc

branch : respec-26.0.2

created branch time in 12 hours

PR opened w3c/webrtc-pc

Update to latest ReSpec version

Automated changes by create-pull-request GitHub action

+293 -292

0 comment

1 changed file

pr created time in 12 hours

create barnchw3c/mediacapture-main

branch : respec-26.0.2

created branch time in 12 hours

PR opened w3c/mediacapture-main

Update to latest ReSpec version

Automated changes by create-pull-request GitHub action

+293 -292

0 comment

1 changed file

pr created time in 12 hours

issue commentw3c/mediacapture-main

what is the default channelCount

In theory, reading the spec should be sufficient to implement it and get interoperability with other implementations. I do not think the spec is there yet, implementors have to study what other browsers are doing to actually get to that point :(

As an example, the spec does not say whether, if echoCancellation is supported, echoCancellation should be on or off. I would guess browsers turn echo cancellation on by default, and many applications are relying on it.

I generally disagree with "If your app assumes there is, then your app is broken", good and reliable defaults are extremely important.

fippo

comment created time in 19 hours

issue commentw3c/mediacapture-main

what is the default channelCount

I know users can change default devices from OS UI. Is Firefox (or any browser) providing such camera configuration UI?

Well, we have the camera and microphone picker in the Firefox permission prompt. 🙂 But even without that, all major browsers respect OS defaults, which are often user configurable. E.g. going to Audio MIDI Setup and choosing my Logitech BRIO makes it the default microphone on macOS and Firefox, and now {audio: true} gives you channelCount 2 instead of 1.

I also could have sworn an earlier version of Audio MIDI Setup let me change the 2 ch to 1 ch, but I might be misremembering there, or it did with a different device I no longer own. I believe other OSes allow this though.

This means there is no one default channelCount. That's what we should document. If your app assumes there is, then your app is broken. This is why we have constraints and not a simpler settings API: if an app requires mono to not break, constrain it to mono. The model is: if you care about it, constrain it. Otherwise you get what you get.

fippo

comment created time in 2 days

issue commentw3c/mediacapture-main

what is the default channelCount

  1. The user configures the camera and settings they want in their OS or browser, perhaps with per-site exceptions.

I know users can change default devices from OS UI. Is Firefox (or any browser) providing such camera configuration UI?

If that is important, we can try to find wording that would still allow per-site default exceptions.

If a user inserts a stereo microphone they just bought, why shouldn't they get stereo on every site out there?

We could define a default rule so that, post device selection, channelCount would be set to 2 if feasible. I do not see how this use case describes the benefit of the current approach, especially if one browser would use stereo if available and another would stick to mono.

One of the advantages of the native WebRTC stack is that this can just work without requiring each app to support it.

I am not sure what 'just work' means. Some native clients do not support stereo and may break if the default suddenly changes. Some web clients will not benefit from stereo and will experience suboptimal experience (due to bandwidth increase).

Browsers may not be doing much with their defaults atm, but defaulting to 640x480x30 mono forever doesn't seem very forward looking.

The idea is not to stick to 640x480x30 + mono forever, web specs do change everyday. The idea is to document these defaults, if we can agree on these defaults. Then, to change these defaults progressively and consistently.

I do not know what default rules Firefox is using. If it does something similar (or is willing to do something similar) to Chrome and Safari, why not documenting it?

fippo

comment created time in 2 days

issue commentw3c/mediacapture-main

what is the default channelCount

This would make all implementations work in a more predictable way, especially in the common cases where few or no constraints are passed to gUM

I'm sympathetic to web compat concerns, which we experience as well. However, I'm not sure this would be better for users. Constraints were purposely designed to balance control between two stakeholders: the user and the application, perhaps best illustrated by their two extremes:

  1. The user configures the camera and settings they want in their OS or browser, perhaps with per-site exceptions.
  2. Each application configures what camera and settings to use

1 is an unconstrained track. 2 is a constrained track. This is why constraints were purposely designed to not specify defaults, and why constraints are distinct from settings in the API in the first place.

User agents conspiring on a fixed set of default settings forever for all devices in the interest of web compat for apps, would wreck 1.

For example: If a user inserts a stereo microphone they just bought, why shouldn't they get stereo on every site out there? One of the advantages of the native WebRTC stack is that this can just work without requiring each app to support it.

Browsers may not be doing much with their defaults atm, but defaulting to 640x480x30 mono forever doesn't seem very forward looking. I don't think we should lock ourselves down there.

fippo

comment created time in 2 days

pull request commentw3c/webrtc-insertable-streams

Add API and algorithm to expose transform to workers

uggest making one PR to add the new API and another one that takes the old API away, so that we can discuss them separately.

I reverted the changes, PR now only adds stuff!

youennf

comment created time in 3 days

issue commentw3c/mediacapture-main

what is the default channelCount

Could we do the same for channelCount without having to revert the culprit CL?

fippo

comment created time in 3 days

issue commentw3c/mediacapture-main

what is the default channelCount

Chromium does something very similar to that as well for those 3 properties.

fippo

comment created time in 3 days

issue commentw3c/mediacapture-main

what is the default channelCount

Agreed. In Safari, we are artificially adding ideal width/height/frame rate constraints (640/480/30) if no corresponding constraint is given.

fippo

comment created time in 3 days

issue commentw3c/mediacapture-main

what is the default channelCount

I think we should in as many cases as possible specify default values for all constrainable properties a criteria to break ties when multiple configurations have the same fitness. This would make all implementations work in a more predictable way, especially in the common cases where few or no constraints are passed to gUM.

fippo

comment created time in 3 days

issue commentw3c/mediacapture-main

what is the default channelCount

I am in favour of making browsers as consistent as possible in the way tracks are initialised, past the point devices are selected. That includes channel count, width, height... It is probably painful for web developers and error prone since testing might only happen in one browser in practice.

In general, it seems good to document the default behavior, especially if it is consistent amongst browsers. If the defaults have to change in the future, it might be best to document the change and coordinate within implementations.

fippo

comment created time in 3 days

issue commentw3c/mediacapture-main

what is the default channelCount

@guidou says the default likely changed here: https://chromium-review.googlesource.com/c/chromium/src/+/2593122

fippo

comment created time in 3 days

issue commentw3c/mediacapture-main

what is the default channelCount

Per summary over at https://github.com/w3c/webrtc-extensions/issues/63#issuecomment-786118846, would it make sense to mandate default channel count or is this something that should be up to the browser?

@guidou what do you think about default channel count = 1 in Chrome?

fippo

comment created time in 3 days

issue commentw3c/webrtc-pc

Should garbage collecting RTCDataChannels be observable?

I concur, that's a reasonable solution

jan-ivar

comment created time in 4 days

pull request commentw3c/webrtc-insertable-streams

Add API and algorithm to expose transform to workers

Suggest making one PR to add the new API and another one that takes the old API away, so that we can discuss them separately.

youennf

comment created time in 4 days