Hello,
We're using a custom input board to drive the Video Input Ports of the DM8168. With the RidgeRun omx_camera extensions for gstreamer, we can stream 1080p30 video from an HDMI source on Video Input Port 1 using 16-bit capture mode. Of course, we can also record using the TI capture_encode demo.
We're having problems, however, capturing NTSC bt.656 embedded-sync video on Video Input Port 2(A) with 8-bit mode. The NTSC decoder is the TVP5151, similar to the ever-popular 5150 and we're confident we have the chip configured for bt.656 embedded sync and we're confident we're clocking at 27 Mhz. When I switch the omx_camera or capture_encode demo to 8 bit mode and VIP2_PORTA, it hangs... never receiving any frames.
Are there other OMX configuration widgets I need to play with?
Looking around, I've found similar issues but little guidance:
http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/157094.aspx : Shows some success with external syncs, but not embedded. Our hardware design does not allow us to switch to external syncs, so I can't duplicate those results.
http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/t/154092.aspx : Provides some suggestions on ACTVID manipulation, but again appears to apply to external sync only.
http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/159862.aspx : Not sure it's relavant, but this indicates problems with 4:2:2 support at the VFCC layer. I don't have source code, so cannot confirm or deny.
One additional note: From what little I know, bt.656 uses UYVY byte ordering, but VFCC can only be configured for OMX_COLOR_Format24bitRGB888 or OMX_COLOR_FormatYCbYCr (YUY2). Could that be causing timing problems? I would have expected video with wonky colorspacing rather than no video at all, but I'm already way past the edge of my useful knowledge, so can't say with certainty if this is a problem or not.
Thanks in advance for guidance or suggestions.
Dave