search

aau-zid / BigBlueButton-liveStreaming

Streams a given BBB Meeting to an RTMP Server.
GNU General Public License v3.0
200 stars 159 forks source link

Switching to variable bit rate for streaming #64

Closed glunardi closed 3 years ago

glunardi commented 4 years ago

All the rate parameters are being ignored when using cbr. Switching to vbr goes from 4170Kbit/s (constant) to anywhere between 2000Kbit/s and 3500Kbit/s in my quick tests.

That should improve the bandwidth consumption between the streamer and the RTMP destination.

mtsonline commented 4 years ago

...the docs of youtube / fb / other streaming platforms did state, that cbr is required. Did you test with them?

we would prefer, if you could make this change optional. would you mind to add a parameter for vbr/cbr and an additional parameter for other options - so the users can configure this in the docker-compose file? this way users could decide themself what they want to use / change to their needs easily.

I'll be fine if you set your bandwith-saving config as default if it is working with fb and youtube, as most users stream to this platforms. cheers

uka-support commented 3 years ago

Update: The quality of these settings is not very good upon closer inspection. 1MBit just isn't enough for Full-HD.

I took a look at ffmpeg docs (see here https://trac.ffmpeg.org/wiki/Encode/H.264 in section "Constrained encoding (VBV / maximum bit rate)") and came up with the following options which work quite well for us, no dropped frames etc.:

video_options = '-c:v libx264 -profile:v high -level:v 4.2 -vf format=yuv420p -b:v 1000k -maxrate 1500k -bufsize 3000k -g 30 -preset fast -tune zerolatency'

This translates to: aim at 1 MBit/s, max 1.5 MBit/s, use up to two second buffer, add I-rame every 30 frames (=1s). Note: no "nal-hrd=cbr" x264-param, no minrate. We've got a pretty beefy machine (24 cores) so ffmpeg taking 150% CPU (=1.5 cores) was no problem (Google Chrome seemed to take another 150% btw). Filesize was greatly reduced for Full-HD streaming.

But that's optimized for HLS streaming via nginx-rtmp. Note that according to the page I mentioned, In general, the higher the bitrate, the more time needed for encoding." So lowering bitrate and going from ultrafast to fast actually improved quality in my experiments. Quoting the page again: "Using fast saves about 10% encoding time, faster 25%. ultrafast will save 55% at the expense of much lower quality."

Maybe we should provide some presets for certain use cases. Currently it's all hardcoded

mtsonline commented 3 years ago

yeah, would be great if you could provide some presets the users could choose from. this is something I wanted to impliment since the beginning but time always is to short ...

mtsonline commented 3 years ago

...I will close this pr because in the current version the ffmpeg options where made available as config values ... if anybody wants to improve the quality, please feel free to add config samples or if prroven quality improvement, change the defaults in the samples files. thanks.