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.

DM8148 Component Video Capture

Other Parts Discussed in Thread: TVP7002, PCF8575

I'm trying to capture some HD video through the TVP7002 on the DM8148 EVM. I'm right now using a XBOX 360 configured to 1080P output and connecting the RGB component cables to the EVM ports J8-J10. I have confirmed the XBOX 360 and the cables work by connecting them to a Vizio TV. 

With the connections made, I run the saLoopBack application and get back the error Setting DV Preset Failed. I enabled the "debug" flag for both the tvp7002 and ti81xxvin modules in the /etc/init.d/load-hd-v4l2-firmware.sh script.

With the debugging enabled, I get the messages:

tvp7002 3-005d: detection failed: lpf = 1, cpl = 0
ti81xxvin ti81xxvin: Failed to set standard for sub devices

Looking at the code, this indicates that the TVP7002 was unable to determine the lines per frame (lpf) and colors per line (cpl) and as such the look up in the table of supported resolutions failed.

When I try gstreamer, I get the error ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Could not negotiate format, which from my reading of this[1] thread indicates the same problem as saLoopBack, i.e., it can't figure out what the format of the incoming video is.

Is it possible that my EVM is somehow defective causing this issue? Is there a way of confirm that it's defective? I have another EVM that I will try just to see what happens.

[1] - http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/213275.aspx

  • I will answer my own post. As I had guessed at the end of my previous post, it turns out to be a problem with the EVM itself. I tried a different EVM and I got much better results from saLoopBack..

    tvp7002 3-005d: detected preset: 18
    tvp7002 3-005d: MBUS_FMT: Width - 1920, Height - 1080
    Mode set is 1080P60

    So I'm all set for now..

  • I've observed at 1080p60 that the tvp7002 component input will lock on a couple of different lines per frame, and the way the codec code is written it has to match exactly.  I was able to "work around" it at 1080p60 by disconnecting the input and reconnecting a couple of times until it locked on the frequency that the codec driver was looking for.  I sort of think this is actually a bug in the codec software -- it should be a little more flexible on the locked lines per frame.  Had similar problems with the 720p60 mode, our DVD player is putting out 0x2ED lines instead of 0x2EE lines (in the driver presets tables).  I had to change the driver table to get the codec to accept the input format and press on -- working fine now...

    -MIke

  • Hi,

    You can modify the driver to change this but all registers are implemented keeping standard in mind.

  • In my 1+ day of testing the video, I've found that the XBOX 360 video being output at 1080p60 is properly detected by saLoopBackFbdev each time and the video shows up without any problems. I'm also seeing consistent frame rates of 58-62 FPS which is perfectly fine with me.

  • This type of problem of video not getting detected properly normally happens if base board and IO expansion card is not connected properly.

  • We have 2 units.  Both behave the same.  The units I have came screwed together (at least 7 or 8 screws appear to be holding it together) with the expansion I/O board.  I pulled one all apart and reconnected it (based on some other thread saying the same thing), no difference.

    We are using an HDMI to component converter until HDMI capture is supported, perhaps that is the problem.  At 1080p60 the TVP7002 reports 1125 lines about 50% of the time, and 1124 lines about 50% of the time (based on power up / reset / or disconnecting and reconnecting the component inputs).  At 720p60 the TVP7002 consistently reports 749 lines.  If I force it "on" by messing with the preset tables in the driver, I seem to get good video, but of course you are correct, the standards say that 1125 and 750 lines are what should be expected.  I'm still scratching my head about the behavior, it's probably the converter box.  Sorry for the trouble.

    -Mike

  • Hi,

    For now you can change TVP7002 driver to detect resolution.

  • Hi,


    We are having the same issue with 8168 EVM.


    Tried with:

    1) saLoopBack(EVM images on EVM)

    2) DVR RDK MCFW API (DVR RDK images on EVM) (Added tvp7002 driver to mcfw)


    Both the cases:

    detection failed: lpf = 1, cpl = 0

    is seen.

    Looking at this post it seems that the problem might be with the EVM.

    Currently we just have one EVM. Is there a way to make this work with our current board.

    8168 EVM:

    Spectrum Digital Board

    REVISION J

    IO EXPANSION CARD

    REVISION C

  • Hi Tushar,

    Are you using discrete sync input? If not, EVM can not cause incorrect frame size. it has to be in your decoder.
    If yes, again delaying vsync by 1650 or 2200 clock cycles is way too much. I don't think EVM can delay this much. it must be something in your TVP7002 configuration or in your hdmi to component decoder..

    Rgds,
    Brijesh
  • Hi Brijesh,

    We are using Embedded sync.

    We have tried different register configurations for tvp7002 found from various sources online.


    Still detection "failed: lpf = 1, cpl = 0 " error persists.

    We used a Oscilloscope to detect VGA signals. In this case analog video is going from VGA connector to TVP7002.
    Beyond this there is no output clock, no output video.

    Is there any "bare minimum" register setting that can be done without running the TVP7002 driver that would enable video capture from TVP7002 to VIP.

    Please suggest.
  • Hi,

    I can help you in VIP, not in TVP7002.

    Rgds,
    Brijesh
  • Hello,

    Tushar Nautiyal said:

    1) saLoopBack(EVM images on EVM)

    2) DVR RDK MCFW API (DVR RDK images on EVM) (Added tvp7002 driver to mcfw)

    What you is the software release that you are using here since the saLoopBack demo is part of EZSDK and it is using v4l2 capture/display driver?

    Have you checked are the base board and IO expansion card is connect properly, as Hardik posted?

    BR
    Margarita

  • Hi Margarita,

    The version of ezsdk we are using is: 5.05.02.00

    By IO Expansion card, I think you mean the pcf8575.

    Previously we were trying to port DVR RDK on 8168 EVM. In that case, setup code for a use case in DVR RDK configures pcf8575.

    when using v4l2 capture driver we do not see any initialization for pcf8575. Does it happen in "board init" or we have to do it externally. Can you give any pointers regarding this....

    Thanks
    Tushar Nautiyal
  • Hi,

    We have been able to configure pcf8575 correctly and tvp7002 is reporting 1125 lines per frame at 1080p.

    Now while using saLoopBack to stream the video on HDMI port we are getting a yellow screen(we can see it getting refreshed while the application is running).

    We think, at saLoopBack.c level all instances of display1 should be replaced by display0 because we are using HDMI output.

    Other than that what changes are we supposed to make in saLoopBack.c for this ti work.

    Thanks
    Tushar Nautiyal
  • Hello,

    In the default SaLoopBack demo
    #define DISPLAY_DEVICE "/dev/video1" is configure.
    You could check this guide:
    processors.wiki.ti.com/.../TI81XX_PSP_VPSS_Video_Driver_User_Guide

    BR
    Margarita
  • Hi Brijesh,

    Need some help with VIP, specifically ti81xxvin_main.c:

    Trying to run saLoopBack application for Capture and Display (v4l2).

    Capturing on "/dev/video0" which is connected to VIP0 Port A,

    which in turn is connected to one of the TVP7002s which is at 0x5D i2c address.


    When our application starts the capture - display while loop it gets stuck in the VIDIOC_DQBUF ioctl.

    To see what might be causing it we opened the device with O_NONBLOCK and found that errorno = 11 (EAGAIN) is returned.



    Next we tried printing the state of the buffers inside the vidioc_dqbuf(...) function in ti81xxvin_main.c by using this:

    buf_obj->buffer_queue.bufs[i]->state


    The state printed is 2, which corresponds to VIDEOBUF_QUEUED.



    Our interpretation is that for some reason video frames are not moving from VIP0 Port A to the Queued Buffers. Hence, there might be nothing to DeQueue.



    saLoopBack detects video on tvp7002 and using CRO we were able to determine somewhat that frames are reaching VPSS(VIP0 Port A).



    Can anyone please suggest what might be the problem with this. What are we missing. Anything to do with VDINTx, and if yes how to figure it out.

    Also, we tried putting a printk in ti81xxvin_poll(...) function. It never gets printed.

    How does frame coming to VIP get stored in buffers queued through qbuf, to be later dequeued using dqbuf.


    One last thing, till a few days back the application used to complete the whole while loop (10,000 - default), it was just that the video was all yellow screen. Then, suddenly this VIDIOC_DQBUF error started coming.

    Thanks
    Tushar Nautiyal