[solved]Does VPFE driver support progressive BT.656 cmos sensor input?

Jason,

 The current VPFE linux driver does not support BT.656 progressive capture on the CCDC. If you want to proceed so, you will have to combine the settings for the raw progressive MT9T001 CMOS sensor and the BT.656 Interlaced TVP5146 sensor to arrive at the same.

Also, as BT.656 is a standard only for PAL/NTSC, to capture a full resolution (if greater than D1), you will have to capture in a raw RBG format and use the previewer to convert it into the YUV format. The RGB, progressive configuration is already implemented for the MT9T001 sensor and you can refer that!

Jason/Sundar,

BT.656 is a standard which includes progressive/interlaced information embedded within the data stream.  By setting our video input interface (VPFE) to BT.656 as our Linux driver do by default, it can process either interlaced or progressive (it depends on the video stream being input).  On our current EVM, TVP5146 happens to input BT.656 interlaced video; however, if MT9M131 inputs BT.656 progressive video, our current drivers and hardware will process that video input correctly as well.  You will still need to write the driver for the MT9M131 sensor to output BT.656 progressive, but our current V4L2 Linux captur driver when placed in BT.656 mode will accept that video input correctly (no driver changes necessary).

Let me know if this helps.

This is mostly a terminology comment but my understanding of bt.656 is that by definition it is interlaced (bt.656 only defines NTSC or PAL), if it was progressive it would be something else. Of course it would be possible for a sender and receiver to agree to ignore the field bit in the sync codes making it progressive but it would not technically be bt.656 anymore.

Our VPFE user guide suggests that field ID codes found in BT.656 streams are coverted by our video front end controller to appropriate signals (defining interlaced/progressive) inside our hardware.  Since BT.656 sender and reciver controllers are likely in hardware, I do not think you have much to worry about, but I believe the F field bits are all 0s when sending progressive video.

HI, SundarIyer/Juan/Bernie,

I have finish the testing that using progressive cmos camera(MT9M131) on DM6446,
Presently, i can capture one frame in 1280*1024 resolution by setting the VPFE to BT.656 mode
and progressive mode in SYN_MODE.

About other method in RGB mode , i will try it when i finish driver in the bt.656 mode .

All of your replies are very useful.
Thanks again.

Hi Juan Gonzales,

Could you give me some suggestion about my problem? Thanks.

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/100/p/60546/218555.aspx

We use TVP5146 as external input source, and connect the 5146 board with dm365 ipnc using J5 Port on the ipnc board, and the 5146 output data use  8bit BT.656 mode. Can we get the right display  on this case? Our test result is the image looks very dark on TV.

Thanks.

Yanbin Yue

Dear Juan,

I searched "field ID" in E2E and found your answer here. I would like to ask some questions:

1. There is a SYN_MODE.FLDSTAT register bit which the document described as indicating the current field when in interlaced mode. Does this contradict with what you are saying here?

2. I regard field identification as a basic information needed for video processing. Nowadays many BT.656 signal are actually output by CCD/CMOS sensors and they only split a frame that is taken at a single time to two fields (top and bottom) to accommodate the widely-used 656 standard. In this case there should be a need to combine neighboring top-bottom field pair to recover the orignal single frame. If field ID are coverted, how can the developer do that? More concretely, upon entering an ISR triggered either by VDINT0 or VDINT1, how can the code know if it is invoked by the top or the bottom field? If the interrupt is from the bottom field, the ISR could combine the two fields; but if the interrupt is from the top field, the memory block starting from SDR_ADDR actually contains a mixture of (I am discussing "linger" mode in which SDR_ADDR remains unchanged and VPFE uses SDOFST configuration to do de-interlacing)

1. bottom field from the previous frame
2. top field from the current frame

which are not taken at the same time. Basically, how can the programmer / ISR know if two fields belong to a single whole frame has completed so he could now retrieve and process it from the memory?

3. For the SYN_MODE.FLDSTAT bit mentioned in 1, I actually did experiments but observed erratic changing patterns rather than toggling between 0 and 1. I raised the question in Several VPFE related questions , could you please have a look at it?

       
Sincerely,
Zheng

Dear Juan,

I searched "field ID" in E2E and found your answer here. I would like to ask some questions:

1. There is a SYN_MODE.FLDSTAT register bit which the document described as indicating the current field when in interlaced mode. Does this contradict with what you are saying here?

2. I regard field identification as a basic information needed for video processing. Nowadays many BT.656 signal are actually output by CCD/CMOS sensors and they only split a frame that is taken at a single time to two fields (top and bottom) to accommodate the widely-used 656 standard. In this case there should be a need to combine neighboring top-bottom field pair to recover the orignal single frame. If field ID are coverted, how can the developer do that? More concretely, upon entering an ISR triggered either by VDINT0 or VDINT1, how can the code know if it is invoked by the top or the bottom field? If the interrupt is from the bottom field, the ISR could combine the two fields; but if the interrupt is from the top field, the memory block starting from SDR_ADDR actually contains a mixture of (I am discussing "linger" mode in which SDR_ADDR remains unchanged and VPFE uses SDOFST configuration to do de-interlacing) 

1. bottom field from the previous frame
2. top field from the current frame

which are not taken at the same time. Basically, how can the programmer / ISR know if two fields belong to a single whole frame has completed so he could now retrieve and process it from the memory?

3. For the SYN_MODE.FLDSTAT bit mentioned in 1, I actually did experiments but observed erratic changing patterns rather than toggling between 0 and 1. I raised the question in Several VPFE related questions , could you please have a look at it?

       
Sincerely,
Zheng

Hi Jason,

I am also using mt9m131 and DM6446 , I could get data from camera in processed bayer format(8 bits), convert into yuv 4:2:2 using previewer and display it. But the image is not clear.

It looks like every alternate vertical lines are missing.

Because of which i am trying to capture yuv image directly from camera. My question is do i have to change the davinci_vpfe for getting yuv image? or just configuring ccdcfg and syn_mode and calling  ccdc_config_ycbcr() function is enough?

If you could help in this

Thanks in advance,

Abdul