AnsweredAssumed Answered

i.MX6Q+ADV7481: Capturing YUV420, but from script setting up YUV422

Question asked by Will Hoie on Mar 23, 2018
Latest reply on May 14, 2018 by Will Hoie

I am using an ADV7481 that connects via MIPI to an i.MX6Q (running Linux) over 4 CSI lanes. I am attempting to set up the ADV7481 for HDMI input, YUV 422 8-bit, 4-Lane CSI output. I originally posted this question in the Analog Devices video and Linux forums, but I am still stuck even with their help.

 

I am using the “:08-08 Free-run MIPI TxA CSI 4-Lane - YUV422 8-Bit, 1280x720p 60Hz:” snippet from the ADV7481ES3C-VER.3.6c.txt file for the ADV7481 required settings in order to generate a test pattern (colorbars) over the MIPI connection to the i.MX6.

 

I am using the driver developed by Wally Yeh, and discussed here. The driver has been working so far, and I have extended it with the script I just mentioned above. Wally had been using it for 2-Lane capture, but I was able to set it up for 4 lanes, and I have confirmed that in the lab.

 

I can communicate with the part successfully, and can program the EDID successfully (verified with a  GoPro camera hooked up to it), so I know communication is good between the i.MX6 and ADV7481.

 

However, when I capture the test pattern, it has obvious defects. I’m not sure what it could be, but I am also unsure what the color pattern is actually supposed to look like at this resolution. I have attached a screen grab of the test pattern I am getting. It looks like the color bar pattern is being repeated 8 times, and I don't think that's right.

 

Screen capture at 1280x720

 

Looking at the binary data for this raw video capture, the format actually looks like yuv420, not  yuv422, which is very strange. The settings are clearly yuv422 going to the ADV7481, so this is the most important issue to resolve at first. Why am I receiving what appears to be yuv420 back? I am using ffplay (from the ffmpeg project) in order to play the raw video capture, and it claims that the color format is also yuv420 when it attempts to discover the format automatically. This software has been used to view other video captures in yuv422 format, so I trust it is not being faked about the format.

 

Command line to run raw video file:

ffplay.exe -f rawvideo -pixel_format yuv420p -video_size 1280x720 test-color-bars-1280x720-yuv422.yuv

 

Another developer analyzed the binary data when I ran the same script (except set for solid blue screen instead of color bars), and he also concluded that the format was actually yuv420 instead of yuv422:

 

Looks like YUV 4:2:0  (https://en.wikipedia.org/wiki/Chroma_subsampling)

 

I see 0x0f for the first 0xe1000 bytes(0xe1000 == 921600 == 1280*720)

0xC4 for the next 0x38400 bytes(0x38400 ==  230400 == (1280 * 720 / 4))

0x75 for the next 0x38400 bytes

 

I have attached both the color bar raw video file, and the solid blue raw video file in separate zipped attachments.

 

Here is a link to the post I made in the Analog Devices Video forum, and here is the one I made in the Analog Devices Linux forum.

 

In summary, I’d like to know what could possibly cause the repeating color bar pattern in the i.MX6, given the setting from that script, and why the received format appears to be YUV 420 instead of YUV 422 like the script is attempting to set up in the ADV7841.

 

My hunch is that the ADV7481 is set up correctly, but I'm missing something in the processing chain in the i.MX6. Hope that makes sense.

 

Here is what I have from a 1920x1080p test run, and this has 3 repeating test patterns. The settings I am putting in the ADV7481 are the same except for the video resolution.

 

Screen capture at 1920x1080 via 4 lanes showing 3 color bar patterns

 

Thank you for taking a look!

Outcomes