GNOME Bugzilla – Bug 593605
Record audio/video calls
Last modified: 2018-05-22 13:40:25 UTC
It would be extremely useful to enable recording of audio and video calls and even better if it could be integrated with empathy's chat logs
Having a "record" button would be cool. I'm not convince that should be done automatically though.
I was thinking a record button along with an option in preferences which says "automatically record and log audio/video calls" (disabled by default)
A manual "start/stop" recording button would indeed be very useful. You could even do interviews this way! Regarding the "automatic recording" feature, what could be done (on top of having it turned off by default - for privacy and performance reasons) is to ask the user, at the end of a call. Something like "would you like to save this audio conversation? [Save] [[Don't save]]".
New call UI is done-- time to revisit this?
We have a design (see https://bugzilla.gnome.org/show_bug.cgi?id=629902#c24) so that's "just" a matter of implementing it yeah.
*** Bug 578802 has been marked as a duplicate of this bug. ***
I been playing around writing some GStreamer prototypes to figure out how this could be implemented. So the most obvious solution of just having a record button and recording directly seems quite CPU heavy (http://blogs.gnome.org/uraeus/2012/11/08/gstreamer-python-and-videomixing/). I am sure there are things in that pipeline that could be improved, but I do worry that trying to record during the conference will risk affecting the quality of your call. The other option I am testing out is just taking the 2 video streams and 2 audio streams of the call and just muxing them into a Matroska file as is. Then once the call is done pop up a dialog asking if you want to export the recorded call for viewing elsewhere. If the user says yes to that we then do the mixing and re-encoding of the call. Just muxing the streams into a Matroska containers should be next to free in terms of CPU usage, and the CPU heavy task of re-encoding will instead be done as a separate task once the call is done. Any comments?
From a user's point of view, I think the "just dump now, do post-processing later" approach would be the way to go. Not only do you get better performance and avoid losing quality initially, users could eventually choose how to encode - you could even have Empathy throw the file over to transmageddon or pitivi. This is what most screencasting software does, too (and it should be noted that https://launchpad.net/kazam does exactly that: it throws the resulting files at video editors).
Created attachment 228967 [details] Small sample application mixing audio and video from 2 video and 2 audio streams
Created attachment 228968 [details] Small sample app to generate a file for use as input by other app. These two sample apps should demonstrate what would need to happen for recording a conversation. proto2.py is a simple application generating a Matroska file with 2 audio and 2 video streams inside. This is the data that needs to be gathered out of Empathy/Telepathy/Farstream. Proto4.py is a simple application taking such a file as its input and mixing them together into a unified file.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/empathy/issues/111.