2. Approach: provide a single manual simulcast layer to make sure the resolution stays high Capture window with resolution: 1728x1001px (in browser) and 2200x1400px (true px captured via webrtc internals media source) Based on the manual config simulcast layers are:

[
    {
        "rid": "q",
        "scaleResolutionDownBy": 1.2,
        "maxBitrate": 250000,
        "maxFramerate": 2,
        "priority": "medium",
        "networkPriority": "medium"
    },
    {
        "rid": "h",
        "scaleResolutionDownBy": 1,
        "maxBitrate": 1500000,
        "maxFramerate": 15
    }
]

RESULT Playback 1 with resolution: 1773x1108px --> “q” layer selected ⚠️ Playback 2 with resolution: 1260x786px --> “q” layer selected ✅ Intuitively I would expect the first playback to go to

h

because the window being captured is smaller than the one being played back. However because it’s a high density display the actual content being captured has a higher resolution than the logical pixels. So staying on the

q

level is more or less expected because the playback size is closer to the

q

layer than it is to the

h

layer which is fine. Note: Do mind though that the playback sizes are logical px so the real px values should be about double that size as it’s also a high density display. Therefore it would be more or less expected to use the higher quality stream here too.

3. Approach: provide multiple manual simulcast layers to make sure a higher frame rate is used if possible Capture window with resolution: 1728x1001px (in browser) and 2200x1400px (true px captured via webrtc internals media source) Based on the manual config simulcast layers are:

[
    {
        "rid": "q",
        "scaleResolutionDownBy": 1.2,
        "maxBitrate": 250000,
        "maxFramerate": 2
    },
    {
        "rid": "h",
        "scaleResolutionDownBy": 1.2,
        "maxBitrate": 750000,
        "maxFramerate": 6
    },
    {
        "rid": "f",
        "scaleResolutionDownBy": 1,
        "maxBitrate": 1500000,
        "maxFramerate": 15
    }
]

RESULT Playback 1 with resolution: 1773x1108px --> “q” layer selected ❌ Playback 2 with resolution: 1260x786px --> “q” layer selected ✅ Even though the

h

quality has the same resolution as the

q

quality I never get a switch to

h

. No matter what I do it always stays on

q

even though my network connection could easily handle it. I think this must be somehow related to the

adaptiveStream

logic being confused because both

h

and

q

have the same resolution and there is no logic applied to different bitrate or frame rate settings on the layers.

Conclusion I see 2 problems with the current logic that may be improved. 1. Captured px are using real screen px which means a captured stream’s px count is way higher than the logical size we’re capturing on a high dpi display. However I have the feeling the choice of the simulcast layer for playback is based on the logical pixels. Therefore if you capture a window on a high dpi screen and play it back on the exact same screen the adaptive stream logic will likely select a lower res layer which is not expected 2. If you have multiple simulcast layers with the same resolution but different fps and frame rates the adaptive stream logic gets confused. I’d love to get some feedback on those thoughts. I also wouldn’t rule out that I’m getting something wrong as it’s a tricky topic.

After spending some more time with it I saw that you have some code in place to address the high DPI issue. However my 15" MacBook Pro M1. Returns

window.devicePixelRatio=2

which will fall back to

1

which I think isn’t quite right

Shouldn’t the statement here be

if (devicePixelRatio >= 2)

or are you excluding devices with exactly

2

on purpose?

@dry-elephant-14928 or @polite-kilobyte-67570 do you have any input on the topic?

thanks for the info @fancy-wire-61616

if the server is picking a lower layer because of congestion

No it isn’t the server is idling around just waiting for something to do 😄

@polite-kilobyte-67570 do you have any updates on the automatic selection of layers with the same resolution?

@polite-kilobyte-67570 coming back to this once more. Can you tell me in which the lower quality layer would be chosen? I would expect that to happen if there are bandwidth issues / congestions, correct?

@polite-kilobyte-67570 Sorry for digging out this super old thread but it seems like there is a rounding missing in the current

adaptive screen video dimension calculation

implementation. I’ve created an issue on GitHub. Do you want me to find the right spot and create a PR?

let me check with

1.13.2

Looking good, seems to be fixed now 👍

I think i can’t close / reject the issue on github. I’m sorry you have to do that