Pros/Cons of producer.pause() vs producer.close()

mediasoup libraries
1

I’m trying to understand the tradeoffs between closing and recreating producers on mute/unmute versus just pausing/resuming the producer. This topic is a bit similar to this previous one where the response was “pause/resuming is ok”, but I’m trying to actually grasp why that’s the preferred method. This other post is also somewhat similar, but there isn’t really an explanation of why close vs pause in that one either.

Pause/Resume seems to intuitively be the better approach for implementing mute/unmute b/c one would think that’d you’d incur less overhead to run pause/resume, but:

  • the producer will still send silence packets / black frames when paused, right? sure, there is the zeroRtpOnPause option, but I don’t think that’s supported on every browser? It was also recommended to avoid zeroRtpOnPause in this post from 2017. There’s also DTX but that isn’t recommended for video I think? Am I missing something in my understanding that pausing instead of closing the producer would have more long-term overhead from periodic black frames?
  • from my rudimentary profiling I haven’t found any significant differences between pause/resume and close/recreate - maybe I’m not looking in the right places?
  • if you only pause producers instead of closing them, your browser tab will still be marked as using the user’s mic/camera. This is reproducible by going to https://v3demo.mediasoup.org/ and muting your mic and camera - in Chrome I see that the tab is still using my A/V. This seems like not a positive thing? FWIW it seems a lot of popular video conferencing products (like Google Meet) have this same behavior though, so maybe users don’t care.

If it helps to have a specific application in mind, we can use mediasoup-demo as an example. I checked that mediasoup-demo does in fact pause/resume producers when muting/unmuting, so I’m wondering: why? What was the reasoning behind implementing it that way in the demo?

2

Developers let you the right answer, but I presume that is more resource intensive producer.close() (and subsequent creation) than producer.pause() / .resume()

BTW I am using zeroRtpOnPause on Chrome, Firefox and Edge and runs like a charm.

3

bump here - still haven’t found anything that satisfactorily explains this, would appreciate any extra insight or links or anything anyone can point me to

4

Take a look at src

5

It takes more time to re-connect a stream via signalling and the connection of the RTP than to pause/resume.

To sum, it’s less overall use on the CPU to keep a resume/pause in mind and will be noticed greatly when running large tests or have a user base greater than 200 active.