Mosaic in context of Video Display / Incomplete OpenMAX Source Code

Seems something went wrong with my browser and it forgot to add the remainder of my answer :).

Mosaic in display means the ability show multiple data streams on the same display device simultaneously. In the OMX context, that would mean , being able to feed input buffers via multiple input ports and having all of them being simultaneously displayed say on HDMI.

Currently due issues with  Silicon bugs, this is deprecated in the 816x/814X devices. A software mosaic component is under dev to partly offset this loss of feature. This will be multiple input port, single output port component. The display component can then taken in the output buffers of this component to give a 'mosaiced' display.

For access to full OMX source code, please contact your local TI representative.

Archith

_Ralph_ said:

On a related note, is the multi-stream input pixel-to-pixel and line-to-line input demultiplexing operable in the latest EZSDK/PG 1.1 DM8168? How many D1 multiplexed streams can I input into 1 VIP port? I have seen a figure of 16 but I am not sure if this is for each of the 2 HD capture ports or for both combined.

The SoC is certainly capable of doing pixel muxed and channel muxed capture. 4 channels of D1 can be muxed into a single VIP port. As there are 4 VIP ports , we get the number 16.

The EZSDK is not suitable for high channel desnity usecases and hence doesnt support the above features. There is a DVR reference design kit which enables these usecases. Please get in touch with your local TI representative for more details regarding this.

_Ralph_ said:

are all the binaries that are in the "omx" folder in the EZSDK only for the Media Controllers? Are any of them used or linked in for use on the ARM Cortex A8 GPP?

I understand that your question is whether the source code is present in EZSDK for every omx library linked into the A8 executables. The answer is yes. Please let me know if this does not answer your question.

Archith

_Ralph_ said:

Okay, what is the best I can do in terms of the number of D1 channels on a single VIP with the bog standard EZSDK?

You can actually do 4 channels of capture via a single VIP even in the EZSDK. For the VFCC component, that would mean 4 outport ports giving out data.

When the Capture driver on Linux/A8 comes in the EZSDK 5.03, you should be able to interface a decoder capable of muxed 8-bit capture (say TVP5158) to pump data into the VIP port you need.

The only concern would be  the A8 overhead will scale according to the number of channels you capture as the number of FTB and FillBufferDones go up. So streching this to 16 channels will have huge performance costs on A8.

Archith