On 08/10/2019 18:30, Steve Longerbeam wrote:
On 10/8/19 10:20 AM, Ian Arkver wrote:
On 08/10/2019 18:14, Steve Longerbeam wrote:
On 10/8/19 9:55 AM, Tim Harvey wrote:
On Tue, Oct 8, 2019 at 4:21 AM Fabio Estevam <festevam@xxxxxxxxx>
wrote:
On Mon, Oct 7, 2019 at 10:07 PM Fabio Estevam <festevam@xxxxxxxxx>
wrote:
So now I need to see if I can get Gstreamer to accept a pipeline
like:
gst-lauch-1.0 v4l2src ! kmssink
Ok, so now I decided use the hardware video deinterlacer:
media-ctl -l "'adv7180 1-0021':0 -> 'ipu1_csi0':0[1]"
media-ctl -l "'ipu1_csi0':1 -> 'ipu1_vdic':0[1]"
media-ctl -l "'ipu1_vdic':2 -> 'ipu1_ic_prp':0[1]"
media-ctl -l "'ipu1_ic_prp':2 -> 'ipu1_ic_prpvf':0[1]"
media-ctl -l "'ipu1_ic_prpvf':1 -> 'ipu1_ic_prpvf capture':0[1]"
media-ctl -V "'adv7180 1-0021':0 [fmt:UYVY2X8/720x480
field:alternate]"
media-ctl -V "'ipu1_csi0':1 [fmt:AYUV32/720x480]"
media-ctl -V "'ipu1_vdic':2 [fmt:AYUV32/720x480 field:none]"
media-ctl -V "'ipu1_ic_prp':2 [fmt:AYUV32/720x480 field:none]"
media-ctl -V "'ipu1_ic_prpvf':1 [fmt:AYUV32/720x480field:none]"
And then Gstreamer can be launched:
# gst-launch-1.0 v4l2src device=/dev/video2 ! kmssink --verbose
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
/GstPipeline:pipeline0/GstKMSSink:kmssink0: display-width = 800
/GstPipeline:pipeline0/GstKMSSink:kmssink0: display-height = 480
Setting pipeline to PLAYING ...
New clock: GstSystemClock
/GstPipeline:pipeline0/GstV4l2Src:v4l2src0.GstPad:src: caps =
video/x-raw, format=(string)YUY2, width=(int)720, height=(int)480,
framerate=(fraction)25/1, colorimetry=(string)bt601,
interlace-mode=(string)progressive
/GstPipeline:pipeline0/GstKMSSink:kmssink0.GstPad:sink: caps =
video/x-raw, format=(string)YUY2, width=(int)720, height=(int)480,
framerate=(fraction)25/1, colorimetry=(string)bt601,
interlace-mode=(string)progressive
Fabio,
Yes, you need to use the vdic to capture from adv7180 with gstreamer
as it can't handle alternate.
However the video looks like a broken old TV scrolling the image
horizontally:
https://www.dropbox.com/s/2yef8egn6s8z7ff/mx53_adv7180_capture.mp4?dl=0
This would be because of the initial corrupt frames that this and many
other decoders produce while waiting for proper sync. I added
'g_skip_frames' support in 9483a3f8e1b58ba1d7cd21687d8d0a63a015c36b
but I'm not sure how to get gstreamer to use it?
I still carry around a patch from Steve for imx-csi that drops first
few frames from BT656 sources:
https://github.com/Gateworks/linux-imx6/commit/959fbd42ee6433f49ef4a04fb1abe8f8c78db5ad
to deal with this.
Yes, that's likely the issue, from a look at Fabio's video. The patch
referenced by Tim hard-codes the number of frames to skip, instead of
calling the adv7180's g_skip_frames op. I still don't have an answer
as to how to call the adv7180 from the CSI subdev.
Seems to me initial corrupt frames would produce a fixed offset of
some kind. A rolling video like that looks more like the number of
lines being captured is wrong.
Nope, rolling video is one of the symptoms of initial corrupt frames,
from my own experience. I don't really have an explanation for it, but
IIRC the IPU will insert lines on its own to recover from an initial
wrong # lines captured, to regain vertical sync. That should mean the
rolling should eventually stop once vertical sync is re-established, but
I've seen many instances where rolling video continues, and skipping the
initial corrupt frames fixes it.
OK, good to know. Thanks Steve.
Steve
