Livestream YouTube Audio Crackling like jack contact sound, solutions?

Apparantly plug:cloop must be before the -af option…(I do not know what I’m doing…)

I changed it in the src and now I do not get any errors.
The file src/main/kotlin/org/jitsi/jibri/capture/ffmpeg/Commands.kt now has:

fun getFfmpegCommandLinux(ffmpegExecutorParams: FfmpegExecutorParams, sink: Sink): List {
return listOf(
“ffmpeg”, “-y”, “-v”, “info”,
“-f”, “x11grab”,
“-draw_mouse”, “0”,
“-r”, ffmpegExecutorParams.framerate.toString(),
“-s”, ffmpegExecutorParams.resolution,
“-thread_queue_size”, ffmpegExecutorParams.queueSize.toString(),
“-i”, “:0.0+0,0”,
“-f”, “alsa”,
“-thread_queue_size”, ffmpegExecutorParams.queueSize.toString(),
"-i", “plug:cloop”,
"-af", “equalizer=f=100:t=h:width=200:g=-64”,
“-acodec”, “aac”, “-strict”, “-2”, “-ar”, “44100”,
“-c:v”, “libx264”, “-preset”, ffmpegExecutorParams.videoEncodePreset,
*sink.options, “-pix_fmt”, “yuv420p”, “-r”, ffmpegExecutorParams.framerate.toString(),
“-crf”, ffmpegExecutorParams.h264ConstantRateFactor.toString(),
“-g”, ffmpegExecutorParams.gopSize.toString(), “-tune”, “zerolatency”,
“-f”, sink.format, sink.path

Btw: I don’t understand why -thread_queue_size is mentioned twice…

In the logfile /var/log/jitsi/jibri/log.0.txt the ffmpeg command is now:

Starting ffmpeg with command ffmpeg -y -v info -f x11grab -draw_mouse 0 -r 30 -s 1280x720 -thread_queue_size 4096 -i :0.0+0,0 -f alsa -thread_queue_size 4096 -i plug:cloop -af equalizer=f=100:t=h:width=200:g=-64 -acodec aac -strict -2 -ar 44100 -c:v libx264 -preset veryfast -maxrate 2976k -bufsize 5952k -pix_fmt yuv420p -r 30 -crf 25 -g 60 -tune zerolatency -f flv rtmp://…

It runs but I still hear the cracks :frowning: :frowning:

The -af audio filtering option works nice on the command line. Can a developer build this the proper way in jibri?

1 Like

For now I ended up wrapping /usr/bin/ffmpeg using /usr/local/bin/ffmpeg.
A settings which is “reasonable” is for example:

$ cat /usr/local/bin/ffmpeg 
exec /usr/bin/ffmpeg $(echo "$@" | sed 's/rtmp/-af highpass=f=300,lowpass=f=4000,equalizer=f=50:t=h:width=150:g=-48 rtmp/')

The “equalizer” option seems redundant but I’ve the feeling it made a difference… Anyway, the options probably need a bit more adjusting.
man ffmpeg-filters is your friend.

I’ve been playing with a few settings today (including everything mentioned here) and have yet to find any of them which seemed to fix the issue. If anyone has found any that seem to improve this, let me know.

Sure? I must say the ffmpeg wrapperscript does quite a reasonable job. Not a permanent solution (or fix) I guess but for now it works for me. The crackling is a lot less, hardly noticeable.
Haven’t tried it out with multiple users in a room. I’ll sent a recorded demo “soon”.

I tried the same args you mentioned in your post but still heard the crackling–I edited Jibri directly, don’t think there’d be a difference between that and wrapping ffmpeg.

I put the same options in Jibri but for some reason still heard the crackling. I cannot explain but using the script seems to be different… I admit this does not seem logical… :slight_smile:

For me the crackling is happening every time I streaming from jitsi to youtube, even in the “normal mode” instead of ‘“low latency mode”.

The strange thing is if I use any other streaming tool like OBS or Zoom it doesn’t happen.

Has anyone tested changing the audio frequency in ffmpeg from 44100 to 48000? This crackling seems to be related to the audio frequency. 48 kHz could solve because is a larger frequency.

I also thought if it could be something related Chrome driver version used by jibri, if it would be upgraded to the latest could solve it.

1 Like

Hi, folks!
I started using jitsi meet on my android mobile phones a month and a half ago to broadcast classes on youtube and hold video conferences with my students.

Until June 4th it worked very well, but that same day youtube automatically changed my transmission code (or key) and from that moment on there started to be noises in the audio of the transmission and, from what I was seeing, I guess it’s the same problem that everyone is having in this thread, and in 2 or 3 threads that I saw separately.

I have tried conferences between all my devices (2 mobile phones and 1 notebook) and they work fine. The problem is only noticed when watching the live broadcast on youtube and is recorded in the resulting videos.

I hope that the makers of jitsi (or someone) can solve this problem soon.

Since I don’t speak English, I used a translator.
I’m sorry if something’s not clear.


Maybe worth mentioning: when I create a /usr/local/bin/ffmpeg with contents:

exec /usr/bin/ffmpeg $(echo "$@" | sed 's/44100/48000/')

the “crackling” is a lot less.

For myself I’m not sure about June 4th but it seems a recent problem? Maybe others also have also only recent problems with the audio crackling?

I haven’t had time to test, but from my general knowledge, going with 48k sampling rate should be much better regardless. 44.1k is “cd quality” while 48k generally is more/default native to computers, and resampling one to another can require very “tight work” from cpu. I would suggest not specifying -ar at all and let it go with system default, if ffmepg allows it.As for sometimes it crackles sometimes it does not, there might be some nonderminism in crackling case, on how scheduling on process happens/starts and if say chrome is interruping ffmpeg a lot. I would suggest trying to increase priority of ffmpeg, in wrapper script, do something like this:

exec nice -n 20 /usr/bin/ffmpeg $(echo "$@" | sed 's/44100/48000/')

Hm though this will not work… as only root can increase priority…
But seems it can be allowed via such:

@jibri   hard nice     -20

Should allow nicing for jibri user (if I understood) SO answer correctly.

1 Like

Nice :wink:

Note: to increase priority you have to be less nice :wink: So, for example, nice -n -10 increases priority.
In /etc/security/limits.conf @jibri - nice -20 (not using “hard”) allows the jibri user to increase priorities.
Be carefull: this way it’s easy to let ffmpeg use most resources…

Thats the idea :slight_smile: So if you tried it, did it work?
For me since I have separated jibri to separate sever all on it’s own for auto-scaling of streaming instances, I would have no problem with ffmpeg being fully prioritized. What’s left should be enough for chrome :slight_smile:

Another thing that I guess could work is use “libfdk_aac” instead of native ffmpeg AAC Encoder. Native ffmpeg AAC has a poor quality compared to fdk aac. Maybe is better to use MP3 (if is not possible to compile fdkaac), than native ffmpeg aac. Could you test it as well? Thanks a lot for your support.

I compiled ffmpeg from source by using this script (I needed to add x264) and libfdk_aac encoding worked successfully. But the sound crackling continues even with libfdk_aac :frowning: Any suggestion is welcome.

The date this started happening could be an important factor in finding the problem, which may be in some change made by the developers in those days.
Or maybe to find out if youtube made any changes, since it happened just when they automatically updated my broadcast code.

Finding out the exact time is simple, as all live broadcasts are stored on youtube.
You just have to watch them one by one until there are noises.

I think it’s not a problem of codecs or their configuration although changing those parameters might seem to improve the sound.

I think that the problem is in the way that links jitsi with youtube, and that only the developers can solve it, obviously, with the data that we, the affected users, can provide them.
What would be very good is to know if the developers are aware of the problem, and if they are doing something to fix it.

Since I don’t speak English, I used a translator.
I’m sorry if something’s not clear.

Thanks for your reply @emrekoc . Only to double check, did you edit jibri/ffmpeg command to use libfdk_aac instead of aac native? And could you test with MP3 codec as well? Just to eliminate these codec possibilities.

Maybe could be related to Chrome version (or some parameter used) and virtual soundcard. Example:

" Setting chrome.exe to Prefer Maximum Performance in the NVIDIA Control Panel seems to reduce the frequency of these pops too."

Tried 48k sample rate, but still got the crackling.

Also, I don’t think it’s related to the chrome capture side, as we haven’t seen any issues with file recording. I also tried using the live streaming params (which differ slightly) but recording to a file and didn’t hear any crackling.

I made some test today. According to my point, the issue is completely related to the network conditions. As @bbaldino said , there is no problem when recording to a file with the same parameters.

The problem is even more common when the ‘low latency’ mode chosen. This confirms that it is network related. Dropped frames cause this issue.

It’s easy to test this. Change the -crf value. Increasing the value (for example -crf 40) will reduce to the problem and decreasing the value (for example -crf 13) will enhance it.

The Jibri’s default value is -crf 25. The same effect can be done by changing -maxrate and -bufsize.