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

icecube45 · 2022-01-03T04:13:11Z

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.

The text was updated successfully, but these errors were encountered:

JamesH65 · 2022-01-04T09:41:57Z

@6by9 Not sure if you will have seen this so flagging up just in case.

icecube45 · 2022-01-11T00:28:41Z

Found another pi 4 that is unafflicted, revision code a03111

If I had to wager a guess here - if I'm reading how to decode revision codes correctly, the only link I see is that this isn't affecting revision 1 pi 4s

JamesH65 · 2022-01-11T10:44:17Z

It seems extremely unlikely (not impossible) this is revision based - the differences are on the whole unrelated to the issue being described. I'd suspect a timing problem, but @6by9 is more likely to figure it out than I am.

popcornmix · 2022-01-11T11:57:00Z

I agree the board revision is unlikely to be significant.
Can you confirm that you are testing the same sdcard on each of the four Pi4's (just in case there is something on some of the sdcards that has an effect)?
And can you confirm this is repeatable? (i.e. ten passes on good revision and ten fails on bad revision)?

icecube45 · 2022-01-11T19:53:02Z

This has been a different sdcard per Pi (one of them was USB boot, as well), but all set up using the same installation script on top of vanilla raspbian bullseye.
I can confirm that it's repeatable - the non working pis consistently don't work past the commit given, consistently do prior - the working Pis continue to work throughout. I don't have an exact number, but they've definitely been tested at least 7-10 times through the course of me trying to figure out what's going on.

popcornmix · 2022-01-12T13:02:51Z

Are you able to swap sdcard between a working and non-working board and confirm the problem remains with the board (and not the sdcard)?

popcornmix · 2022-01-12T13:03:54Z

A long shot - add over_voltage=2 to config on a bad pi. Any improvement?

icecube45 · 2022-01-13T00:55:17Z

Swapping the physical sdcard won't be possible here due to the distances between pis, but what I can do is take an image of the working pi's sdcard, and flash it into the sdcard of a non working pi.

Will report back with results (and over_voltage test as well) when I have them.

icecube45 · 2022-01-15T03:31:09Z

Tested b03111, a03111, c03112 on the same image (https://github.com/icecube45/G37_Builder/suites/4934864438/artifacts/142769129) without any other modifications.
No change observed (b03111 and a03111 continued to work, whereas c03112 did not).
Also tried over_voltage on c03112 and b03114 with no change (did not work)

icecube45 · 2022-01-19T23:25:07Z

Managed to source another pi (b03112) locally and tested an sd card swap from a pi that was working (with the same, unmodified image as linked above), and the issue did not appear.

icecube45 · 2022-01-23T04:17:57Z

Continuing to gather whatever information I can that may be relevant.
While I can't swap an sd card from a working Pi to one that isn't, here are three sdcard speed tests from the agnostics package, one from a working pi, two from non working pis.
rpdiags_gstreamer_bad_sdcard_pass_b03114.txt
rpdiags_gstreamer_bad_sdcard_pass_c03112.txt
rpdiags_gstreamer_ok_sdcard_fail_b03111.txt

icecube45 · 2022-01-28T04:05:22Z

Ok! I did a lot more digging into this and think I found not only the actual core of this issue, but also a proper means of replicating it. I will edit the issue title to properly reflect this.

It's not a matter of revision (as @JamesH65 properly guessed), nor is it an SD card issue (as @popcornmix suggested testing - I was able to swap cards on "bad" and "good" pis finally).
Instead, it's a h264 bytestream issue.. kinda?

The attached .h264 file replicates this issue on all pi revisions I've tested on so far, by running
gst-launch-1.0 filesrc location=testfile.h264 ! h264parse ! v4l2h264dec ! video/x-raw,format=I420 ! autovideosink

On bullseye: This command and testfile always fails with "Internal data stream error", regardless of firmware version

On buster: This command fails with "No valid frames decoded before end of stream" when on latest firmware, after a sudo rpi-update 15471b6e99b6db2f3206f0aed67d0aebbfc9f9cf (the commit before the v4l2 stateful update), this command works as expected and the video is shown.

testfile.zip

icecube45 · 2022-01-30T01:48:29Z

I've done a bit of further debugging here:
It looks like on buster the error is thrown if the color_description matrix_coefficients is set (non zero), and works when set to zero (confirmed by hex editing the above testfile).
And on bullseye the error is thrown if the color_description data is in the header at all (present_flag + the color primaries, transfer characteristics, matrix_coefficients) - confirmed again by hex editing.

At this point I am fully outside of my knowledge, but hoping my novice debugging of h264 can help out in some way.

6by9 · 2022-02-02T12:14:02Z

The colour description fields translates to the V4L2 colourspaces - https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/colorspaces-defs.html
The codec will decode these and tell the client if they change, in the same way that it will tell the client if the resolution changes.

Trying on Bullseye, (GStreamer 1.18.4), the kernel logging from V4L2 shows a load of attempts at TRY_FMT on the encoded stream which doesn't inherently have a colourspace), but no format being set or buffers passed in.

[ 1078.558072] videodev: v4l2_open: video10: open (0)
[ 1078.558090] video10: VIDIOC_QUERYCAP: driver=bcm2835-codec, card=bcm2835-codec-decode, bus=platform:bcm2835-codec, version=0x00050f12, capabilities=0x84204000, device_caps=0x04204000
[ 1078.558207] video10: VIDIOC_ENUM_FMT: error -22: index=0, type=vid-out, flags=0x0, pixelformat=.... little-endian (0x00000000), mbus_code=0x0000, description=''
[ 1078.558269] video10: VIDIOC_ENUM_FMT: index=0, type=vid-out-mplane, flags=0x1, pixelformat=MPG4 little-endian (0x3447504d), mbus_code=0x0000, description='MPEG-4 Part 2 ES'
[ 1078.558431] video10: VIDIOC_ENUM_FMT: index=1, type=vid-out-mplane, flags=0x1, pixelformat=H264 little-endian (0x34363248), mbus_code=0x0000, description='H.264'
[ 1078.558579] video10: VIDIOC_ENUM_FMT: index=2, type=vid-out-mplane, flags=0x1, pixelformat=MJPG little-endian (0x47504a4d), mbus_code=0x0000, description='Motion-JPEG'
[ 1078.558720] video10: VIDIOC_ENUM_FMT: index=3, type=vid-out-mplane, flags=0x1, pixelformat=VC1G little-endian (0x47314356), mbus_code=0x0000, description='VC-1 (SMPTE 412M Annex G)'
[ 1078.558863] video10: VIDIOC_ENUM_FMT: index=4, type=vid-out-mplane, flags=0x1, pixelformat=H263 little-endian (0x33363248), mbus_code=0x0000, description='H.263'
[ 1078.559001] video10: VIDIOC_ENUM_FMT: index=5, type=vid-out-mplane, flags=0x1, pixelformat=MPG2 little-endian (0x3247504d), mbus_code=0x0000, description='MPEG-2 ES'
[ 1078.559137] video10: VIDIOC_ENUM_FMT: error -22: index=6, type=vid-out-mplane, flags=0x0, pixelformat=.... little-endian (0x00000000), mbus_code=0x0000, description=''
[ 1078.559228] video10: VIDIOC_ENUM_FMT: error -22: index=0, type=vid-cap, flags=0x0, pixelformat=.... little-endian (0x00000000), mbus_code=0x0000, description=''
[ 1078.559286] video10: VIDIOC_ENUM_FMT: index=0, type=vid-cap-mplane, flags=0x0, pixelformat=YU12 little-endian (0x32315559), mbus_code=0x0000, description='Planar YUV 4:2:0'
[ 1078.559474] video10: VIDIOC_ENUM_FMT: index=1, type=vid-cap-mplane, flags=0x0, pixelformat=YV12 little-endian (0x32315659), mbus_code=0x0000, description='Planar YVU 4:2:0'
[ 1078.559620] video10: VIDIOC_ENUM_FMT: index=2, type=vid-cap-mplane, flags=0x0, pixelformat=NV12 little-endian (0x3231564e), mbus_code=0x0000, description='Y/CbCr 4:2:0'
[ 1078.559762] video10: VIDIOC_ENUM_FMT: index=3, type=vid-cap-mplane, flags=0x0, pixelformat=NV21 little-endian (0x3132564e), mbus_code=0x0000, description='Y/CrCb 4:2:0'
[ 1078.559903] video10: VIDIOC_ENUM_FMT: index=4, type=vid-cap-mplane, flags=0x0, pixelformat=RGBP little-endian (0x50424752), mbus_code=0x0000, description='16-bit RGB 5-6-5'
[ 1078.560046] video10: VIDIOC_ENUM_FMT: error -22: index=5, type=vid-cap-mplane, flags=0x0, pixelformat=.... little-endian (0x00000000), mbus_code=0x0000, description=''
[ 1078.563134] video10: VIDIOC_QUERYCTRL: error -22: id=0x990a95, type=0, name=, min/max=0/0, step=0, default=0, flags=0x00000000
[ 1078.563170] video10: VIDIOC_QUERYCTRL: error -22: id=0x990a96, type=0, name=, min/max=0/0, step=0, default=0, flags=0x00000000
[ 1078.563216] video10: VIDIOC_QUERYCTRL: error -22: id=0x990a0e, type=0, name=, min/max=0/0, step=0, default=0, flags=0x00000000
[ 1078.563246] video10: VIDIOC_QUERYCTRL: error -22: id=0x990a0f, type=0, name=, min/max=0/0, step=0, default=0, flags=0x00000000
[ 1078.563301] video10: VIDIOC_QUERYCTRL: error -22: id=0x990a67, type=0, name=, min/max=0/0, step=0, default=0, flags=0x00000000
[ 1078.563331] video10: VIDIOC_QUERYCTRL: error -22: id=0x990a6b, type=0, name=, min/max=0/0, step=0, default=0, flags=0x00000000
[ 1078.563733] videodev: v4l2_release: video10: release
[ 1079.649495] videodev: v4l2_open: video10: open (0)
[ 1079.649567] video10: VIDIOC_QUERYCAP: driver=bcm2835-codec, card=bcm2835-codec-decode, bus=platform:bcm2835-codec, version=0x00050f12, capabilities=0x84204000, device_caps=0x04204000
[ 1079.649891] video10: VIDIOC_ENUMINPUT: error -25: index=0, name=, type=0, audioset=0x0, tuner=0, std=0x00000000, status=0x0, capabilities=0x0
[ 1079.649975] video10: VIDIOC_ENUMSTD: error -25: index=0, id=0x0, name=, fps=0/0, framelines=0
[ 1079.650090] video10: VIDIOC_QUERYCTRL: id=0x980001, type=6, name=User Controls, min/max=0/0, step=0, default=0, flags=0x00000044
[ 1079.650202] video10: VIDIOC_QUERYCTRL: id=0x980927, type=1, name=Min Number of Capture Buffers, min/max=1/1, step=1, default=1, flags=0x00000004
[ 1079.650289] video10: VIDIOC_QUERYCTRL: error -22: id=0x80980927, type=0, name=, min/max=0/0, step=0, default=0, flags=0x00000000
[ 1079.650720] video10: VIDIOC_ENUM_FMT: index=0, type=vid-out-mplane, flags=0x1, pixelformat=MPG4 little-endian (0x3447504d), mbus_code=0x0000, description='MPEG-4 Part 2 ES'
[ 1079.651005] video10: VIDIOC_ENUM_FMT: index=1, type=vid-out-mplane, flags=0x1, pixelformat=H264 little-endian (0x34363248), mbus_code=0x0000, description='H.264'
[ 1079.651287] video10: VIDIOC_ENUM_FMT: index=2, type=vid-out-mplane, flags=0x1, pixelformat=MJPG little-endian (0x47504a4d), mbus_code=0x0000, description='Motion-JPEG'
[ 1079.651508] video10: VIDIOC_ENUM_FMT: index=3, type=vid-out-mplane, flags=0x1, pixelformat=VC1G little-endian (0x47314356), mbus_code=0x0000, description='VC-1 (SMPTE 412M Annex G)'
[ 1079.651656] video10: VIDIOC_ENUM_FMT: index=4, type=vid-out-mplane, flags=0x1, pixelformat=H263 little-endian (0x33363248), mbus_code=0x0000, description='H.263'
[ 1079.651800] video10: VIDIOC_ENUM_FMT: index=5, type=vid-out-mplane, flags=0x1, pixelformat=MPG2 little-endian (0x3247504d), mbus_code=0x0000, description='MPEG-2 ES'
[ 1079.651945] video10: VIDIOC_ENUM_FMT: error -22: index=6, type=vid-out-mplane, flags=0x0, pixelformat=.... little-endian (0x00000000), mbus_code=0x0000, description=''
[ 1079.652221] video10: VIDIOC_ENUM_FRAMESIZES: index=0, pixelformat=H264 little-endian (0x34363248), type=3, min=32x32, max=1920x1920, step=2x2
[ 1079.652437] video10: VIDIOC_ENUM_FRAMEINTERVALS: error -25: index=0, pixelformat=H264 little-endian (0x34363248), wxh=1920x1920, type=0
[ 1079.652513] video10: VIDIOC_TRY_FMT: type=vid-out-mplane, width=1920, height=1920, format=H264 little-endian (0x34363248), field=none, colorspace=3, num_planes=1, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
[ 1079.652545] plane 0: bytesperline=0 sizeimage=786432
[ 1079.652561] video10: VIDIOC_TRY_FMT: type=vid-out-mplane, width=1920, height=1920, format=H264 little-endian (0x34363248), field=none, colorspace=1, num_planes=1, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
[ 1079.652590] plane 0: bytesperline=0 sizeimage=786432
[ 1079.652603] video10: VIDIOC_TRY_FMT: type=vid-out-mplane, width=1920, height=1920, format=H264 little-endian (0x34363248), field=none, colorspace=2, num_planes=1, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
[ 1079.652632] plane 0: bytesperline=0 sizeimage=786432
[ 1079.652643] video10: VIDIOC_TRY_FMT: type=vid-out-mplane, width=1920, height=1920, format=H264 little-endian (0x34363248), field=none, colorspace=3, num_planes=1, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
[ 1079.652672] plane 0: bytesperline=0 sizeimage=786432
[ 1079.652684] video10: VIDIOC_TRY_FMT: type=vid-out-mplane, width=1920, height=1920, format=H264 little-endian (0x34363248), field=none, colorspace=5, num_planes=1, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
[ 1079.652712] plane 0: bytesperline=0 sizeimage=786432
[ 1079.652727] video10: VIDIOC_TRY_FMT: type=vid-out-mplane, width=1920, height=1920, format=H264 little-endian (0x34363248), field=none, colorspace=6, num_planes=1, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
[ 1079.652755] plane 0: bytesperline=0 sizeimage=786432
[ 1079.652769] video10: VIDIOC_TRY_FMT: type=vid-out-mplane, width=1920, height=1920, format=H264 little-endian (0x34363248), field=none, colorspace=7, num_planes=1, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
[ 1079.652797] plane 0: bytesperline=0 sizeimage=786432
[ 1079.652810] video10: VIDIOC_TRY_FMT: type=vid-out-mplane, width=1920, height=1920, format=H264 little-endian (0x34363248), field=none, colorspace=8, num_planes=1, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
[ 1079.652839] plane 0: bytesperline=0 sizeimage=786432
[ 1079.652852] video10: VIDIOC_TRY_FMT: type=vid-out-mplane, width=1920, height=1920, format=H264 little-endian (0x34363248), field=none, colorspace=9, num_planes=1, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
[ 1079.652880] plane 0: bytesperline=0 sizeimage=786432
[ 1079.652893] video10: VIDIOC_TRY_FMT: type=vid-out-mplane, width=1920, height=1920, format=H264 little-endian (0x34363248), field=none, colorspace=10, num_planes=1, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
[ 1079.652922] plane 0: bytesperline=0 sizeimage=786432
[ 1079.652936] video10: VIDIOC_TRY_FMT: type=vid-out-mplane, width=1920, height=1920, format=H264 little-endian (0x34363248), field=none, colorspace=11, num_planes=1, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0
[ 1079.652964] plane 0: bytesperline=0 sizeimage=786432
[ 1079.673188] videodev: v4l2_release: video10: release

The GStreamer logging shows:

0:00:01.185869542   845   0x5bc450 DEBUG           v4l2videodec gstv4l2videodec.c:916:gst_v4l2_video_dec_sink_getcaps:<v4l2h264dec0> Returning sink caps video/x-h264, width=(int)[ 32, 1920, 2 ], height=(int)[ 32, 1920, 2 ], framerate=(fraction)[ 0/1, 2147483647/1 ], stream-format=(string)byte-stream, alignment=(string)au, colorimetry=(string){ bt709, bt601, smpte240m, 2:4:5:2, 2:4:5:3, 1:4:7:1, 2:4:7:1, 2:4:12:8, bt2020, 2:0:0:0 }, parsed=(boolean)true
0:00:01.186374624   845   0x5bc450 DEBUG           v4l2videodec gstv4l2videodec.c:916:gst_v4l2_video_dec_sink_getcaps:<v4l2h264dec0> Returning sink caps video/x-h264, width=(int)[ 32, 1920, 2 ], height=(int)[ 32, 1920, 2 ], framerate=(fraction)[ 0/1, 2147483647/1 ], stream-format=(string)byte-stream, alignment=(string)au, colorimetry=(string){ bt709, bt601, smpte240m, 2:4:5:2, 2:4:5:3, 1:4:7:1, 2:4:7:1, 2:4:12:8, bt2020, 2:0:0:0 }, parsed=(boolean)true
0:00:01.186637710   845   0x5bc450 DEBUG           v4l2videodec gstv4l2videodec.c:916:gst_v4l2_video_dec_sink_getcaps:<v4l2h264dec0> Returning sink caps EMPTY
0:00:01.186955957   845   0x5bc450 DEBUG           v4l2videodec gstv4l2videodec.c:916:gst_v4l2_video_dec_sink_getcaps:<v4l2h264dec0> Returning sink caps EMPTY
0:00:01.187293851   845   0x5bc450 DEBUG           v4l2videodec gstv4l2videodec.c:916:gst_v4l2_video_dec_sink_getcaps:<v4l2h264dec0> Returning sink caps EMPTY
0:00:01.187496980   845   0x5bc450 DEBUG           v4l2videodec gstv4l2videodec.c:916:gst_v4l2_video_dec_sink_getcaps:<v4l2h264dec0> Returning sink caps EMPTY
ERROR: from element /GstPipeline:pipeline0/GstH264Parse:h264parse0: Internal data stream error.
Additional debug info:

so I suspect it to be a colourspace mapping thing, and h264parse0 ends up saying that it can't produce something that meets the caps advertised by h264v4l2dec

Enabling more logging with GST_DEBUG=caps*:7 before gst-launch-1.0, I get

0:00:00.161445531   949   0x540450 TRACE          caps-features gstcapsfeatures.c:191:gst_caps_features_new_empty: created caps features 0xb4916f60
0:00:00.161521955   949   0x540450 DEBUG             capsfilter gstcapsfilter.c:298:gst_capsfilter_transform_caps:<capsfilter1> input:     video/x-raw, width=(int)800, height=(int)480, framerate=(fraction)0/1, colorimetry=(string)2:4:16:3
0:00:00.161573102   949   0x540450 DEBUG             capsfilter gstcapsfilter.c:299:gst_capsfilter_transform_caps:<capsfilter1> filter:    (NULL)
0:00:00.161625545   949   0x540450 DEBUG             capsfilter gstcapsfilter.c:300:gst_capsfilter_transform_caps:<capsfilter1> caps filter:    video/x-raw, format=(string)I420
0:00:00.161685284   949   0x540450 DEBUG             capsfilter gstcapsfilter.c:302:gst_capsfilter_transform_caps:<capsfilter1> intersect: video/x-raw, format=(string)I420, width=(int)800, height=(int)480, framerate=(fraction)0/1, colorimetry=(string)2:4:16:3
0:00:00.161767819   949   0x540450 DEBUG             capsfilter gstcapsfilter.c:298:gst_capsfilter_transform_caps:<capsfilter1> input:     video/x-raw, format=(string)I420, width=(int)800, height=(int)480, framerate=(fraction)0/1, colorimetry=(string)2:4:16:3
0:00:00.161827744   949   0x540450 DEBUG             capsfilter gstcapsfilter.c:299:gst_capsfilter_transform_caps:<capsfilter1> filter:    video/x-raw, width=(int)800, height=(int)480, framerate=(fraction)0/1, colorimetry=(string)2:4:16:3
0:00:00.161886650   949   0x540450 DEBUG             capsfilter gstcapsfilter.c:300:gst_capsfilter_transform_caps:<capsfilter1> caps filter:    video/x-raw, width=(int)800, height=(int)480, framerate=(fraction)0/1, colorimetry=(string)2:4:16:3, format=(string)I420
0:00:00.161945907   949   0x540450 DEBUG             capsfilter gstcapsfilter.c:302:gst_capsfilter_transform_caps:<capsfilter1> intersect: video/x-raw, width=(int)800, height=(int)480, framerate=(fraction)0/1, colorimetry=(string)2:4:16:3, format=(string)I420

so I read that as h264parse viewing the stream as colorimetry=(string)2:4:16:3 (need to find references to decode that).

ffprobe decodes your clip as " bt470bg/bt470bg/smpte170m".

icecube45 · 2022-02-03T05:15:48Z

@6by9, thank you for looking into this.
From everything you've detailed, I agree that it looks like a colorspace issue.
Similarly, I think there might be two different things going on:

Gstreamer not linking on buster due to the caps advertised by h264v4l2dec
Potentially something more firmware based (the color space not being supported?)

Bear with me here as I try and explain why I think this is the case - I might be misinterpreting things.

I've repeated your logging on Buster, with fully updated firmware, and downgraded firmware below the commit that this issue first started appearing. I've replaced the gstreamer logging for a dot file export. The dmesg and resultant pipeline can both be found in the files at the end of this issue.

In both cases, it looks as if v4l2 is setting the same format (I see two VIDIOC_S_FMT statements in each log, one for H264, one for YU12). Similarly, the gstreamer pipelines look identical, with no colorspace cap on h264parse, and v4l2h264dec spitting out bt601.

These tests are what made me feel like something more underlying firmware based is occurring.

For the case of bullseye, it does look as if gstreamer is failing to link, for the reasons you mentioned (colorspace caps). That is to say, I can replicate your results.
When the video_signal info is removed from the VUI in the testfile, and the same pipeline tested, again we see the same results as buster: no colorimetry from h264parse, bt601 from v4l2h264dec, S_FMT for h264 & YU12.

Similarly, I can get the gstreamer pipeline to link if I lie to it using capssetter:
gst-launch-1.0 filesrc location=testfile.h264 ! h264parse ! capssetter replace=true caps="video/x-h264, width=(int)800, height=(int)480, framerate=(fraction)0/1, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true, stream-format=(string)byte-stream, alignment=(string)au, profile=(string)baseline, level=(string)3.1" ! v4l2h264dec ! video/x-raw,format=I420 ! autovideosink
Similarly, I see the two S_FMT lines, though the pipeline still errors with
ERROR: from element /GstPipeline:pipeline0/v4l2h264dec:v4l2h264dec0: No valid frames decoded before end of stream (the error case from an updated buster install)

And because I was curious, I downgraded the firmware and combined it with the capssetter linking - no difference.
bullseye_updated_firmware_capssetter_dmesg.txt
bullseye_updated_firmware_video_signal_removed_dmesg.txt
buster_firmware_up_to_date_dmesg.txt
buster_old_firmware_dmsg.txt

Buster, firmware up to date

Buster, old firmware

Bullseye, updated firmware, video signal removed from testfile.

Bullseye, updated firmware, capssetter

6by9 · 2022-02-03T13:05:45Z

So decoding that colorimetry=(string)2:4:16:3
https://github.com/GStreamer/gst-plugins-base/blob/master/gst-libs/gst/video/video-color.c#L149

    return g_strdup_printf ("%d:%d:%d:%d", cinfo->range, cinfo->matrix,
        cinfo->transfer, cinfo->primaries);

range = 1 -> GST_VIDEO_COLOR_RANGE_0_255
matrix = 4 -> GST_VIDEO_COLOR_MATRIX_BT601
transfer = 16 -> GST_VIDEO_TRANSFER_BT601
primaries = 3 -> GST_VIDEO_COLOR_PRIMARIES_BT470BG

So it is correct that that your stream doesn't match any of the "standard" colorimetries .

However there is the question as to whether h264parse should really be caring about the colorimetry of the encoded stream, or v4l2h264dec should care on the sink pad for the encoded data. Unfortunately I don't think v4l2h264dec gets a choice about it, as it just advertises the list of things it'll support in the caps, and the src pad then matches it.

Otherwise the comment at https://github.com/GStreamer/gst-plugins-good/blob/master/sys/v4l2/gstv4l2object.c#L2394

   /* step 2: probe all colorspace other than default
   * We don't probe all colorspace, range, matrix and transfer combination to
   * avoid ioctl flooding which could greatly increase initialization time
   * with low-speed devices (UVC...) */

is an invalid choice in v4l2h264dec.

6by9 · 2022-02-03T15:40:46Z

Having enabled the V4L2 and videobuf2 logging, it looks like GStreamer doesn't implement the dynamic resolution change handling required by the V4L2 Stateful Decoder Interface.

After parsing the H264 headers the decoder has noted a change in the colourspace, and so triggered a resolution/format change event.

After encountering a resolution change in the stream, the decoder sends a V4L2_EVENT_SOURCE_CHANGE event with changes set to V4L2_EVENT_SRC_CH_RESOLUTION.

GStreamer hasn't subscribed to these events (VIDIOC_SUBSCRIBE_EVENT(V4L2_EVENT_SOURCE_CHANGE)), so it doesn't see it.

The decoder will then process and decode all remaining buffers from before the resolution change point.

The last buffer from before the change must be marked with the V4L2_BUF_FLAG_LAST flag, similarly to the Drain sequence above.

Warning: The last buffer may be empty (with v4l2_buffer bytesused = 0) and in that case it must be ignored by the client, as it does not contain a decoded frame.

Note: Any attempt to dequeue more CAPTURE buffers beyond the buffer marked with V4L2_BUF_FLAG_LAST will result in a -EPIPE error from VIDIOC_DQBUF().

On the next DQBUF the decoder does generate a -EPIPE

[  635.646035] videodev: v4l2_poll: video10: poll: 00000041
[  635.646429] videobuf2_common: [cap-71bd83c8] __vb2_wait_for_done_vb: last buffer dequeued already, will not wait for buffers
[  635.646449] video10: VIDIOC_DQBUF: error -32: 00:00:00.000000000 index=0, type=vid-cap-mplane, request_fd=0, flags=0x00000000, field=any, sequence=0, memory=mmap

The client must continue the sequence as described below to continue the decoding process.

The client doesn't (it misinterprets the -EPIPE as only applying to EOS documented under DRAIN), and therefore decode stops.

gstv4l2src calls gst_v4l2_buffer_pool_enable_resolution_change to subscribe to the event, and gst_v4l2_buffer_pool_poll will then respond with GST_V4L2_FLOW_RESOLUTION_CHANGE, but gstvideodec doesn't.

Ah https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/240
Except I'm confused as https://bugzilla.gnome.org/show_bug.cgi?id=752962 is resolved, and I could have sworn that resolution change had worked. Perhaps it was just detecting the formats outside of V4L2, and setting the port formats correctly.

icecube45 · 2022-02-03T19:58:43Z

range = 1 -> GST_VIDEO_COLOR_RANGE_0_255
matrix = 4 -> GST_VIDEO_COLOR_MATRIX_BT601
transfer = 16 -> GST_VIDEO_TRANSFER_BT601
primaries = 3 -> GST_VIDEO_COLOR_PRIMARIES_BT470BG

Double checking this (though I don't think it matters in the wider picture of what's going on)
isn't the colorspace being reported range =2 -> GST_VIDEO_COLOR_RANGE_16_235 ?

Sounds like an update to gstreamer (or well, the plugins) is needed to correct this, then?

6by9 · 2022-02-04T15:20:54Z

Double checking this (though I don't think it matters in the wider picture of what's going on)
isn't the colorspace being reported range =2 -> GST_VIDEO_COLOR_RANGE_16_235 ?

Yes, typo by me. It's 16_235.

Sounds like an update to gstreamer (or well, the plugins) is needed to correct this, then?

AFAICT this is GStreamer not following the spec, so it would be an update required to the plugin.

icecube45 · 2022-02-06T01:30:05Z

I went ahead and recompiled gst-plugins-good with the PR you linked above - the capssetter pipeline works in that case, so seems as though you're correct in the issue at play here.
Hopefully that gets merged soon 🤞. Any chance of a kernel flag to work around this until it does? 😅

6by9 · 2022-02-06T09:48:23Z

Seeing as that MR was started 2 years ago, the v4l2src rework was 11 months ago, I suspect it's stalled at present. I'm amazed it'll still apply and compile after all that time.

You may find that changing https://github.com/raspberrypi/linux/blob/rpi-5.15.y/drivers/staging/vc04_services/bcm2835-codec/bcm2835-v4l2-codec.c#L2533 so MMAL_PARAMETER_VIDEO_STOP_ON_PAR_COLOUR_CHANGE is set to 0 instead of 1 will workaround the issue - that could be done as a module parameter. We can't just ignore the parameter at the kernel level as the firmware will already have stopped when it saw the change.

icecube45 · 2022-02-06T10:18:18Z

😅 For what it's worth I actually tried that exact thing a few days back. Tested it again just now - sad to say it doesn't workaround the issue.

6by9 · 2022-02-07T15:40:15Z

You also need to stop it setting the last_buffer_dequeued flag when it receives a MMAL_EVENT_FORMAT_CHANGED event.

index 472d97d1d228..cc6a096d8647 100644
--- a/drivers/staging/vc04_services/bcm2835-codec/bcm2835-v4l2-codec.c
+++ b/drivers/staging/vc04_services/bcm2835-codec/bcm2835-v4l2-codec.c
@@ -1077,9 +1077,9 @@ static void handle_fmt_changed(struct bcm2835_codec_ctx *ctx,
                q_data->field = V4L2_FIELD_NONE;
        }
 
-       vq = v4l2_m2m_get_vq(ctx->fh.m2m_ctx, V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE);
-       if (vq->streaming)
-               vq->last_buffer_dequeued = true;
+       //vq = v4l2_m2m_get_vq(ctx->fh.m2m_ctx, V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE);
+       //if (vq->streaming)
+       //      vq->last_buffer_dequeued = true;
 
        queue_res_chg_event(ctx);
 }
@@ -2530,7 +2530,7 @@ static int bcm2835_codec_create_component(struct bcm2835_codec_ctx *ctx)
                 * Enable firmware option to stop on colourspace and pixel
                 * aspect ratio changed
                 */
-               enable = 1;
+               enable = 0;
                vchiq_mmal_port_parameter_set(dev->instance,
                                              &ctx->component->control,
                                              MMAL_PARAMETER_VIDEO_STOP_ON_PAR_COLOUR_CHANGE,

All of these command lines have then worked

pi@raspberrypi:~/tmp $ GST_DEBUG=caps*:7,video*:7,v4l2*:7 gst-launch-1.0 -vvv filesrc location=testfile.h264 ! h264parse ! capssetter caps="video/x-h264, colorimetry=(string)bt601" ! v4l2h264dec ! "video/x-raw,format=I420,colorimetry=(string)bt601" ! filesink location=testfile.i420
pi@raspberrypi:~/tmp $ GST_DEBUG=caps*:7,video*:7,v4l2*:7 gst-launch-1.0 -vvv filesrc location=testfile.h264 ! h264parse ! capssetter caps="video/x-h264, colorimetry=(string)bt601" ! v4l2h264dec ! "video/x-raw,format=NV12,colorimetry=(string)bt601" ! filesink location=testfile.nv12
pi@raspberrypi:~/tmp $ GST_DEBUG=caps*:7,video*:7,v4l2*:7 gst-launch-1.0 -vvv filesrc location=testfile.h264 ! h264parse ! capssetter caps="video/x-h264, colorimetry=(string)bt601" ! v4l2h264dec ! "video/x-raw,format=NV12,colorimetry=(string)bt601" ! kmssink

icecube45 · 2022-02-08T05:56:22Z

Thank you - confirming I can replicate your results by applying the same patch

ndufresne · 2022-02-20T16:12:16Z

Does NXP MR for resolution changes works with your driver? I've been waiting all this time for folks to actually test this, but I see that workaround in drivers / firmware is more tempting. Note that the submitter has be very slow fixing review comments, but I can take over if some tested-by comment showed up.

ndufresne · 2022-02-20T16:21:17Z

For an update, I realized you are looking at an old MR, the current implementation is here:
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1381

icecube45 · 2022-02-23T22:51:02Z

@ndufresne once I get some free time (rare for these next 3 weeks), I'll give a go at compiling the MR linked, and testing the above pipeline with it

6by9 · 2022-03-05T10:17:22Z

I see that it is now merged to GStreamer's main branch, so it may be possible for a backport to Raspberry Pi OS's 1.18 repo.

Is there already a timeframe available for this?

I've not even looked at how the trees have changed.
There is a significant change in that all the repos have been merged into one repo (monorepo), but as it is only affecting gst-plugins-good I would expect that it can be separated out relatively easily. The question is whether there are any additional dependencies that it relies on.

hailfinger · 2022-03-06T11:54:43Z

It might be easier to backport that change to GStreamer 1.20 and ship a patched GStreamer 1.20 in Raspberry Pi OS as backport. During GStreamer 1.19 development, quite a few bug fixes in GStreamer affecting streaming on a Raspberry Pi were merged. I went forward from 1.18 and it has been a tremendous improvement.

fduncanh · 2022-03-06T20:04:24Z

@icecube45 @6by9

I've been exploring the capssetter fix, to try to perfect it.

@IceCubes's capsetter replace=true caps = "...." with the caps replicated except for the colorimetry value, is not really a viable fix in general when the caps are not known. Instead I find I can use a pipeline that uses the default capsetter values replace=false, join=true:

(appsrc = h264 stream, starting with PPS, SPS)\
 ! queue ! h264parse ! capssetter caps="video/x-h264,colorimetry=bt709" ! v4l2h264dec ! v4l2convert ! autovideosink sync=false

This replaces the "true" colorimetry value 1:3:5:1 (that v4l2 can't find a match to) which I always seem to see on Apple's AirPlay h264 streams, with bt709, which seems to be the appropriate one, but ideally, I would like to just delete the colorimetry entry from the caps as @icecube45 's fix does (in that case, by omitting it but replicating all the other caps entries, and using replace=true).

can someone confirm that there is no way to use capssetter to just remove one caps entry, leaving the others in place, (replace = false, join = true) without specifying them?

(If not, it would be a good enhancement to capsetter to give it a "delete" capability something like ... ! capsetter caps="video/x-h264, colorimetry=(none)" ! ... )

With the capsetter fix, I encouragingly see a brief opening and closing of the window created by autovideosink ( I am on X11, not using kmssink, on R Pi 4B 8GB R Pi OS Bullseye 64bit Desktop), before the failure.

The failure I see is now:

INFO               GST_EVENT gstevent.c:847:gst_event_new_caps: creating caps event video/x-raw, interlace-mode=(string)progressive, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, framerate=(fraction)0/1, format=(string)YV12, width=(int)1440, height=(int)1080
INFO          v4l2bufferpool gstv4l2bufferpool.c:570:gst_v4l2_buffer_pool_set_config:<v4l2convert0:pool0:src> reducing maximum buffers to 32
INFO          v4l2bufferpool gstv4l2bufferpool.c:570:gst_v4l2_buffer_pool_set_config:<v4l2h264dec0:pool0:src> reducing maximum buffers to 32
WARN            v4l2videodec gstv4l2videodec.c:861:gst_v4l2_video_dec_decide_allocation:<v4l2h264dec0> Duration invalid, not setting latency
INFO                    task gsttask.c:516:gst_task_set_lock: setting stream lock 0x558443f3e0 on task 0x7f74009050
INFO                GST_PADS gstpad.c:6235:gst_pad_start_task:<v4l2h264dec0:src> created task 0x7f74009050
INFO                    task gsttask.c:368:gst_task_func:<v4l2h264dec0:src> Task going to paused
INFO                 basesrc gstbasesrc.c:3037:gst_base_src_loop:<video_source> pausing after gst_pad_push() = eos
INFO                    task gsttask.c:368:gst_task_func:<video_source:src> Task going to paused
WARN            videodecoder gstvideodecoder.c:1246:gst_video_decoder_sink_event_default:<v4l2h264dec0> error: No valid frames decoded before end of stream

I assume (hope) the the "Duration invalid, not setting latency" is just a harmless warning, because the stream just started.

What is the next step (patching v4l2 in gstreamer1.0-plugins-good, or kernel driver bcm2835-v4l2-codec.c ?) to try to demonstrate a fix. (I want to try to make sure that a fix to my issue exists and works, rather than just wait for the release cycle, and find out it's still broken).

6by9 · 2022-03-06T21:02:11Z

It might be easier to backport that change to GStreamer 1.20 and ship a patched GStreamer 1.20 in Raspberry Pi OS as backport. During GStreamer 1.19 development, quite a few bug fixes in GStreamer affecting streaming on a Raspberry Pi were merged. I went forward from 1.18 and it has been a tremendous improvement.

Raspberry Pi OS follows Debian unless there is a very good reason not to. Bullseye ships with GStreamer 1.18.
I'll have a discussion with @XECDesign, but if we can get a backport of 1.18 working then that is the preferred option.

ndufresne · 2022-03-07T16:03:49Z

The dynamic resolution change support is now queue or 1.22 release. Feel free to backport, obviously, 1.20 would be an easier target. The colorimetry issue remains, patch welcome of course. A new issue was reported today in the encoder, the driver does not allow "constrained-baseline", which is a bit of a non-sense as it expose its superset baseline (which I doubt it uses any of the features, ASO / FMO).

fduncanh · 2022-03-07T17:34:38Z

I have applied the "1381" patch to 1.20.0 (1.18.4 needs more work because other things would need to be backported too)

Running on Manjaro 5.15.24-1-MANJARO-ARM-RPI #1 SMP PREEMPT Fri Feb 18 18:48:21 UTC 2022 aarch64 GNU/Linux
on R Pi 4B 8GB 64bit, which uses gst 1.20.0. Runs (with capssetter as I described above)

GStreamer video pipeline is

appsrc name=video_source stream-type=0 format=GST_FORMAT_TIME is-live=true ! queue ! h264parse ! capssetter caps="video/x-h264, colorimetry=bt709" ! v4l2h264dec ! v4l2convert ! autovideosink name=video_sink sync=false

very poor latency with an AirPlay stream of a youtube clip of a speech.

GST_DEBUG=2 warnings are

WARN            v4l2videodec gstv4l2videodec.c:948:gst_v4l2_video_dec_decide_allocation:<v4l2h264dec0> Duration invalid, not setting latency
WARN            v4l2videodec gstv4l2videodec.c:689:gst_v4l2_video_dec_loop:<v4l2h264dec0> Received resolution change
WARN                    v4l2 gstv4l2object.c:2226:gst_v4l2_object_get_streamparm:<v4l2h264dec0:src> VIDIOC_G_PARM failed
WARN            videodecoder gstvideodecoder.c:3158:gst_video_decoder_prepare_finish_frame:<v4l2h264dec0> decreasing timestamp (457:24:32.814183173 < 457:24:32.817497788)

** (uxplay:1010): WARNING **: 12:06:59.496: v4l2h264dec0: Too old frames, bug in decoder -- please file a bug
WARN            videodecoder gstvideodecoder.c:3158:gst_video_decoder_prepare_finish_frame:<v4l2h264dec0> decreasing timestamp (457:24:32.817431120 < 457:24:32.817497788)
WARN            videodecoder gstvideodecoder.c:3158:gst_video_decoder_prepare_finish_frame:<v4l2h264dec0> decreasing timestamp (457:24:32.817464445 < 457:24:32.817497788)

** (uxplay:1010): WARNING **: 12:06:59.499: v4l2h264dec0: Too old frames, bug in decoder -- please file a bug

** (uxplay:1010): WARNING **: 12:06:59.499: v4l2h264dec0: Too old frames, bug in decoder -- please file a bug

** (uxplay:1010): WARNING **: 12:06:59.576: v4l2h264dec0: Too old frames, bug in decoder -- please file a bug

fuller output is GST_DEBUG4.txt

will try to build development branch.

fduncanh · 2022-03-07T20:11:21Z

Now tested on main (1.21.0.1) as above.

Same bad latency
GST_DEBUG=2 again reports (after streaming begins)

0:00:13.221773599 23134 0xaaab0ebd9c00 WARN                    v4l2 gstv4l2object.c:3189:gst_v4l2_object_reset_compose_region:<v4l2h264dec0:sink> Failed to get default compose rectangle with VIDIOC_G_SELECTION: Invalid argument
0:00:13.224382368 23134 0xaaab0ebd9c00 WARN                    v4l2 gstv4l2object.c:2235:gst_v4l2_object_get_streamparm:<v4l2h264dec0:src> VIDIOC_G_PARM failed
0:00:13.297538105 23134 0xaaab0ebd9c00 WARN            v4l2videodec gstv4l2videodec.c:948:gst_v4l2_video_dec_decide_allocation:<v4l2h264dec0> Duration invalid, not setting latency
0:00:13.376847685 23134 0xaaab0ebda060 WARN            v4l2videodec gstv4l2videodec.c:689:gst_v4l2_video_dec_loop:<v4l2h264dec0> Received resolution change
0:00:13.400901841 23134 0xaaab0ebda060 WARN                    v4l2 gstv4l2object.c:2235:gst_v4l2_object_get_streamparm:<v4l2h264dec0:src> VIDIOC_G_PARM failed
0:00:13.410801701 23134 0xaaab0ebda060 WARN            v4l2videodec gstv4l2videodec.c:948:gst_v4l2_video_dec_decide_allocation:<v4l2h264dec0> Duration invalid, not setting latency
0:00:18.878874790 23134 0xaaab0ebda060 WARN            videodecoder gstvideodecoder.c:3158:gst_video_decoder_prepare_finish_frame:<v4l2h264dec0> decreasing timestamp (457:24:43.451885752 < 457:24:43.455183690)

** (uxplay:23134): WARNING **: 15:04:17.493: v4l2h264dec0: Too old frames, bug in decoder -- please file a bug

** (uxplay:23134): WARNING **: 15:04:17.497: v4l2h264dec0: Too old frames, bug in decoder -- please file a bug

fduncanh · 2022-03-07T21:49:26Z

@ndufresne

Actually MUCH better news.

the terrible latency was due to autovideosink choosing xvimagesink.
It goes away when using glimagesink.

so I would now say that the fix in 1.21.0.1 (plus the capssetter trick) works!

EVEN BETTER, just applying the "1381" patch to 1.20.0 works too, with glimagesink.
(does the GPU send directly to gl, but not to xvimagesink?)

This means that the backport to 1.20 will be easy! (maybe it could get into 1.20.x?)

1.18 backport needs more investigation as changes in gstv4l2bufferpool will also need to be backported.

need to test in kmssink, but I'm guessing it will be good.

ndufresne · 2022-03-08T13:43:00Z

Yes, glupload will turn the decoder dmabuf into EGL image, which let the GPU sample the buffer directly, while XV requires 2 copied (1 to SHM, and the second into GL). The timestamp issue is on you though, since you use appsrc, its coming from you app. If you control the encoder, 1381 might be sufficient, but we samples that won't work as they have slightly different colorimetry from the "allowed list", which is partial really. This needs fixing in GStreamer still.

fduncanh · 2022-03-08T18:38:28Z

I have posted a clean backport to 1.20.0 at FDH2/UxPlay#70.

1.18.4 backport seems like a nightmare, though.

I don't control the encoding, but probably Apple does (I don't know it Apple reencodes media that it streams) , and it always seems to report as colorimetry 1:3:5:1; the substitution bt709 seems to give good results.

Of course, if I patch, maybe I could find where the "allowed list" is defined, and add 1:3:5;1.

6by9 · 2022-03-10T11:38:50Z

Colorimetry is a combination of 4 parameters, hence the 4 numbers you get. Certain combinations have an alternate name based on the standards that apply.
The decode is as referenced in #1673 (comment)

g_strdup_printf ("%d:%d:%d:%d", cinfo->range, cinfo->matrix,
        cinfo->transfer, cinfo->primaries);

and the list of defined standards is at https://github.com/GStreamer/gst-plugins-base/blob/master/gst-libs/gst/video/video-color.c#L66

Your 1:3:5:1 decodes as
GST_VIDEO_COLOR_RANGE_0_255
GST_VIDEO_COLOR_MATRIX_BT709
GST_VIDEO_TRANSFER_BT709
GST_VIDEO_COLOR_PRIMARIES_BT709
(all defines are in https://github.com/GStreamer/gst-plugins-base/blob/master/gst-libs/gst/video/video-color.h#L39)

The standard BT709 colorimetry is the same except being GST_VIDEO_COLOR_RANGE_16_235. Don't ask me why Apple has chosen to encode full range - that's pretty uncommon within the video standards.

I'm trying to backport to 1.18 at the moment.

6by9 · 2022-03-10T16:41:40Z

Backport pushed to https://github.com/6by9/gst-plugins-good/tree/1_18_res_change.

It seems to work for me, so unless anyone else complains in the next few days, I'll send the 5 patches to be merged into Raspberry Pi OS.

bellum07 · 2022-03-10T17:41:38Z

I'd like to test - how to get an updated package?

fduncanh · 2022-03-10T19:59:48Z

@6by9
Tested, on RPi OS Bullseye 64bit. works great with my app (with the capssetter fix)
(fails to negotiate colorimetry caps with colorimetry=1:3:5:1 without changing it with caps to bt709)

Since I will always get Apples choice, this seems to be a good fix.

fduncanh · 2022-03-10T20:17:18Z

@ndufresne
now that @6by9 has done the 1.18 backport, It would be great if you could get that 1381 patch into 1.20.x, preferably x=1...

6by9 · 2022-03-11T14:21:57Z

I'd like to test - how to get an updated package?

I've pushed a source branch - I don't build Debian packages.

@fduncanh Thanks for testing. I'll send those patches to the relevant person to get Raspberry Pi OS updated.

fduncanh · 2022-03-11T15:48:48Z

@bellum07
see FDH2/UxPlay#70 for how to use @6by9's backport on your Bullseye system

bellum07 · 2022-03-12T09:01:26Z

@bellum07 see FDH2/UxPlay#70 for how to use @6by9's backport on your Bullseye system

Thank you very much.
With this I was able to build the patched library and can confirm that my pipeline is also working now with the fix.

fduncanh · 2022-03-13T07:59:06Z

@6by9

I also tested on the 32-bit "lite" version using kmssink. Worked great as well.

6by9 · 2022-03-15T12:24:54Z

Raspberry Pi OS updated to include the backport today.
http://archive.raspberrypi.com/debian/pool/main/g/gst-plugins-good1.0/
1.18.4-2+~rpt1

6by9 · 2022-03-15T12:25:21Z

@fduncanh Please start a new thread if you have a different issue.

ndufresne · 2022-03-15T14:39:51Z

A regression was found and fixed in the new resolution change code:

https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1960

6by9 · 2022-03-15T15:09:39Z

Thanks for the heads-up. I'll get that one backported too.

fduncanh · 2022-03-16T09:14:39Z

@6by9

there are two other of @ndufresne 's commits to master that need to be backported. I've checked that they work in 1.18.4 and can be added to your backport

The first one is essential, without it there is a crash if the size of the video is changed, which requires a caps renegotiation

https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/e2b2ff26c99723cbbe7129412cc707d0de6d78dd

the second one didn't cause me any issues, but should also be added.

https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/d394b8b4bdc229ab3a47dd6b666157b57b3eb8a3

6by9 · 2022-03-29T17:20:53Z

Patches sent to the relevant person to be merged into Raspberry Pi OS.

icecube45 changed the title ~~Embedded gstreamer pipeline errors on some Pi4 models after V4L2 stateful decode update~~ Gstreamer errors on specific h264 bytestream on Bullseye and Buster, works if Buster has firmware downgraded. Jan 28, 2022

icecube45 mentioned this issue Feb 6, 2022

Whitescreen workaround openDsh/openauto#27

Merged

6by9 mentioned this issue Feb 7, 2022

V4L2 Codec/camera fixes raspberrypi/linux#4765

Closed

ardera mentioned this issue Mar 6, 2022

Gstreamer does not use HW encoding ardera/flutter-pi#224

Closed

bugsyb mentioned this issue Mar 8, 2022

bcm2835-codec bcm2835-codec: bcm2835_codec_start_streaming: Failed enabling i/p port, ret -3 #1701

Open

fduncanh mentioned this issue Mar 18, 2022

Backport of Video4Linux2 changes (gstreamer-plugins-good) needs one more patch #1707

Open

icecube45 mentioned this issue May 24, 2022

White Screen openDsh/dash#125

Open

marvinfrankeengram mentioned this issue Sep 7, 2022

gstreamer1.0-plugins-good: Fix v4l2 bt709 issue agherzan/meta-raspberrypi#1082

Closed

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

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

Comments

icecube45 commented Jan 3, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

JamesH65 commented Jan 4, 2022

Uh oh!

icecube45 commented Jan 11, 2022

Uh oh!

JamesH65 commented Jan 11, 2022

Uh oh!

popcornmix commented Jan 11, 2022

Uh oh!

icecube45 commented Jan 11, 2022

Uh oh!

popcornmix commented Jan 12, 2022

Uh oh!

popcornmix commented Jan 12, 2022

Uh oh!

icecube45 commented Jan 13, 2022

Uh oh!

icecube45 commented Jan 15, 2022

Uh oh!

icecube45 commented Jan 19, 2022

Uh oh!

icecube45 commented Jan 23, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

icecube45 commented Jan 28, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

icecube45 commented Jan 30, 2022

Uh oh!

6by9 commented Feb 2, 2022

Uh oh!

icecube45 commented Feb 3, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Buster, firmware up to date

Buster, old firmware

Bullseye, updated firmware, video signal removed from testfile.

Bullseye, updated firmware, capssetter

Uh oh!

6by9 commented Feb 3, 2022

Uh oh!

6by9 commented Feb 3, 2022

Uh oh!

icecube45 commented Feb 3, 2022

Uh oh!

6by9 commented Feb 4, 2022

Uh oh!

icecube45 commented Feb 6, 2022

Uh oh!

6by9 commented Feb 6, 2022

Uh oh!

icecube45 commented Feb 6, 2022

Uh oh!

6by9 commented Feb 7, 2022

Uh oh!

icecube45 commented Feb 8, 2022

Uh oh!

ndufresne commented Feb 20, 2022

Uh oh!

ndufresne commented Feb 20, 2022

Uh oh!

icecube45 commented Feb 23, 2022

Uh oh!

6by9 commented Mar 5, 2022

Uh oh!

hailfinger commented Mar 6, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fduncanh commented Mar 6, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

6by9 commented Mar 6, 2022

Uh oh!

ndufresne commented Mar 7, 2022

Uh oh!

fduncanh commented Mar 7, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

icecube45 commented Jan 3, 2022 •

edited

Loading

icecube45 commented Jan 23, 2022 •

edited

Loading

icecube45 commented Jan 28, 2022 •

edited

Loading

icecube45 commented Feb 3, 2022 •

edited

Loading

hailfinger commented Mar 6, 2022 •

edited

Loading

fduncanh commented Mar 6, 2022 •

edited

Loading

fduncanh commented Mar 7, 2022 •

edited

Loading

fduncanh commented Mar 7, 2022 •

edited

Loading

fduncanh commented Mar 8, 2022 •

edited

Loading

fduncanh commented Mar 10, 2022 •

edited

Loading

fduncanh commented Mar 13, 2022 •

edited

Loading