Corrupted vp8 simulcast video in Chrome 67

With upgrade to Chrome 67 I’ve noticed a number of degradations when using simulcast (3 layers vp8) with the jitsi videobridge. Much of it was discussed and addressed in [jitsi-users] Simulcast doesn't work in Chrome 67 beta. Thanks for fixing that.

However after upgrading to JVB 1068 we still see issues in the scenarios where vp8 simulcast is used. The issues often appear when there is a switch between simulcast layers. In the chrome log you then see warnings like

[62791:59059:0628/] Frame with (timestamp:picture_id:spatial_id) (544992430:1000000000000003251:0) sent to decoder after frame with (timestamp:picture_id:spatial_id) (544998400:1000000000000003243:0).
[62778:59723:0628/] Frame with (timestamp:picture_id:spatial_id) (1381914185:1000000000000003338:0) sent to decoder after frame with (timestamp:picture_id:spatial_id) (1381920155:1000000000000003330:0).

and the video either freezes for a while or becomes corrupted (recovers later after another periodic keyframe or switch of simulcast layer)

This issue happens when ENABLE_VP8_PICID_REWRITING=false but not when it is set to true. A known issue?

Hi Henrik, we haven’t seen such bad degradation in a while. Could you share your file? Also, are you able to reproduce the issue and if so, it would be useful to capture a decrypted pcap and send it over to have a look.

Thank you and apologies for the late reply.


Thanks George,
I am currently on vacation but can try to reproduce it again next week when I am back. When I tested it was happening fairly frequently (every 3-4 5min calls or so). What’s the proper way to dump pcap from the JVB to a specified file? Not sure I’ve seen any documentation on that (when testing I typically run both JVB and clients locally on a Mac).

Attached is the file (1.1 KB)


Hi Henrik,

I missed the last part from your initial message. Setting ENABLE_VP8_PICID_REWRITING=false can cause this situation. You should remove that line from your file.

The only valid problem is that the video freezes when that setting is enabled and raw packet dumps are helpful to debug that too.

There’s a short guide that documents the steps here


Hi George,
Are you saying that it is expected to get corrupted video stream with ENABLE_VP8_PICID_REWRITING=false? So, is that just a test mode which should not be used? I think we have used that for some time with earlier versions of Chrome without seeing issues.

The freezing wasn’t that much of a problem. Sorry I wasn’t clearer on that in the initial description. It was only a matter of max a second, so I wouldn’t worry about that. The real issue was the corrupted video which stays corrupted for 30+ seconds


Hi Henrik, recent versions of Chrome (> 58 I believe) have a new jitter buffer that causes the issues that you’re observing, unless the bridge does picture id rewriting. There was some fuzz about it in the discuss-webrtc group, but I can’t find the exact post right now. Nowadays picture id rewriting is on by default; we’ve left flag the flag there only because we didn’t bother removing it.

I hope this helps,