The latest update for Teamspeak has been great in a lot of ways and I do want to thank the team behind it very much for the great work. Throughout using it for months now I’ve had my fair share of issues specifically for screen sharing and I want to list all of those here (and temporary fixes for them if you have problems too). As I use Linux, this will be mostly Linux specific. I don’t know which of all these problems also happen on other platforms.
Missing Hardware acceleration for AMD GPUs on Fedora Based systems:
On Fedora based Distros libraries differ from other distros. The /usr/lib folder doesn’t contain both 32bit and 64bit libraries, instead it uses /usr/lib/ for 32bit and /usr/lib64/ for 64bit libraries. Teamspeak only looks for libraries in /usr/lib/ and fails because the 32bit libva driver is incompatible with a 64bit Application (wrong ELF class).
This is temporarily fixable by adding this environment variable:
LIBVA_DRIVERS_PATH=/usr/lib64/dri:$LIBVA_DRIVERS_PATH
Missing VAAPI decoders
I don’t know if this is distro specific (if yes, this is on a Fedora based distro once again), but even with the fix listed above, VAAPI doesn’t show up for decoding. I tested if ffmpeg can decode streams and videos with VAAPI and it was able to.
The (very) temporary fix for me was to install the AMF en/decoder. I want to stress that Teamspeak should support full VAAPI en- and decoding. You can follow the community post here to see how you can install it yourself.
Crash on joining a stream
I tried a bunch of things to get acceptable video quality in streams with someone else. Something we couldn’t do was to join a stream encoded with VAAPI AV1 while using the AMF AV1 decoder. Teamspeak would crash consistently on every try to join the stream. We didn’t save the logs, but we can reproduce it and send them in if you desire.
We worked around the issue by not using the VAAPI AV1 encoder and sticking to the AMF Encoder. I might add that Teamspeak did not crash when decoding a VAAPI AV1 stream with the CUVID AV1 decoder. We also noticed that Teamspeak avoids using VAAPI AV1 when decoding with AMF, falling back back to H.264 (which I streamed using NVENC).
Weird bitrate enforcement behaviours
The default settings for streaming with AMF are problematic. I am not 100% sure what this is related to but I found that changing the rate control mode fixes some things but also introduces other very weird issues.
Tests were done at 1080p60 with a set bitrate of 10 Mbps. None of the rc modes limited themselves to that bitrate setting though, even if I reduced it.
In most rc modes (including the default one) the bitrate doesn’t go over 2 Mbps, which in turn regardless of stream settings just looks bad. It is smooth, but the low quality makes the stream so ugly that it’s unwatchable.
These rc modes include:
- vbr_latency
- vbr_peak
- cbr
As expected, cqp looks very good, but also at times uses up to 320 Mbps and even higher even at 1080p30 with qp set to 63 (My max upload is 50 Mbps, so even I can’t stream this). This rc mode is never recommended for streaming, but I’m mentioning it because it disregards the configured max bitrate by a lot (over 3000% and possibly more).
These following modes also exceeded the set maximum Bitrate up to 40 Mbps:
- qvbr
- hqcbr
Only one mode exceeds the max bitrate given in the stream settings, but didn’t overdo it too much compared to the modes above and stayed mostly close to or below 10 Mbps.
- hqvbr
This mode confidently allows you to stream at higher fps or resolutions, but based on that it will also ramp up the bitrate slightly and over the limit, potentially asking for more bandwidth than you have.