decodebin claims incompatible element due to bad colorimetry choice
I'm wondering about a particular behavior of decodebin
.
I am working on Raspberry Pi 4B with kernel version Oct 26 2022 11:09:05
/c72ad6b26ff40c91ef776b847436094ee63fabee
. I can reproduce this behavior with versions 1.20.4, 1.20.5, and 1.21.3 (the 1.20 with backports).
I can construct the following pipeline successfully:
gst-launch-1.0 v4l2src device=/dev/video0 io-mode=4 ! image/jpeg,width=1280,height=720,framerate=30/1 ! v4l2jpegdec ! kmssink
This works nicely, the pipeline is constructed and the video output is shown. This is the debug log, and the pipeline looks as follows:
Now, I was in the process of revising the custom choices of decoders for all kinds of sources and from earlier tests think that I remember that decodebin
as of 1.20 with backports pretty much always makes the optimal choice. So to make automatic pipeline construction simpler and more source-independent, I want to replace all the decoders just by decodebin
.
gst-launch-1.0 v4l2src device=/dev/video0 io-mode=4 ! image/jpeg,width=1280,height=720,framerate=30/1 ! decodebin ! kmssink
And either I remember incorrectly or this was due to a kernel update or whatever. But decodebin
(same for decodebin3
) tries v4l2jpegdec
first, then claims that it does not support the format and goes to the software decoder jpegdec
:
The full debug log contais the astonishing line:
0:00:01.581408231 [33m 2108 [00m 0x558fd6bde0 [33;01mWARN [00m [00m decodebin gstdecodebin2.c:2379:connect_pad:<decodebin0>[00m Element v4l2jpegdec0 does not accept caps
But apparently the pipeline works if I just put v4l2jpegdec
in manually.
Now, the problem is pretty obvious: In the case where I put v4l2jpegdec
manually, the colorimetry 2:0:0:0
is negotiated, which v4l2jpegdec
can work with. When I put decodebin
, the colorimetry 2:4:5:1
is negotiated, and this doesn't work with the accelerated decoder. If I manually force the respective colorimetries, I can verify that indeed v4l2jpegdec
fails; or that decodebin
stays with v4l2jpegdec
. However, the objective for choosing decodebin
over a manual decoder construction is to make things easier. If I now have to check which colorimetry should be enforced to make use of accelerated decoders (which only makes sense if the format actually has accelerated decoders, and then only works if the source supports the colorimetry that the decoder does), then I'm back to an even higher degree of complexity - since before, with manual construction, the colorimetry was just negotiated in the best possible way.
Is there a way for decodebin
to also choose the "most optimal" colorimetry - i.e., if none is enforced, just do the same as would happen if the decoder was plugged in directly?