Processing of BigBlueButton (later BBB) recordings can be very slow. Even if you selected MP4 as playback format in
video_formats: # - webm - mp4
The problem is that, until BBB version 2.3 will be released, there’s no plan to configure how many workers of records processing can be run simultaneously.
There’s a little trick however you can use to add a workaround for this limit.
This solution is based on this howto on an issue on github. I’ve rearranged based on my experience also to support more than two recordings. I will keep here my solution to have it at my fingertips when I’ll need it again.
A little consideration not to overcommit your machine.
ffmpeg in bigbluebutton runs with multiple trheads, so you’ll consider every 4 core 1 running encoding process.
You can divide the processes of encoding passing a parameter by matching ID with a regexp. In this example is on the last digit.
rap-process-worker.rb -p "[0-4]$" /* encode recordings with ID finishing by 0 1 2 3 4 */ rap-process-worker.rb -p "[5-9]$" /* encode recordings with ID finishing by 5 6 7 8 9 */
In this way we can double the processing queue:
/usr/lib/systemd/system/bbb-rap-process-worker.service to have ExecStart as follows
ExecStart=/usr/local/bigbluebutton/core/scripts/rap-process-worker.rb -p "[0-4]$"
then duplicate the systemd service
cp /usr/lib/systemd/system/bbb-rap-process-worker.service /usr/lib/systemd/system/bbb-rap-process-worker2.service
and edit it to have ExecStart as follows
ExecStart=/usr/local/bigbluebutton/core/scripts/rap-process-worker.rb -p "[5-9]$"
/usr/lib/systemd/system/bbb-record-core.target and add bbb-rap-process-worker2.service in the “Wants=” row as follows
Wants=bbb-rap-archive-worker.service bbb-rap-sanity-worker.service bbb-rap-process-worker.service bbb-rap-process-worker2.service bbb-rap-publish-worker.service bbb-rap-events-worker.service
add bbb-rap-process-worker2.service to the monitored processes by /usr/bin/bbb-record, circa line 639
systemctl --no-pager status bbb-rap-archive-worker.service bbb-rap-sanity-worker.service bbb-rap-process-worker.service bbb-rap-process-worker2.service bbb-rap-publish-worker.service
let systemd know that there’s something new in its files
and restart bbb-record-core.target
systemctl restart bbb-record-core.target
now you’ve doubled the processing capacity of your bigbluebutton service.
If you’re plenty of cores, you can always split the processing queue in more than 2 workers modifying this notes woth different workers with different ranges of regexp ie:
rap-process-worker.rb -p "[0-3]$" /* encode recordings with ID finishing by 0 1 2 3 */ rap-process-worker.rb -p "[4-6]$" /* encode recordings with ID finishing by 4 5 6 */ rap-process-worker.rb -p "[7-9]$" /* encode recordings with ID finishing by 7 8 9 */
and so on.
Feel free to drop a comment if you need some advice.