metaonly module ti.sdo.ce.examples.codecs.videnc1_copy.VIDENC1_COPY

VIDENC1_COPY codec specification

This file specifies information necessary to integrate with the Codec Engine. [ more ... ]
XDCspec summary sourced in ti/sdo/ce/examples/codecs/videnc1_copy/VIDENC1_COPY.xdc
metaonly module VIDENC1_COPY {  ...
    // inherits ti.sdo.ce.ICodec
XDCscript usage meta-domain
var VIDENC1_COPY = xdc.useModule('ti.sdo.ce.examples.codecs.videnc1_copy.VIDENC1_COPY');
module-wide config parameters
    const VIDENC1_COPY.ialgFxns// Name of xDAIS alg function table = String "VIDENC1COPY_TI_IVIDENC1COPY";
 
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true
    ];
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true
    ];
    VIDENC1_COPY.stubFxns// Name of stubs fxn table = String "VIDENC1_STUBS";
module-wide functions
 
XDCspec declarations sourced in ti/sdo/ce/examples/codecs/videnc1_copy/VIDENC1_COPY.xdc
 
metaonly module VIDENC1_COPY inherits IVIDENC1 {
module-wide config parameters
    readonly config VIDENC1_COPY.Module alg//  = VIDENC1_COPY.module;
    override readonly config String ialgFxns// Name of xDAIS alg function table = "VIDENC1COPY_TI_IVIDENC1COPY";
    override readonly config String idma3Fxns// Name of xDAIS alg IDMA3 Interface function table = "VIDENC1COPY_TI_IDMA3";
 
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true
    ];
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true,
        true
    ];
    override config String serverFxns// Name of skeleton fxn table = "VIDENC1_SKEL";
    override config String stubFxns// Name of stubs fxn table = "VIDENC1_STUBS";
module-wide functions
}
DETAILS
This file specifies information necessary to integrate with the Codec Engine.
By inheriting ti.sdo.ce.video1.IVIDENC1, VIDENC1_COPY declares that it "is a" video 1.0 encoder algorithm. This allows the Codec Engine to automatically supply simple stubs and skeletons for transparent execution of DSP codecs by the GPP.
In addition to declaring the type of the VIDENC1_COPY algorithm, we declare the external symbol required by xDAIS that identifies the algorithms implementation functions.
 
config VIDENC1_COPY.alg  // module-wide
XDCscript usage meta-domain
const VIDENC1_COPY.alg = VIDENC1_COPY.Module VIDENC1_COPY.module;
 
 
config VIDENC1_COPY.ialgFxns  // module-wide

Name of xDAIS alg function table

XDCscript usage meta-domain
const VIDENC1_COPY.ialgFxns = String "VIDENC1COPY_TI_IVIDENC1COPY";
 
DETAILS
All xDAIS algorithms must define an IALG_Fxns structure that contains implementations of the IALG methods. This configuration parameter is simply the extern name of this structure.
 
config VIDENC1_COPY.idma3Fxns  // module-wide

Name of xDAIS alg IDMA3 Interface function table

XDCscript usage meta-domain
const VIDENC1_COPY.idma3Fxns = String "VIDENC1COPY_TI_IDMA3";
 
DETAILS
All xDAIS algorithms that use DMA must define an IDMA3_Fxns structure containing the pointers to functions implementatng the IDMA3 interface. If algorithm does not use DMA this structure does not have to be defined.
This configuration parameter is simply the extern name of this structure when defined, null otherwise.
 
config VIDENC1_COPY.iresFxns  // module-wide

Name of xDAIS alg IRES Interface function table

XDCscript usage meta-domain
const VIDENC1_COPY.iresFxns = String computed value;
 
DETAILS
All xDAIS algorithms that use an IRES resource must define an IRES_Fxns structure containing the pointers to functions implementatng the IRES interface. If algorithm does not use an IRES resource this structure does not have to be defined.
This configuration parameter is simply the extern name of this structure when defined, null otherwise.
SEE
 
config VIDENC1_COPY.rpcProtocolVersion  // module-wide

Version of the Protocol used between the stubFxns and the serverFxns

XDCscript usage meta-domain
const VIDENC1_COPY.rpcProtocolVersion = Int 0;
 
DETAILS
This is set by a particular implementation of a stub/skeleton RPC pair, and is used at runtime to ensure the protocol matches. This is important, for example, to ensure that the protocol used by skeletons built into a server matches that used by the stubs built into the application. Specifically, this is typically changed when the marshalling/unmarshalling message format changes.
This is generally not configured by application or server config scripts, but rather by developers of VISA-like API class extensions.
This rpcProtocolVersion is built into the local application executable, as well as the remote server's executable.
Developers of class extensions should ensure this config parameter is set appropriately by each release of their stubs/skeletons. If a new protocol is introduced, implying that updating both would result in error, the number should be incremented.
There is no "backward-compatibility" requirement in rpcProtocolVersion. If the version is different, regardless of whether it's larger or smaller, the creation of algorithms of this class will fail.
 
config VIDENC1_COPY.manageInBufsCache  // module-wide

Codec Class configuration param

XDCscript usage meta-domain
VIDENC1_COPY.manageInBufsCache = Bool[16] [
    true,
    true,
    true,
    true,
    true,
    true,
    true,
    true,
    true,
    true,
    true,
    true,
    true,
    true,
    true,
    true
];
 
DETAILS
Determines whether cache will be managed on the DSP for each of the (up to 16) input buffers given to the codec's "process()" call.
If this flag is set to "false" for one or more elements, the cache for the corresponding input buffer will not be invalidated before the process() call. Skipping unnecessary cache invalidation improves performance, especially if a buffer is large.
(If element "i" in this array is set to true, cache for inBufs[i] will be invalidated only if the buffer is supplied, of course.)
For example, if you know that a particular codec of this class always reads the data from its inBufs[1] buffer only via DMA, you can set manageInBufsCache[1] = false;
 
config VIDENC1_COPY.manageOutBufsCache  // module-wide

Codec Class configuration param

XDCscript usage meta-domain
VIDENC1_COPY.manageOutBufsCache = Bool[16] [
    true,
    true,
    true,
    true,
    true,
    true,
    true,
    true,
    true,
    true,
    true,
    true,
    true,
    true,
    true,
    true
];
 
DETAILS
Determines whether cache will be managed on the DSP for each of the (up to 16) output buffers given to the codec's "process()" call.
If this flag is set to "false" for one or more elements, the cache for the corresponding output buffer will not be invalidated before the process() call. Skipping unnecessary cache invalidation improves performance. Whether the buffer will be written back after the process() call depends on the algorithm and cannot be controlled here.
For example, if you know that a particular codec of this class always writes the data to its outBufs[2] buffer only via DMA, you can set manageOutBufsCache[2] = false;
 
config VIDENC1_COPY.serverFxns  // module-wide

Name of skeleton fxn table

XDCscript usage meta-domain
VIDENC1_COPY.serverFxns = String "VIDENC1_SKEL";
 
DETAILS
All algorithm's that can run on a remote processor must specify a set of "stub" functions that marshall arguments to send to the remote process that runs corresponding "skeletons" to do the actual processing. This configuration parameter defines the entry point for this algorithm's the skeletons (which run on the remote processor).
This is generally not configured by application or server config scripts, but rather by developers of VISA-like API class extensions. However, an application or server integrator could use this config param to configure in custom serverFxns.
SEE
 
config VIDENC1_COPY.stubFxns  // module-wide

Name of stubs fxn table

XDCscript usage meta-domain
VIDENC1_COPY.stubFxns = String "VIDENC1_STUBS";
 
DETAILS
All algorithm's that can run on a remote processor must specify a set of "stub" functions that marshall arguments to send to the remote process that runs corresponding "skeletons" to do the actual processing. This configuration parameter defines the entry point for this algorithm's the stubs (which run on the local processor).
This is generally not configured by application or server config scripts, but rather by developers of VISA-like API class extensions. However, an application or server integrator could use this config param to configure in custom stubFxns.
SEE
 
config VIDENC1_COPY.useCache  // module-wide

If set to true, the codec's memory requests will be allocated from cacheable memory. If set to false, the memory will be allocated from non-cached memory. If this is not set, the ti.sdo.ce.alg.Settings.useCache flag will determine whether the codec's memory will be allocated from cached or non-cached memory

XDCscript usage meta-domain
VIDENC1_COPY.useCache = Bool undefined;
 
 
config VIDENC1_COPY.uuid  // module-wide

Unique algorithm implementation ID

XDCscript usage meta-domain
VIDENC1_COPY.uuid = Int undefined;
 
DETAILS
This integer must be a unique ID for every algorithm in a "system", where the "system" includes all possible DSP Servers.
This id is used by the Codec Engine APIs to identify the algorithm implementation that will create an instance on a DSP Server.
If a codec doesn't explicitly configure this parameter, a "very likely unique" ID will be generated. It is recommended that codecs not explicitly configure this parameter, and leave it to the system.
 
VIDENC1_COPY.getCreationStackSize( )  // module-wide

Get the maximum required stack size (in octets) for this algorithm during algorithm instance creation

XDCscript usage meta-domain
VIDENC1_COPY.getCreationStackSize( Program.Module prog ) returns Int
 
DETAILS
This method is called during DSP Server configuration and is used to ensure that the instance creation thread on the server has sufficient stackspace to instantiate the algorithm. This stack size is typically the greater of the stack sizes required by the algorithm's algNumAlloc(), algAlloc(), or algInit() methods.
 
VIDENC1_COPY.getDaramScratchSize( )  // module-wide

Get the maximum scratch size (in octets) required for this algorithm from DARAM space

XDCscript usage meta-domain
VIDENC1_COPY.getDaramScratchSize( Program.Module prog ) returns Int
 
DETAILS
This method is called during DSP Server configuration and is used to ensure that sufficient scratch space is configured for the specified set of algorithms.
 
VIDENC1_COPY.getSaramScratchSize( )  // module-wide

Get the maximum scratch size (in octets) required for this algorithm from SARAM space

XDCscript usage meta-domain
VIDENC1_COPY.getSaramScratchSize( Program.Module prog ) returns Int
 
DETAILS
This method is called during DSP Server configuration and is used to ensure that sufficient scratch space is configured for the specified set of algorithms.
 
VIDENC1_COPY.getStackSize( )  // module-wide

Get the maximum stack size (in octets) required for this algorithm during its execution phase

XDCscript usage meta-domain
VIDENC1_COPY.getStackSize( Program.Module prog ) returns Int
 
DETAILS
This method is called during DSP Server configuration and is used to ensure that threads on the server have sufficient stackspace to run the algorithm.
generated on Mon, 20 Sep 2010 23:50:14 GMT