Creating Package Files
Developing an xDM Codec
2-7
In addition to declaring the type of algorithm, this file uses the following
statement to declare the external symbol required by xDAIS to identify
the algorithm’s implementation functions.
/*!
 ======== ialgFxns ========
 name of this algorithm's xDAIS alg fxn table
*/
override readonly config String ialgFxns =
"VIDDECCOPY_TI_VIDDECCOPY";
If the codec uses DMA, you must also specify the idma3Fxns vtable
symbol’s name in this file.
2.2.5
<MODULE>.xs File
This is the module’s implementation.
Rename the VIDDEC_COPY.xs file to match the module name you used
in the package.xdc file. This file should contain the implementation of any
methods declared in VIDDEC_COPY.xdc. By analogy, the *.xs file is to
its corresponding *.xdc file as a *.c file is to a *.h file.
This file defines codec properties that can vary across platforms and
configurations.
It implements the functions specified in the ti.sdo.ce.ICodec interface.
These functions enable the configuration tool to validate user-supplied
configuration parameters. For example, the default VIDEEC_COPY.xs
file specifies the stack size for the thread running this codec.
function getStackSize(prog)
{
if (verbose) {
print("getting stack size for " + this.$name
+ " built for the target " + prog.build.target.$name
+ ", running on platform " +  prog.platformName);
}
return (1024);
}
Pdf thumbnail generator online - Draw thumbnail images for PDF in C#.net, ASP.NET, MVC, Ajax, WinForms, WPF
Support Thumbnail Generation with Various Options for Quick PDF Navigation
.pdf printing in thumbnail size; generate thumbnail from pdf
Pdf thumbnail generator online - VB.NET PDF Thumbnail Create SDK: Draw thumbnail images for PDF in vb.net, ASP.NET, MVC, Ajax, WinForms, WPF
Support Thumbnail Generation with Various Options for Quick PDF Navigation
enable pdf thumbnail preview; pdf thumbnail viewer
2-8
VB.NET Image: Program for Creating Thumbnail from Documents and
multiple document and image formats, such as PDF, TIFF, GIF version of RasterEdge .NET Imaging SDK online and you can use the thumbnail creation control
enable thumbnail preview for pdf files; pdf files thumbnails
How to C#: Generate Thumbnail for Word
VB.NET How-to, VB.NET PDF, VB.NET Word, VB.NET Excel NET Twain, VB.NET Barcode Read, VB.NET Barcode Generator, view less. How to C#: Generate Thumbnail for Word.
pdf thumbnail preview; generate pdf thumbnails
3-1
Chapter 3
Supporting Non-xDM Algorithms
This chapter describes how to create stubs and skeletons to allow non-
xDM algorithms to be used remotely in Codec Server applications.
3.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–2
3.2 Core Algorithm Interface Requirements . . . . . . . . . . . . . . . . . . . . . . 3–4
3.3 Creating Codec Engine Extensions. . . . . . . . . . . . . . . . . . . . . . . . . . 3–5
3.4 Designing a New Application Interface. . . . . . . . . . . . . . . . . . . . . . . 3–5
3.5 Developing Stubs and Skeletons. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–9
3.6 Binding Stubs and Skeletons to Framework Extensions . . . . . . . 3–19
3.7 Packaging and Configuring the Core Algorithm . . . . . . . . . . . . . . 3–20
3.8 Non-xDM Stub and Skeleton Example: SCALE . . . . . . . . . . . . . . . 3–22
Topic
Page
How to C#: Generate Thumbnail for PowerPoint
VB.NET How-to, VB.NET PDF, VB.NET Word, VB.NET NET Twain, VB.NET Barcode Read, VB.NET Barcode Generator, view less. How to C#: Generate Thumbnail for PowerPoint.
pdf no thumbnail; how to make a thumbnail of a pdf
How to C#: Set Image Thumbnail in C#.NET
VB.NET How-to, VB.NET PDF, VB.NET Word, VB.NET Excel NET Twain, VB.NET Barcode Read, VB.NET Barcode Generator, view less. How to C#: Set Image Thumbnail in C#.NET
can't view pdf thumbnails; thumbnail view in for pdf files
Overview
3-2
3.1
Overview
Codec Engine (CE) provides an  easy-to-use  application interface—
VISA—for multi-media developers to integrate and deploy compliant
codecs.  All  VISA-compliant  codecs  internally  use  a  xDAIS/xDM-
compliant algorithm core. CE uses the core algorithm's generic IALG
interface to dynamically create and destroy codec instances. CE uses the
codec's xDM interface to call specific processing and control functions.
This chapter shows how to extend CE by adding new VISA-like APIs for
remotely accessing xDAIS algorithms that do not implement the xDM
interface. It also presents techniques for developing a custom media
application  layer  interface,  which  seamlessly  integrates  non-xDM
algorithms into the extended CE framework.
An extension example, SCALE, illustrates the concepts in this chapter.
This  example  is  provided  in  the  ti.sdo.ce.examples.codecs.scale
package, which is found in the CE_INSTALL_DIR/examples repository.
In order to use a CE extension, such as SCALE, a GPP client application
uses the existing CE interfaces (Engine APIs) to configure and open a
processing engine. It then uses new SCALE APIs to create, delete and
drive "scale" algorithms.
3.1.1
Tasks
The tasks for developing a CE extension can be broken down as follows:
Create core algorithm interface. See Section 3.2.
xDAIS IALG interface required for standard instance creation
and deletion.
IMOD xDAIS extension providing core processing and control
functions.
Create CE extension layer. See Section 3.3.
New MOD application framework API and library. See Section
3.4.
CE RPC layer for remote processing on a dual-processor target.
See Section 3.5.
Client-side: custom MOD stub interface. See Section 3.5.1.
Server-side: custom MOD skeleton interface. See Section
3.5.2. 
Perform CE packaging and configuration.
Configuring engine, binding skeleton interface. See Section 3.6.
MOD packaging. See Section 3.7.
Create Thumbnail in Web Image Viewer | Online Tutorials
You Wish; Annotate & Redact Documents or Images; Create Thumbnail; NET; XDoc.Converter for .NET; XDoc.PDF for .NET; Reader for .NET; XImage.Barcode Generator for
pdf files thumbnails; show pdf thumbnails
Create Thumbnail Winforms | Online Tutorials
Create Thumbnail; Generate Barcodes on Your Documents; Read Barcodes XDoc.Converter for .NET; XDoc.PDF for .NET; Reader for .NET; XImage.Barcode Generator for .NET
pdf thumbnails; generate thumbnail from pdf
Overview
Supporting Non-xDM Algorithms
3-3
3.1.2
Roles and Interactions
Figure 3–1 provides a high-level overview of the interactions between a
GPP client application, Codec Engine and a remote (DSP) server running
xDAIS-compliant algorithms. 
Figure 3–1  Overview of GPP / DSP Interactions
In Figure 3–1, the roles of stubs and skeletons in remote calls to an
xDAIS DSP algorithm are shown. The numbers in the figure correspond
to the following actions:
1) The GPP-side application makes an algorithm MOD_process() call.
2) Codec Engine (CE) forwards this call and its arguments to the GPP-
side algorithm stub.
3) The stub places the arguments in a compact inter-CPU message and
replaces all GPP-side (virtual address) pointer values with DSP-side
(physical  address)  values.  This  is  called  "marshalling"  the
arguments.
4) CE delivers the message to the DSP-side algorithm skeleton.
5) The skeleton unmarshals the arguments and calls the actual xDAIS
algorithm's process() function.
6) On the way back, the skeleton marshals any return arguments,
places them in a message, and the stub unmarshals them for the
application.
msg  
GPP 
DSP 
Shared memory 
alg stub + CE
CE + alg skeleton 
Application 
xDAIS alg 
MOD_process( 
)
process*( 
)
,
,
* IMOD function
2
4
How to C#: Generate Thumbnail for Raster
VB.NET How-to, VB.NET PDF, VB.NET Word, VB.NET Excel NET Twain, VB.NET Barcode Read, VB.NET Barcode Generator, view less. How to C#: Generate Thumbnail for Raster
enable thumbnail preview for pdf files; pdf first page thumbnail
How to C#: Overview of Using XImage.Raster
Empower to navigate image(s) content quickly via thumbnail. Able to support text extract with OCR. You may edit the tiff document easily. Create Thumbnail.
pdf thumbnail generator; view pdf thumbnails in
Core Algorithm Interface Requirements
3-4
In Codec Engine, memory shared by the GPP and DSP is not cached on
the GPP, but is cached on the DSP. The skeleton must manage the
cache by invalidating the cache area occupied by the input and output
buffers before the xDAIS process() call and by flushing the output buffers'
cache area after the xDAIS process() call.
Technically, the process() and control() function prototypes on the GPP
side do not need to be the same as those of the xDAIS algorithm.
However,  if  they  are  not  the  same,  the  API  layer  becomes  more
complicated, and is beyond the scope of this document.
3.2
Core Algorithm Interface Requirements
The core algorithm interface must be compliant with TI's TMS320 DSP
Algorithm Standard (xDAIS). For details, see the following documents:
TMS320 DSP Algorithm Standard Rules and Guidelines (SPRU352)
TMS320 DSP Algorithm Standard API Reference (SPRU360)
TMS320 DSP Algorithm Standard Developer’s Guide (SPRU424)
Additionally, to be able to operate in a dual-processor environment, the
interface must support remote calls. The xDM interface is an example of
a remote callable API. Remote calling within the CE framework currently
imposes the following restrictions:
Creation parameters cannot contain client-side address references.
Each argument's operational semantics must be specified as either
In, Out, or In/Out.
Arguments passed to algorithm methods—for example, process()
and control()—must be serializable.This means:
Each address reference passed in an argument must be explicit
and must point to a client-provided memory location whose size
can be determined by parsing the provided run-time arguments.
Each address reference passed in an Out or In/Out argument
must be aligned with respect to cache line sizes and must have
a size that is a multiple of the cache-line size.
The sizes of all arguments must be fixed or computable by
parsing the run-time arguments.
Client  applications  must  ensure  that  all  data  passed  to  algorithm
processing functions by reference are:
contiguously allocated
located within a shared memory segment
aligned with respect to cache line sizes and have a size that is a
multiple of the cache-line size.
Creating Codec Engine Extensions
Supporting Non-xDM Algorithms
3-5
3.3
Creating Codec Engine Extensions
The Codec Engine VISA APIs provide uniform synchronous procedure
call semantics for client applications. When the server is "local", the calls
are true local procedure calls. However, when the server is "remote",
Codec  Engine  provides  a  classic  Remote  Procedure  Call  (RPC)
abstraction.
Section 3.4 describes how to develop a VISA-like application interface to
support non-xDM algorithms. These extended APIs facilitate VISA-like
easy-to-use creation, deletion, and processing operations for both local
and remote server configurations.
Then, Section 3.5.1 and Section 3.5.2 describe how to develop the CE
stubs and skeletons that implement the RPC abstraction in a remote
configuration.
3.4
Designing a New Application Interface
You should create a new API module that can be delivered to the client
application  as  a  separate,  configurable  package  that  extends  (and
leverages) the Codec Engine framework. This section uses the SCALE
extension example provided in the toolkit to explain the key concepts
required to create such a package.
The SCALE example provides a new application interface with contains
the  following  core  functions:  SCALE_create,  SCALE_delete,
SCALE_process,  and  SCALE_control.  These  functions  are  used  to
create and delete local or remote "scale" codec instances and to process
data using the algorithm.
The  CE  extension  package,  "ti.sdo.ce.examples.extensions.scale",
implements the SCALE APIs and provides  a configuration interface
module,  ISCALE, which extends ti.sdo.ce.ICodec to  support  remote
operation and to configure stubs and skeletons. More details on ISCALE
and stubs and skeletons are provided in Section 3.5.1 and Section 3.5.2.
Designing a New Application Interface
3-6
3.4.1
Creation and Deletion APIs
The easiest APIs to define and implement are the create and delete APIs,
since these are fairly generic and can simply invoke the VISA_create and
VISA_delete functions. Follow these guidelines for seamless integration:
Algorithm Handle. All algorithm handles used should be compatible
with the VISA_Handle type.
Algorithm Creation Parameter. Creation parameters must extend
IALG_Params.  The  first  field  contains  the  size  of  the  structure
definition; the rest can be arbitrary non-pointer elements.
Engine_Handle. The Engine_Handle argument to VISA_create
must be to an open engine which contains references to the core
algorithm package.
Algorithm Name. The name argument to VISA_create must match
the string used to configure the algorithm in the engine.
Codec Name. The fully-qualified module name of the codec in the
extension  package  must  be  passed  as  the  last  argument  to
VISA_create.
The source code for the SCALE_create and SCALE_delete APIs, which
follows, shows how to implement them using VISA APIs.
/* ======== SCALE_create ======== */
SCALE_Handle SCALE_create(Engine_Handle server, 
String name, SCALE_Params *params)
{
SCALE_Handle visa;
if (params == NULL) {
params = &SCALE_PARAMS;
}
visa = VISA_create(server, name, (IALG_Params *)params,
sizeof (_SCALE_Msg), "extensions.scale.ISCALE");
return (visa);
}
/* ======== SCALE_delete ======== */
Void SCALE_delete(SCALE_Handle handle)
{
VISA_delete(handle);
}
Designing a New Application Interface
Supporting Non-xDM Algorithms
3-7
3.4.2
Processing Function APIs
To create processing function APIs, you create custom functions that use
the public core algorithm interface of the xDAIS-compliant (but non-xDM)
codec. When implementing these functions, use the following VISA APIs: 
VISA_getAlgFxns
VISA_getAlgHandle
VISA_enter, VISA_exit
First, use the VISA_Handle returned by the create call (for example,
SCALE_create) to obtain the actual algorithm instance handle and the
algorithm's IALG interface function table. Use these to call the core
algorithm’s  processing  functions.  It  is  possible,  although  not
recommended, for the framework APIs to have different arguments than
those of the core algorithm interface.
The technique recommended here allows the same API implementation
to be used for both local and remote invocation. When the application
configures the codec as "remote", the VISA layer routes the call to the
remote  algorithm  instance  using  stubs and skeletons that  must  be
provided as part of the CE extension package. (see Section 3.5) When
configured as "local", the processing call is a function call to the actual
algorithm instance.
Calls to an algorithm's processing functions must be bracketed with
VISA_enter and VISA_exit calls using the instance handle. These calls
allow the VISA layer to perform the necessary instance activation and
deactivation that may be necessary for xDAIS algorithms.
Designing a New Application Interface
3-8
For example, the SCALE_process function is implemented as follows:
/* ======== SCALE_process ======== */
XDAS_Int32 SCALE_process(SCALE_Handle handle, 
XDAS_Int8 *inBuf, XDAS_Int8 *outBuf, 
SCALE_InArgs *inArgs, SCALE_OutArgs *outArgs)
{
XDAS_Int32 retVal = SCALE_EFAIL;
if (handle) {
ISCALE_Fxns *fxns =
(ISCALE_Fxns *)VISA_getAlgFxns((VISA_Handle)handle);
ISCALE_Handle alg = 
VISA_getAlgHandle((VISA_Handle)handle);
if (fxns && (alg != NULL)) {
VISA_enter((VISA_Handle)handle);
retVal = fxns->process(alg, inBuf, outBuf,
inArgs, outArgs);
VISA_exit((VISA_Handle)handle);
}
}
return (retVal);
}
Documents you may be interested
Documents you may be interested