Basic Encoder Questions dm8168

It's easy to miss some of the architecture in a first read of the documentation. Here are some things to keep in mind (I'll be talking about the 'DM8168, though the 'DM8148 is very similar)...

1. There's a pair of minimally documented ARM M3s controlling the HDVPSS. They are called the "Media Controller". You'll probably never see source code for their binary. You talk to them through the HDVPSS driver, or probably a higher abstraction. The latest I heard, the HDVPSS driver source will be going away in the upcoming release.

2. The various video processing blocks aren't tied together in a processing chain like you'd find in some TV input IC. They are tied together with the also mysterious "VPDMA", which shouldn't be confused with the well-documented EDMA. Non-tunnelled architecture, present in the current EZSDK beta release, moves video between the blocks through buffers in RAM. It's also possible to "tunnel" the output of one block to another block, reducing SDRAM activity. The circuitry is generally clocked at higher than the pixel rate, so that the blocks can do a bit of multi-tasking.

3. The datasheet and TRM reflect the capabilities of silicon, not the current state of the software. You need to study the available code too, in order to see what the part can actually do.

3. The HDVICP2s can do most all the repetitive processing for an encode or decode. H.264 encode/decode is supported by the current EZSDK release, but formats are limited. This makes the DSP available for things like motion detection, advanced audio processing, video analytics.. maybe lots of things you don't need.

The architecture is powerful. You can buy the DVR SDK at a nice price, and simultaneously encode and store the encoded data for 16 simultaneous D1 streams. The down side to the Netra architecture is that there are many, many "real-time" tasks going on, with only one VPDMA, maybe two SDRAM banks, three encode/decode blocks, lots of outputs and inputs... so allocation and prioritization of resources ("scheduling") becomes unmanageable without a great deal of work and knowledge of the part's internals. Even if you could do it, TI wouldn't be able to help you if you got stuck.

TI is addressing this by providing standard interfaces, including OMX, GStreamer, Open GL, V42L, etc. This reduces the internal complexity to standard magic, at some loss of capability. Work isn't complete for any of these standards, though major releases of the still-beta EZSDK occur about once a quarter. Don't think of Netra's current state as a finished package for evaluation. TI is sharing their work-in-progress to help you get an early start. The parts aren't yet fully released to production, and the code is still clearly marked "beta".

Right now, with the 'DM8168, the only video/graphics input you can have is non-interlaced component analog video. Interlacing in general is barely supported. One could simply read the posts here and come up with a sizeable list of fairly basic things that you can't currently do. I have a list that is focused on my needs, and I recommend that you keep one for yourself. Initial silicon had personality, and the required work-arounds also limit performance.

Next-stepping silicon exists, and new software releases are imminent and scheduled. It's up to you to study the specs, the wiki, this forum, and the EZSDK to determine whether your application has become feasible, and whether it makes sense to get started anyway.

Note that the DVR SDK has it's own software interface, utilizing a "multi-stream framework", tuned for an SD DVR application. This platform hints at capabilities to come. Z3 makes a board-level "embedded" platform for the 'DM8168. It has hardware and software which is currently more capable than the SDK, though their standard eval offering doesn't include schematics and some of the source code (their goal is to make money, so deals may be possible). There's also a video-conferencing development underway, but its fruits appear to be by invitation only.

I believe that TI has created a really cool piece of silicon that has the potential to do the strange things I have to do, and that TI's software effort is a work in progress that's heading in the fundamentally right direction, at least for TI. It's frustrating to be unable to dig in and do a product yet, but TI is getting close, and I know that when things fall into place, my competitors will be working on the platform, and it will be good if I beat them.

Where are the links? The E2E forum is a good source for status and limitations, and the wiki deals more with defining software use and capabilities. You can start at http://processors.wiki.ti.com/index.php/Category:DaVinci, scroll down, and click on DM816x and DM814x, etc.  in the Da Vinci Directory to get started with your exploration. Some things are well hidden in plain site, like this gem: http://processors.wiki.ti.com/index.php/RoadMap. It's good to keep your own list of favorite E2E threads and other resources.

Disclaimer - I don't work for TI, and have little "inside" knowledge. I do spend a great deal of time here and on the Wiki trying to understand the software's current status. Hopefully, if I've inadvertently fibbed, I'll be corrected shortly.

Best wishes,

-Herb

Hello Herb,

I appreciate your discussion points.  As an active community member myself, I am sure I have inadvertently fibber :) However this is my first dive into the new dm8168 part.

I have worked with the ARM/DSP combo with the dm6467 but I am beginning to the think it is not as similar as I had hope.  My application does not care about how it gets its video input.  In fact it will be a data stream probably over PCIe.  Then I need to be able to point my encoders to the data and then act on the encoded data. 

Have you worked with the older versions - the dm6467?  I am trying to decide how my application will work on the newer parts.  Is there still a codec server that needs to be set up through the codec engine?  Is there still DMAI as the abstraction layer to the codec? 

I am trying to avoid sifting through the new EZSDK for weeks ...

Thanks!

Brandy,

The DM6467T did not have dedicated video acclerators as the DM8168 does. The DSP on the 67T was considered the accelerator whereas we have 'black box' accelerators in the DM8168.

This trivializes the work going on behind the scene, but basically picture the ARM calling a function which configures the DMA to copy the video data from RAM into the accelerator which processes the video and sends the finished result back out to RAM. This detaches the accelerator from the video input so that the accelerator does not care where the video came from. Each piece is independent.

The EZSDK leverages OpenMax (OMX) which replaces the CE model for video codecs used previously; all codecs are validated and supported through this OMX model. I think this link should help answer your question as I understand it, but let me/us know if you still have any confusion.

Tim,

I think I get it.

So just one more clarification.  The 67t says it has "Dual Programmable High-Defination Video Image Co-Processors".  But what you are saying is this is actually the DSP?  But in the 8168, there are 3 HCVICP2s.  And these are not in the DSP but seperate cores inside the chip and are controlled through the OMX (which will be have like the codec engine did before).  Therefore, not only am I not using ARM cycles but I am also not using DSP cycles to encode the data. Is the HCVICP2 its own processor so that I have to use Syslink to talk to it or is it more like a core module inside the ARM (like the EDMA or TSIF was)?

The link you sent, says if I really, really wanted too I could still use Codec Engine and the DSP to do my encoding as I did on the 67t but that would be considered wasteful considering the other resources at my disposal.  Understood.

And will I still use the CMEM? And will there be a DMAI interface to the OMX and CMEM?  Or will I have to dive into the these levels my self?  I also notice that I don't use DSPlink any more but something called Syslink.  Is this basically the same?   I tried to download the EZSDK but I found I have to have Ubuntu.  That seems odd.  i would like to find away around that.

Thanks so much,

Brandy

Brandy,

Brandy Jabkiewicz said:

So just one more clarification.  The 67t says it has "Dual Programmable High-Defination Video Image Co-Processors".  But what you are saying is this is actually the DSP?

Brandy Jabkiewicz said:

And these are not in the DSP but seperate cores inside the chip and are controlled through the OMX (which will be have like the codec engine did before).  Therefore, not only am I not using ARM cycles but I am also not using DSP cycles to encode the data.

Brandy Jabkiewicz said:

Is the HCVICP2 its own processor so that I have to use Syslink to talk to it or is it more like a core module inside the ARM (like the EDMA or TSIF was)?

Brandy Jabkiewicz said:

And will I still use the CMEM? And will there be a DMAI interface to the OMX and CMEM?  Or will I have to dive into the these levels my self?  I also notice that I don't use DSPlink any more but something called Syslink.  Is this basically the same?

Brandy Jabkiewicz said:

I tried to download the EZSDK but I found I have to have Ubuntu.  That seems odd.  i would like to find away around that.