Hi Steve, On Tue, 2018-06-19 at 18:30 -0700, Steve Longerbeam wrote: > Hi Philipp, Krzysztof, > > On 06/15/2018 01:33 AM, Krzysztof Hałasa wrote: > > Steve Longerbeam <slongerbeam@xxxxxxxxx> writes: > > > > > Right, the selection of interweave is moved to the capture devices, > > > so the following will enable interweave: > > > > > > v4l2-ctl -dN --set-fmt-video=field=interlaced_tb > > > > and > > > > > So the patch to adv7180 needs to be modified to report # field lines. > > > > > > Try the following: > > > > > > --- a/drivers/media/i2c/adv7180.c > > > +++ b/drivers/media/i2c/adv7180.c > > > > With this patch, fix-csi-interlaced.3 seems to work for me. > > "ipu2_csi1":2 reports [fmt:AYUV32/720x576 field:seq-tb], but the > > /dev/videoX shows (when requested) 720 x 576 NV12 interlaced, top field > > first, and I'm getting valid output. > > > > Thanks for your work. > > I've found some time to diagnose the behavior of interweave with B/T line > swapping (to support interlaced-bt) with planar formats. > > There are a couple problems (one known and one unknown): > > 1. This requires 32 pixel alignment to meet the IDMAC 8-byte alignment > of the planar U/V buffer offsets, and 32 pixel alignment precludes > capturing raw NTSC/PAL at 720 pixel line stride. What needs to be aligned to multiples of 32 pixels? I thought 8 pixel width alignment should be good enough for NV12/NV16, for which luma and chroma strides are equal to the width in pixels, and 16 pixel alignment for YUV420/YVU420/YUV422P, where chroma stride is half the width in pixels. > 2. Even with 32 pixel aligned frames, for example by using the prpenc scaler > to generate 704 pixel strides from 720, the colors are still wrong when > capturing interlaced-bt. As a side note, we can't properly scale seq-tb/bt direct input from the CSI vertically with the IC, as the bottom line of the first field will be blended with the top line of the second field... > I thought for sure this must be because we > also > need to double the SLUV line strides in addition to doubling SLY > line stride. > But I tried this and the results are that it works only for YUV > 4:2:2. For 4:2:0 > it causes system hard lockups. (Aside note: interweave without line > swap > apparently has never worked for 4:2:2, even when doubling SLUV, so it's > quite bizarre to me why 4:2:2 interweave _with_ line swap _does_ work > after doubling SLUV). When you say 4:2:2 you only mean YUV422P, not NV16 or YUYV/UYVY ? > For these reasons I think we should disallow interlaced-bt with planar > formats. Does that include NV12/NV16? Capturing to NV12 could be desirable if at all possible, because the result can be encoded by the CODA. The other formats are bandwidth inefficient anyway. > If the user needs NTSC interlaced capture with planar, the fields can be > swapped at > the CSI, by selecting seq-tb at the CSI source pad, which allows for > interlaced-tb > at the capture interface, which doesn't require interweave line swapping. regards Philipp
