Choppy audio in Talk recordings

[drfinkus]

Steps to reproduce

1. Start a Talk conversation
2. Record the conversation
3. Play back the recording

Expected behavior

The audio track of the recording should accurately reflect the audio quality of the actual Talk conversation.

Actual behavior

The audio track of the recording is very choppy. The video has no issues, but the audio is choppy.

I must mention that the audio during the actual call is always fine, there is no choppiness. It's just the recording that has this problem.

Host OS

Ubuntu 22.04

Nextcloud AIO version

Nextcloud AIO v7.7.1

Current channel

beta

Other valuable info

• The VPS has 8vCPUs, 16GB RAM, and 320GB SSD
• Same issue occurred on the latest stable channel; this is not specifically related to the beta channel
• All optional containers are enabled, except Docker Socket Proxy

[nickvergessen]

@szaimen any details on the recording version and configuration AIO is using?

[szaimen]

See https://github.com/nextcloud/all-in-one/blob/main/Containers/talk-recording/start.sh and https://github.com/nextcloud/all-in-one/blob/main/Containers/talk-recording/Dockerfile

[drfinkus]

If there's anything I can do to help debug or test, please let me know! I can share a recording, if it helps.

[drfinkus]

Hey @szaimen and @nickvergessen, just wanted to let you know this is still an issue, and I would love to help debug it.

I would like to change the recording setting in https://github.com/nextcloud/all-in-one/blob/main/Containers/talk-recording/start.sh from the current:
-c:v libvpx -deadline:v realtime -crf 10 -b:v 1M

To something milder like:

-c:v libvpx -deadline:v realtime -b:v 500k -crf 32 -cpu-used:v 15

I'm not sure where to make that change. If I try to modify start.sh in the nextcloud-aio-talk-recording container, I am not allowed to (read-only file, even when logged into the container as root). Could you tell me how to change that setting?

Again, I don't think resource constraint is the issue here, but this would help rule it out. I'm not sure what else to do. All videos, even those where I record myself (just one person on the call) are of the same poor quality, when the video is turned on. If the video is turned off, the audio quality is significantly better, which makes me think the issue is with the video encoding. A VPS with 8vCPUs, 16GB RAM, and 320GB SSD shouldn't, IMHO, struggle with recording a single video feed, when it can carry 8-10 simultaneous video conference participants without a problem.

[danxuliu]

and I would love to help debug it.

Thanks! :-D

I would like to change the recording setting in https://github.com/nextcloud/all-in-one/blob/main/Containers/talk-recording/start.sh from the current: -c:v libvpx -deadline:v realtime -crf 10 -b:v 1M

To something milder like:

-c:v libvpx -deadline:v realtime -b:v 500k -crf 32 -cpu-used:v 15

I'm not sure where to make that change. If I try to modify start.sh in the nextcloud-aio-talk-recording container, I am not allowed to (read-only file, even when logged into the container as root). Could you tell me how to change that setting?

Unfortunately I do not know either how to customize the ffmpeg settings in the AIO container. As far as I understand start.sh overwrites the configuration file used by the recording server every time that the container is run/started, so it would not be possible to run the container and then change the contents of the recording server configuration file in a persistent way. But if it is just for testing you might be able to start the container, run a shell on it, manually adjust the configuration file in /conf/recording.conf and then kill the recording server and start it again from that shell (although killing the recording server might stop the container altogether due to being the starting command of the container, but I am not sure 🤷)

But all of that is just guessing. @szaimen should have the real answer :-)

Again, I don't think resource constraint is the issue here, but this would help rule it out. I'm not sure what else to do. All videos, even those where I record myself (just one person on the call) are of the same poor quality, when the video is turned on. If the video is turned off, the audio quality is significantly better, which makes me think the issue is with the video encoding. A VPS with 8vCPUs, 16GB RAM, and 320GB SSD shouldn't, IMHO, struggle with recording a single video feed, when it can carry 8-10 simultaneous video conference participants without a problem.

It is indeed strange. As you can reproduce the issue with a single person in the call please try to record just yourself (to ensure that other connections do not interfere) and check the CPU load of the recording server. How high is the load when you have video enabled and when you have video disabled? Are the 8 vCPUs fully used? Also, are the 8 vCPUs exclusive to the recording server, or are they shared with any other container (like the one for the HPB)?

I wonder if the problem could be in the network rather than in the CPU. In the past we have seen that, in some cases, the browser (suprisingly) favours video over audio, so the video is still smooth while the audio is noticeably worse. Could you also check the upload/download bandwidth used by the recording server and the HPB during the recording?

Thanks!