Vdec->Vcap Chain in MCFW

The Vcap/Vdec/Venc/Vdis MCFW "blocks" don't really have anything to do with what the hardware can do or is doing. They are artificial distinctions that may fit some needs, but certainly not all. 

You can use any of the links in any of the pieces, so adding a DEI to the Vcap module isn't a problem, and in fact I think several of the example use-cases have exactly that. I think the Links layer architecture is pretty good, but I would definitely change how the higher-level MCFW is structured. It is not as flexible as I'd like a general-purpose API to be. It builds-in assumptions and references to all the different use-cases, but in the real-world, no one except TI will be using most of those, and few people will be using more than one or two use-cases of any kind.

What we've ended up doing is making serious modifications to the MCFW at several levels, to make it fit our desired structure better. This involved moving pieces between the higher-level blocks and changing the top-level management. I've tried to keep the Vsys layer from having as many connections into the lower layers, so that it would be more modular.

We've also removed all the use-cases except our custom one, because the others are code we'd never use and don't want to have to maintain over the life of the product. This was not a small change, and took several tries before I understood the system well enough to do it right. It also makes merging in new RDK releases a bit of a pain.

In my ideal world, the MCFW would be a thin wrapper managing the links code, with no special knowledge of use-cases. It would just manage startup/shutdown and pass parameters through. All of the use-case setup and teardown code would live in callbacks in the application, rather than in the middle of the RDK, so that a user application could simply link against the RDK. The way things are now, you almost certainly have to make modifications inside the MCFW code if you are doing anything not already covered by a use-case TI supplies.

Also, the use-cases are a highly-coupled part of the RDK, so unless you are writing the TI demo application, you either need to remove large chunks of the MCFW (which means modifications in lots of places), or you need to live with a large amount of code that you'll never use.

I do wish that TI had a bunch of very very simple use-cases that showed how to use the different links. The Links demo code could have been very useful, but they have consistently said not to use it and that it was unsupported. Which is too bad, because you have to understand the Links to make any changes to the MCFW.

Right now, the use-cases cover many of the features of the system, but they are so complex that it has been challenging to extract just the pieces that we needed to build our own. This means that when something doesn't work, it can be hard to figure out why, since the only reference example has so much else going on.

The good news is that you do get all the source in the RDK, so you can make the changes you want, but it is a steep learning curve to really understand it.