h264 doesn't work any more

[rhwu]

This Issue tracker is only for reporting bugs and tracking code related issues.

Before posting, please make sure you check community.jitsi.org to see if the same or similar bugs have already been discussed. General questions, installation help, and feature requests can also be posted to community.jitsi.org.

Description

H.264 works on video bridge 1030, but not with version >= 1055.

Current behavior

H.264 no longer works with the latest version. A bitset search shows it was broken since this commit 9457cfa.

Expected Behavior

H.264 should work.

Possible Solution

---

Steps to reproduce

Can't see the remote video in a meeting like this:
https://meet.jit.si/h264-via-bridge#config.preferH264=true&config.p2p.enabled=false&config.disableSimulcast=true

Environment details

Mac Chrome Version 68.0.3440.106

[damencho]

I tested this a little.

So the changes of libjitsi from ..-336 to ..-340 is the difference between:
2015b2732bed0d52a0664f7d0a669eb90fdd0358..05bbcbc287d4002001042221c8ed6d973fcf148d.
The suspected commit I had in mind is: jitsi/libjitsi@4c9c5cd
I tried by just registering the h264 formats and nothing had changed (reverting some of the changes in the commit above).
Then I tried just reverting the bridge to an older version: jitsi-videobridge_879 and I have the same experience.
The client joining with preferH264 is sending H264 video, but nothing is received on the other side.

How were you bisecting? Was it working for you at some point?

[rhwu]

Thanks for your reply.

I should have mentioned that you need a change in jicofo first in order to do the bisecting. Basically
"add the missing h264 fmtp params around here: https://github.com/jitsi/jicofo/blob/master/src/main/java/org/jitsi/jicofo/util/JingleOfferFactory.java#L370". Please see jitsi/jicofo#276 for detail.

With above change in jicofo, you should be able to see H264 video works before videobridge version 9457cfa.

Please let me know if you need more information.

[ghost]

I think I can confirm this. We've recording our results from 'forcing' video encoding to VP8, VP9 and H264, and the audio encoding to Opus. Our technique is to edit ('mangle') the SDP derived from the incoming session-initiate Jingle before setting the WebRTC Remote Description. Our results are as follows:

• VP8 - Two-way video and audio flow as expected
• VP9 - video flows TO JVB only. Two-way audio. (See VP9 SVC does not work #573
• H264 - video does not flow. Two-way audio.

We're using the Org.WebRtc wrapper in a Windows UWP project (https://github.com/webrtc-uwp/webrtc-uwp-sdk). This seems pretty solid and reliable. One of the test clients is a HoloLens. Our debugging tools include Wireshark and the WebRTC logs.

In the case of H264 we compared the Jingles being generated in our project with those being generated by Jitsi Meet when H264 was selected, and found the profile level parameter was not being supplied. We applied the patch described in [https://github.com/jitsi/jicofo/issues/276] to fix this, and the Jingles matched afterwards. We ascertained that our H264 codecs conformed to this profile level. Incidentally, we couldn't make H264 work with Jitsi Meet with two Chrome browsers - as soon as video was turned on, we received a 'network issues' dialog in Jitsi Meet.

Looking through the WebRTC logs it looks like the H264 codec - despite no frames being forwarded - is being engaged successfully, although because WebRTC uses the class H264Encoder.cc in this instance, a direct comparison with VP8 logging is not possible.

Again, I'm happy to provide any further information or help with any testing.