twilio / twilio-video-ios

Programmable Video SDK by Twilio
http://twilio.com/video
Other
68 stars 22 forks source link

CPU / Network usage with VP8 in simulcast mode #87

Open zintus opened 4 years ago

zintus commented 4 years ago

Disabled tracks consume system resources

Steps to reproduce

1) Setup latest quickstart example from https://github.com/twilio/video-quickstart-ios 2) Modify mute button to disable local video track.

    @IBAction func toggleMic(sender: AnyObject) {
        if (self.localAudioTrack != nil) {
            self.localAudioTrack?.isEnabled = !(self.localAudioTrack?.isEnabled)!
            self.localVideoTrack?.isEnabled = !(self.localVideoTrack?.isEnabled)!
            // Update the button title
            if (self.localAudioTrack?.isEnabled == true) {
                self.micButton.setTitle("Mute", for: .normal)
            } else {
                self.micButton.setTitle("Unmute", for: .normal)
            }
        }
    }

3) Run app, choose VP8 simulcast codec, connect to a room 4) Wait for network usage / CPU to stabilize 5) Disable audio / video tracks with mute button

Actual result

CPU usage stay almost same, network drops to 0.5x of enabled state

Expected result

CPU usage drop 30%, network drop 90%. These numbers are from same test performed with simulcast disabled. Ideally CPU / network would be the same as connecting to room with local tracks unpublished. From our tests this is -80% CPU, -99% network

ceaglest commented 4 years ago

Hi @zintus,

Disabled audio tracks still send muted audio but they are not forwarded to other Participants in a Group Room. With simulcast video, there is an issue where significant bandwidth and CPU are consumed to generate each layer when a LocalVideoTrack is disabled. As a workaround, we recommend unpublishing simulcast video tracks instead of disabling them. This is implemented in Video App for iOS, but not in the QS examples at the moment.

I will leave this issue open to serve as documentation, and because it may be possible to resolve it in future releases of our SDK.

Thanks, Chris