Implementing Recording In Mediasoup Conference Software

Integration
21

I Mostly Use 4 vCPUS Server. Encoding And Decoding Wasn’t An Issue Because I Wasn’t Doing It Much. Capturing All Streams Separately And Then Combining Would Take Alot Of CPU, Maybe About 3 To 4 Times More So I Wanted To Get Something Working With Pupeteer

22

Great, will not it be similar to getDisplayMedia()? As you will still be decoding videos to display them on page and then you will use ffmpeg to capture it the CPU should remain almost same as before. I think the only difference will be that you will be able to directly save to the file using ffmpeg beside that CPU consumption should remain almost same, is this right?

23

I Think There Will Be A Little Bit Of Overhead When Using GetDisplayMedia() Because The Stream Eventually Has To Be Decoded And Recorded Either By MediaRecorder Or By FFmpeg If We Produce Using Mediasoup Or Send It Via Some API To The Server. While If We Use X11Grab, We Are Simply Just Recording The Screen So Its Better

24

Ok so saving recording to file directly instead of getting stream and then producing it to mediasoup or uploading it to server using api.

It will be really helpful if you can share the results with the old and this new way at the end of experiment to have a good understanding of the results.

25

Yeah, I Did That And Was Quite Successful In It. I Used X11Grab To Capture Screen And ALSA To Get The Audio Out. However, The Final Recording Had Some Pops And Crackles So We Shifted To Capturing From GetDisplayMedia And Then Producing To Mediasoup And Capturing That With FFmpeg, That Reduced The Crackles But There Still Were Some Crackles So We Decided To Move To A Windows Server Instead. This Really Minimized The Crackles But Here And There We Still Get A Poping Sound Or A Crackle. Was Wondering How Did You Manage To Fix The Crackles In Final Audio?

26

I don’t think there is a need to produce to mediasoup and capture again with ffmpeg after getDisaplayMedia, this will create overhead and hell lot of issues. Once you have captured stream with getDisplayMedia in headless browser you can use MediaRecorder etc to get the chunks and send them over to nodejs api etc to save it to file. No need to produce it again and then capture with ffmpeg

27

Well, I Had Used A Package Before Named ‘puppeteer-stream’ Which Used MediaRecorder And Took Alot Of CPU. Exhausted The CPU Only When There Were 3-4 People In Meeting. This Is Why I Didn’t Use MediaRecorder. FFmpeg Took Only About 2-3% Of CPU To Record The Stream. Did You Get Any Pops Or Crackles Using Media Recorder?

28

I wasn’t actually too much into it, it was a while ago, not sure about this exact problem. You need to find out the root cause of it. In your headless browser where you capture stream with getDisplayMedia, you can listen to the audio before producing it to mediasoup to see if the audio is fine at this point. If it is fine then ffmpeg may be causing the issue, in that case you can go deeper into ffmpeg to get the issue fixed.

29

I wanted to provide you with more insights into the recording options available for WebRTC.

  1. Screen Grabbing vs. Raw Track Recording:

    • Screen Grabbing: While this may seem like the easier option, it can become cost-ineffective, especially for extended periods or large-scale events.
    • Raw Track Recording: To capture individual tracks, I recommend using GStreamer to save the files. FFmpeg, while powerful, may encounter challenges with out-of-order packets, particularly when you’re no longer running and saving on your localhost.

  2. Recomposing Media:

    • If you’re interested in recomposing the media, the complexity varies based on the entropy of your room.
    • Low-Entropy (Simple Broadcaster): For constant media transmission, you shouldn’t face significant challenges.
    • Medium-Entropy (Intermittent Broadcasting): Managing on/off mic and camera switches may introduce temporal challenges.
    • High-Entropy (Event Room with Multiple Participants Producing): Piecing together numerous media files involves both spatial and temporal (spatiotemporal) complexities and requires careful consideration.

If you’re still exploring recording solutions, you might find MediaSFU interesting.

Recording with MediaSFU:

  • Reliable Recordings: MediaSFU ensures stable recordings, irrespective of your event room’s size.
  • Raw Tracks and Recomposed Media: Receive both raw tracks and recomposed media for a comprehensive recording experience.
  • Competitive Pricing: Starting at $0.3 per 100 minutes for QnHD, $0.6 per 100 minutes for SD quality, and $1.2 per 100 minutes for HD.

Flexibility:
You don’t have to host your events on MediaSFU to leverage its recording capabilities. Simply forward your media to be recorded exclusively for you.

30

Hi @zaidiqbal, as per your suggestion, I have tried with XVFB with Puppeteer. But the “evaluate” function of Puppeteer is never called. Any suggestions?

31

Hey @zaidiqbal this Ashutosh
hey guys I have implemented the above solution with @zaidiqbal
Let me tell you we can get data from the media recorder by byte seriality. and save the file on the local level by creating a downloadable link for file or uploading it in multipart chunks
everything can be done
I have also used gstreamer and ffmpeg etc
if you need any more info let me know
have fun

@ishan501 @HGB467