Bug 249298

Created attachment 464037 [details]
Screenshot showing the console output from a random page

Triggering the navigator.getUserMedia (with specifying aspectRatio) multiple times in a row results in inconsistent streams. The initial one or two attempts behaves properly (track resolution respects the aspectRatio) but then it returns tracks with default camera resolution (similar as if the aspectRatio constraint was not supplied at all).

When NOT specifying the aspectRatio, the default for my camera is 4:3 (640x480)
I want to grab my camera in 16:9 ratio (so the resolution should be 640x360).

When I call the following code in the Web inspector console for a few times in a row:

```
navigator.mediaDevices.getUserMedia({"video":{"aspectRatio":{"exact":1.7777777}}}).then(s => console.log(JSON.stringify(s.getVideoTracks()[0].getSettings())))
```

I see the following results:

```
> navigator.mediaDevices.getUserMedia({"video":{"aspectRatio":{"exact":1.7777777}}}).then(s => console.log(JSON.stringify(s.getVideoTracks()[0].getSettings())))
[Log] {"deviceId":"9511AD54568AA9F2D0BA428EC9613BA508DB5746","frameRate":30,"height":360,"width":640}
> navigator.mediaDevices.getUserMedia({"video":{"aspectRatio":{"exact":1.7777777}}}).then(s => console.log(JSON.stringify(s.getVideoTracks()[0].getSettings())))
[Log] {"deviceId":"9511AD54568AA9F2D0BA428EC9613BA508DB5746","frameRate":30,"height":360,"width":640}
> navigator.mediaDevices.getUserMedia({"video":{"aspectRatio":{"exact":1.7777777}}}).then(s => console.log(JSON.stringify(s.getVideoTracks()[0].getSettings())))
[Log] {"deviceId":"9511AD54568AA9F2D0BA428EC9613BA508DB5746","frameRate":30,"height":480,"width":640}
```

You can see that the first 2 attempts results in the right resolution (640x360) but then its 640x480.

Tested on Safari 16.1 in MacOS Ventura 13.0.1
It behaves the same on Safari Technology Preview 16.4 except that only the first attempt returns the current resolution, every next returns the wrong one.

Please note that I'm intentionally NOT destroying/cleaning the streams in between attempts. The issue DOES NOT occur when the streams gets cleaned in between attempts (by calling `track.stop()` on every track of the stream).