Closed wolftune closed 2 years ago
So are you saying you want to host a meeting with video content BUT only want to record the audio from that meeting?
Yes, exactly
You can use the "Local recording" feature - each participant will activate it on their end and at the end of the meeting, they'll send you the recorded audio files. This gives you the highest quality audio from your meeting.
You mean like each participant uses their own software to record their own audio input right? Not that "local recording" is a feature in Jitsi itself, right? (I'm not aware of such a feature).
I agree that everyone recording locally is the best way to get a publishing-quality audio mix.
But there's another use case: people have a bureaucratic meeting like some organizational procedural thing. They want to see each other during the meeting. And they just want a low-size audio recording in order to have a record that may not even ever get published or listened to. They just want something quick and easy and no extra hassle of mixing multiple recordings.
No, each participant records with Jitsi. Jitsi has a "Local Recording" feature that you can make available, if you're hosting your own server. The feature allows each participant on a call to record audio during the call. You enable it in config.js - https://github.com/jitsi/jitsi-meet/blob/5cae5985c00fd8604d35eaadf2bde92ef0774dc8/config.js#L525
Once enabled, clicking the button will bring up this pop-up where they (participants) can start the recording:
But that way you can only record your own voice. how can jitsi frontend combine everyone's voice into one file?
We don't have that functionality at the moment, but it can be implemented with the WebAudio or MediaRecorder APIs.
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.
Hi bot, status remains, worth still doing IMO
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.
I still say this should happen, and I'd rather a human won't-fix decision (or better fixing it) rather than just going stale
We are not planning on adding this feature at this time, sorry.
Hey @wolftune, i made a custom build specifically for this, it's the standard jibri demon without the embedded video recording options.
One of my customer also wanted to just record audio in a conference
Unfortunately it's a "permanent" change, you need to reinstall the original jibri.jar to record the full audio/video again, for the moment it cannot be done otherwise.
https://github.com/luponata/jibri_audio_only
Cheers
Thanks @luponata
Please if you ever devise it as a flexible option that can be adjusted per-session by users, submit it as a PR.
For my purposes, I use video enough that the permanent audio-only is not worthwhile.
Internally we usually use JWT, maybe we could implement a new option in the body of the JSON that instruct Jitsi to use the audio-only version while creating the room.
{ "room": "jitsi-room", "operator": "operator1", "epoch_start": 1631628667, "epoch_end": 1651628667, "audio_only": true }
In our instance nobody can't open a room before the JWT run, is this your case?
Would there be a front-end user-facing simple method to choose the setting for a room each time it is made?
Someone's problem is someone else's solution? https://stackoverflow.com/questions/72446551/jibri-records-audio-only-without-video
Not a real solution but something worth investigating to find a hack to audio-recording only?
A simple hack would be to extract the audio from the video in the finalize script.
Granted that means you might be recording video unnecessarily, but adding another type of recorder would require a lot of changes...
I would like to sometimes recording audio-only, hoping that it would use less bandwidth and smaller file sizes. For some types of meetings, video content is not worthwhile enough for the extra data use.
I could just record locally the streams and that's fine, but a standard approach might end up higher quality and more convenient.