Gstreamer errors on specific h264 bytestream on Bullseye and Buster, works if Buster has firmware downgraded.

Start with the embedded GStreamer pipeline and the reported firmware commits b4e395b3e87dba4964f314e12871630cabb35f70 and 15471b6e99b6db2f3206f0aed67d0aebbfc9f9cf. Compare affected and unaffected Pi revision numbers, then reproduce with v4l2h264dec using the provided appsrc stream and gst-launch-1.0 filesrc pipeline. Done means identifying the firmware or decoder regression and confirming that the affected stream decodes successfully without downgrading firmware.

Hi there, I work with a project that utilizes a C++ embedded gstreamer pipeline to process and display a h264 stream of video.
This pipeline, on a raspberry pi 4, resolves to:

appsrc name=mysrc is-live=true block=false max-latency=100 do-timestamp=true stream-type=stream ! queue ! h264parse ! v4l2h264dec ! videocrop top=0 bottom=0 name=videocropper ! capsfilter caps=video/x-raw name=mycapsfilter ! qtquick2videosink

(a dotfile was captured for this pipeline, here)

We're experiencing an issue where some Pi 4s updated to, or past, commit b4e395b3e87dba4964f314e12871630cabb35f70 error out on this pipeline, throwing

0:00:29.404484942 23266 0xa330e000 WARN            videodecoder gstvideodecoder.c:1161:gst_video_decoder_sink_event_default:<v4l2h264dec0> error: No valid frames decoded before end of stream
0:00:29.404541645 23266 0xa330e000 WARN            videodecoder gstvideodecoder.c:1161:gst_video_decoder_sink_event_default:<v4l2h264dec0> error: no valid frames found

when these affected pis are downgraded below the stateful decode update commit, the embedded gstreamer pipeline works as expected.

Furthermore, these afflicted Pis can properly execute
gst-launch-1.0 filesrc location=testfile ! h264parse ! v4l2h264dec ! video/x-raw,format=I420 ! autovideosink
where testfile was recorded with
appsrc name=mysrc is-live=true block=false max-latency=100 do-timestamp=true stream-type=stream ! filesink location=testfile

These afflicted Pis can also properly execute an embedded pipeline of
appsrc name=mysrc is-live=true block=false max-latency=100 do-timestamp=true stream-type=stream ! queue ! h264parse ! avdec_h264 ! videocrop top=0 bottom=0 name=videocropper ! capsfilter caps=video/x-raw name=mycapsfilter ! qtquick2videosink

Out of four Pi 4s this has been tested one, two were afflicted, and two worked even post the stateful decode update commit. All tested pis were on bullseye.

Afflicted revision numbers:
c03112
b03114

Unafflicted revision number:
b03111
a03111

I'd appreciate any help in resolving this manner, as I'm fully out of my depth debugging this issue further. Please let me know if you need any additional information.