What are the simulcast changes should I do while updating Daily from 0.47 to latest version

Options
2

Answers

  • mark_at_daily
    mark_at_daily Community Manager, Dailynista admin
    Options

    I did set maxQuality as 'high' and 'medium' , when the threshold is 'good' and 'low' respectively.
    Should I set maxQuality as 'low' or should I turn off local camera, when the threshold is 'very-low'?
    I heard that "we should lower the quality when the bandwidth is low and we should turn off local camera when there is no enough network.

    This is a choice you have to make for your application. We do this exact thing (turn off camera for 'very-low') in Daily Prebuilt.

  • svm_agilis
    Options

    Thank you @mark_at_daily
    When the cpu load state is high should I change both send and receive settings? Or should I check cpuLoadStateReason as follows?
    1. When cpuLoadStateReason = encode, lowering the outgoing video by calling updateSendSettings().
    2. When cpuLoadStateReason = decode, requesting a lower simulcast layer by calling updateReceiveSettings().
    3. When the cpuLoadStateReason = scheduleDuration, do both.

  • mark_at_daily
    mark_at_daily Community Manager, Dailynista admin
    Options

    What you proposed seems logical.

  • svm_agilis
    Options

    Hi @mark_at_daily
    the method updateReceiveSettings is working for participant video track. But when I use the method to update receive settings for custom video tracks, it is not working. I have used the method with the key "[customVideoTrackName]" also with the key "custom". But none of them seems to work. Also the key "video" doesn't seems to work for custom video tracks. Is there any other way?

    await callObject?.updateSendSettings({ streamVideoTrack: { maxQuality: 'low' } });
    callObject?.updateReceiveSettings({ [streamingParticipantId]: { video: { layer: 1 }, streamVideoTrack: { layer: 1 }, custom: { layer: 1 } } });


    though updateReceiveSettings were not working. updateSendSettings working fine with the key [customTrackName].




  • mark_at_daily
    mark_at_daily Community Manager, Dailynista admin
    Options

    @svm_agilis you're right. updateReceiveSettings() isn't currently support for custom tracks. This is something that we plan to add in the near future. Apologies for this gap.

  • svm_agilis
    Options

    @mark_at_daily Thank you for confirming.

  • svm_agilis
    Options

    Hi @mark_at_daily

    I saw a suggestion about screenshares in Daily's documentation, please check the below screenshot. Here it is mentioned that screenshares are bandwidth intensive. Hence, use only one simulcast layer and set maxQuality as low.


    In my application, I am creating a custom track from recorded video using "captureStream" method and publishing it to other participants using "callObject.startCustomTrack" method. Similar to screenshare videos, are custom tracks created from recorded videos also bandwidth intensive? . If so, Can you please let me know, is the suggestion(use only one simulcast layer and set maxQuality as low) about screenshares also applicable for custom tracks created from recorded videos.

    Thank you

  • mark_at_daily
    mark_at_daily Community Manager, Dailynista admin
    Options

    It depends what you're capturing. Screen share videos are usually high bandwidth because of two factors: 1) the pixel size can be large, 2) there's complex content to encode and stream. For example, when a screen share is left uncapped (i.e. no maxBitrate specified), just scrolling a webpage can take upwards of 5-7 Mbps. By default, the screen share send setting preset uses a 2 Mbps cap.

    If your recorded video is more like a webcam (720p or lower resolution) then simulcast would potentially be fine. If it's more like a screen share (higher resolution, complex video), then you might want to be more conservative with your settings.

    Notes:
    - screen shares aren't always high bandwidth, but they're often bursty. For example, if that web page you were scrolling becomes idle, the bitrate and frame rate drop to relatively low values. Its' the bursty bandwidth behavior that makes screen shares trickier to handle.
    - simulcast often isn't a good idea for screen shares because lower resolutions leave finer details, like text, illegible.

    Hope this helps!

  • svm_agilis
    Options

    videos are recorded from webcam using Daily's "startRecording" method. So as per your comments, Daily's default simulcast encodings and setting maxQuality as high will be fine for my application. Is that correct?

    Thank you @mark_at_daily

  • mark_at_daily
    mark_at_daily Community Manager, Dailynista admin
    Options

    Daily's default simulcast encodings and setting maxQuality as high will be fine for my application. Is that correct?

    Yes, the default settings should be fine.