• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 100 subscribers
  • Views 628 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.

Can we input 4x720p60 into VIP1 and VIP2?

Anjli Behl
Prodigy 715 points

HI DM8168 Champs,

can you pls validate this use case

We where planning on using the DSP to encode four 720p60 video source at the same time. From what I see in the documentation, the DSP can have 4x8Bit video input on the two video ports (two independently clocked 8 bit video per video port). Normally a resolution of 720p60 has 16 bits of video (8 bit Luma and 8 bit Chroma) with a pixel clock of 74.25MHz. If we convert this 720p60 to an 8 bit video using a clock at 148.5MHz with the luma and chroma multiplexed on the same 8 bit video, we could provide four 720p60 on the two video ports. Each video would have a clock frequency of 148.5MHz which is within the 165MHz clock frequency limit of the Netra.

 

Will this application work the way we think?

  • 0
    TI__Guru 66230 points

    Yes, you can use 8bits port of VIP1/2 to capture four 720p-60 stream.

    Regards,

    yihe

  • 0 in reply to yihe
    Prodigy 50 points

    We are in the process of trying to do this ourselves.  We have a DM8167 feeding out 720p 16 bit video.  We feed this into an FPGA that multiplexes the 16 bits into an 8-bit bus, doubles the clock and feeds this to a second DM8167.  We are not getting the second DM8167 to recognize this video.  One of my concerns is when we multiplex the 16 bits to 8 bits we'll get redundant SAV/EAV.  Won't this confuse the DM8167?  Is there any documentation that describes in detail how the DM8167 wants to see the video in this scenario?  Maybe I need to discard/switch in a different value for the EAV/SAV in the Chroma?  Any help would be appreciated.  I guess i'm wondering if the DM8167 wants to see BT.656 timing information or if this multiplexed BT.1120 data is OK?  Thank you.

  • 0 in reply to Roger Leopold
    TI__Mastermind 20245 points

    Hi,

    It should be BT656. So you should get rid of redundant EAV/SAV codes. Else DM8167 wont be able to recognize it. While multiplexing you should take care to throw away EAV/SAV from either chroma or luma to make it like BT656.

    Regards,

    Hardik shah

  • 0 in reply to HardikShah
    Prodigy 50 points

    Thank you for the quick reply.  I'll try to implement this today.

  • 0 in reply to Roger Leopold
    Prodigy 50 points

    Have not gotten this to work.  Have multiplexed the data as discussed.  If anyone has details on how they've accomplished this we would appreciate that.  Since this is not really a "standard" viedo format I would think the code would have to be changed to recognize it?  I'm guessing for an 8-bit format the part is only set up for maybe 480i/576i and maybe 480p but probably not 720p.  An more information would be appreciated.  Register settings for running at twice the pixel rate etc..  Thank you.

  • 0 in reply to Roger Leopold
    TI__Guru**** 477995 points

    Hi,

    Could you please check if multiplexing of SAV/EAV code is done correctly?

    Instead of

    0xFF 0xFF 0x00 0x00 0x00 0x00 0x00 0x00 0xXY 0xXY codes,

    it should be

    0xFF 0x00 0x00 0xXY

    As hardik/yihe said earlier, for 8bit mode, input streams has to be in BT656 mode.

    Thanks,

    Brijesh Jadav

  • 0 in reply to Brijesh Jadav
    TI__Mastermind 20245 points

    Further make sure that you drive pixel clock at double the rate. Means for 720P60 you should be driving pixel clock@ 148.5MHz instead of 74.25MHz. There are no register settings for dual pixel clock.

    Regards,

    Hardik Shah