H.264 Base/Main/High Profile
Encoder on DM365/DM368
User’s Guide
Literature Number: SPRUEU9
C
August 2010
IMPORTANT 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 Applications
Amplifiers amplifier.ti.comAudio www.ti.com/audio
Data Converters dataconverter.ti.comAutomotive www.ti.com/automotive
DLP® Products www.dlp.comCommunications and www.ti.com/communicationsTelecom
DSP dsp.ti.com Computers and www.ti.com/computersPeripherals
Clocks and Timers www.ti.com/clocksConsumer Electronics www.ti.com/consumer-apps
Interface interface.ti.comEnergy www.ti.com/energy
Logic logic.ti.comIndustrial www.ti.com/industrial
Power Mgmt power.ti.comMedical www.ti.com/medical
Microcontrollers microcontroller.ti.com Security www.ti.com/security
RFID www.ti-rfid.comSpace, Avionics & www.ti.com/space-avionics-defenseDefense
RF/IF and ZigBee ® S o lu tions www.ti.com/lprfVideo and Imaging www.ti.com/video
Wireless www.ti.com/wireless-apps
This document describes how to install and work with Texas Instruments’
(TI) H.264 Base/Main/High Profile Encoder implementation on the
DM365/DM368 platform. It also provides a detailed Application
Programming Interface (API) reference and information on the sample
application that accompanies this component.
TI’s codec implementations are based on the eXpressDSP Digital Media
(XDM) and IRES standards. XDM and IRES are extensions of
eXpressDSP Algorithm Interface Standard (XDAIS).
Intended Audience
This document is intended for system engineers who want to integrate
TI’s codecs with other software to build a multimedia system based on
the DM365/DM368 platform.
This document assumes that you are fluent in the C language, have a
good working knowledge of Digital Signal Processing (DSP), digital
signal processors, and DSP applications. Good knowledge of
eXpressDSP Algorithm Interface Standard (XDAIS) and eXpressDSP
Digital Media (XDM) standard will be helpful.
How to Use This Manual
This document includes the following chapters:
Chapter 1 – Introduction, provides a brief introduction to the XDAIS
Chapter 2 – Installation Overview, describes how to install, build,
Chapter 3 – Sample Usage, describes the sample usage of the
and XDM standards, Frame work Components, and software
architecture. It also provides an overview of the codec and lists its
supported features.
and run the codec.
codec.
Chapter 4 – API Reference, describes the data structures and
interface functions used in the codec.
Appendix A – Time-Stamp Insertion, describes insertion of frame
time-stamp through the Supplemental Enhancement Information
(SEI) Picture Timing message.
iii
Read This First
Appendix B – Error Description, provides a list of error
descriptions.
Appendix C – VICP buffer usage by codec, provides details of
how VICP buffers are used by codec.
Appendix D – ARM926 TCM buffer usage by codec, provides
details of using ARM926 TCM buffer by codec.
Appendix E - Simple Two-pass Encoding Sample Usage,
explains how multi-pass encoding can be used to improve the quality
of the H264 encoded video
Appendix F – Revision History, highlights the changes made to the
SPRUEU9A codec specific user guide to make it SPRUEU9B.
Related Documentation From Texas Instruments
The following documents describe TI’s DSP algorithm standards such
as, XDAIS and XDM. To obtain a copy of any of these TI documents,
visit the Texas Instruments website at
TMS320 DSP Algorithm Standard Rules and Guidelines (SPRU352)
defines a set of requirements for DSP algorithms that, if followed,
allow system integrators to quickly assemble production-quality
systems from one or more such algorithms.
www.ti.com.
TMS320 DSP Algorithm Standard API Reference (SPRU360)
describes all the APIs that are defined by the TMS320 DSP
Algorithm Interoperability Standard (also known as XDAIS)
specification.
Using IRES and RMAN Framework Components for C64x+
(literature number SPRAAI5) provides an overview of the IRES
interface, along with some concrete resource types and resource
managers that illustrate the definition, management and use of new
types of resources.
Related Documentation
You can use the following documents to supplement this user guide:
ISO/IEC 14496-10:2005 (E) Rec. H.264 (E) ITU-T Recommendation
Abbreviations
The following abbreviations are used in this document.
Table 1-1. List of Abbreviations
Abbreviation Description
ASO Arbitrary Slice Ordering
iv
AVC Advanced Vi deo Coding
Abbreviation Description
BIOS TI’s simple RTOS for DSPs
CAVLC Context Adaptive Variable Length Coding
CABAC Context Adaptive Binary Arithmetic Coding
D1 720x480 or 720x576 resolutions in
progressive scan
DCT Discrete Cosine Transform
DDR Double Data Rate
DMA Direct Memory Access
FC Framework components
FMO Flexible Macro-block Ordering
HD 720 or 720p 1280x720 resolution in progressive scan
Read This First
HDTV High Definition Television
HDVICP High Definition Video and Imaging Co-
processor sub-system
IDR Instantaneous Decoding Refresh
ITU-T International Telecommunication Union
JM Joint Menu
JVT Joint Video Team
MB Macro Block
MBAFF Macro Block Adaptive Field Frame
MJCP MPEG JPEG Co-Processor
MPEG Motion Pictures Expert Group
MV Motion Vector
NAL Network Adaptation Layer
NTSC National Television Standards Committee
PDM Parallel Debug Manager
PicAFF Picture Adaptive Field Frame
PMP Portable Media Player
PPS Picture Parameter Set
v
Read This First
Abbreviation Description
PRC Perceptual Rate Control
RTOS Real Time Operating System
RMAN Resource Manager
SEI Supplemental Enhancement Information
SPS Sequence Parameter Set
VGA Video Graphics Array
VICP Video and Imagin g Co-Processor
XDAIS eXpressDSP Algorithm Interface Standard
XDM eXpressDSP Digital Media
YUV Color space in luminance and
chrominance form
Text Conventions
Product Support
ROI Region Of Interest
STP Simple Two Pass
Note:
MJCP and VICP refer to the same hardware co-processor blocks.
The following conventions are used in this document:
Text inside back-quotes (‘‘) represents pseudo-code.
Program source code, function and macro names, parameters, and
command line commands are shown in a mono-spaced font.
When contacting TI for support on this codec, quote the product name
(H.264 Base/Main/High Profile Encoder on DM365/DM368) and version
number. The version number of the codec is included in the Title of the
Release Notes that accompanies this codec.
Trademarks
vi
Code Composer Studio, DSP/BIOS, eXpressDSP, TMS320,
TMS320C64x, TMS320C6000, TMS320DM644x, and TMS320C64x+ are
trademarks of Texas Instruments.
All trademarks are the property of their respective owners.
Contents
Read This First..................................................................................................................iii
About This Manual .......................................................................................................iii
Figure 3-4. Interaction Between Application and Codec.............................................3-7
Figure 3-5. Interrupt Between Codec and Application. ...............................................3-8
Figure C-1. VICP Buffers Managed By FC. .................................................................. C-2
ix
This page is intentionally left blank
x
Tables
Table 1-1. List of Abbreviations.......................................................................................iv
Table 2-2. Component Directories for Linux. ...............................................................2-3
Table 3-1. process () Implementation..........................................................................3-11
Table 4-1. List of Enumerated Data Types....................................................................4-2
xi
This page is intentionally left blank
xii
Chapter 1
Introduction
This chapter provides a brief introduction to XDAIS, XDM, and DM365
software architecture. It also provides an overview of TI’s implementation
of the H.264 Base/Main/High Profile Encoder on the DM365/DM368
platform and its supported features.
Topic Page
1.1 Software Architecture 1-2
1.2 Overview of XDAIS, XDM, and Framework Component Tools 1-2
1.3 Overview of H.264 Base/Main/High Profile Encoder 1-7
1.4 Supported Services and Features 1-10
1.5 Comparison between version 01.10.00.xx with new version
02.00.00.xx (Platinum Encoder)
1-11
1-1
Introduction
p
r
1.1 Software Architecture
DM365/DM368 codec provides XDM compliant API to the application for
easy integration and management. The details of the interface are provided
in the subsequent sections.
DM365/DM368 is a digital multi-media system on-chip primarily used for
video security, video conferencing, PMP and other related application.
DM365/DM368 codec are OS agonistic and interacts with the kernel
through the Framework Component (FC) APIs. FC acts as a software
interface between the OS and the codec. FC manages resources and
memory by interacting with kernel through predefined APIs.
Following diagram shows the software architecture.
Application
DM365 Codecs
CMEM APIs
CSL
SYNC APIs
iMX
EDMA APIs
IRQ drive
Linux Kernel
Figure 1-1. Software Architecture.
1.2 Overview of XDAIS, XDM, and Framework Component Tools
TI’s multimedia codec implementations are based on the eXpressDSP
Digital Media (XDM) standard. XDM is an extension of the eXpressDSP
Algorithm Interface Standard (XDAIS). IRES is a TMS320 DSP Algorithm
Standard (xDAIS) interface for management and utilization of special
resource types such as hardware accelerators, certain types of memory
and DMA. RMAN is a generic Resource Manager that manages software
component’s logical resources based on their IRES interface configuration.
Both IRES and RMAN are Framework Component modules.
Linux User
Space
Linux Kernel
S
ace
1.2.1 XDAIS Overview
An eXpressDSP-compliant algorithm is a module that implements the
abstract interface IALG. The IALG API takes the memory management
function away from the algorithm and places it in the hosting framework.
Thus, an interaction occurs between the algorithm and the framework. This
1-2
Introduction
interaction allows the client application to allocate memory for the algorithm
and share memory between algorithms. It also allows the memory to be
moved around while an algorithm is operating in the system. In order to
facilitate these functionalities, the IALG interface defines the following
APIs:
The algAlloc() API allows the algorithm to communicate its memory
requirements to the client application. The
algInit() API allows the
algorithm to initialize the memory allocated by the client application. The
algFree() API allows the algorithm to communicate the memory to be
freed when an instance is no longer required.
Once an algorithm instance object is created, it can be used to process
data in real-time. The
algActivate() API provides a notification to the
algorithm instance that one or more algorithm processing methods is about
to be run zero or more times in succession. After the processing methods
have been run, the client application calls the
algDeactivate() API prior
to reusing any of the instance’s scratch memory.
The IALG interface also defines two more optional APIs
and
Algorithm Standard API Reference (SPRU360).
1.2.2 XDM Overview
In the multimedia application space, you have the choice of integrating any
codec into your multimedia system. For example, if you are building a
video decoder system, you can use any of the available video decoders
(such as MPEG4, H.263, or H.264) in your system. To enable easy
integration with the client application, it is important that all codecs with
similar functionality use similar APIs. XDM was primarily defined as an
extension to XDAIS to ensure uniformity across different classes of codecs
(for example audio, video, image, and speech). The XDM standard defines
the following two APIs:
control()
process()
The control() API provides a standard way to control an algorithm
instance and receive status information from the algorithm in real-time. The
control() API replaces the algControl() API defined as part of the
IALG interface. The
(encode/decode) of data. This API represents a blocking call for the
encoder and the decoder, that is, with the usage of this API, the control is
returned to the calling application only after encode or decode of one unit
(frame) is completed. Since in case of DM365/DM368, the main encode or
decode is carried out by the hardware accelerators, the host processor
algNumAlloc()
algMoved(). For more details on these APIs, see TMS320 DSP
process() API does the basic processing
1-3
Introduction
from which the
parallel with the encode or the decode operation. To enable this, the
framework provides flexibility to the application to pend the encoder task
when the frame level computation is happening on coprocessor.
Apart from defining standardized APIs for multimedia codecs, XDM also
standardizes the generic parameters that the client application must pass
to these APIs. The client application can define additional implementation
specific parameters using extended data structures.
The following figure depicts the XDM interface to the client application.
process() call is made can be used by the application in
Client Application
XDM Interface
XDAIS Interface (IALG)
TI’s Codec Algorithms
As depicted in the figure, XDM is an extension to XDAIS and forms an
interface between the client application and the codec component. XDM
insulates the client application from component-level changes. Since TI’s
multimedia algorithms are XDM compliant, it provides you with the flexibility
to use any TI algorithm without changing the client application code. For
example, if you have developed a client application using an XDMcompliant MPEG4 video decoder, then you can easily replace MPEG4 with
another XDM-compliant video decoder, say H.263, with minimal changes
to the client application.
For more details, see eXpressDSP Digital Media (XDM) Standard API Reference (literature number SPRUEC8).
1.2.3 Framework Component
As discussed earlier, Framework Component acts like a middle layer
between the codec and OS and also serves as a resource manag er. The
following block diagram shows the FC components and their interfacing
structure.
Each component is explained in detail in the following sections.
1.2.3.1 IRES and RMAN
IRES is a generic, resource-agnostic, extendible resource query,
initialization and activation interface. The application framework defines,
implements and supports concrete resource interfaces in the form of IRES
extensions. Each algorithm implements the generic IRES interface, to
request one or more concrete IRES resources. IRES defines standard
interface functions that the framework uses to query, initialize,
activate/deactivate and reallocate concrete IRES resources. To create an
algorithm instance within an application framework, the algorithm and the
application framework agrees on the concrete IRES resource types that
are requested. The framework calls the IRES interface functions, in
addition to the IALG functions, to perform IRES resource initialization,
activation and deactivation.
FCtools
vicpsync
vicp
The IRES interface introduces support for a new standard protocol for
cooperative preemption, in addition to the IALG-style non-cooperative
sharing of scratch resources. Co-operative preemption allows activated
algorithms to yield to higher priority tasks sharing common scratch
resources. Framework components include the following modules and
interfaces to support algorithms requesting IRES-based resources:
IRES - Standard interface allowing the client application to query and
provide the algorithm with its requested IRES resources.
RMAN - Generic IRES-based resource manager, which manages and
grants concrete IRES resources to algorithms and applications. RMAN
uses a new standard interface, the IRESMAN, to support run-time
registration of concrete IRES resource managers.
Client applications call the algorithm’s IRES interface functions to query its
concrete IRES resource requirements. If the requested IRES resource type
matches a concrete IRES resource interface supported by the application
1-5
Introduction
framework, and if the resource is available, the client grants the algorithm
logical IRES resource handles representing the allotted resources. Each
handle provides the algorithm with access to the resource as defin ed by the
concrete IRES resource interface.
IRES interface definition and function-calling sequence is depicted in the
following figure. For more details, see Using IRES and RMAN Framework
Components for C64x+ (literature number SPRAAI5).
Figure 1-3. IRES Interface Definition and Function-calling Sequence.
In DM365/DM368, FC manages multiple resources for smooth intera ction with
other algorithms and application. The resources and the utilities p rovided by
FC are listed in this section.
1.2.3.2 HDVICP
The IRES HDVICP Resource Interface, IRES_HDVICP, allows algorithms
to request and receive handles representing Hardware Accelerator
resource, HDVICP, on supported hardware platforms. Algorithms can
request and acquire one of the co-processors using a single IRES request
descriptor. IRES_HDVICP is an example of a very simple resource type
definition, which operates at the granularity of the entire processor and
does not publish any details about the resource that is being acquired other
than the ‘id’ of the processor. It leaves it up to the algorithm to manage
internals of the resource based on the ID.
1.2.3.3 EDMA3
The IRES EDMA3 Resource Interface, IRES_EDMA3CHAN, allows
algorithms to request and receive handles representing EDMA3 resources
associated with a single EDMA3 channel. This is a very low-level resource
definition.
1-6
1.2.3.4 VICP
VICP resource manager provides access to its VICP compute engine and
its buffer. The compute engines are MJCP, NSF, IMX0 and IMX1. In
addition to this, the VICP buffers are also assumed as resources and can
be requested as either named buffers (for MPEG and JPEG codec
operation) of generic scratch buffer (for H.264 codec operation).
1.2.3.5 HDVICP Sync
Synchronization is necessary in a coprocessor system. HDVICP sync
provides framework support for synchronization between codec and HDVICP
coprocessor usage. This module is used by frameworks or application s, which
have xDIAS algorithms that use HDVICP hardware accelarators.
Introduction
Note:
The existing xDAIS IDMA3 and IDMA2 interfaces can be used to request
logical DMA channels, but the IRES EDMA3CHAN interface provides
the ability to request resources with finer precision than with IDMA2 or
IDMA3.
1.2.3.6 Memutils
This is for generic APIs to perform cache and memory related operations.
ARM TCM resource manager provides access to request ARM926 TCM
memory. ARM926 in DM365/DM368 has 32K TCM, which can be allocated
to codec/algorithm on request. The allocation is in granularity of 1/2K
blocks, which can be used as scratch memory by the codec/algorithm.
1.3 Overview of H.264 Base/Main/High Profile Encoder
H.264 (from ITU-T, also called as H.264/AVC) is a popular video coding
algorithm enabling high quality multimedia services on a limited bandwidth
network. H.264 standard defines several profiles and levels that specify
restrictions on the bit stream and hence limits the capabilities needed to
decode the bit streams. Each profile specifies a subset of algorithmic
features and limits that all decoders conforming to that profile may support.
Each level specifies a set of limits on the values that may be used by the
syntax elements in the profile.
1-7
Introduction
Some important H.264 profiles and their special features are (These are
feature as defined by H.264 standard, few of them may not be part of
DM365/DM368 H.264 implementation):
Baseline Profile:
o Only I and P type slices are present
o Only frame m ode (progressive) picture types are present
o Only CAVLC is supported
o ASO/FMO an d redundant slices for error concealment is supported
High Profile:
o Only I, P, and B type slices are present
o Frame and field picture modes (in progressive and interlaced modes)
picture types are present
o Both CAVLC and CABAC are supported
o ASO is not supported
o Tran sform 8x8 is supported
o Sequen ce scaling list is supported
o B frames and weighted prediction.
The input to the encoder is a YUV sequence, which can be of format 420
with the chroma components interleaved in little endian. The output of the
encoder is an H.264 encoded bit-stream in the byte-stream syntax. The
byte-stream consists of a sequence of byte-stream NAL unit syntax
structures. Each byte-stream NAL unit syntax structure contains one start
code prefix of size four bytes and value 0x00000001, followed by one NAL
unit syntax structure. The encoded frame data is a group of slices, each is
encapsulated in NAL units. The slice consists of the following:
Intra coded data: Spatial prediction mode and prediction error data,
subjected to DCT and later quantized.
Inter coded data: Motion information and residual error data
(differential data between two frames), subjected to DCT and later
quantized.
The first frame is called Instantaneous Decode Refresh (IDR) picture
frame. The decoder at the receiving end reconstructs the frame by spatial
intra-prediction specified by the mode and by adding the prediction error.
The subsequent frames may be intra or inter coded.
In case of inter coding, the decoder reconstructs the bit-stream by adding
the residual error data to the previously decoded image, at the location
specified by the motion information. This process is repeated until the
entire bit-stream is decoded.
1-8
In motion estimation, the encoder searches for the best match in the
available reference frame(s). After quantization, contents of some blocks
become zero. H.264 Encoder tracks this information and passes the
information of coded 4x4 blocks to inverse transform so that it can skip
computation for those blocks that contain all zero co-efficients and are not
coded.
p
Input
cture
Pi
Introduction
H.264 Encoder defines in-loop filtering to avoid blocks across the 4x4 block
boundaries. It is the second most computational task of H.264 encoding
process after motion estimation. In-loop filtering is applied on all 4x4 edges
as a post-process and the operations depend upon the edge strength of
the particular edge.
H.264 Encoder applies entropy coding methods to use context based
adaptivity, which in turn improves the coding performance. All the macro
blocks, which belong to a slice, must be encoded in a raster scan order.
Baseline profile uses the Context Adaptive Variable Length Coding
(CAVLC). CAVLC is the stage where transformed and quantized
coefficients are entropy coded using context adaptive table switching
across different symbols. The syntax defined by the H.264 Encoder stores
the information at 4x4 block level.
The following figure depicts the working of the encoder.
Coder
Control
Control
Transform /
Data
Quant
Transf coeffs
Intra-frame
Prediction
Motion-
ensation
Com
Motion-
Estimation
Figure 1-4. Block Diagram of H.264 Encoder.
From this point onwards, all references to H.264 Encoder mean H.264
Base/Main/High Profile Encoder only.
Scaling and Inv.
Transform
Deblocking
Filter
Reconstructed
Picture
Entropy
Coding
Output
Picture
Motion
Data
1-9
Introduction
1.4 Supported Services and Features
This user guide accompanies TI’s implementation of H.264 Encoder on the
DM365/DM368 platform.
This version of the codec has the following supported features of the
standard:
eXpressDSP Digital Media (XDM1.0 IVIDENC1) interface compliant
Compliant with H.264 High Profile up to level 5.0
Supports resolutions up to 2048x2048
Supports YUV420 semi planer input format for the frames
Supports progressive and interlaced encoding
Generates bit-stream compliant with H.264 standard
Supports CAVLC and CABAC encoding
Supports sequence scaling matrix
Supports transform 8x8 and transform 4x4
Supports frame based encoding with frame size being multiples of 2
Supports rate control (CBR and VBR)
Supports Insertion of Buffering Period and Picture Timing
Supplemental Enhancement Information (SEI) and Video Usability
Information (VUI)
Supports Unrestricted Motion Vectors (UMV)
Supports Half Pel and Quarter Pel Interpolation for motion estimation
Supports following Smart Codec features:
o Simple Two Pass (STP) Encoding
o Regi on of Interest (ROI)
Supports Low latency feature
o Can b e configured to provide output at NAL granularity or after entire
frame is encoded.
o Suppo rts encoded output in NAL stream or Bytes stream format
DM365/DM368 H.264 encoder can be configured in two modes:
Platinum mode, which gives 1080P@30fps performance in DM368 –
432 Mhz device
1-10
Version 1.1 backward compatible mode which gives performance of
720P@30fps on DM365/DM368 - 300 MHz
This version of the encoder does not support the following features as per
the Baseline Profile feature set:
Error Resilience features such as ASO/FMO and redundant slices
Introduction
Adaptive Reference Picture Marking
Reference Picture List Reordering
1.5 Comparison between version 01.10.00.xx wi th new version 02.00.00.xx
(Platinum Encoder)
Version 02.00.00.xx is a new enhanced codec version with 1.5x better
performance than earlier version without affecting quality. Few of the
enhancements are listed below:
Achieves 1080P@30fps on DM368.
More feature rich codecs which includes
• Smart codec technology
• Low latency API support
Version 02.00.00.xx also supports version 1.1 standard mode as a
backward compatible option. This can be enabled by setting
encodingPreset = XDM_USER_DEFINED and encQuality = 0. It
enables application that needs low-resolution encoding, lesser EDMA
channels or some specific tools like perceptual rate control.
Feature Version 1.1 - Gen 1 Versio n 2.0 - Platinum
Resolution Min – 128 x 96
Max – 2k x 2k
Performance 720P@30fps on DM365/DM368 1080P@30fps on DM368
EDMA channels 37 46
Support for Ver
1.1 – Gen1
NA YES
Min – 320 x 128
Max – Current (2k x 2k)
1-11
Introduction
This page is intentionally left blank
1-12
Chapter 2
Installation Overview
This chapter provides a brief description on the system requirements and
instructions for installing the codec component. It also provides information on
building and running the sample test application.
Topic Page
2.1 System Requirements for Linux 2-2
2.2 Installing the Component for Linux 2-2
2.3 Building and Running the Sample Test Application on Linux 2-4
2.4 Configuration Files 2-4
2.5 Standards Conformance and User-Defined Inputs 2-8
2.6 Uninstalling the Component 2-9
2-1
Installation Overview
2.1 System Requirements for Linux
This section describes the hardware and software requirement s for the
normal functioning of the codec in MV Linux OS. For details about the
version of the tools and software, see Release Note
2.1.1 Hardware
DM365/DM368 EVM (Set the bits 2 and 3 of switch SW4 to low(0)
position and Set the bits 4 and 5 of switch SW5 to high(1) position)
RS232 cable and network cable
2.1.2 Software
The following are the software requirements for the normal functioning of
the codec:
Build Environment: This project is built using Linux with MVL ARM
tool chain.
ARM Tool Chain: This project is compiled and linked using MVL ARM
tool chain.
2.2 Installing the Component for Linux
The codec component is released as a compressed archive. To install the
codec, extract the contents of the tar file onto your local hard disk. The tar
file extraction creates a directory called
dm365_h264enc_xx_xx_xx_xx_production.
directories created in this directory.
Note:
xx_xx_xx_xx in the directory name is the version of the codec. For
example, If the version of the codec is 02.00.01.00, then the directory
created on extraction of tar file is
dm365_h264enc_02_00_01_00_production.
Figure 2-5 shows the sub-
2-2
Installation Overview
Figure 2-5. Component Directory Structure for Linux.
Table 2-2 provides a description of the sub-directories created in the
dm365_h264enc_xx_xx_xx_xx_production directory.
Table 2-2. Component Directories for Linux.
Sub-Directory Description
\package Contains files related while building the package
\packages\ti\sdo\codecs\h264enc\lib Contains the codec library files on host
\packages\ti\sdo\codecs\h264enc\docs Contains user guide, datasheet, and release notes
\packages\ti\sdo\codecs\h264enc\apps\clie
Contains read-only reference output to be used for verifying
against codec output
Contains configuration parameter files
2.3 Building and Running the Sample Test Application on Linux
To build the sample test application in linux environment, follow these
steps
1) Verify that dma library h264v_ti_dma_dm365.a exists in the
packages\ti\sdo\codecs\h264enc\lib.
2) Verify that codec object library library h264venc_ti_arm926.a exists in
the \packages\ti\sdo\codecs\h264enc\lib.
3) Ensure that you have installed the LSP, Montavista arm tool chain,
XDC, Framework Components releases with version numbers that are
mentioned in the release notes.
4) In the folder \packages\ti\sdo\codecs\h264enc\client\build\arm926,
change the paths in the file rules.make according to your setup.
5) Open the command prompt at the sub-directory
\packages\ti\sdo\codecs\h264enc\client\build\arm926 and type the
command make. This generates an executable file h264venc-r in the
same directory.
To run the executable generated from the above steps:
1) Load the kernel modules by typing the command ./loadmodules.sh,
which initializes the CMEM pools.
2) Now branch to the directory where the executable is present and type
./h264venc-r in the command window to run.
2.4 Configuration Files
This codec is shipped along with:
Generic configuration file ( testvecs.cfg) – list of configuration files for
running the codec on sample test application.
Encoder configuration file ( testparams.cfg) – specifies the
configuration parameters used by the test application to configure the
Encoder.
2-4
2.4.1 Generic Configuration File
The sample test application shipped along with the codec uses the
configuration file, Testvecs.cfg for determining the input and reference files
for running the codec and checking for compliance. The testvecs.cfg file is
available in the
\packages\ti\sdo\codecs\h264enc\apps\client\test\testvecs\config subdirectory.
The format of the testvecs.cfg file is:
X
config
input
output/reference
recon
where:
X may be set as:
o 1 - for co mpliance checking, no output file is created
o 0 - for writing the output to the output file
Installation Overview
config is the Encoderconfiguration file. For details, see Section 2.4.2.
input is the input file name (use complete path).
output/reference is the output file name (if X is 0) or reference file
name (if
recon is reconstructed YUV output file name (use complete path).
X is 1) (use complete path).
2-5
Installation Overview
A sample testvecs.cfg file is as shown:
For output dump mode:
The encoder configuration file, testparams.cfg contains the configuration
parameters required for the encoder. The testparams.cfg file is available in
the \client\test\testvecs\config sub-directory.
A sample Testparams.cfg file is as shown:
# Config File Format is as follows
# <ParameterName> = <ParameterValue> # Comment
####################################################
Parameters
####################################################
ImageWidth = 1280 # Image width in Pels, must be multiple of 16
ImageHeight = 720 # Image height in Pels, must be multiple of 16
FrameRate = 30000 # Frame Rate per second*1000(1-120)
BitRate = 4000000 # Bitrate(bps) #if ZERO=>> RC is OFF
ChromaFormat = 9 # 9 => XDM_YUV_420P
InterlacedVideo = 0 # 0: Progressive, 1 :Interlaced
TimerScale = 60. # Timer Resolution for Picture Timing
NumUnitsInTicks = 1 # Number of Timer units per Tick
AspectRatioWidth = 1 # Aspect Ratio Width Scale
AspectRatioHeight = 1 # Aspect Ratio Height Scale
PixelRange = 1 # 1 =>Y- 0 to 255, Cb/Cr-0 to 255
0 => Y-16 to 235, Cb/Cr-16 to 240
EnableVUIParam = 1 # 1 => Enable VUI parameters,
0 => Disable VUI Parameters
EnableBufSEI = 1 # 1 => Enable Buffering Period SEI Message,
0 => Disable
ME_Type = 0 # ME search algorithm
0 => Normal,
1 => Low Power
RC_PRESET = 5 # 1 => Low Delay,
2 => Storage,
3 => 2 Pass,
4 => None,
5 => user defined
ENC_PRESET = 3 # 3 => User Defined Parameters
####################################################
# Encoder Control
####################################################
ProfileIDC = 100 # Profile IDC (66=baseline, 77=main,
100=high profile)
2-6
Loading...
+ 101 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.