xdm 0.9 to 1.0 migration - texas instruments 2008-08-11آ  xdm 0.9 to xdm 1.0 migration 1...

Download xDM 0.9 to 1.0 Migration - Texas Instruments 2008-08-11آ  xDM 0.9 to xDM 1.0 Migration 1 Introduction

Post on 23-Mar-2020

1 views

Category:

Documents

0 download

Embed Size (px)

TRANSCRIPT

  • xDM 0.9 to 1.0 Migration

    ABSTRACT

    xDM is an extension of xDAIS for multimedia algorithms and provides uniform APIs for basic functionality, parameters and status. It enables plug and play for multimedia codecs across standards and vendors. This document describes the changes between xDM 0.9 to xDM1.0 and provides a guideline for the migration from xDM 0.9 to xDM 1.0.

    1

  • xDM 0.9 to xDM 1.0 Migration

    Contents 1 Introduction .....................................................................................................................................3 2 Why XDM 1.0? .................................................................................................................................3

    2.1 Drawbacks of xDM 0.9 ..............................................................................................................3 2.2 Improved Buffer Management for Video ...................................................................................4 2.3 Hooks for Video Transcoding ....................................................................................................4 2.4 Improved channel density for speech........................................................................................4 2.5 Introduction of Single Buffer Descriptor.....................................................................................5 2.6 Other Improvements..................................................................................................................5

    3 Header File Cchanges between xDM0.9 and xDM 1.0..................................................................6 4 Codec Changes for xDM 1.0...........................................................................................................6 5 Application Changes for xDM 1.0 ..................................................................................................6

    5.1 Frame Buffer Management by Application ................................................................................6 6 Important Links .............................................................................................................................14

    Figures Figure 1. Interaction of frame buffers between application and framework.................................7

    2 xDM 0.9 to 1.0 Migration

  • xDM 0.9 to xDM 1.0 Migration

    1 Introduction xDM is a uniform lightweight APIs used across various classes of multimedia algorithms, such as audio, video, speech, and image. This document details the changes between xDM 0.9 to xDM 1.0 and its implications in existing codec and application software. This document provides the guidelines to users who are using xDM0.9 in their application/codec and need to migrate to xDM 1.0.

    xDM 0.9 evolved around programmable DSP that can handle SD multimedia content. The SoCs had all the multimedia algorithms running on a single processor. As the technology evolved and demand increased for HD video, TI SoCs were built using H/W accelerators. xDM 0.9 was not capable of handling such designs, which led to the introduction of xDM 1.0.

    Many new interface changes were added to xDM 1.0 based on feedback accumulated for xDM 0.9. These changes effected all the interfaces namely, speech, audio and video. A brief listing is described below -

    • xDM 1.0 interfaces are provided in addition to the previously released xDM 0.9 interfaces. Both 0.9 and 1.0 interfaces are provided in the ti.xdais.dm package.

    o To enable both xDM 0.9 and 1.0 compliant algorithms/frameworks/apps to reside in a system, unique names were created as new interfaces were developed. For example, in xDM 0.9, video decoders used the IVIDDEC_ prefix; in xDM 1.0, they use the IVIDDEC2_ prefix. In this way, there is no naming collision, and the two classes can coexist in a single application.

    o In fact, if an algorithm provider so wished, the algorithm can implement both interfaces. It can provide and document two IALG function tables, one complying with the 0.9 interface, and the other complying with the 1.0 interface. The system integrator could then choose which one to instantiate, based on the interface the application using the algorithm was written.

    2 Why XDM 1.0? This sections details information about why xDM 1.0 came into existence.

    2.1 Drawbacks of xDM 0.9

    This section provides information on the drawbacks of xDM 0.9 that required commissioning of updated interfaces.

    xDM 0.9 was essentially a beta interface; it was an initial effort to standardize the application’s view of Video/Imaging/Speech/Audio codecs.

    Although xDM 0.9 has been highly successful and many codecs implement these interfaces, it has the following limitations:

    xDM 0.9 to 1.0 Migration 3

  • xDM 0.9 to xDM 1.0 Migration

    • Requires application customizations for several advanced algorithms. Recall that VISA is intended to enable plug and play (from a base parameters perspective), that is, a MPEG4 decoder can be swapped for another MPEG2 decoder without modifying the application code. However, the only way to support interlaced content in MPEG2 Main Profile is to extend xDM 0.9 and add custom application logic (specifically related to outArgs) to distinguish between when the codec is being primed (first frame) and when a frame is interlaced. Therefore, if the first frame of an MPEG2 clip is interlaced, the application cannot determine what to do in xDM 0.9 context. The DVSDK 1.30 demos on DM6446 add custom logic to accommodate this. However, with DM6467 DVSDK 1.40, the demos are ‘clean’ with respect to MPEG2 decoder since IVIDDEC2 comprehends this issue. For more information about this, click here.

    • Inefficient channel density for speech. When creating systems with multiple speech decoder channels, the size per channel structures is important. For example, several fields in ISPHDEC_Params were 32 bits where 16 bits would have been sufficient.

    • Incompatible I/O buffers for speech encoder and decoder which was an issue incase of hybrid devices like DM644x. Remotablity was a another limitation. xDM1.0 specifies more generic buffer pointers for speech encoders and decoders.

    • Did not comprehend new application scenarios. The initial focus was on Video, Imaging, Audio and Speech. However interfaces such as Transcode and Video Analytics were not comprehended at the time of xDM 0.9.

    In summary, xDM 0.9 had some limitations. However, it is a supported interface and works well for common codecs such as MPEG4 video decoder and AAC audio decoder. xDM 1.0 was necessary to handle additional High-Definition use-cases and other new applications. The fact that both interfaces can coexist (IVIDDEC, IVIDDEC2, and so on) improves the migration. However, it is recommend that codec producers and system integrators adopt xDM 1.0 for the reasons outlined in this document.

    2.2 Improved Buffer Management for Video

    High Definition video handling has to be more sensitive towards data bandwidth and memory requirements.

    With the new xDM 1.0, decoder does not request for frame buffer at the time of alg_create(). It uses buffer from xDM1_BufDesc *outBufs, which it obtains during each decode process call. Hence, there is no distinction between algorithm and application buffers. The framework needs to ensure that it does not overwrite the buffers that are locked by the codec.

    2.3 Hooks for Video Transcoding

    In xDM 1.0, new element was added in base class to help transcoding feature.

    2.4 Improved Channel Density for Speech

    To improve channel density, the sizes of many of the speech structure fields have decreased. Only the speech interfaces were compressed as those interfaces are often used in high density systems.

    4 xDM 0.9 to 1.0 Migration

    http://wiki.davincidsp.com/index.php?title=Extending_data_structures_in_xDM#The_perils_of_extending_inArgs.2C_outArgs

  • xDM 0.9 to xDM 1.0 Migration

    Note:

    Structures were padded as required to preserve 32-bit alignment. This is essential as many structures support extended arguments that immediately follow the base structures and these fields must be 32-bit aligned.

    2.5 Introduction of Single Buffer Descriptor

    For improved performance of codec classes that do not require multiple buffers (that is, xDM_BufDesc, xDM_SingleBufDesc) was introduced.

    To enable applications and frameworks integrating xDM algorithms, xDM1_BufDesc and xDM1_SingleBufDesc were introduced. These buffer descriptors include a per-buffer "access mask" indicating how the algorithm accessed that buffer. A typical use case for this flag is that applications can now identify when an algorithm filled a buffer using DMA, rather than CPU access, and avoid unnecessary cache write back-related maintenance of that buffer. Previously, the application had to know the behavior of the algorithm, and assume there may be dirty cache write lines.

    2.6 Other Improvements

    • Introduced XDM_EUNSUPPORTED error value (as a peer to XDM_EOK and XDM_EFAIL). This will also be reflected in the xDM 1.0 classes (example, ISPHDEC1_EUNSUPPORTED)

    o XDM_ERUNTIME was removed. As the xDM 0.9 interface included this definition, it is available for backward compatibility in xdm.h, but the source must #define XDM_INCLUDE_DOT9_SUPPORT to have XDM_ERUNTIME defined.

    • Introduced XDM_CmdId, XDM_GETVERSION. Applications can issue this command to query the algorithms for its version.

    • Introduced a data field of type XDM1_SingleBufD

Recommended

View more >