• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 97 subscribers
  • Views 2086 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.

DM365 TVP5150 video capture problem

Mitch Rybczynski
Intellectual 320 points
noisy.mp4
Other Parts Discussed in Thread: TVP5150

Hi,  I'm doing board bringup on a custom board to capture and encode h264 video from on a dm365, from a NTSC camera via a tvp5150 decoder.

  • DM365 custom board, with TVP5150 YOUT to a 74CBTLV16210DL switch, to DM365 YIN
  • NTSC input from camera to TVP5150
  • modified DMAI based recorder test application
  • YCINSWP added: ccdcfg |= CCDC_YCINSWP_YCBCR in dm365_ccdc.c driver.
  • Using tvp5150 driver from DVSDK3.0

The recorded video has some vertical line noise, and some pulsing intensity artifacts.  Attached is a sample recorded video.

Any ideas what settings might be causing this sort of problem?  It appears to be some sort of misconfiguration, but I have not been able to pinpoint it.  There was some flywire rework to the lines between the TVP5150 and the switch, but as this is a digital signal, i expect that it would not introduce video noise of this sort.

Regards,

Mitch Rybczynski

added some debug output and configuration changes to the tvp5150.c, dm365_cdcc.c, and vpfe_capture.c:

tvp5150 1-005c: tvp5150am1 detected.
tvp5150 1-005c: MTR: Selecting video route: route input=0, output=0 => tvp5150 input=0x0, opmode=0x0
tvp5150 1-005c: tvp5150 Set video std register to 2.
ccdc: writing ccdcfg: 0x812
ccdc: configuring SDOFST for 0x249 - two field interleaved   
vpfe-capture vpfe-capture: Setting video standard: 45056
vpfe-capture vpfe-capture: vpfe_config_image_format() MTR: hard coding NTSC 720x480, V4L2_BUF_TYPE_SLICED_VBI_CAPTURE, V4L2_FIELD_INTERLACED; for tvp5150
vpfe-capture vpfe-capture: vpfe_config_ccd_image_format() pix_fmt is configured to: UYVY
vpfe-capture vpfe-capture: hard coding V4L2_PIX_FMT_UYVY: UYVY
vpfe-capture vpfe-capture: successfully set pix format UYVY in ccdc
vpfe-capture vpfe-capture: set frame format: 1, ret: 0
vpfe-capture vpfe-capture: setting fmt.fmt.pix.bytesperline: 1440 fmt.fmt.pix.height: 480 and sizeimage: 691200
MTR vpfe_lookup_pix_format() returning pix_fmts[] for pix_format: NV12
vpfe_check_format found pix_fmt: NV12
vpfe-capture vpfe-capture: width = 720, height = 480, bpp = 1
vpfe-capture vpfe-capture: vpfe_check_format(): returning pix_fmt: NV12, adjusted width = 720, height = 480, bpp = 1, bytesperline = 736, sizeimage = 529920
vpfe-capture vpfe-capture: vpfe_s_fmt_vid_cap(): MTR: v4l2_format type: 1
MTR vpfe_lookup_pix_format() returning pix_fmts[] for pix_format: NV12
vpfe_check_format found pix_fmt: NV12
vpfe-capture vpfe-capture: width = 720, height = 480, bpp = 1
vpfe-capture vpfe-capture: vpfe_check_format(): returning pix_fmt: NV12, adjusted width = 720, height = 480, bpp = 1, bytesperline = 736, sizeimage = 529920
ccdc MTR: writing ccdcfg: 0x812
ccdc MTR: configuring SDOFST for 0x249 - two field interleaved  
ipipe_set_resizer, resizer - A enabled
vpfe-capture vpfe-capture: VPFE Start Capture

  • 0
    TI__Mastermind 43875 points

    Can you share your schematics which show the connectivity of the TVP5150 to the DM365 please?

    Could you also print out a luma ramp which goes from white to black gradually across the page then point your camera at this so I can see how the image behaves with a more controlled image.

    It would also be helpful to fo the same for color ramps of red, green and blue.

    BR,

    Steve

  • 0 in reply to Steve Clynes
    Intellectual 320 points

    Hi Steve,

    I've forwarded the schematics to your email.  Here are the videos of white+rgb ramps.   Looks like the G and B ramps in particular are very messed up in color space.  Apologies for poor quality, I don't have access to an NTSC signal source other than my camera, so I've just pointed it at a monitor...

    Regards, 

    Mitch Rybczynski

  • 0 in reply to Mitch Rybczynski
    TI__Mastermind 43875 points

    Mitch,

    This looks like one of two possibilities.

    1) The data is changing too close to the clock edge which might be causing the previous sample to be captured rather than the new sample. Since luma and chroma are interleaved it can cause the two to be mixed somewhat. It can also cause noise on samples where high order bits change state

    2) The input port needs to be configured correctly to accept data a) on the correct clock edge and b) in the correct format, e.g. YUYV or UYVY.

    A combination of the above 2 possibilities may also be causing the 'noise'.

    My feeling is that it may be a clock issue causing luma and chroma to be effectively swapped some times since if you look at some of the 'flat' areas there are very well defined vertical lines which looks like chroma is being interpreted as luma and since chroma alternates between U & V we see alternating pixels.

    If possible either invert the pixel clock (not sure if this is possible through DM software registers or not but the TVP5150 cannot invert the clock) or delay the clock slightly with a buffer.

    BR,

    Steve

  • 0 in reply to Steve Clynes
    Intellectual 320 points

    Thanks Steve,

     

    It turned out to be our filtering of the input signal to the TVP5150, once we bridged out the filter network here, video was suddenly clear:

     

     

    Regards,

    Mitch

  • 0 in reply to Mitch Rybczynski
    TI__Mastermind 43875 points

    Glad you are now clear.

    Where did you get this filter design from?

    It is preferable to have an anti-alias filter on the inputs. This is not critical, but the image quality will then depend a little more on the video source re-construction filter quality if there is no anti-alias filter on your input.

    BR,

    Steve