Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
mklepaczewski opened this issue Dec 11, 2023 · 2 comments
Labels
bug Something isn't working

Comments

@mklepaczewski
Copy link

mklepaczewski commented Dec 11, 2023

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

  • Device: PC Ryzen 5900x, also MacBook M1 Pro
  • OS, version: MacOs, Windows 10
  • Browser, version: Chrome 119.0.6045.200
@mklepaczewski mklepaczewski added the bug Something isn't working label Dec 11, 2023
@mklepaczewski mklepaczewski changed the title BUG - scaleResolutionBy and maxFramerate are ignored for video when network topology is peer BUG - scaleResolutionBy and maxFramerate are ignored for video and screenVideo when network topology is peer Dec 11, 2023
@mattieruth
Copy link
Contributor

mattieruth commented Dec 18, 2023

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
Copy link
Author

mklepaczewski commented Dec 18, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants