DRA744: VIP: camera input sometimes looks like odd and even rows are reversed

Hi Carlo,

The camera supported in the Android is JAMR board analog camera connected over TVP5158.
Since this is an analog camera BT565, the video is interlaced.

The VPE hardware is used to perform de-interlacing and then the final progressive image is passed by the HAL layer.

"Odd and even lines being reversed" sounds like a problem in the de interlacing configuration of the VPE driver.
The errata i839 is about the byte order in memory. e.g. RGBA might be written as ABGR.
I don't think this symptom is related to the errata.


Regards,
Nikhil D

Hi David ,
thank you but I m using VIP .
we found a workaround on VIP where I ll need your confirmation if usable in production :

-HAL camera we configure the video frame format in V4 L2_FIELD_SEQ_TB (the frame contains in a single buffer the sequence Top + Bottom);
-VIP Driver takes from the "Data Transfer Descriptor Format" the bit "Field" (bit 24);
--> if Field = 1, VIP Driver passes to the HAL Camera the information that the frame contains Bottom + Top. If Field = 0 VIP Driver passes to the HAL Camera the information that the frame contains Top + Bottom.
Camera HAL It assembles dynamically the video frame based on the information received from the VIP

do you think is it correct ? any side effect ?
thank you very much
regards
Carlo

Hi Carlo,

I don't think our VIP driver supports V4L2_FIELD_SEQ_TB? This would normally be something handled by VPE. I don't believe the Camera HAL we ship supports using V4L2_FIELD_SEQ_TB either. 

Assuming these are addressed, it's also necessary to ensure that in the case of a dropped field, the TB order is maintained across, and there are no temporal order issues. Since we don't use V4L2_FIELD_SEQ_TB, I can't comment much further on correctness. It does look like it's supported by the VPE driver though. 

Without using either the VPE or another adaptive deinterlacing solution, it's likely that a rough field order presentation would result in common deinterlacing artifacts like these: 

Thanks,

David

Hi Yordan ,

I m working on it with colleagues in Dallas , still having  issues

please leave it open  for a while

thank you

regards

Carlo

Hi Carlo,

No problem. Please write here if you have any progress or new questions.

Regards,
Yordan

Hi Carlo,

I will close this thread, you can write here to reopen it when there are new questions.

Regards,
Yordan

Hi Yordan , sorry for late reply .

It seems we have now a good image coming out from the VPE in NV12.

The VPE NV12 frame is then converted in assembler format nv12+stride (similar to the convertYUV422ToNV12Tiler you mentioned) and then finally sent to the sendFrameToSubscribers.

We need in any case to fill the "stride" (4096) to every line of the VPE frame.
The assembler function is just necessary for this particular purpose.

We have then a couple of of questions:

1. This require a lot of cpu usage; so do you know if there is a way to avoid it?

2. We are using: Jacinto DRA744, linux kernel 3.8, Android Jelly Bean 4.3. Do you know if newer version of Android still require it?

thank you
regards
Carlo