ADV7403 ADV7842 and ADV7850 chips

I am about to start a composite and s-video signal digitization project. Before i get started i need to establish which of your chips to use. I may as well start with what ever your current chip is as I may have been reading old internet webpages.

I have been looking keenly at your ADV7403 chip. Can you tell me whether this has been updated by your ADV7842 and ADV7850 chips and are there even any later chips than these? I could have easily missed something on your website.

Outputs required are digital(s-pdif)  for PC card capture and HDMI for the TV.  I will also require the 3D comb filter and TBC facilities mentioned for these chips in your datasheets. I will also require stereo inputs for the HDMI TV output.

Thanks

Steve

Parents
  • The ADV7842 has an input HDMI port and the ADV7850 has both input and output HDMI ports.  The analog sections are very similar. Both have 3D comb and TBC.  TBC was used to correct issues with old VCRs so I'd be surprised if you need it for modern systems.

    The ADV7403 does not handle HDMI directly.  It only has a digital input port, not HDMI decoding.

    If you need HDIM input and output plus analog decoding plus audio insertion I'd look at the ADV7850 single chip solution.  The ADV7842 is great where you need HDMI input and analog decoding feeding an FPGA or a ADV7511.  Note  these chip only handle HDMI 2.0 spec.  Do you need to handle HDMI 2.1?

    Also keep in mind you will need to be an HDMI and HDCP adopter to use these chips with HDCP keys.

    If you can include a list of supported inputs and outputs with formats required we can point you to a possible solution. 

  • Thank you very much for your informative reply. What i need to do first is to get the chips sorted out.

    input signals

    I have 2 input analogue Video signals to process:-

         1) composite (CVBS) from a laserdisc player
           1.1) Hence the need for an excellent comb filter to split this composite signal into its S-Video Y & C signals.

         2) S-video signal from VHS players
            2.1) And from the Lasedisc Y&C signal just mentioned
            2.2) VHS players - Hence the need for a TBC.

    Output signals

     I need 2 output signals:-

         1) Digital output signal for input into a computer PC capture card.
     
         2) HDMI output signal for input into a TV
            2.1) This will also need stereo input sockets to take the audio signal from the 2 input sources above.  

    What Chips do i need?

    How does the above translate into chips? And this is where i need your help. Can you sort me out here.    

    first possibility. Have 2 seperate chips in use on 2 seperate boards:-

         1) ADV7842 to take the input sources listed above and create a digital output signal for input into a computer PC card .
         2) ADV7850 to take the input sources listed above and create an HDMI signal for input into a TV.

    second possibility. Have 2 connected chips available:-

         1) ADV7842 to take the input sources listed above and create a digital output  for input to a PC card and ADV7511
         2) ADV7511 to take the digital output from the ADV7842
            2.1) to create the HDMI output signal for input into a TV.       

    I have a problem with the ADV7511 - its datasheet does not show an HDMI output connection. Can you update me on this.

    HDMI 2.0 will do the job very nicely.

    Hope the above makes sense. If i have anything wrong then please correct me on it.

    Thanks

  • 1) The ADV7511 outputs HDMI so it will work with either PC capture cards or TV's

    2) You do not need HDCP keys to output to TVs.  HDCP keys are only requested from TVs if the source requests them and analog sources will never request them.  So no key problems.  The ADV7511 comes with keys but since the 7511 is only a transmitter, the powers to be don't care if you transmit encrypted or plaintext.  You can turn it on and off as needed.  Now the powers to be do care about receivers with keys since with them you can violate copyright rules.  Bottom line is TVs don't care, they'll display plaintext video just fine.

    3) DDR == Dual Data Rate, SDR == Single Data Rate.  Basically SDR present new data on only a rising or falling clock edge while DDR presents new data on both clock edges.

    4) Capture cards can replace the dongle.  I just though a dongle would be more more convenient then opening up a PC to install a PCI card.  (Hard to do on a laptop also)

    5) Basically the ADV7511 is just a parallel to serial converter.  For video streams compression only occurs when you do 444 to 422 conversion, the pixel colors are compressed from 8 bytes down to 4 bytes.  This conversion can be disabled.

    6) RGB444 over HDMI will display on TVs.  

    7) The USB port on the eval is a control port only and has been deprecated.  Now we only recommend using the serial port for control.  (Software issues).  It cannot carry video.

    8) BIG IDEA.  The hard part is writing a 36 bit stream to a memory card.  This is what the capture cards/dongle do.  Remember video is a continuous data stream while USB to memory transfers are block transfers.  How do you convert a continuous streams into block transfers.

    I think I addressed most of the questions.  

  • AnNother great answer. It's all coming together at last! It looks like i can get everything i want out of your evaluation board.

    I think thats about all on the video side.

    I wish to start a new series of AUDIO Q/A as this video one is getting long 

    Big idea  - take 2

    I appreciate what you said about writing a 36 bit stream program but applications like nchsoftware and Cyberlink Power Director do it so the question is how. The real problem here is not to let the writing to disk of the recorded input stream  interrupt the recording of the input stream so the write to disk function would have  to be a lot faster than the recording of the input stream.

    This takes me back to my programming days where, when running the programs i had written, they would be given a number of input buffers by the OS which would be filled and controlled by the OS.  As you said, this is a block driven process. The applications i mentioned must be using a similar technique of having a number  of input buffers which the application will have  to empty a lot faster than the input stream can fill them up.

    How could this be done?

    This is a conceptual solution.

    Lets start with the USB PCIe caddy i mentioned at 10Gb/s with a USB 3.2 gen 2 (or whtever it is) on the PCB  that can write at something approaching 10Gb/s.         

    The program to record and write the input stream:-

        1) has, lets says, 6 buffers at, lets say, 32KB.

        2) the buffers are in ram (the evaluation board DDR chip or an upgraded or dedicated  memory chip)

        3) When  a 32KB buffer is full the program moves onto the next buffer and the full buffer is written to disk (the PCIe drive i have just mentioned). Each full buffer has now become a "block"
     
        4) The  32KB of a full buffer could be written to PCie disk all at once or, if such a large write to PCIe would interupt the recording of the input stream, at smaller amounts, lets say 4KB, that could make use of microsecond gaps when the input stream is not being recorded to a buffer.

        5) the program cycles around these 6 buffers sequentially.

        6) Making sure the buffers are empty before they are required again is the clever bit.  
     
    An alternative is to write the input stream straight to PCIe card which would save a lot of messing around with buffers and memory and, providing the write  to PCIe is faster than the rate at which the input stream is arriving, would be a very neat solution.

    How about a Thunderbolt 4 connection straight to a PCIe card, ie miss out USB altogether!  

    Whats recorded on the PCIe card is a single file, lets say 300GB of yuk.

    On completion of the recording the PCIe caddy is transferred to a computer where there is a program that can format the 300GB of yuk into a raw file of, lets say, 80 byte dif blocks (80bytes seems a bit small to me).  The point about the raw file is that it can now be be editted by an appliction that can process raw files.

    This is not a bad system with all parts of the process, capture ->  format -> edit, split up into separate jobs. The capture part, which is the difficult and partly unknown part of the process, has been well and truly isolated from the rest which can now proceed at a more leisurely speed.  

    OK, its a thought

  • All PC capture cards (let's use pexhdcap60l2 as an example) will have some sort of frame buffers that they ping-pong back and forth to capture video streams using an ASIC or FPGA.   Then it normally compresses the video stream into H264 format and then sends the packets over the PCIe interface to the main memory.

    I believe H264 can be set as lossless.  Compression still happens, you just don't lose any raw data.  Once in main memory you can decompress it back to RGB.  I just don't know of any video RGB file formats.  The video editors only work with files in main memory, not directly with the capture card.  It may look like editors work directly with the capture card however the the video is just moved in smaller blocks then an entire file.  (Something similar to pipes)

    video --> capture --> compression(H264) --> PCIe --> main memory --> video editor

    You can't sent video directly to main memory over PCIe.  PCIe is a bus and must be shared so PCIe packets must be created and sent only when the bus is free.  This is what the PCI interfaces do.

    Thunderbolt is similar to USB except its specs include video transmission.  All video is packetized. (Uses the same USB-C connector)

    On another note, originally we started with digitizing S-Video VCR outputs.  The S-video output my only use an 8-bit DAC.  You don't need 12-bit of data to capture an 8-bit source.  Nothing is gained by the extra 4-bits, it's just noise at best.

    If you want to start talking about audio then please start another thread, this one is kind of long already and really dedicated to video.

  • Do you have a parametrics list for ADC only chips. I still require 192/24bit with I2S out . I no longer need DAC facilities.

  • Audio CODECs can be found here

    https://www.analog.com/en/parametricsearch/11357#/

    CODECs come with output DACs but you don't have to connect or use them them.  The key you are looking for is I2S bus, 2 input channels (ADCs) and 192k sampling rate.

Reply Children
No Data