[IPNC RDK] McFW API vs. Link API

I wrote some thoughts about using the RDK here:

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/200316.aspx

In general, if your design matches the MCFW architecture fairly closely, then adapting an existing usecase is probably easier than doing things from scratch with Links, although there is a lot of stuff you need to know if you really want to understand what is happening. I think the intent with MCFW usecases is "lots of our customers need something almost like one of these", and in those cases the customer can save time by tweaking existing code. But I really wish they had made it more flexible and separated the core functionality from the use-case specifics. As it stands, you end up with all the code for all the different use-cases compiled into your system, even if (as is likely) you are only using one. You can chop the unused pieces out, but it gets pretty ugly.

If your design doesn't match the flow or modular breakdown (capture, encode, decode, display, with simple connections between them), Links is probably easier, or at least you won't need to understand the entire MCFW framework and then make a branch of it for your system, which is cumbersome and difficult to manage over multiple MCFW releases. You need to understand how links work in any case, since the MCFW usecases all use links to do the actual work of constructing the dataflow.

TI doesn't really provide support for using just Links, so you should take that into consideration as well. 

Hi Brett,

Thank you very much for taking the time to share some detailed thoughts on this -- I really appreciate it!

I'm currently working with the IPNC RDK 3.0.0, and am struggling to find any high level overviews of the use cases (or any substantial documentation on the underlying architecture of the use cases, for that matter).  I gather that some other RDK (the "DVR RDK"  as opposed to this "IPNC RDK") has some sort of Usecases.pdf document that I assume presents an overview -- can anyone confirm/deny this?

At any rate, I'm finding myself just digging through the the use case source just to figure out what each use case does, which obviously requires that I get up to speed on the Link API.  At this point, I might as well just tough it out and develop at the Link API level. 

I'm not familiar with the IPNC RDK, but I'm surprised they didn't include the usecase docs in it. In the DVRRDK, the usecase docs are in dvr_rdk/docs/Usecases. Maybe you can get a copy of the DVRRDK and see if the docs there are helpful? There is also a "Trainings" directory under docs that has an overview of MCFW and Links. I would expect that much of that info would apply to your RDK as well. It certainly doesn't have everything you need, but it is at least something to start with.

Hi Brett,

Thanks for verifying!

After quite a bit of searching, I'm positive that the IPNC RDK 3.0.0 does not have a standalone Usecases document.

There is an User Guide document that has a couple link diagrams of what  I believe to be a subset (3) of the usecases. I was hoping the remaining use cases (in particular, the ones for the 8148EVM) would have at least some brief documentation.

Could someone from TI comment on this? Perhaps a document or two didn't make it into the release tar.gz's?

Thank you!

Jon

Hi Bret,

maybe you can help me in some understanding of the following RDK issue. I'm using rdk 3.0 for DM8168, and the issue of non dynamic parameters (static parameters) is very problematic in my case: as I understand I need to stop the whole chain (encoding chain or decoding chain) in order to change parameter of some channel. This mean that I need to stop other channel. Are you familiar with that ? for example: encoder codec type is not a dynamic parameter. this means that changing codec type for channel 1 means that I stop and start all channels.   Is there anyway to overcome this interfere between channels ? Is it a hardware limitation ? where ? we have enough codec engine for all so where is this limitation reside ?

Thank you,

Ran

I'm afraid I can't help very much with this one. I suspect that you are correct, for non-dynamic parameter changes you are going to have to stop and restart the entire chain, but I don't know that for sure. We are using an 8148 and RDK 2.80, and I have not tried to change codec types on the fly. But because of the way the RDK is constructed for multi-stream handling, I don't think you can easily change just one stream.

One alternative you might consider is having both codecs running all the time, and just picking the output from one or the other as needed. We're doing something like that in our system, where we dup the input stream, send it to codecs at different bit rates, and use the output from one or the other.

Hi Brett,

I considered your method, but also another method of disable/create channel, which already exist in decoder Link, but not in encoder Link. If I will add support in code for disable/create channel, than without any further changes in usecase, I can achieve the same result (dynamic update of map table + disable/create channel with new parameter should be an alternative solution I believe).

you can read more about this considerations in the following thread:

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/p/213251/764224.aspx

Thanks,

Ran