Re: [PATCH v2 10/10] media: imx.rst: Update doc to reflect fixes to interlaced capture
On Sat, 2018-06-02 at 11:44 -0700, Steve Longerbeam wrote: > > On 06/01/2018 06:44 AM, Philipp Zabel wrote: > > On Thu, 2018-05-31 at 17:30 -0700, Steve Longerbeam wrote: > > > > > + > > > +.. code-block:: none > > > + > > > + # Setup links > > > + media-ctl -l "'adv7180 3-0021':0 -> 'ipu1_csi0_mux':1[1]" > > > + media-ctl -l "'ipu1_csi0_mux':2 -> 'ipu1_csi0':0[1]" > > > + media-ctl -l "'ipu1_csi0':2 -> 'ipu1_csi0 capture':0[1]" > > > + # Configure pads > > > + media-ctl -V "'adv7180 3-0021':0 [fmt:UYVY2X8/720x480 field:seq-bt]" > > > + media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY2X8/720x480]" > > > + media-ctl -V "'ipu1_csi0':2 [fmt:AYUV32/720x480 field:interlaced]" > > > > Could the example suggest using interlaced-bt to be explicit here? > > Actually, I don't think we should allow interlaced on the CSI src pads > > at all in this case. Technically it always writes either seq-tb or seq- > > bt into the smfc, never interlaced (unless the input is already > > interlaced). > > > > Hmm, if the sink is 'alternate', and the requested source is > 'interlaced*', perhaps we should allow the source to be > 'interlaced*' and not override it. For example, if requested > is 'interlaced-tb', let it be that. IOW assume user knows something > we don't about the original field order, or is experimenting > with finding the correct field order. If the source material is really interlaced and not alternate, shouldn't the sink pad be set to interlaced? regards Philipp
Re: [PATCH v2 10/10] media: imx.rst: Update doc to reflect fixes to interlaced capture
Steve Longerbeam writes: > Hmm, if the sink is 'alternate', and the requested source is > 'interlaced*', perhaps we should allow the source to be > 'interlaced*' and not override it. For example, if requested > is 'interlaced-tb', let it be that. IOW assume user knows something > we don't about the original field order, or is experimenting > with finding the correct field order. Yes, this is clearly possible. In fact the analog signal doesn't carry information about the field order (if any). The video editing/encoding software does motion estimation for this, and there is no other way (given that the video material can change from progressive to interlaced and vice versa, and probably can change the field order, at any time). -- Krzysztof Halasa Industrial Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland
Re: [PATCH v2 10/10] media: imx.rst: Update doc to reflect fixes to interlaced capture
On 06/01/2018 06:44 AM, Philipp Zabel wrote: On Thu, 2018-05-31 at 17:30 -0700, Steve Longerbeam wrote: + +.. code-block:: none + + # Setup links + media-ctl -l "'adv7180 3-0021':0 -> 'ipu1_csi0_mux':1[1]" + media-ctl -l "'ipu1_csi0_mux':2 -> 'ipu1_csi0':0[1]" + media-ctl -l "'ipu1_csi0':2 -> 'ipu1_csi0 capture':0[1]" + # Configure pads + media-ctl -V "'adv7180 3-0021':0 [fmt:UYVY2X8/720x480 field:seq-bt]" + media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY2X8/720x480]" + media-ctl -V "'ipu1_csi0':2 [fmt:AYUV32/720x480 field:interlaced]" Could the example suggest using interlaced-bt to be explicit here? Actually, I don't think we should allow interlaced on the CSI src pads at all in this case. Technically it always writes either seq-tb or seq- bt into the smfc, never interlaced (unless the input is already interlaced). Hmm, if the sink is 'alternate', and the requested source is 'interlaced*', perhaps we should allow the source to be 'interlaced*' and not override it. For example, if requested is 'interlaced-tb', let it be that. IOW assume user knows something we don't about the original field order, or is experimenting with finding the correct field order. Steve
Re: [PATCH v2 10/10] media: imx.rst: Update doc to reflect fixes to interlaced capture
On 06/01/2018 06:44 AM, Philipp Zabel wrote: On Thu, 2018-05-31 at 17:30 -0700, Steve Longerbeam wrote: Also add an example pipeline for unconverted capture with interweave on SabreAuto. Signed-off-by: Steve Longerbeam --- Documentation/media/v4l-drivers/imx.rst | 51 - 1 file changed, 37 insertions(+), 14 deletions(-) diff --git a/Documentation/media/v4l-drivers/imx.rst b/Documentation/media/v4l-drivers/imx.rst index 65d3d15..4149b76 100644 --- a/Documentation/media/v4l-drivers/imx.rst +++ b/Documentation/media/v4l-drivers/imx.rst @@ -179,9 +179,10 @@ sink pad can take UYVY2X8, but the IDMAC source pad can output YUYV2X8. If the sink pad is receiving YUV, the output at the capture device can also be converted to a planar YUV format such as YUV420. -It will also perform simple de-interlace without motion compensation, -which is activated if the sink pad's field type is an interlaced type, -and the IDMAC source pad field type is set to none. +It will also perform simple interweave without motion compensation, +which is activated if the sink pad's field type is sequential top-bottom +or bottom-top or alternate, and the IDMAC source pad field type is +interlaced (t-b, b-t, or unqualified interlaced). I think sink pad alternate behaviour should be equal to sink pad top- bottom for PAL and sink pad bottom-top for NTSC. If we agree on this, we should mention that here. Agreed. This subdev can generate the following event when enabling the second IDMAC source pad: @@ -383,13 +384,13 @@ and CSC operations and flip/rotation controls. It will receive and process de-interlaced frames from the ipuX_vdic if ipuX_ic_prp is receiving from ipuX_vdic. -Like the ipuX_csiY IDMAC source, it can perform simple de-interlace +Like the ipuX_csiY IDMAC source, it can perform simple interweaving without motion compensation. However, note that if the ipuX_vdic is included in the pipeline (ipuX_ic_prp is receiving from ipuX_vdic), -it's not possible to use simple de-interlace in ipuX_ic_prpvf, since -the ipuX_vdic has already carried out de-interlacing (with motion -compensation) and therefore the field type output from ipuX_ic_prp can -only be none. +it's not possible to use interweave in ipuX_ic_prpvf, since the +ipuX_vdic has already carried out de-interlacing (with motion +compensation) and therefore the field type output from ipuX_vdic +can only be none (progressive). Capture Pipelines - @@ -514,10 +515,32 @@ On the SabreAuto, an on-board ADV7180 SD decoder is connected to the parallel bus input on the internal video mux to IPU1 CSI0. The following example configures a pipeline to capture from the ADV7180 +video decoder, assuming NTSC 720x480 input signals, using simple +interweave (unconverted and without motion compensation). The adv7180 +must output sequential or alternating fields (field type 'seq-tb', +'seq-bt', or 'alternate'): + +.. code-block:: none + + # Setup links + media-ctl -l "'adv7180 3-0021':0 -> 'ipu1_csi0_mux':1[1]" + media-ctl -l "'ipu1_csi0_mux':2 -> 'ipu1_csi0':0[1]" + media-ctl -l "'ipu1_csi0':2 -> 'ipu1_csi0 capture':0[1]" + # Configure pads + media-ctl -V "'adv7180 3-0021':0 [fmt:UYVY2X8/720x480 field:seq-bt]" + media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY2X8/720x480]" + media-ctl -V "'ipu1_csi0':2 [fmt:AYUV32/720x480 field:interlaced]" Could the example suggest using interlaced-bt to be explicit here? Actually, I don't think we should allow interlaced on the CSI src pads at all in this case. Technically it always writes either seq-tb or seq- bt into the smfc, never interlaced (unless the input is already interlaced). Agreed, I'll make that change in v3 and update the doc. Steve +Streaming can then begin on the capture device node at +"ipu1_csi0 capture". The v4l2-ctl tool can be used to select any +supported YUV pixelformat on the capture device node. + +This example configures a pipeline to capture from the ADV7180 video decoder, assuming NTSC 720x480 input signals, with Motion -Compensated de-interlacing. Pad field types assume the adv7180 outputs -"interlaced". $outputfmt can be any format supported by the ipu1_ic_prpvf -entity at its output pad: +Compensated de-interlacing. The adv7180 must output sequential or +alternating fields (field type 'seq-tb', 'seq-bt', or 'alternate'). +$outputfmt can be any format supported by the ipu1_ic_prpvf entity +at its output pad: .. code-block:: none @@ -529,9 +552,9 @@ entity at its output pad: 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]" # Configure pads - media-ctl -V "'adv7180 3-0021':0 [fmt:UYVY2X8/720x480]" - media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY2X8/720x480 field:interlaced]" - media-ctl -V "'ipu1_csi0':1 [fmt:AYUV32/720x480 field:interlaced]" + media-ctl -V "'adv7180 3-0021':0 [fmt:UYVY2X8/720x480 field:seq-bt]" + med
Re: [PATCH v2 10/10] media: imx.rst: Update doc to reflect fixes to interlaced capture
On Thu, 2018-05-31 at 17:30 -0700, Steve Longerbeam wrote: > Also add an example pipeline for unconverted capture with interweave > on SabreAuto. > > Signed-off-by: Steve Longerbeam > --- > Documentation/media/v4l-drivers/imx.rst | 51 > - > 1 file changed, 37 insertions(+), 14 deletions(-) > > diff --git a/Documentation/media/v4l-drivers/imx.rst > b/Documentation/media/v4l-drivers/imx.rst > index 65d3d15..4149b76 100644 > --- a/Documentation/media/v4l-drivers/imx.rst > +++ b/Documentation/media/v4l-drivers/imx.rst > @@ -179,9 +179,10 @@ sink pad can take UYVY2X8, but the IDMAC source pad can > output YUYV2X8. > If the sink pad is receiving YUV, the output at the capture device can > also be converted to a planar YUV format such as YUV420. > > -It will also perform simple de-interlace without motion compensation, > -which is activated if the sink pad's field type is an interlaced type, > -and the IDMAC source pad field type is set to none. > +It will also perform simple interweave without motion compensation, > +which is activated if the sink pad's field type is sequential top-bottom > +or bottom-top or alternate, and the IDMAC source pad field type is > +interlaced (t-b, b-t, or unqualified interlaced). I think sink pad alternate behaviour should be equal to sink pad top- bottom for PAL and sink pad bottom-top for NTSC. If we agree on this, we should mention that here. > This subdev can generate the following event when enabling the second > IDMAC source pad: > @@ -383,13 +384,13 @@ and CSC operations and flip/rotation controls. It will > receive and > process de-interlaced frames from the ipuX_vdic if ipuX_ic_prp is > receiving from ipuX_vdic. > > -Like the ipuX_csiY IDMAC source, it can perform simple de-interlace > +Like the ipuX_csiY IDMAC source, it can perform simple interweaving > without motion compensation. However, note that if the ipuX_vdic is > included in the pipeline (ipuX_ic_prp is receiving from ipuX_vdic), > -it's not possible to use simple de-interlace in ipuX_ic_prpvf, since > -the ipuX_vdic has already carried out de-interlacing (with motion > -compensation) and therefore the field type output from ipuX_ic_prp can > -only be none. > +it's not possible to use interweave in ipuX_ic_prpvf, since the > +ipuX_vdic has already carried out de-interlacing (with motion > +compensation) and therefore the field type output from ipuX_vdic > +can only be none (progressive). > > Capture Pipelines > - > @@ -514,10 +515,32 @@ On the SabreAuto, an on-board ADV7180 SD decoder is > connected to the > parallel bus input on the internal video mux to IPU1 CSI0. > > The following example configures a pipeline to capture from the ADV7180 > +video decoder, assuming NTSC 720x480 input signals, using simple > +interweave (unconverted and without motion compensation). The adv7180 > +must output sequential or alternating fields (field type 'seq-tb', > +'seq-bt', or 'alternate'): > + > +.. code-block:: none > + > + # Setup links > + media-ctl -l "'adv7180 3-0021':0 -> 'ipu1_csi0_mux':1[1]" > + media-ctl -l "'ipu1_csi0_mux':2 -> 'ipu1_csi0':0[1]" > + media-ctl -l "'ipu1_csi0':2 -> 'ipu1_csi0 capture':0[1]" > + # Configure pads > + media-ctl -V "'adv7180 3-0021':0 [fmt:UYVY2X8/720x480 field:seq-bt]" > + media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY2X8/720x480]" > + media-ctl -V "'ipu1_csi0':2 [fmt:AYUV32/720x480 field:interlaced]" Could the example suggest using interlaced-bt to be explicit here? Actually, I don't think we should allow interlaced on the CSI src pads at all in this case. Technically it always writes either seq-tb or seq- bt into the smfc, never interlaced (unless the input is already interlaced). > +Streaming can then begin on the capture device node at > +"ipu1_csi0 capture". The v4l2-ctl tool can be used to select any > +supported YUV pixelformat on the capture device node. > + > +This example configures a pipeline to capture from the ADV7180 > video decoder, assuming NTSC 720x480 input signals, with Motion > -Compensated de-interlacing. Pad field types assume the adv7180 outputs > -"interlaced". $outputfmt can be any format supported by the ipu1_ic_prpvf > -entity at its output pad: > +Compensated de-interlacing. The adv7180 must output sequential or > +alternating fields (field type 'seq-tb', 'seq-bt', or 'alternate'). > +$outputfmt can be any format supported by the ipu1_ic_prpvf entity > +at its output pad: > > .. code-block:: none > > @@ -529,9 +552,9 @@ entity at its output pad: > 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]" > # Configure pads > - media-ctl -V "'adv7180 3-0021':0 [fmt:UYVY2X8/720x480]" > - media-ctl -V "'ipu1_csi0_mux':2 [fmt:UYVY2X8/720x480 field:interlaced]" > - media-ctl -V "'ipu1_csi0':1 [fmt:AYUV32/720x480 field:interlaced]" > + media-ctl -V "'adv7180 3-0021':0 [fmt:UYVY2X8/720x4