API functions using the Codec Engine

Chapter 4 Using the Codec Engine APIs

The 4th chapter uses the API function of Codec Engine

This chapter describes how to use the Codec Engine APIs in an application.
4.1 Overview

4.2 The Core Engine APIs

4.3 The VISA classes:video, Image, Speech, Audio

4.4 The Server APIs
4.5 What happens to DSP Memory issues?
4.6 What happens to DSP real-time issues?
4.7 What's about Codec Engine debugging?
4.8 What's about software Trace?

This chapter describes how to use the API functions of Codec Engine in your application.

4.1 Reviews

4.2 Core engine API functions

4.3 VISA Category: Video, image, voice, audio

4.4 Codec Server API functions

4.5 What happens to DSP memory problems?

4.6 What happens to DSP real-time problems?

4.6 How to debug Codec Engine?

4.7 How to use software tracking?

4.1 Overview

4.1 Reviews

The CODEC engine has Core engine APIs and VISA APIs. The following table shows the Core Engine API modules:

Codec engine contains the core engines API functions and the VISA function. The following table shows the core engine API modules:

Table 4–1 Codec Engine Modules

In addition to modules the perform setup and teardown activities, a Memory abstraction module provides support for Applic ations. Codec Engine in a GPP+DSP system.

In addition to performing the installation and uninstallation of the active module, the Memory abstraction module provides support for applications that use Codec Engine in the GPP+DSP system.

The following table shows the VISA API modules:

The following table shows the VISA API modules:

Table 4–2 Codec Engine Modules

The VISA interfaces provided with CE 1.20 include support for both the XDM 0.9 and XDM 1.0 interfaces. The "x" suffixes in Table 4–2 represent a version of the interface. In XDM 0.9, the suffix is omitted; In XDM 1.0, it is "1".

The visa interface provides CE 1.20 that includes support for the XDM 0.9/XDM 1.0 interface. The "x" suffix in table 4-2 represents the version number of an interface. In XDM 0.9, the suffix is omitted, and in XDM 1.0, the suffix is "1".

Copy codecs complying with the XDM 1.0 interfaces is provided with the Xdais 5.21 product. CE 1.20 utilizes those codecs in some of its examples. For example, the video1_copy example utilizes the VIDENC1 and VIDDEC1 VISA interfaces to communicate with those copy codec S.

A copy of the codec conforming to the XDM 1.0 interface is the product of Xdais 5.21. CE 1.20 uses these codecs in some of its examples, for example, the video1_copy example uses the VIDENC1 and VIDDEC1 VISA interfaces to communicate with a copied codec.

The package name corresponds to the path your application must use to reference the header file it includes to use a parti Cular module. For example, the Speech encoder module, SPHENCX, have a package name of Ti.sdo.ce.speech (x). The #include statement for this module are (where x is a version-based suffix):

#include <ti/sdo/ce/speechx/sphencx.h>

The package name corresponds to the path of the header file that your application must reference that contains the specific module. For example, the Voice encoder module, SPHENCX, has a name for the Ti.sdo.ce.speech (x) package. The #include statement in this module (where x is a version-based suffix) is:

#include <ti/sdo/ce/speechx/sphencx.h>

Your application uses the engine module to open and close instances of the Codec Engine. You can also use the This module to get information about memory use and CPU loading. See section 4.2, the Core Engine APIs.

Your application uses engine modules to open and close Codec engine instances. You can also use this module to get information about memory usage and CPU load, see section 4.2, API functions for the core engine.

Once your application has opened a instance of the Codec Engine, you use the modules in the VISA packages (for example, V Idenc for video encoding) to create instances of various algorithms. Using the handle for the algorithm instance you create, and then use the same module to run or otherwise control the Algor Ithm. See section 4.3, the VISA classes:video, Image, Speech, Audio.

Once your application opens an instance of Codec Engine, you use the VISA package module (for example, Video encoding Videnc) to create instances of various algorithms. Use the handle (handle) for the algorithm instance you created, and then run with the same module or otherwise control the algorithm. See section 4.3, VISA categories: video, images, voice, audio.

Reference documentation for the CODEC engine APIs are installed with the CODEC engine software at ce_install_dir/docs/html. This chapter provides a overview of the the APIs and how to use them. For details on the calling syntax, see the reference documentation.

Refer to the software documentation in ce_install_dir/docs/html to learn about the Codec engine API function, which is generated when installing the CODEC engine software. This chapter provides an overview of the API functions and how to use them. For more information about the invocation syntax, see referencing the document.

4.2 The Core Engine APIs

4.2 Core engine API functions

The CODEC engine has a "core" module called "Engine". Your application uses this module to open and close Engine instances. Multi-threaded applications must either serialize access to a shared engine instance or create a separate Engine instance For each thread.

CODEC engine has a "core" module called "Engine". Your application uses this module to open and close engine instances. Multithreaded applications must either continuously access a shared engine instance, or create a separate instance of the engine for each thread.

Note:be aware that Engine handles is not thread-protected. Each thread, the uses an engine, instance should perform its own engine_open (), and use its own Engine handle. This protects all Engine instance from Access is threads in a multi-threaded environment.

Note: Note that the engine handle (handles) is not thread protected. Each thread that uses an instance of the engine should perform its own engine_open () function call and use its own engine handle. This protects every instance of the engine from being accessed by other threads in a multithreaded environment.

You can also with the Engine module to get information about memory use and CPU loading.

You can also use the engine module to get information about memory usage and CPU load.

The APIs for the Engine module is:
? Engine_open (). Open an Engine.
? Engine_close (). Close an Engine.
? Engine_getcpuload (). Get Server ' s CPU usage in percent.
? Engine_getlasterror (). Get the error code of the last failed operation.
? Engine_getusedmem (). Get Engine memory usage.
? Engine_getnumalgs (). Get the number of algorithms in an Engine.
? Engine_getalginfo (). Get information about an algorithm.

The engine modules for these APIs are:

1. Engine_open (). Open an engine.

2. Engine_close (). Shut down an engine.

3. Engine_getcpuload (). Gets the percentage of CPU usage for the server.

4. Engine_getlasterror (). Gets the error code for the last failed operation.

5. Engine_getusedmem (). Gets the engine memory usage.

6. Engine_getnumalgs (). Gets the number of algorithms in an engine.

7. Engine_getalginfo (). Gets information about the algorithm.

After opening a Engine, you create algorithm instances using the VISA APIs described in section 4.3.

After you open an engine, you will create an algorithm instance using the Visa API described in section 4.3.

Reference documentation for the CODEC engine APIs are installed with the CODEC engine software at ce_install_dir/docs/html. For details on the calling syntax, see the reference documentation.

Refer to the software documentation in ce_install_dir/docs/html to learn about the Codec engine API function, which is generated when installing the CODEC engine software. For more information about the invocation syntax, see referencing the document.

API functions using the Codec Engine