Follow-Up: v4l2h264dec gstreamer 1.18.4 not accepting stream

[gstreamer at iktek.de]

Hi together...

After a bit more of digging I found out that it seems to be the profile cap which is not accepted here:

I see the "gst_caps_set_subset" beeing called with the following:

caps video/x-h264, stream-format=(string)byte-stream, alignment=(string)au, width=(int)800, height=(int)600, framerate=(fraction)0/1, chroma-format=(string)4:2:0, bit-depth-luma=(uint)8,
bit-depth-chroma=(uint)8, parsed=(boolean)true, profile=(string)constrained-baseline, level=(string)3.1

template_caps: video/x-h264, stream-format=(string)byte-stream, alignment=(string)au, level=(string){ 1, 1b, 1.1, 1.2, 1.3, 2, 2.1, 2.2, 3, 3.1, 3.2, 4, 4.1 }, profile=(string){ baseline, main, high }

As this function does only compare for "equal" features, I would assume that it breaks here.

I'm currently wondering who does the mistake here:

Should the h264parse element also add the profile="baseline" feature or should the decoder also answer "constrained-baseline" in it's caps to fullfil this issue.?!

Some help of the gst-experts what should be the expected behaviour is appreciated here, so I would know at which module I should search for changes.

Best Regards

Pascal

Am 07.03.22 um 08:18 schrieb Pascal Speck via gstreamer-devel:
> 
> Currently I'm wondering about 3 things:
> 
> 1: Is it really the colorimetry that is not accepted?
> I don't see the "ERROR: from element /GstPipeline:pipeline0/v4l2h264enc:v4l2h264enc0:
> Device '/dev/xxx' does not support xxx colorimetry" message here. I was assuming into the direction of "baseline" vs "constrained-baseline" because v4l2h264enc is only returning baseline in accepted caps.
> 
> 2: Can one give me an idea how to gain more logging information about which capability is causing the "non-acceptance"? Would it be a deal to generally having this information in the gst-error-log?
> 
> I'll try to dig in further meanwhile but as I'm not a gstreamer-expert I first have to find the file where it's worth starting to dig into the code... :-)
> 
> 3: Is there a simple solution to just override the caps in the pipeline only "downstream" to pretend to have a different colorimetry or profile.. If so I would maybe findout more which of the caps is
> not accepted...
> 
> Regards Pascal
> 
> Am 04.03.22 um 14:52 schrieb Nicolas Dufresne via gstreamer-devel:
> Am 04.03.22 um 14:52 schrieb Nicolas Dufresne via gstreamer-devel:
> 
>> Le vendredi 04 mars 2022 à 11:21 +0100, Pascal Speck via gstreamer-devel a
>> écrit :
>>>
>>> 0:00:03.690824695  1500  0xffa000 INFO                    v4l2 gstv4l2object.c:4469:gst_v4l2_object_probe_caps:<v4l2h264dec0:sink> probed caps: video/x-h264, stream-format=(string)byte-stream,
>>> alignment=(string)au, level=(string){ 1, 1
>>> b, 1.1, 1.2, 1.3, 2, 2.1, 2.2, 3, 3.1, 3.2, 4, 4.1 }, profile=(string){ baseline, main, high }, width=(int)[ 48, 1920 ], height=(int)[ 16, 1088 ], 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
>>>
>>> I can see that with the old setup the caps seem very similar but are accepted:
>>>
>>> /GstPipeline:pipeline0/GstH264Parse:h264parse0.GstPad:src: caps = video/x-h264, stream-format=(string)byte-stream, alignment=(string)au, width=(int)800, height=(int)600, framerate=(fraction)0/1,
>>> interlace-mode=(string)progressive, chrom
>>> a-format=(string)4:2:0, bit-depth-luma=(uint)8, bit-depth-chroma=(uint)8, parsed=(boolean)true, profile=(string)constrained-baseline, level=(string)3.1
>>>
>>> Does someone have an Idea where to dig further?
>>
>> Looks quite similar to:
>>
>> https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/1056
>>
>> We *just* need someone with free time to fix it.
>>
>> Nicolas