Cisco Headend System Release 2.5 User Guide

4011043 Rev B 

Introducing Cisco’s OCAP Object Carousel Solution:  

1-11 

   

The TSBroadcaster 

 

Functional Overview, Continued 

The TSBroadcaster can signal approximately 130 modules in a single Download 

Information Indication (DII). Prior to TSBroadcaster 1.03, all carousels contained 

only a single DII. In TSBroadcaster 1.03 and beyond, you can define multiple DIIs to 

allow a larger number of modules. We do not provide recommendations beyond 250 

supported modules.  
You can identify the current number of modules by using the feature “Download 

Latest Build” and counting the module entries in the “stream-control” file. Future 

versions of the TSBroadcaster will contain an enhancement in this area. 

There is no minimum file size for applications. The maximum size is limited by MHP 

specification at 254 sections (slightly more than 1 MB). Some non-compliant OCAP 

stream generators allow some non-compliant receivers to receive files that are 

greater than 1MB. There is a change request being raised to change the OCAP 

specification to allow files larger than 1MB with the correct signaling.  A directory is 

limited to less than 512 entries. 

HD set-tops can support up to 19.4 Mbps, average, and the peak bit rates are allowed 

to spike up to the limit of the data channel (typically 38.811 Mbps). 

Performance depends on the behavior of the application, the available bit rate, the 

size of the application, the characteristics of the receiver, and the particular aspect of 

performance you are measuring. 
You can enhance startup performance by separating content needed at application 

startup into a separate group and giving it a higher priority than other content. If an 

application contains class or uncompressed data files, compressing them may 

improve performance by reducing the size of the data to be broadcast. Compressing 

graphics files (assuming they have been properly optimized for broadcast) generally 

does not provide any significant compression and may be counter-productive as the 

receiver has to decompress the content when it receives the module. You should 

place content that can be compressed in groups with compression selected.  Content 

that cannot be compressed should be placed in separate groups. 
If an application cannot be entirely cached in receiver memory, then the performance 

may be improved by placing content that is required often or that is needed for 

startup into groups with increased priority. This setup will increase the frequency of 

this content at the expense of other content, and thus may improve performance by 

shortening the acquisition time of that content. However, the acquisition time of 

other content will be lengthened.