• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 339 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

OMAP3530 Analog video output has horizontal pixel shift

Philip Park1
Prodigy 20 points
Other Parts Discussed in Thread: OMAP3530

The horizontal shift is worst for NTSC at 14 pixels compared to 4 pixels for PAL.

Has anybody else seen this problem and better still have a solution for it?

This has been observed using various tests:

Visually on an analog video monitor a horizontal shift can be seen between the Input video and Output video using a Capture and Display application.

Using an Oscilloscope to measure the difference between the input and output video for a vertical line frame test pattern input wrt falling edge of the horizontal line sync.

The application was changed to internally generate the Output buffer with a vertical line frame test pattern. An Oscilloscope was then used to measure the actual delay between falling edge of the horizontal line sync and the vertical line, and comparing to the theoretical timing point.

We are using an OMAP3530, with TI's DVSDK V4.01.00.09  which contains PSP 3.00.01.06

The Video Encoder settings have been verified against the recommended values in the Technical Reference Manual Rev W, which are in the Linux Kernel under drivers/video/omap2/dss/venc.c

  • 0
    Prodigy 20 points

    Also on reviewing the Video output frame captured images against the input realised there was a one line (up) vertical shift in the PAL output.  This was verified using an Oscilloscope.  This is even worse than the horizontal shift as this causes a temporal change in the video between the input and output fields.  I have modified the Linux kernel drivers/video/omap2/dss;  venc.c to provide a PAL format flag which is used by disp.c to change the values loaded into DISPC_VID1_BA0 and 1;  This makes assumptions and does not cover all DISPC rotation cases, but is OK for us as we are not using DISPC for any rotations.

    This leads me to think I should look at modifying the DISPC Linux driver to correct the horizontal shift rather than VENC.

  • 0 in reply to Philip Park1
    TI__Expert 4635 points

    Phil,

    could you give some more details of the software stack that you are using in your application and in particular which display framebuffer API is being used to drive the display output - directfb?. I assume that you are also using several graphics overlay layers giving rise to the temporal change.

    Regards,

    Garry