• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 539 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.

Lost in a sea of acronyms. SD->HD?

Helmut Forren
Mastermind 6805 points
Other Parts Discussed in Thread: THS8200, CDCE949

I believe my basic question is whether or not the DM6467T can convert SD to HD, "up-convert".  I believe it can, but before going too far down this road, would greatly appreciate any advice I can get!

I'm already somewhat familiar with using the DM6467T EVM (Spectrum Digital HD1080P), and I've completed my SD-only custom board derivation system.

So, already, I receive NTSC->TVP5147->BT.656 in SD format.  My codec receives whole frames at 30 per second.  So, I suspect that the "de-interlace" step is already done for me by default.  I also know that the code I began with was strictly HD.  So I must be able to get back to that point.  I'm thinking I can just have the ARM code submit each codec output frame TWICE to the display queue, and then configure the display side back to HD operation.  That will provide 60 frames per second, which will work for my application.  Note that I don't need motion adaptation or anything else special for my frame rate conversion.  Simply doubling every frame is fine.  Also, regarding image size, I can easily make my custom video analytics codec change the input image size to the output image size while doing all its other work.

This seems just too easy to be true, so I'm wondering where the snafu is hiding!

In more detail, while my analog input really is NTSC, my analog output is perhaps not really "HD".  It might be more correctly called "VGA", VESA compatible at that.  I need to produce analog RGB plus H & V sync, to drive an eMagin micro-OLED.  I had only minor NTSC experience last year when I started on this, and I still don't have VGA or HD experience of any consequence.  The OLED doc simply says it's VESA VSIS compatible.  The OLED supports SVGA, but it has a VGA mode as well.  From what I've been able to glean in my limited time, the analog RGB plus H & V sync signalling is very simple.  

The OLED requires 40Hz to 85Hz frame rate.  So if I simply double my 30Hz NTSC-originated frame rate, I should be good to go.  I'm then just worried about the nature of the data stream and wiring between the DM6467T and the THS8200 I plan to use.  I believe I have a handle on the data stream and wiring from the THS8200 to the OLED.

And then, just recently, I noticed mention of a 74.25MHz clock.  Oh my, I don't know if I need to deal with that or not, because I don't know if my output is really HD, much less if it requires one or two output channels from the DaVinci.

Any suggestions or clarifications for my ill-informed mind?

I do have the EVM, and I plan on trying to get this stuff working, one step at a time, using the EVM.  However, I'm under scheduling pressure to get the pcb schematic and board designed first, so that they can be in prototype fab while I'm working on the software side.  Therefore, it would be nice to understand the hardware requirements first and quickly, before getting mired down in the software setup!

Thanks very much for you assistance,

Helmut

  • 0
    TI__Expert 3925 points

    Hi,

     

    When you get 30 NTSC frames from the capture driver, they are not deinterlaced output. Instead, 2 fields are line-merged into one buffer and given to the application.

     

    VPIF capture and display drivers support SD as well as HD resolutions, SD is a small frame size resolution like 720x480 whereas HD is large image size resolutions like 1280x720. If your codec is giving SD output, you can still display it on HD resolution by position small image on large buffer. You can also display it on SD resolution. THS8200 driver does support SD resolution.

     

    From VPIF point of view, separate sync signals are not supported, you will need some encoder like THS8200 to take embedded sync input and provide separate sync output. I believe you want to display VESA resolutions through VPIF. These resolutions are currently not supported. You will need to add support for them in the VPIF driver as well as in THS8200 driver. Also you will need to change CDCE949 driver to generate required pixel clock. VESA pixel clocks are not same as required by the HD resolutions.

     

    Thanks,

    Brijesh Jadav

  • 0 in reply to Brijesh Jadav80
    Mastermind 6805 points

    Brijesh,

    Hello again.  I hope you're doing well.  Thanks for your help.

    Brijesh Jadav said:

    When you get 30 NTSC frames from the capture driver, they are not deinterlaced output. Instead, 2 fields are line-merged into one buffer and given to the application.

    I am aware of the above.  Since I get 30 whole frames per second from the capture queue, this is just as good as de-interlacing for me.  Then, if I double-submit to the display queue, I should end up with 60 whole frames for my output.  This is good enough for my application.  I don't need interpolation or motion adaptation.

    Brijesh Jadav said:

    VPIF capture and display drivers support SD as well as HD resolutions, SD is a small frame size resolution like 720x480 whereas HD is large image size resolutions like 1280x720. If your codec is giving SD output, you can still display it on HD resolution by position small image on large buffer. You can also display it on SD resolution. THS8200 driver does support SD resolution.

    Thanks for the above info.  Since I'll be working in 640x480, I guess I'm not "HD".  Also, I believed the THS8200 could do SD, and hearing it from you adds confidence.  Actually, since the THS8200 can do both SD and HD, I have increased confidence it can do whatever it is I need (VESA VGA).

    Brijesh Jadav said:

    From VPIF point of view, separate sync signals are not supported, you will need some encoder like THS8200 to take embedded sync input and provide separate sync output. I believe you want to display VESA resolutions through VPIF. These resolutions are currently not supported. You will need to add support for them in the VPIF driver as well as in THS8200 driver. Also you will need to change CDCE949 driver to generate required pixel clock. VESA pixel clocks are not same as required by the HD resolutions.

    The above is where I now need to focus.  I guess I can worry about the software stuff later, but I need to address the clock issue now because it may impact my schematic and board.  My recent NTSC-only product was derived from the DM6467T EVM.  So it still includes the same 27MHz->CDCE949(Y4)->VPIF_CLKIN2 pathway.  My big question here is can that hardware configuration generate the needed VESA VGA clock?  (When I look at wikipedia for "VGA", I see 25.175MHz.)  A quick inspection of CDCE949 datasheet page 25 suggests 25.175MHz = 27MHz/Pdiv x N/M should work perfectly for Pdiv=4, N=1007, M=270.  Wow!  The CDCE949 is pretty flexible.  Perhaps you can confirm my calculations as well as correct me if I have the wrong frequency (25.175MHz).

    So this should mean my hardware doesn't need to change for the purpose of the clock.

    Thanks very much,
    Helmut 

     

     

     

     

  • 0 in reply to Helmut Forren
    TI__Expert 3925 points

    Hi,

     

    You can submit same frames twice to display to get 60fps display using 30fps captured frames, but since frames are captured at 30fps, when you display it on 60fps, you will see jump in the output.

     

    You calculation looks correct for generating 25.175MHz pixel clock from CDCE949.

     

    You can get other timing information for your VESA resolutions from below link.

    http://www.epanorama.net/faq/vga2rgb/calc.html

     

    Thanks,

    Brijesh Jadav

  • 0 in reply to Brijesh Jadav80
    Mastermind 6805 points

    Thanks again.  

    Thanks for the VESA calculator link.  It confirms 25.17MHz, close enough to 25.175MHz and within 198ppm relative to crystal accuracy (which will indeed be better).

    Jumping should not be a problem, but let me rethink that for a moment.  Right now, NTSC doesn't jump.  But is that because we're getting 60 fields per second, and there's display persistence for the alternate non-updated lines?  Ignoring fast panning or moving objects, that cause tearing, ...  Oh, wait.  Maybe the situation is that, for the same slow moving image that did not cause tearing on interlaced NTSC, I won't get jumping (akin to flickering we see below 60Hz) on my output.  But for faster moving images that DO tear on NTSC, I'll get ?jumping? on my output.

    Actually, I think that in situations where the NTSC would tear, I'll get a frame to my codec with jagged edges from that tearing.  Then I'll output those in pairs.  I think what I'll see is BOTH the tear and the jump of the tears.

    I'll ask the project manager about this.  It may be fine for our application.  Otherwise, I have to code interpolation or motion adaptation of my own, which will cost development time, CPU cycles, and heat sink ramifications, or else go back to much more complicated external de-interlacer and frame rate converter.

    Thanks VERY Much for this insight as well.

    -Helmut

  • 0 in reply to Helmut Forren
    Mastermind 6805 points

    Brijesh:

    Five months later I'm back on the project and have my new boards.  I got no new help from the forum.  

    Thanks to your comments back in June, however, I was eventually able to figure it out.  

    You wrote: "I believe you want to display VESA resolutions through VPIF. These resolutions are currently not supported. You will need to add support for them in the VPIF driver as well as in THS8200 driver. Also you will need to change CDCE949 driver to generate required pixel clock. VESA pixel clocks are not same as required by the HD resolutions."

    See http://e2e.ti.com/support/embedded/f/354/p/149931/542030.aspx#542030 for my solution.

    -Helmut