Jitsi-meet: local recording

Created on 14 Apr 2020  路  36Comments  路  Source: jitsi/jitsi-meet

Is your feature request related to a problem you are facing?
Quite often are virtual recording device busy - either streaming to YouTube or trying to use Dropbox recording.

There could be certainly other cloud storages available (e.g. Google Drive, OneDrive, pCloud, MegaSync) but all of these rely on virtual recording device, which resources seems to be too limited:

  • #5972
  • #5961
  • #5957
  • #5939
  • #5756
  • #5474
  • etc

... and causing too many negative issues for users. Therefore I propose local recording that will not use Jitsi Meet virtual recording device but works locally via user's browser. Currently YouTube streaming and Dropbox recording are only one options to record all participants audio and video properly and as we see these features are overloaded.

Describe the solution you'd like
Through 3-dot menu there will be choices

  • _Start recording locally_
  • _Stop recording locally_

In addition there is a long awaited PAUSE functionality expected:

  • _Pause recording locally_
  • _Continue recording locally_

UI design options

  • choices under 3-dot menu only
  • clearly visible buttons at top floating bar

    • right side rounded pause/continue

    • left side start/stop button

    • in the middle is session time ticking

  • both options - would suggest that one

    • menu choices under 3-dot menu

    • clearly visible buttons at top floating bar

Local recording settings

  • 3-dot menu -> _Settings_ -> _Local recording_ tab
  • where can be configured

    • folder location in local device (either computer or smart device)

    • if applicable, audio and video codec choices and its settings according chosen codec.

  • configurable option: record text chat separately into .txt file locally or not

I guess as in case of Dropbox recording there are no choices of audio, video codec - it would be fine if in local version also there are no options for that. In Dropbox there will be .mp4 file where video is H.264 and audio is MPEG AAC (mp4a) with 44,1 kHz, 32-bit which are good enough.

Certainly with local recording option there are expected to be saved all participants audio and video, e.g. like Dropbox or YouTube recording does - all the Jitsi Meet window, including chat, etc.

Describe alternatives you've considered
Currently using local screen recording software (e.g. Simple Screen Recorder under Linux) could be alternative but it will not save all participants audio as screen recording software allows to define only one audio input.

feature-request

Most helpful comment

I have implemented client-side recording using MediaRecorder directly in JavaScript and this works very well with P2P meetings and bridged meetings with a few more users. I have no tests for how scale-able it can go.

The media chunks for every transmitting remote webRTC peer-connection from JVB are written every second into the external IndexedDB browser database and saved into webm files when the recording stops. Any meta-data like captions and chat messages are saved as as an external WebVTT with a synced time-code.

A playback index.html file is also created that provides a grid layout to playback the recorded webm files in sync with the WebVTT file.

I first contemplated drawing the conference UI on canvas object and saving that as a webm file, but dismissed the idea because of the code complexity and the performance impact on the client. Jitsi-Meet has a high CPU utilization client-side.

All 36 comments

related:
meet.jit.si recording - no audio recorded #5403

@edmundlaugasson may you provide a more decent issue title, thank you!

5403 was about missing audio in Dropbox recording - I've been checked already that issue. My proposal is about local recording and related actions like start/stop, pause/continue, also text saving separately - so a bit different topics.

Having a local recording option would be handy. Here is my user story:

As a jitsi meet host
I want to record my video locally
So that recording quality and performance are not impacted by online or third party services (eg Dropbox / YouTube)

Implementation details:

  • being able to record natively in a browser would be ok.
  • idealy I would like to trigger a local screen recorder (eg Simple Screen Record or Kazam)

I would suggest not to depend on 3rd party software on recording. When invocating local recording in browser-based Jitsi Meet then it should ask where to save, possibly also used file formats. I think the same browser-based recording feature like currently into Dropbox, YouTube but without any distraction with "no recording device available" issues like currently, would be expected.
Currently SSR, Kazam are options but these do not record from multiple inputs, I mean my and all other participant's voices. I can choose either my microphone input or other participant's input is recorded. Also when participating from smart device then SSR, Kazam are not available but recording feature should work in any case in any device, smoothly, flawlessly.
We would like to also see current recorded file size, available storage space on chosen device and predicted time how long can recording continue until chosen storage space is full. Therefore there could be an option to specify even multiple storage devices and e.g. say that when x % free space left on first storage space then automatically switch onto next storage space specified in Settings. Sometimes also local storage devices can be vary and added during recording. Then would be good to be able relocate next recording location in local device.
Therefore also external storage protocols (SSH, SFTP, FTP, WebDAVs, NFS, Samba, etc) would be appreciated - not only local one. Basically in UNIX-like OS world these might be possible to connect at OS level but sometimes not.
Also other cloud storages would be good to support even the initial idea was local recording. Sometimes these cloud storages are offering also network drives that could be used for recording (e.g. pCloud, Keybase).

I'm not sure local recording would be possible.

We'd need to paint the entire site on a hidden canvas so we can turn that into a stream and record that tream. Then mix the audio of all audio streams and merge it with the video stream so we can have a final destination for both. Ussing getdisplayMedia for the current tab would be ideal, but it's not possible to decide on the tab programatically. Then ue the Media Recorder API: https://developer.mozilla.org/en-US/docs/Web/API/MediaStream_Recording_API

I'm not sure it's possible to start a download where chunks keep being added ad eternum.

I used to say: if the issue is possible describe with words, it can be solved. So - it is close already to full description of the issue. When fully described, developers can solve it.

Hi, is there any progress on this? Is there any plan or consideration to do it soon?

@saghul

I'm not sure local recording would be possible.

But how does the recording for dropbox work then?
It also must write the stream into a file, so why can't that be used for local recording as well?
In my understanding (no expert) it would be just another destination.

@toby63 no they are quiet different in how recording will be done, not even related to dropbox thing yet.

@tu-nv

no they are quiet different in how recording will be done, not even related to dropbox thing yet.

Can you elaborate that? I can't imagine that dropbox does any of the work putting the streams together etc., so I don't see why that can't be replicated for local use, or use on a remote file server etc.

@toby63 it is explained in @saghul comment (https://github.com/jitsi/jitsi-meet/issues/6014#issuecomment-628022219)
and dropbox is not related here.
If I understand correctly, your intent is to save video to local storage and not dropbox, and you do not care about the internal recording mechanism. However, the current recorder is server-side, so you do not have option to save video locally. This thread is about doing recording locally (in client-side), which has a different mechanism, and it has some difficulties to implement (I believe they can be addressed though).

the current recorder is server-side

I see, now I understand, yes I read over that part:

Therefore I propose local recording that will not use Jitsi Meet virtual recording device but works locally via user's browser.

or missunderstood it.
Still the server recording problem could be solved first (so we can record things to other platforms or local harddrives).
I only see complicated workarounds.

@edmundlaugasson temporary, you may find this chrome extension useful to record screen + mic + speaker.
https://github.com/muaz-khan/Chrome-Extensions/tree/master/screen-recording

I think a similar implementation can be done to Jitsi, but directly using webRTC recording APIs.

I have implemented client-side recording using MediaRecorder directly in JavaScript and this works very well with P2P meetings and bridged meetings with a few more users. I have no tests for how scale-able it can go.

The media chunks for every transmitting remote webRTC peer-connection from JVB are written every second into the external IndexedDB browser database and saved into webm files when the recording stops. Any meta-data like captions and chat messages are saved as as an external WebVTT with a synced time-code.

A playback index.html file is also created that provides a grid layout to playback the recorded webm files in sync with the WebVTT file.

I first contemplated drawing the conference UI on canvas object and saving that as a webm file, but dismissed the idea because of the code complexity and the performance impact on the client. Jitsi-Meet has a high CPU utilization client-side.

@deleolajide is it possible to capture the whole jitsi tab instead of individual jitsi components and streams? this would use less CPU and better scaling when more users join.

As far as I know, MediaRecorder object works with a webRTC MediaStream object. You can create a stream object from a canvas object. I am not sure you could with a browser tab object. It would interesting to investigate this.

You don't need a chrome extension to capture a desktop display/screen or application window or browser tab any more. See https://developer.mozilla.org/en-US/docs/Web/API/Screen_Capture_API/Using_Screen_Capture

Thanks for tip. I will make that an issue for me to implement sometime later. Using getDisplayMedia to obtain a single MediaStream object of the browser tab for jitsi-meet instead of all the remote media streams.

@deleolajide this is a really interesting potential feature. I've been spending the last few days trying to get the client side WebRTC recording APIs to integrate with the iFrame Embed API. Using getDisplayMedia to grab the MediaStream object seems super promising. Have you made any progress on that part? Thanks for your contribution

Have you made any progress on that part? Thanks for your contribution

Yes. See https://github.com/igniterealtime/openfire-pade-plugin/issues/54#issuecomment-644685391

Nice! Do you think it'd work with an Embedded Jitsi Meet? Looks like you're storing the data in IndexedDB after?

I guess so. I don't use Jitsi Meet embedded and can't confirm. Yes, video/audio chunks are still stored in IndexedDB

@damencho @saghul using client side WebRTC APIs (getDisplayMedia, etc) to record the meeting seems like the best way going forward rather than server side recording the way Jibri uses now.

Jibri requires setting up a resource intensive server and can only record one meeting at a time. It is not ideal for most use cases.

What are your thoughts on trying to formalize the approach @deleolajide did here?

I built a rough, proof-of-concept hack using just getDisplayMedia and a 2nd getUserMedia call with Jitsi Meet here for reference:
write-up: https://webrtchacks.com/jitsi-recording-getdisplaymedia-audio/
repo: https://github.com/webrtcHacks/jitsiLocalRecorder

Note this does not directly interact with any of the Jitsi API's, but there plenty of places it could.

@chadwallacehart that is really interesting, thanks for a great read. What do you think would be required to create a more robust local webRTC recorder? Or are the APIs just not there yet?

I do not think that the screen source and system selection API and UI it dictates are suitable for this application - at least not for a general audience like Jitsi Meet targets.

I think the approach @saghul mentioned earlier in this thread is best. I have not played with this in a while, but I had success combining the local getUserMedia streams and all the various audio tracks from incoming PeerConnections inside Jitsi Meet in a previous project recorder extension project. I did this by overloading the peerConnection, but I believe you can directly access these with the lib-jitsi-meet api.

I haven't tried to write the Meet display to a canvas for recording, but I have used that methodology before and I don't think it would be hard.

Painting the screen with a hidden canvas could definitely be an interesting approach. Would love to see what is possible there.

I can add breakout to your jitsi meet instance with local recording and etherpad to full funtionality, and you can have control to all of them in your API, I can handle a webinar mode that guest can not sea each other too, I made a change to jitsi alot and now is ready to others but not for free and not expensive.

Break out
Local Record no jibri needed
Local Snapshopt
Etherpad
HIde guests from guests and moderator sea all
stream to youtube/instagram/facebook and all rtpm server.

I can add breakout to your jitsi meet instance with local recording and etherpad to full funtionality, and you can have control to all of them in your API, I can handle a webinar mode that guest can not sea each other too, I made a change to jitsi alot and now is ready to others but not for free and not expensive.

Break out
Local Record no jibri needed
Local Snapshopt
Etherpad
HIde guests from guests and moderator sea all
stream to youtube/instagram/facebook and all rtpm server.

Hi Nimaam

Can you reach out to me with details - [email protected]

Thanks
Naveen

I can add breakout to your jitsi meet instance with local recording and etherpad to full funtionality, and you can have control to all of them in your API, I can handle a webinar mode that guest can not sea each other too, I made a change to jitsi alot and now is ready to others but not for free and not expensive.

Break out
Local Record no jibri needed
Local Snapshopt
Etherpad
HIde guests from guests and moderator sea all
stream to youtube/instagram/facebook and all rtpm server.

Shared my email id . Do contact me on my maild id [email protected]

@nimaam please stop advertising here, there is a job board for this.

@saghul @damencho

This is surely a useful resource to look into if anyone is planning to implement local recording feature.

I made this code and it is ready to install, but not free

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Could someone solve this auto-closing issue?
I guess there should be options to exclude certain issues from that.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

galvaniccoffee picture galvaniccoffee  路  3Comments

532910 picture 532910  路  3Comments

tanvir23 picture tanvir23  路  4Comments

VogtAI picture VogtAI  路  3Comments

jidanni picture jidanni  路  3Comments