I hope everyone can help to take a look at this issue. When using the Docker deployed Jibri service, the memory of Jibri keeps skyrocketing when the service starts recording in the background, occupying 32g of memory space in 30 minutes. What is the possible reason for Jibri recording to stop
ffmpeg.0.txt (252.8 KB)
log.0.txt (58.7 KB)
Please stoping opening new threads about the same issue:
As mentioned in responses to your previous topic, it’s most likely that your jibri instance does not have enough CPU resource to encode video in real-time and therefore the stream gets buffered in memory until you eventually run out of memory and it goes boom.
As you see in this snipped from ffmpeg.0.txt:
frame= 800 fps= 24 q=24.0 size= 3328kB time=00:00:26.63 bitrate=1023.7kbits/s speed=0.808x
frame= 807 fps= 24 q=24.0 size= 3328kB time=00:00:26.86 bitrate=1014.8kbits/s speed=0.798x
frame= 818 fps= 24 q=24.0 size= 3584kB time=00:00:27.23 bitrate=1078.0kbits/s speed=0.795x
Speed of 0.8x means that the encoding and flushing to disk is only 80% as fast as the stream being generated.
thanks，Are there any good solutions, such as limiting and allocating more CPU cores to jibri, or replacing encoding and decoding tools
Technically it’s the ffmpeg process that needs more CPU here, and my assumption is that ffmpeg would use as much CPU resource as available to it.
So you either need to:
- make sure you run on a host that has enough CPUs and not sharing with other resource hungry services
- or, configure jibri to record at a lower resolution which means there will be less for ffmpeg to encode. You can search the forum for how to do this since I believe this has been asked multiple times already.
Okay, thank you. I’ll try it out