{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','https://www.xiaopingtou.cn//data/attach/topic/topicKPo7gB.jpg', '推荐 u013209302 的文章《Codec Engine 应用开发使用手册》','https://www.xiaopingtou.net/article-82307.html','页面编码gb2312|utf-8默认gb2312'));){kind=link}
Codec Engine Application Developer User's Guide
Literature Number: SPRUE67D September 2007IMPORTANT NOTICE
Texas Instruments Incorporated and its subsidiaries (TI) reserve the right to make corrections, modifications, enhancements, improvements, and other changes to its products and services at any time and to discontinue any product or service without notice. Customers should obtain the latest relevant information before placing orders and should verify that such information is current and complete. All products are sold subject to TI's terms and conditions of sale supplied at the time of order acknowledgment. TI warrants performance of its hardware products to the specifications applicable at the time of sale in accordance with TI's standard warranty. Testing and other quality control techniques are used to the extent TI deems necessary to support this warranty. Except where mandated by government requirements, testing of all parameters of each product is not necessarily performed. TI assumes no liability for applications assistance or customer product design. Customers are responsible for their products and applications using TI components. To minimize the risks associated with customer products and applications, customers should provide adequate design and operating safeguards. TI does not warrant or represent that any license, either express or implied, is granted under any TI patent right, copyright, mask work right, or other TI intellectual property right relating to any combination, machine, or process in which TI products or services are used. Information published by TI regarding third-party products or services does not constitute a license from TI to use such products or services or a warranty or endorsement thereof. Use of such information may require a license from a third party under the patents or other intellectual property of the third party, or a license from TI under the patents or other intellectual property of TI. Reproduction of TI information in TI data books or data sheets is permissible only if reproduction is without alteration and is accompanied by all associated warranties, conditions, limitations, and notices. Reproduction of this information with alteration is an unfair and deceptive business practice. TI is not responsible or liable for such altered documentation. Information of third parties may be subject to additional restrictions. Resale of TI products or services with statements different from or beyond the parameters stated by TI for that product or service voids all express and any implied warranties for the associated TI product or service and is an unfair and deceptive business practice. TI is not responsible or liable for any such statements. TI products are not authorized for use in safety-critical applications (such as life support) where a failure of the TI product would reasonably be expected to cause severe personal injury or death, unless officers of the parties have executed an agreement specifically governing such use. Buyers represent that they have all necessary expertise in the safety and regulatory ramifications of their applications, and acknowledge and agree that they are solely responsible for all legal, regulatory and safety-related requirements concerning their products and any use of TI products in such safety-critical applications, notwithstanding any applications-related information or support that may be provided by TI. Further, Buyers must fully indemnify TI and its representatives against any damages arising out of the use of TI products in such safety-critical applications. TI products are neither designed nor intended for use in military/aerospace applications or environments unless the TI products are specifically designated by TI as military-grade or "enhanced plastic." Only products designated by TI as military-grade meet military specifications. Buyers acknowledge and agree that any such use of TI products which TI has not designated as military-grade is solely at the Buyer's risk, and that they are solely responsible for compliance with all legal and regulatory requirements in connection with such use. TI products are neither designed nor intended for use in automotive applications or environments unless the specific TI products are designated by TI as compliant with ISO/TS 16949 requirements. Buyers acknowledge and agree that, if they use any non-designated products in automotive applications, TI will not be responsible for any failure to meet such requirements. Following are URLs where you can obtain information on other Texas Instruments products and application solutions: Products ApplicationsAmplifiers amplifier.ti.com Audio www.ti.com/audio
Data Converters dataconverter.ti.com Automotive www.ti.com/automotive
DSP dsp.ti.com Broadband www.ti.com/broadband
Interface interface.ti.com Digital Control www.ti.com/digitalcontrol
Logic logic.ti.com Military www.ti.com/military
Power Mgmt power.ti.com Optical Networking www.ti.com/opticalnetwork
Microcontrollers microcontroller.ti.com Security www.ti.com/security
RFID www.ti-rfid.com Telephony www.ti.com/telephony
Low Power Wireless www.ti.com/lpw Video & Imaging www.ti.com/video
Wireless www.ti.com/wireless Mailing Address: Texas Instruments, Post Office Box 655303, Dallas, Texas 75265 Copyright © 2007, Texas Instruments Incorporated
Preface
About This Book
The Codec Engine is a set of APIs that you use to instantiate and run xDAIS algorithms. A VISA interface is provided as well for interacting with xDM-compliant xDAIS algorithms. The intended audience for this document is the embedded-OS application developer treating the DSP-side of DaVinci as a black box represented by an API.Additional Documents and Resources
You can use the following sources to supplement this user’s guide:❏ Codec Engine Server Integrator User's Guide (SPRUED5)
❏ Codec Engine Algorithm Creator User's Guide (SPRUED6)
❏ Codec Engine Application (API) Reference Guide. CE_INSTALL_DIR/docs/html/index.html
❏ Configuration Reference Guide. CE_INSTALL_DIR/xdoc/index.html
❏ Example Build and Run Instructions. CE_INSTALL_DIR/examples/build_instructions.html
❏ xDM API Reference. XDAIS_INSTALL_DIR/docs/html/index.html
❏ DaVinci EVM Home at Spectrum Digital: http://c6000.spectrumdigital.com/davincievm/revc/
❏ TI Linux Community for DaVinci Processors: http://linux.davincidsp.com
❏ xDAIS-DM (Digital Media) User Guide (SPRUEC8)
❏ TMS320 DSP Algorithm Standard Rules and Guidelines (SPRU352)
❏ TMS320 DSP Algorithm Standard API Reference (SPRU360)
❏ TMS320 DSP Algorithm Standard Developer’s Guide (SPRU424)
❏ TMS320 DSP Algorithm Standard Demonstration Application (SPRU361)
Notational Conventions
This document uses the following conventions:❏ Program listings, program examples, and interactive displays are shown in a special typeface. Examples use a bold version of the special typeface for emphasis; interactive displays use a bold version of the special typeface to distinguish commands that you enter from items that the system displays (such as prompts, command output, error messages, etc.).
❏ Square brackets ( [ and ] ) identify an optional parameter. If you use an optional parameter, you specify the information within the brackets. Unless the square brackets are in a bold typeface, do not enter the brackets themselves.
❏ This manual uses an icon like the one to the left to identify information that is specific to a particular type of system. For example, this icon identifies information that applies if you are using Codec Engine on a dual-processor GPP+DSP system.
Trademarks
The Texas Instruments logo and Texas Instruments are registered trademarks of Texas Instruments. Trademarks of Texas Instruments include: TI, DaVinci, XDS, Code Composer, Code Composer Studio, Probe Point, Code Explorer, DSP/BIOS, RTDX, Online DSP Lab, DaVinci, TMS320, TMS320C54x, TMS320C55x, TMS320C62x, TMS320C64x, TMS320C67x, TMS320C5000, and TMS320C6000. MS-DOS, Windows, and Windows NT are trademarks of Microsoft Corporation. UNIX is a registered trademark of The Open Group in the United States and other countries. Linux is a registered trademark of Linus Torvalds. Solaris, SunOS, and Java are trademarks or registered trademarks of Sun Microsystems, Inc. All other brand, product names, and service names are trademarks or registered trademarks of their respective companies or organizations.Contents
1 Codec Engine OverviewThis chapter introduces the Codec Engine.
1.1 What is the Codec Engine?
1.2 Why Should I Use It?
1.3 Where Does the Codec Engine Fit into My Architecture?
1.4 What Are the User Roles?
1.4.1 Algorithm Creator
1.4.2 Server Integrator
1.4.3 Engine Integrator
1.4.4 Application Author
1.5 Where Can I Get More Information?
2 Installation and Setup
This chapter describes steps you may need to perform for installation and setup.
2.1 Installing Codec Engine
2.2 Packages and Repositories
2.3 Directory Structure
3 Using the Sample Applications
This chapter describes how to test the sample applications provided with the Codec Engine.
3.1 Overview
3.2 Building Applications
3.3 Running Applications
4 Using the Codec Engine APIs
This chapter describes how to use the Codec Engine APIs in an application.
4.1 Overview 4.2 The Core Engine APIs
4.2.1 Codec Engine Setup Code
4.2.2 Opening an Engine
4.2.3 Closing an Engine
4.2.4 Getting Memory and CPU Information from an Engine
4.2.5 Getting Information About Algorithms Configured into an Engine
4.3 The VISA Classes: Video, Image, Speech, Audio
4.3.1 VISA API Setup Code 4.3.2 Creating an Algorithm Instance 4.3.3 Deleting an Algorithm Instance
4.3.4 Controlling an Algorithm Instance
4.3.5 Processing Data with an Algorithm Instance
4.3.6 Overriding a Remote Algorithm's Priority and Memory Requests
4.4 The Server APIs
4.4.1 Getting a Server Handle
4.4.2 Getting Memory Heap Information
4.4.3 Reconfiguring the DSP Server's Algorithm Heap
4.5 What Happens to DSP Memory Issues?
4.5.1 Buffer Handling and Shared Memory Maps
4.5.2 Memory Fragmentation
4.5.3 Cache Alignment
4.5.4 Cache Coherence
4.6 What Happens to DSP Real-Time Issues?
4.6.1 Transaction Latency
4.6.2 Multi- vs. Uni-Processor Performance
4.6.3 Local Performance
4.7 What About Codec Engine Debugging?
4.7.1 Codec Engine Debugging from the ARM on ARM+DSP Systems
4.7.2 Codec Engine Debugging on a DSP-only System
4.8 What About Software Trace?
4.8.1 Configuring TraceUtil at Design Time
4.8.2 Supporting TraceUtil in Your Application's C Code
4.8.3 Configuring the DSP Server for DSP/BIOS Logging
4.8.4 Configuring the DSP Server To Redirect Trace Output
4.8.5 Configuring TraceUtil at Application Start Time
4.8.6 Controlling Trace at Run-Time Through a Named Pipe
4.8.7 Trace Mask Values
5 Integrating an Engine
This chapter describes how the Engine Integrator should configure an Engine for use by the application developer.
5.1 Overview
5.2 A Reusable Example
5.2.1 Advanced Engine Creation
5.3 Understanding Engine Configuration Syntax
5.3.1 Framework Components Configuration
Chapter 1
Codec Engine Overview
This chapter introduces the Codec Engine.Topic Page
1.1 What is the Codec Engine? 1–2
1.2 Why Should I Use It? 1–3
1.3 Where Does the Codec Engine Fit into My Architecture?1–4
1.4 What Are the User Roles? 1–6 1.5 Where Can I Get More Information?1–10
1.1 What is the Codec Engine?
From the application developer’s perspective, the Codec Engine is a set of APIs that you use to instantiate and run xDAIS algorithms. A VISA interface is provided as well for interacting with xDM-compliant xDAIS algorithms. The API is the same for all of the following situations:❏ The algorithm may run locally (on the GPP) or remotely (on the DSP).
❏ The system may be a GPP+DSP, DSP-only, or GPP-only system.
❏ All supported GPPs and DSPs have the same API. ❏ All supported operating systems have the same API. For example, Linux, PrOS, VxWorks, DSP/BIOS, and WinCE. This manual uses an icon like the one to the left to identify information that is specific to a particular type of system. For example, this icon identifies information that applies if you are using Codec Engine on a dual-processor GPP+DSP system. xDM is the eXpressDSP Algorithm Interface Standard for Digital Media. It is sometimes referred to as xDAIS-DM. Any xDM algorithm is compliant with the eXpressDSP Algorithm Interface Standard (xDAIS). Additionally, it implements the xDAIS-DM (xDM) interface, an extension to the xDAIS standard that provides support for digital media encoders, decoders, and codecs. The xDM specification defines APIs for digital media codecs by class, with extensions defined for video, imaging, speech, and audio codec classes. The xDM interfaces divide codec algorithms into four classes: Video, Image, Speech, and Audio (VISA). VISA reflects this xDM interface. One set of APIs is provided per codec class. Thus, MP3 can be replaced with WMA without changing the application source code. Only the configuration needs to be changed. The Codec Engine also supports real-time, non-intrusive visibility into codec execution. It provides APIs for accessing memory and overall CPU usage statistics and execution trace information. The Codec Engine runtime is supplied in binary form. Thus, application libraries built with same Codec Engine release are always compatible.
1.2 Why Should I Use It?
The Codec Engine is designed to solve some common problems associated with developing system-on-a-chip (SoC) applications. The most significant problems include:❏ Debugging in a heterogeneous processor environment can be painful. There are multiple debuggers and complex bootstrapping.
❏ Different implementations of the same algorithm, such as MP3, have different APIs. Changing to a more efficient algorithm involves significant recoding.
❏ Portability issues are compounded with two processors. You may want to port to a different board with a newer DSP or a newer GPP.
❏ Some algorithms may run on either the GPP or the DSP. To balance system load, “low complexity” algorithms can run on a GPP, but the
definition of “low” changes over time. If changing the location where the algorithm runs were easy, you wouldn’t have to weigh performance issues against the difficulty of changing the application.
❏ For market success, most applications need to support multiple codecs to handle the same type of media. For example, an application might need to support three or four audio formats. ❏ Programmers with a GPP (general-purpose processor) view typically don’t want to have to learn to be DSP programmers. And, they don’t want to have to worry about a DSP’s complex memory management and DSP real-time issues. The Codec Engine addresses these problems by providing a standard software architecture and interfaces for algorithm execution. The Codec Engine is: ❏ Easy-to-use. Application developers specify what algorithm needs to be run, not how or where.
❏ Extensible and configurable. New algorithms can be added by anyone, using standard tools and techniques.
❏ Portable. The APIs are target, platform, and even codec independent.
1.3 Where Does the Codec Engine Fit into My Architecture?
The application code (or the middleware it uses) calls the Codec Engine APIs. Within the Codec Engine, the VISA APIs use stubs and skeletons to access the core engine and the actual codecs, which may be local or remote. The following figure shows the general architecture of an application that uses the Codec Engine. It also shows the user roles involved in creating various portions of the application. See Section 1.4, What Are the User Roles? for more on user roles.
The application (or middleware it uses) calls the core Engine APIs and the VISA APIs. The VISA APIs use stubs to access the core engine SPIs (System Programming Interfaces) and the skeletons. The skeletons access the core engine SPIs and the VISA SPIs. The VISA SPIs access the underlying algorithms. The following figure is a modification of the previous diagram that shows how this architecture is distributed in a GPP+DSP system. In this example, yellow portions run on the GPP, and grey portions run on the DSP. That is, the video encoder skeleton and the video encoder codecs are on the DSP and the application and video encoder stubs are on the GPP.
Since Codec Engine is flexible, alternate diagrams could be shown for GPP-only and DSP-only systems.
1.4 What Are the User Roles?
The Codec Engine has several customer use cases, from application developers to codec authors. In some cases, these roles may be played by a single person. In other development environments, a different developer may be assigned each role. This topic describes the primary roles that Codec Engine users will play. Because Codec Engine is very portable and configurable and can run in many different environments, the descriptions of these roles are intentionally generalized. When applicable, specific hardware and software environments are described after the general descriptions. This document describes the APIs available to the Application Author. Other documents are referenced for the other roles.1.4.1 Algorithm Creator
The Algorithm Creator is responsible for creating an xDAIS algorithm and providing the necessary packaging to enable these algorithms to be consumed and configured by Codec Engine. If the codec is xDM-compliant, Codec Engine's VISA APIs support remote execution without additional support. However, if the codec is not xDM-compliant and the codecs support remote execution, the Algorithm Creator should supply Codec Engine skeletons and stubs. The Algorithm Creator uses xDAIS and the XDC Tools. Using these, the Algorithm Creator generates a codec library with the IALG and optional IDMA3 interface symbols exported. This person also creates an XDC module that implements the ti.sdo.ce.ICodec interface. The Algorithm Creator hands a released Codec package to the Server Integrator. This package includes a module that implements ti.sdo.ce.ICodec, as well as the libraries that contain the algorithm's implementation. The Algorithm Creator uses the following resources:❏ Codec Engine Algorithm Creator User's Guide (SPRUED6)
❏ Codec Engine SPI Reference Guide. CE_INSTALL_DIR/docs/spi/html/index.html
❏ xDAIS-DM (Digital Media) User Guide (SPRUEC8)
❏ xDM API Reference. XDAIS_INSTALL_DIR/docs/html/index.html
❏ TMS320 DSP Algorithm Standard Rules and Guidelines (SPRU352)
❏ TMS320 DSP Algorithm Standard API Reference (SPRU360)
❏ TMS320 DSP Algorithm Standard Developer’s Guide (SPRU424)
❏ Example codecsWhat Are the User Roles?
1.4.2 Server Integrator
To support Engines with remote codecs, a Codec Server must be created. The Codec Server integrates and configures the various components necessary to house the codecs (e.g. DSP/BIOS, Framework Components, DSP/BIOS Link drivers, codecs, Codec Engine, etc.) and generates an executable. There are two configuration steps that the Codec Server Integrator must perform, one to configure DSP/BIOS (through a Tconf script) and one to configure "the rest" of the components (through XDC configuration of Framework Components, DSP/BIOS Link, Codec Engine, etc). The Server Integrator receives the various Codec packages from Algorithm Creators. This person uses Codec Engine and its dependent packages (DSP/BIOS, DSKT2, etc) along with the XDC Tools to create the following:❏ A server configuration file (.cfg)
❏ A server DSP/BIOS configuration file (.tcf)
❏ A simple main() routine to do minimal initialization ❏ A DSP executable created by executing the configuration scripts and compiling the output. This executable is a Codec Server. The Server Integrator hands the DSP executable to the Engine Integrator (preferably as a Codec Server package. The Server Integrator should also provide a list of the codecs in the Codec Server, as well as documentation about how they've been configured (for example, thread priorities and resource configuration). The Server Integrator uses the following resources:
❏ Codec Engine Server Integrator's Guide (SPRUED5)
❏ Configuration Reference Guide. CE_INSTALL_DIR/xdoc/index.html
❏ Example Codec Servers
On GPP-only and DSP-only platforms the Codec Server is not used, so this role is not required.
1.4.3 Engine Integrator
The Engine Integrator defines various Engine configurations. This includes the names of the Engines, as well as the codecs and their names within each Engine, whether each codec is local or remote relative to the application, which groups each codec should be integrated into (for environments which support resource sharing), the name of the Codec Server image if a particular Engine contains remote codecs, etc. This is done via an XDC configuration script (*.cfg). This script, when run, generates code and build instructions appropriate for the configuration. The Engine Integrator receives the name of a Codec Server and a list of the codecs it contains from the Server Integrator. Using these, this person creates an Engine configuration file (.cfg) that may reference a Codec Server. On DSP-only and/or GPP-only platforms, the Codec Server is not used, and all codecs will be configured to run locally (that is "local:true"). The Engine Integrator hands the Engine configuration file to the Application Author. The Engine Integrator uses the following resources:❏ Chapter 5 of this manual, Integrating an Engine.
❏ Configuration Reference Guide. CE_INSTALL_DIR/xdoc/index.html
❏ Example Build and Run Instructions. CE_INSTALL_DIR/examples/build_instructions.html
❏ Example configuration scripts (*.cfg)
1.4.4 Application Author
The application uses the Codec Engine APIs (Engine_, VISA, and other utility APIs) to create/delete preconfigured Engine instances, create/delete and interact with codecs, acquire buffers appropriate for the codecs, etc. Since Codec Engine doesn't perform any I/O, the application is responsible for handling I/O. This includes such task as file access (for example, open/read/write/seek/close) and driver interaction (for example, open/close/ioctl and buffer management). The Application Author is responsible for building the application code and for linking "the appropriate content" into the executable image. The Application Author receives the following:❏ Various Codec packages from Algorithm Creators
❏ A Codec Server DSP executable from the Server Integrator if codec will run on a DSP ❏ An Engine config file (.cfg) from the Engine Integrator The Application Author writes application code, generates output from the Engine configuration file (.c and .xdl output files) using the XDC Tools, and compiles the application code and generated files. This person then links the files, including the generated linker command file (.xdl) into an executable. The end result is the application executable. The process for generating an application executable is highly dependant on the application's operating system. If the application runs on the DSP using DSP/BIOS, for example, a .tcf file is needed to configure the DSP/BIOS kernel as well. If the application runs on Linux, the application does not need to configure the operating system. In addition to this manual, the Application Author uses the following resources:
❏ Codec Engine API Reference. CE_INSTALL_DIR/docs/html/index.html
❏ Example Build and Run Instructions. CE_INSTALL_DIR/examples/build_instructions.html
1.4.4.1 Editing a DSP/BIOS Configuration Script
For DSP-only applications, the Application Author creates a static DSP/BIOS configuration in a .tcf file, as described in the DSP/BIOS Tconf User’s Guide (SPRU007) and the DSP/BIOS online help. The syntax used in Tconf configurations is based on JavaScript.To create a .tcf file for an application, follow these steps: 1) Copy local.tcf from one of the example applications located at CE_INSTALL_DIR/examples/apps. This configuration file, in combination with the app_common.tci and bios.tci files that it imports, statically configures several aspects of the DSP/BIOS kernel, such as:
■ base DSP/BIOS kernel
■ memory section names, sizes, and locations
■ platform-specific attributes such as clock rates
■ task manager and dynamic heap allocation
■ ’C64x+ L1 cache and its corresponding memory segment
You can learn more about these modules and attributes in the DSP/BIOS online help or the C6000 DSP/BIOS API Reference (SPRU403).
2) Optionally open this .tcf file with a text editor.
3) Make any changes your application requires and save the file. You can add your own non-Codec Engine configuration items here if you need to add your own functionality for the application.
1.5 Where Can I Get More Information?
The release_notes*.html file at the top of the Codec Engine installation provides general information, information about changes in the latest version, devices supported and validation information, known issues, and links to online documentation provided with the Codec Engine. The online documentation provided with the Codec Engine is as follows:❏ Codec Engine API Reference. CE_INSTALL_DIR/docs/html/index.html
❏ Codec Engine SPI Reference Guide. CE_INSTALL_DIR/docs/spi/html/index.html
❏ Configuration Reference Guide. CE_INSTALL_DIR/xdoc/index.html
❏ Example Build and Run Instructions. CE_INSTALL_DIR/examples/build_instructions.html
For information about xDM, see the xDAIS-DM (Digital Media) User Guide (SPRUEC8).
For platform-specific help, see the Getting Started Guide for your platform.
Chapter 2
Installation and Setup
This chapter describes steps you may need to perform for installation and setup.Topic Page 2.1 Installing Codec Engine 2–2
2.2 Packages and Repositories 2–2
2.3 Directory Structure 2–3
2.1 Installing Codec Engine
The Codec Engine may have already been installed on your system as part of a larger installation. For example, the DVSDK software installation installs the Codec Engine in the codec_engine_#_## subdirectory of the main DVSDK software directory.If you have downloaded the Codec Engine as a standalone piece of software, follow these instructions: 1) Copy the codec_engine_#_##.tar.gz file to the directory where you want to install the software (where #_## is the version number).
2) Unzip the file with an unzip utility.
3) Open the release_notes*.html file at the top level of the installation.
4) Follow the steps to build and run Codec Engine examples.
2.2 Packages and Repositories
Codec Engine is delivered as a set of "packages". A package corresponds to a directory that contains all the files required for an independent component plus metadata about that component. Each package has a unique name that reflects its directory name. For example, "ti.sdo.ce.audio" is the name of a package that must be in a directory whose path ends with "/ti/sdo/ce/audio". Packages may be nested within another package. "Package repositories" are directories that contain one or more packages.A package places its metadata in a sub-directory named "package". This sub-directory contains metadata files that you do not need to be concerned with unless you are creating your own packages. A package also always contains a file named “package.xdc”, which declares the package’s name and an optional compatibility key. This key is used to ensure compatibility between packages.
As an application developer using the Codec Engine, the main reason you should be aware of packages is to understand the #include paths you need to use for header files. These paths are relative to a package repository. The package repositories used by the Codec Engine are part of the "package path", which matches the sequence of –I options you need to pass to the compiler when compiling source files that use a module in the Codec Engine. Since packages all have unique names, even if they are in different repositories, the #include statement tells you which package contains a particular header file. The Codec Engine distribution contains several package repositories:
❏ The core set of Codec Engine packages are in a repository named "packages". This corresponds to the CE_INSTALL_DIR/packages directory.
❏ The examples are distributed in a separate repository named "examples". This corresponds to the CE_INSTALL_DIR/examples directory.
❏ Some distributions of Codec Engine include a third repository containing a collection of dependant packages for convenience. This repository is named "cetools.packages", which corresponds to the CE_INSTALL_DIR/cetools/packages directory.
The XDC Tools provide an xdcpkg command (in the XDC_INSTALL_DIR/bin directory) that identifies all the packages in a directory. For example:
xdcpkg –a –l .
2.3 Directory Structure
The top-level directories within the Codec Engine installation are as follows:❏ cetools. Contains DSP Link and other TI tools used by the Codec Engine. Some distributions of the Codec Engine contain dependent components in this location. Other distributions expect the dependent components to have been installed separately.
❏ docs. Contains documentation files.
❏ examples. Contains a number of example applications.
❏ package. Contains package-related metadata files. You do not need to use this directory unless you are creating packages.
❏ packages. The Codec Engine packages. The /ti/sdo/ce subdirectory (that is, the ti.sdo.ce package) contains the VISA APIs and the stubs and skeletons that enable remote invocation of the VISA APIs. The /ti/sdo/ce/osal subdirectory contains the OS abstraction layer.
❏ xdoc. Contains documentation files for the packages in the Codec Engine distribution.
Chapter 3
Using the Sample Applications
This chapter describes how to test the sample applications provided with the Codec Engine.Topic Page
3.1 Overview 3–2
3.2 Building Applications 3–2
3.3 Running Applications 3–3
3.1 Overview
The CE_INSTALL_DIR/examples repository contains a collection of example packages demonstrating the various use cases that Codec Engine users may develop. These example packages fall into the following categories:❏ Codecs. Contains the codecs distributed with the Codec Engine. These are in the ti.xdais.dm.examples and ti.sdo.ce.examples.codecs namespace. (Note that the codecs in the ti.xdais.dm.examples namespace are copies of those distributed with xDAIS 5.20+.)
❏ Extensions. Contains a scale example that extends the VISA API. These are in the ti.sdo.ce.examples.extensions namespace.
❏ Servers. Contains two pre-configured and pre-linked Codec Servers (see Section 1.4.2, Server Integrator). These are in the ti.sdo.ce.examples.servers namespace.
❏ Applications. Contains example applications. These are in the ti.sdo.ce.examples.apps namespace.
The "copy" encoders/decoders replicate data rather than compressing/decompressing it. This is for simplicity in the examples. The Codec Engine distribution includes copy encoders/decoders for audio, image, speech, and video data for both xDM 0.9 and xDM 1.00. The two pre-configured Codec Servers are: all_codecs and video_copy. If you are using the DVSDK, you use these pre-configured Codec Servers when evaluating the board and learning to use the Codec Engine. Note that the memory maps that these Codec Servers are configured with matches that of the DVSDK.
See the CE_INSTALL_DIR/examples/build_instructions.html file for a full list of examples and links to details about