On 2/28/20 3:47 PM, Tim Harvey wrote:
On Fri, Feb 28, 2020 at 3:10 PM Steve Longerbeam <slongerbeam@xxxxxxxxx> wrote:
Hi Tim,
On 2/28/20 10:32 AM, Tim Harvey wrote:
Greetings,
I'm running into a colorimetry issue when trying to h264 encode video
from adv7180 on an imx6q. I'm using the following setup on a Gateworks
GW5404 which last worked on a 4.20 kernel with a bunch of backports.
setup script:
# imx6q-gw54xx adv7180 IPU2_CSI1 MODE3:sensor->mux->csi->vdic->ic_prp->ic_prpvf
# imx6q-gw54xx IPU2_CSI1 adv7180 UYVY8_2X8240i@29.9Hz YUV
MODE3:sensor->mux->csi->vdic->ic_prp->ic_prpvf
# reset all links
media-ctl --reset
# setup links
media-ctl -l "'adv7180 2-0020':0 -> 'ipu2_csi1_mux':1[1]"
media-ctl -l "'ipu2_csi1_mux':2 -> 'ipu2_csi1':0[1]"
media-ctl -l "'ipu2_csi1':1 -> 'ipu2_vdic':0[1]"
media-ctl -l "'ipu2_vdic':2 -> 'ipu2_ic_prp':0[1]"
media-ctl -l "'ipu2_ic_prp':2 -> 'ipu2_ic_prpvf':0[1]"
media-ctl -l "'ipu2_ic_prpvf':1 -> 'ipu2_ic_prpvf capture':0[1]"
# configure pads
media-ctl --set-v4l2 "'adv7180 2-0020':0 [fmt:UYVY2X8/720x240 field:alternate]"
media-ctl --set-v4l2 "'ipu2_csi1_mux':2 [fmt:UYVY2X8/720x240]"
media-ctl --set-v4l2 "'ipu2_csi1':0 [fmt:UYVY8_2X8/720x240@1001/30000
field:alternate colorspace:rec709 ycbcr:709]"
media-ctl --set-v4l2 "'ipu2_csi1':1 [fmt:AYUV32/720x480]"
media-ctl --set-v4l2 "'ipu2_vdic':2 [fmt:AYUV32/720x480 field:none]"
media-ctl --set-v4l2 "'ipu2_ic_prp':2 [fmt:AYUV32/720x480 field:none]"
media-ctl --set-v4l2 "'ipu2_ic_prpvf':1 [fmt:AYUV32/720x480]"
device details:
~# media-ctl -e "ipu2_ic_prpvf capture"
/dev/video6
~# for i in $(ls -d /sys/class/video4linux/video*); do echo $i:$(cat
$i/name); done
/sys/class/video4linux/video0:ipu1_csi0 capture
/sys/class/video4linux/video1:ipu1_ic_prpenc capture
/sys/class/video4linux/video10:coda-decoder
/sys/class/video4linux/video2:ipu1_ic_prpvf capture
/sys/class/video4linux/video3:ipu1_csi1 capture
/sys/class/video4linux/video4:ipu2_csi0 capture
/sys/class/video4linux/video5:ipu2_ic_prpenc capture
/sys/class/video4linux/video6:ipu2_ic_prpvf capture
/sys/class/video4linux/video7:ipu2_csi1 capture
/sys/class/video4linux/video8:ipu_ic_pp csc/scaler
/sys/class/video4linux/video9:coda-encoder
gstreamer:
~# gst-launch-1.0 --version
gst-launch-1.0 version 1.16.2
GStreamer 1.16.2
Unknown package origin
~# gst-inspect-1.0 | grep -e "v4l2.*convert*"
video4linux2: v4l2convert: V4L2 Video Converter
# gst-launch-1.0 v4l2src device=/dev/video6 ! v4l2convert
output-io-mode=dmabuf-import ! v4l2h264enc
output-io-mode=dmabuf-import ! fakesink
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Device
'/dev/video6' does not support 2:0:0:0 colorimetry
Additional debuginfo:imx_media_try_colorimetry
../sys/v4l2/gstv4l2object.c(3845): gst_v4l2_object_set_format_full ():
/GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
Device wants 2:4:5:1 colorimetry
This is my fault. The CSI cannot convert quantization or do any Y'CbCr
<-> RGB encodingfrom sink to source, only the PRPVF subdevice can do
that with the help of the Image Converter routines (PRPVF is correctly
allowing user to convert quantization and select encoding at its source
pad). So the CSI must propagate all colorimetry params from sink to source.
Can you try the following:
diff --git a/drivers/staging/media/imx/imx-media-csi.c
b/drivers/staging/media/imx/imx-media-csi.c
index b60ed4f22f6d..ac15b1e78f18 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -1459,6 +1459,8 @@ static void csi_try_fmt(struct csi_priv *priv,
/* propagate colorimetry from sink */
sdformat->format.colorspace = infmt->colorspace;
sdformat->format.xfer_func = infmt->xfer_func;
+ sdformat->format.quantization = infmt->quantization;
+ sdformat->format.ycbcr_enc = infmt->ycbcr_enc;
break;
case CSI_SINK_PAD:
And make sure to specify quantization and encoding at PRPVF source pad:
media-ctl --set-v4l2 "'ipu2_ic_prpvf':1 [fmt:AYUV32/720x480 ycbcr:709]"
Steve,
That seems to fix it.
Interestingly if I include v4l2convert gstreamer crashes:
# gst-launch-1.0 v4l2src device=/dev/video6 ! v4l2convert !
v4l2h264enc ! fakesink
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
ERROR: from element /GstPipeline:pipeline0/v4l2convert:v4l2convert0:
Device '/dev/video11' does not support bt601 colorimetry
Additional debug info:
../sys/v4l2/gstv4l2object.c(3845): gst_v4l2_object_set_format_full ():
/GstPipeline:pipeline0/v4l2convert:v4l2convert0:
Device wants bt709 colorimetry
Execution ended after 0:00:00.006826334
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Caught SIGSEGV
exec gdb failed: No such file or directory
Spinning. Please run 'gdb gst-launch-1.0 499' to continue debugging,
Ctrl-C to quit, or Ctrl-\ to dump core.
But if I use 'gst-launch-1.0 v4l2src device=/dev/video6 ! v4l2h264enc
! fakesink' I'm good... perhaps that's a gstreamer issue.
I noticed that too, I got the same "'/dev/video11' does not support
bt601 colorimetry" and "Device wants bt709 colorimetry" message and
subsequent sigsegv, if I include v4l2video11convert in the pipeline.
Which is odd, the capture device is indeed delivering bt709 to /dev/video11.
Steve
