Codec issues: H264 vs VP8 #981
Comments
|
What Electron app / Chrome versions did you test and on what operating system? Depending on the platform HW acceleration may kick in for H264. |
|
I'm running Manjaro Linux here, so pretty much the latest versions of everything:
I'm not sure that hardware acceleration works on Linux, I do have a rather high powered GPU, and it is working, but I know Chrome has some limitations. But on the other hand, my CPU has more than enough power to produce quality H264, so I don't see a reason why the image should be so bad. |
|
In the mean time, I have checked some extra things. You triggered me with your remark on hardware acceleration. Since I'm working on Linux, this is a bit of an issue in all things related Chromium. So I've installed some extra packages, checked my drivers, and set some Chromium flags. Right now I've got full hardware acceleration working in all my Chromium-based browsers (tested in Chrome, Chromium and Brave): My Yet, when I start h264 video using any of these browsers, I get a very pixelated video. Even though Jitsi Meet itself reports that I'm uploading at around 3000 kbits/second. Using Firefox, I get the same bitrate, and a crystal clear image, even on full screen. Interestingly enough, if I share screen in Chromium, I get a crystal clear image at around 300 kbits/second. Using the Jitsi Meet Desktop app, which is for all intents and purposes a Chromium browser, I get the exact same behaviour as Chrome/Chromium/Brave. What is Firefox doing so much better here? What am I missing? Update: Just did one more check. I can see that Firefox is uploading video in 1280x720 (which is my laptop camera resolution) all the time, while Chromium always picks 320x180, no matter what the bandwidth is. Except when sharing screen, then in Chromium the resolution goes up to 1668x938 instantly (higher than what my camera can deliver!), resulting in a nice readable screen. |
That suggests your bridge channel is not working. So the resolution doesn't ramp up. Can you see error messages regarding the bridge channel not being open? |
|
When joining the room, I get the following logging when I search for As I interpret it, the connection to the bridge is fine, but it gets the max resolution of 180px from the server. After some time, I get the following logging: So it should be able to raise the resolution if I'm reading this right? Yet, it doesn't. |
You are requesting the bridge to send you 180p. Is this Jitsi Meet or your own client? Can you try to build unstable images? Lots of work has happened in that area recently. |
|
I've built a set of images, and deployed them (slick looking new interface btw). With two people in the call, the quality starts as SD but quickly ramps up to HD. But as soon as a third person joins (i.e. no more p2p connection) the quality instantly drops to LD. When connecting the third client: And after a bit: The quality remains at 180p all the time however. |
|
How large is your viewport? When it tile view mode (the default for > 2 participants) we use the tile size as the hint for the bridge. |
|
All my browsers are full screen, 1920x1080. |
|
Paging @jallamsetty1 |
|
2021-04-09T12:37:12.953Z [features/video-quality] <Object.D.d.register.deepEquals [as listener]>: Video quality level for thumbnail height: 160, is: 180, override: false, max full res N: 2 The thumbnail height is 160px and therefore client is requesting 180p from the bridge. |
|
Don't mind me looking extremely serious, but here are some screenshots. With two participants:
And immediately after the third participant joins, same screen, same browser (the third one joined in another browser window):
|
|
Hi @cedricroijakkers, can you please capture all the bridge channel logs from the moment the 3rd participant joins ? By default the view should change to tile view and you switch back to stage view or are you using the |
|
Hey @jallamsetty1, I have tested the scenarios out. Attached are the logs for all situations. I have tested it with For each, you will find the browser logs for participant 1, 2, and 3. And the JVB logs when participant 3 joins. I've indeed noticed that as soon as participant 3 joins, the view switches to tile, and then the videos go to lower resolution. This is indeed fine. Then I click on the participant with video, the video goes full screen, and this is where h264 and VP8 behave differently: VP8 switches to HD video in about half a second, while h264 stays on LD video no matter how much I switch participants and views. The reason we're forcing h264, is because the quality of screen sharing is so much better in h264 when compared to VP9. Notably when scrolling the screen takes a good 10-20 seconds to become readable again when using VP9, when using h264 the screen is always crystal clear. Since we use screen sharing much more than video, h264 is the better codec for us. Ideally, we'd use h264 for screen sharing and VP9 for camera video, but I don't know if this is possible. |
Oh I see that simulcast hasn't been disabled on your client for H.264. The JVB doesn't support simulcast for H.264 so even though correct resolution is requested, the bridge always sends LD. You will need to disable simulcast on the client. |
|
That sounds like something that should be fixed in the docker configuration file templates. I will see if I can make a pull request for this. Many thanks for the investigation! |
@jallamsetty1 Can't we fix that in LJM instead? It's very counter intuitive. |
The codec selection mechanism is driven by client preferences expressed in config.js whereas in this specific use case it is being enforced by disabling all but one of the codecs that Jicofo offers. The decision to enable/disable simulcast needs to made before the offer from Jicofo is received otherwise it would add extra processing on every renegotiation cycle which is not very desirable. |
|
Ack. |
|
@cedricroijakkers I am currently also experimenting to get the best screen sharing resolution, because we also mostly use Jitsi for voice and screen sharing, and occasional video. Which configuration currently gives you the best results? |
|
@netFLOw95 We're currently running with these environment variables, which works nicely for us. Most of the time we use screen share, which is fast and clear, but video also works very nicely with these settings: DESKTOP_SHARING_FRAMERATE_AUTO: "1"
DESKTOP_SHARING_FRAMERATE_MIN: "5"
DESKTOP_SHARING_FRAMERATE_MAX: "30"
ENABLE_CODEC_VP8: "true"
ENABLE_CODEC_VP9: "true"
ENABLE_CODEC_H264: "true"
ENABLE_CODEC_OPUS_RED: "true"
ENABLE_CODEC_AV1: "true"
ENABLE_SIMULCAST: "false" |
|
@cedricroijakkers Thank´s for the quick reply!
|
No indeed they don't, but they're still in there from when the
That's depending on the browser capabilities. In my case, the Jitsi desktop app in Linux seems to use VP9 for video, which works nicely and quickly scales up to a higher resolution after starting the video. But I've previously seen good quality with h264 too.
No, in my experience having simulcast disabled works better than having it enabled, but this could also be client (browser) related. Not all browsers work nicely with simulcast. But again, we mostly use it to share screen, camera is used from time to time, but not that important for our workflow. |
|
Alright. Thanks! |
I've noticed some interesting behaviour. Lately, I've been experimenting with the codec settings in the deployment, notably the following three environment variables:
Right now, I have it set to the following:
The reason here being that we use Jitsi mostly for voice and screen sharing, and the occasional video. I've noticed that the H264 coding yields the sharpest screen share image without flickering.
Using VP8 only:
Using H264 only:
Using VP9 only:
For some reason, this falls back to VP8.
Enabling all three codecs:
This also falls back to VP8.
Since we need to have sharp screen sharing and camera video is just for the occasional lulz, the codec is set to H264, and VP8 and VP9 are off.
Now, this is where it gets interesting: this is all using the Jitsi Meet Electron desktop app. Also when using a Chrome-based browser, the behaviour is like this. But when I switch to Firefox, even when using H264 the video is crystal clear in 720p and also the screen sharing is crisp. So it seems like Firefox is compressing the video differently? But using the Electron app is much more convenient, so Firefox rarely gets used.
So I have some questions:
The text was updated successfully, but these errors were encountered: