All IVIDENC1-compliant video encoder modules must implement this
interface.
config IVIDENC1.ialgFxns // module-wide |
 |
Name of xDAIS alg function table
readonly config String ialgFxns;
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 IVIDENC1.idma3Fxns // module-wide |
 |
Name of xDAIS alg IDMA3 Interface function table
readonly config String idma3Fxns;
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 IVIDENC1.iresFxns // module-wide |
 |
Name of xDAIS alg IRES Interface function table
readonly config String iresFxns;
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 IVIDENC1.rpcProtocolVersion // module-wide |
 |
Version of the Protocol used between the stubFxns and the serverFxns
override readonly config Int rpcProtocolVersion = 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 IVIDENC1.manageInBufsCache // module-wide |
 |
Codec Class configuration param
config Bool manageInBufsCache[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 IVIDENC1.manageOutBufsCache // module-wide |
 |
Codec Class configuration param
config Bool manageOutBufsCache[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 IVIDENC1.serverFxns // module-wide |
 |
Name of skeleton fxn table
override config String serverFxns = "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 IVIDENC1.stubFxns // module-wide |
 |
Name of stubs fxn table
override config String stubFxns = "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 IVIDENC1.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
config IVIDENC1.uuid // module-wide |
 |
Unique algorithm implementation ID
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.
IVIDENC1.getCreationStackSize( ) // module-wide |
 |
Get the maximum required stack size (in octets) for this algorithm
during algorithm instance creation
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.
IVIDENC1.getDaramScratchSize( ) // module-wide |
 |
Get the maximum scratch size (in octets) required for this algorithm
from DARAM space
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.
IVIDENC1.getSaramScratchSize( ) // module-wide |
 |
Get the maximum scratch size (in octets) required for this algorithm
from SARAM space
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.
IVIDENC1.getStackSize( ) // module-wide |
 |
Get the maximum stack size (in octets) required for this algorithm
during its execution phase
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.