v4l2h264dec gstreamer 1.18.4 not accepting stream

[Nicolas Dufresne]

Le lundi 07 mars 2022 à 08:18 +0100, Pascal Speck via gstreamer-devel a écrit :
> 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.

Possible, but then you have to report to the RPi kernel folks, it is quite
unlikely they use any of the baseline feature, so encoding and marking the
stream as baseline isn't a great service.

> 
> 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?

gst-validate-launch-1.0 in replacement to gst-launch-1.0 usually helps. For v4l2
specific interaction with the driver, GST_DEBUG="v4l2*:7".

> 
> 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...

Yes, you can use an element called "capssetter". 

> 
> 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