How to check in log which Video codec has been configured for Jitsi

Hi,
Suppose I’ve set
org.jitsi.jicofo.ENABLE_VP9=true

in sip-communicator.properties file in jitsi-docker
Now I want to check if Jitsi using VP9 codec in conference, How can I check logs for this?

You don’t need to check in logs, it says it right there in the connection stats when you hover over the indicator. You can also check using Chrome webrtc-internals.

Thank you, I’ll check it out

Hi, can you help for one thing.
In which file should I add org.jitsi.jicofo.ENABLE_VP9=true this code?
I mean in 5763 I am not having etc/jitsi/jicofo/sip-communicator.properties file.
Is this in Jicofo repo or docker jitsi meet?

In the last few releases, it’s set by default in jicofo.conf. You just have to enable it in your config.js.

Thank you @Freddie . can you please provide the full code to enter in config.js.

and

Hi,
I’ve changed in mentioned lines.
In webrtc internals for OutboundVideoStrem got this.
VP8 (100, x-google-start-bitrate=800).
So, VP9 still not enabled?

ok, after setting in the custom-config.js file it is working, as changing in config.js file after restarting it was resetting.
One thing we noticed that, if any client doesn’t support VP9, then the whole conference participants codec is changing to VP8, is it the behavior? I mean in that case, almost in all scenario we won’t have the benefits of VP9.

if any client doesn’t support VP9, then the whole conference participants codec is changing to VP8, is it the behavior?

Yes, otherwise the client that can’t decode VP9 would not be able to decode the video of participants that transmit VP9.

It is theoretically possible (but not very common) to have an “asymmetric” situation, where a client will support (or prefer, due to hardware support or feature limitations) decoding a codec but not encoding that codec, or vice-versa. In case a client was able/willing to decode VP9 but not able/willing to encode VP9, the other participants in the conference could still transmit VP9, and this client would transmit another codec (e.g. VP8).

I mean in that case, almost in all scenario we won’t have the benefits of VP9.

Depends on your users. We find that a majority of users have VP9 support, so conferences where all users have VP9 support are quite common.

Yes, but if you want to enforce VP9 always, you can set the following to “true”. Of course, the downside to this is that if a client does not support VP9 (right now, most do), then that client will not be able to decode the streams of the other participants (the other participants will still see them).

1 Like