VP8 melting my battery - can I force H264 in jvb too?

[Peter_Villeneuve]

As the title suggests, using the VP8 codec in jitsi-meet leads inevitably to complaints about chrome using up all the power since there doesn’t seem to be VP8 HW acceleration.

Since most platforms have h264 HW acceleration the experience is much better and battery consumption doesn’t go through the roof.

I have h264 preferred for P2P in my config.js, but I was wondering if I could also force H264 for jvb meetings to see if that solves the draining battery problem.

H264 doesn’t have simulcast I believe, so that’s a downside for H264 in jitsi-meet, but I still would like to try it out to see how it works in practice.

Can someone help me force H264? Are there any other downsides besides not supporting simulcast?

Thanks

[Peter_Villeneuve]

Any help?

Is it enough in config.js to just set

preferH264: true,
disableH264: false

Will this setting force H264 instead of VP8 or is there another setting I need to change?

Thanks

[Peter_Villeneuve]

@damencho Can you confirm that to force H264 always (including when using jvb) all I need to do is set the two flags I mentioned above? Or is there something else I need to do?

Thanks!

[Peter_Villeneuve]

Sorry to insist @damencho but I was hoping you could help.

I set preferH264: true, and disableH264: false in config.js but I see in testing with webRTC internals that I’m still getting VP8 codec from an iOS device running the app, whereas other connections seem to be using h264.

This confuses me greatly, specially the fact that iOS should prefer h264 anyway since it has hw decoding capabilities whereas VP8 is also decoded in the CPU and drains the battery super fast.

Any clues as to how to always force H264 (basically disable VP8)?

Thanks

[xranby]

When I profile the webbrowser I see other 3 reasons for high CPU usage that are unrelated to the codec:

Maximum client limitted to 12

My observation is that the client computers connecting to jvb run out of resources when having more than 10 users. You can remove non-essential user interface options to make jitsi work better for 12 users and up. If i would give you 4 options to reduce client CPU usage i would give you: Set default video resolution to 480 in /etc/jitsi/meet/*-config.js reason, many users have reported success with up to 30 users by simply lower the video resolution: Bad audio quality and users dropping r…

[Peter_Villeneuve]

Thanks @xranby
I’ve been following your tweaks in the other thread and indeed they help a lot.

Nonetheless I’d still like to try using different codecs to test them out in real world meetings.

Do I have to hack the SDP code to force only h264, VP8 or hopefully soon VP9?

[speedy01]

you can add the following to jicofo properties
org.jitsi.jicofo.ENABLE_VP8=false

You will lose simulcast, as its not supported for h264. Keep in mind that most modern hardware can also use hw acceleration for vp8 and vp9, so you may not see much of a difference.

[Peter_Villeneuve]

Thanks @speedy01 That’s exactly what I was looking for.
I know I’ll lose simulcast but I’m trying to get jitsi meet (on mobile and OSX) to work more like Zoom (quality and stability wise - obviously not security wise).

Ideally all platforms would already support VP9 and HEVC with SVC, simulcast, etc as well as hardware decoders on iOS/Android and Desktops. But until that day comes I need to experiment a lot to try and find the sweet spot between quality, stability and scalability.

[xranby]

It may actually be a problem with hardware acceleration using chrome on mac.
Here is one report of massive CPU usage caused by the hardware acceleration setting inside of Chrome on mac.

High CPU utilization on client end

I found a workaround by disabling hardware acceleration in Google Chrome on my Mac in the Advanced Settings section. Then the massive CPU usage is no longer there and everything else works in video calls. So seems an issue with the hardware acceleration?