search

daily-co / daily-js

https://docs.daily.co/reference/daily-js
BSD 2-Clause "Simplified" License
103 stars 33 forks source link

BUG - `scaleResolutionBy` and `maxFramerate` are ignored for `video` and `screenVideo` when network topology is peer #234

Open mklepaczewski opened 11 months ago

mklepaczewski commented 11 months ago

Expected behavior

Framerate and resolution should change when in peer topology after this call:

callFrame.updateSendSettings({
                    video: {
                        maxQuality: "low",
                        encodings: {
                            low: { maxBitrate: 3000 * 1000, scaleResolutionDownBy: 16, maxFramerate: 5 },
                        }
                    }
                });
            })

Describe the bug (unexpected behavior)

Framerate and resolution is not affected.

Steps to reproduce

Use the test script below. Note that you need to provide your own ROOM_URL. Uncomment //return callFrame.setNetworkTopology({ topology: "sfu"}); to switch to sfu topology to see the settings being applied. 

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>fullscreen embedded prebuilt with chat overlay</title>
    <script crossorigin src="https://unpkg.com/@daily-co/daily-js"></script>
    <style>
    </style>
</head>

<body onload="join()">

<script>
    const ROOM_URL = "";

    async function join() {
        callFrame = DailyIframe.createFrame({
            showLeaveButton: true,
            iframeStyle: {
                position: "fixed",
                border: 0,
                top: 0,
                left: 0,
                width: "100%",
                height: "100%",
            },
        });

        callFrame
            .join({ url: ROOM_URL })
            .then(() => {
                //return callFrame.setNetworkTopology({ topology: "sfu"});
                return callFrame.setNetworkTopology({ topology: "peer"})
            })
            .then(() => {
                /* Reset send settings */
                return callFrame.updateSendSettings({ video: "default-video"});
            })
            .then(() => {
                console.log("Setting custom quality settings");
                return callFrame.updateSendSettings({
                    video: {
                        maxQuality: "low",
                        encodings: {
                            low: { maxBitrate: 3000 * 1000, scaleResolutionDownBy: 16, maxFramerate: 5 },
                        }
                    }
                });
            })
    }
</script>
</body>
</html>

System information

mattieruth commented 11 months ago

This is expected behavior as simulcast is not supported or needed in peer-to-peer connections. In peer-to-peer, clients share a single stream to each peer in the call and negotiates the best setting for each connection themselves. Sending multiple layers per connection would greatly increase outgoing bitrate with no benefit.

As an aside, we recommend and default to sfu calls for any call with more than 2 participants. It's also required for things like cloud recording, streaming, and mobile development. If you are doing only 1:1 calls and do not need any of the features the sfu provides, but still need to have control over outgoing streams, you can look into setBandwidth() but I recommend extra caution if you have calls that use the sfu.

If you have further questions or want to run your settings and use case by us, I recommend doing so on our community forum.

mklepaczewski commented 11 months ago

Thank you. I'll give setBandwidth() a try. However, I'm concerned about this blog post which states that setBandwidth() will eventually be deprecated. How long can we expect setBandwidth() to be supported?

Update setBandwidth() controls only video stream; it doesn't seem to allow to control screen sharing quality.

Since using updateSendSettings() isn't supported when using peer connections, Daily should log a warning to the console.

In peer-to-peer, clients share a single stream to each peer in the call and negotiates the best setting for each connection themselves.

Note that "best setting" is context-dependent. Our use case requires a very low resolution, even when resources allow far better quality.