tl;dr: if you depend on OpenH264 please read this carefully and test in Canary and Beta.
I just landed a commit that updates the OpenH264 dependency Chromium uses for H264 software encoding (on the constrained baseline profile)
The full changelog is linked in the commit. If everything goes as planned this will land in Chromium 129 stable on September 17th.
The primary reason for updating this was a change in the H264 pic_order_cnt in the SPS generated by OpenH264 from 0 to 2 from
which can be found in the SPS in Wireshark like this:
The value 2 means that the stream can be decoded instantly as the display order is the same as the decode order and there is no
need to wait for the next frame to determine if the current frame can be played out. See
for a great explanation (or the excellent book on H264 by the same author)
What originally spurred the change was this behavior observed in a webrtc-internals dump:
which basically shows the decoder waiting for 30ms or one frame for no reason.
This behavior is a known issue on some Android hardware decoders like the one used in Qualcomms Snapdragon chips and quite undesirable for RTC scenarios in general.
For WebRTC on those devices you should see a drop in the per-frame totalDecodeTime returned from getStats to more reasonable values of 4 milliseconds.
As a bonus this also removes two bytes from each frame encoded with OpenH264. This may not sound much but adds up!
If you depend on H264 please test in Canary and Beta
cheers
Philipp