Issues with H264 on JVB 2.1.137 (and other changes we've noticed)

We have been testing the JVB 2 and H264 isn’t working for us. When a client adds an H264 stream, the track content never shows up on the remote side (the track is muted). And we see this in the JVB logs. WARNING: Dropping an RTP packet, because egress was unable to find an associated encoding. rtpPacket=RtpPacket: PT=107, Ssrc=584900224, SeqNum=2269, M=false, X=true, Ts=1937318498. Are there known issues with H264 on the new JVB or any ideas of why it wouldn’t be working?

We are currently using the jitsi-videobridge2 2.1.137-g07c5cc83 debian package with a slightly modified jicofo based on the latest stable tag (jicofo 508). The only changes to jicofo are a couple patches to the reservation api (here and here). We have a custom client and H264 was working on our current production version of the bridge (which is about a year old).

A few other things we’ve noticed in JVB 2/jicofo:

  1. The JVB doesn’t send a lastNEndpointsChange message on transport connected. There is a TODO in the JVB code for this
  2. The new JVB won’t open a data channel by default or if you set the conference openSctp property (we updated our client to account for this, but this feels like a breaking change especially since jicofo still has the openSctp property but it is ignored)
  3. Jicofo throws an ArrayIndexOutOfBoundsException if the client doesn’t send its feature list and jicofo falls back the default feature list (we discovered because we had a test that wasn’t sending the feature list in response to disco info, not important as the test was fixed to have the client send the features but mostly an FYI)

Thanks a lot for the report. I’ll admit h264 has not seen much attention in the new bridge, and there was significant work done to the frame projection code for vp8 but h264 goes down a different path; we’ve been meaning to revisit that for a while but it hasn’t been a priority since we don’t use h264. I’m not sure when we’ll get to that but will bring it up on Monday. cc @Jonathan_Lennox.

We found another bug related to last-n yesterday as well…last-n will be getting some attention soon, as we need it for ‘big conferences’ which we’re working on now.

I actually didn’t know old bridge supported this. I have a path for this logic here but didn’t know we had a param which controlled it. This isn’t high on our list but a PR for it would be welcome.

Is this related to JVB 2?

Thanks for the quick response and info. We’ve seen some issues with last-n in Firefox that we haven’t come back to yet so good to hear it will be getting some attention soon. EIther myself or someone from my team will be on the community call on Monday.

Ok, good to know that that wasn’t an intentional change.

No, this is just jicofo and I have no idea how long it has been there since we were on a year old version before this. This probably should be a separate topic.

I have a PR which I believe should allow H.264 to work at

It won’t support simulcast or temporal scalability, but basic track projection should work (using the generic track projection context). If you’re using jitsi-meet you’ll want to set config.enableSimulcast to false in your jitsi-meet config, or it’ll end up forwarding only the lowest simulcast layer; but you mentioned having a custom client, so this may not be relevant to you.

Right now we’re focusing on stabilizing the primary jitsi-meet (VP8) use cases, so it might be a bit before this gets merged, but if you could give it a try and comment on that PR, that’d be appreciated.

Yep, that fixed H264. Sorry it took me so long to get it tested (and I see that PR was merged 2 hours ago).