Da Vinci codec engine codec Engine (CE) Ceapp.cfg_davinc da Vinci

DaVinci is a DSP and arm dual-core architecture of the SOC chip. The interaction between the chip and the outside is managed via arm-side MontaVista Linux and related drivers and applications, and the DSP end only deals with codec-related algorithms. The communication and interaction between DSP and arm is done through the engine (Engine) and the servers (server).

1. Codec engine (Codec Engine)
A. Core Engine API
From the application, CE is a set of APIs used to invoke the Xdais algorithm, which allows users to instantiate and invoke Xdais algorithms. Leonardo da Vinci provides a set of visa interfaces for interacting with applications with XDM compatible Xdais algorithms. Need to be aware that whether the algorithm is running in the local (arm end), or the remote (DSP end), regardless of the hardware system is only arm or only DSP or both, and no matter the OS is Linux, VxWorks, Dsp/bios, or wince, the algorithm interface calls are consistent. This point through the engine configuration file *.cfg can be seen, and through the configuration file can determine their own codec is running on the arm or DSP end.
Ce includes core engine API and Visa API, core engine API related Interface module: initialization module (ceruntime_), CE Runtime Module (engine_), Abstraction Layer Memory Module (MEMORY_); The interface modules of the VISA API are: Video Coding Interface (VIDENCX_), Video decoding Interface (VIDDECX_), Audio Coding Interface (AUDENCX_), Audio decoding Interface (AUDDECX_), each module is included in the corresponding header file.
The application must use the three related modules of the CE core engine to open and close the instance of the codec engine. Note that the engine handle is not thread-protected, for each thread that uses CE alone, it must perform engine_open and manage its own engine handle, while for multi-threaded applications, you can also sequentially access a shared engine instance, which we are currently using. Only one engine handle is defined and multiple decoders are shared. The codec engine also provides the relevant APIs to access the system's memory usage and CPU load information, which is as follows:
>engine_open: Open a codec engine;
>engine_close: Closes a codec engine, usually after deleting an algorithm instance to release the related resource;
>engine_getcpuload: Get CPU usage percent;
>engine_getlasterror: Gets the error code that was raised by the last failed operation;
>engine_getusedmem: Getting Memory usage
Specify the header files that the engine needs to include and how to define and use the engine to refer to the engineering instance EXAMPLE_DSP1. We are now sharing an engine handle with multiple decoders, such as:
static String enginename = "Videodec"; /* Define engine name, CEAPP.CFG configuration file will use * *
Engine_handle cehandle_264 = NULL; /* Create a 264 decoder engine handle * *
Engine_error errorcode; /* Used to return the status information of the engine open, the meaning of the different return value can refer to the corresponding header file * *
cehandle_264 = Engine_open (Enginename, NULL, &errorcode);

Based on this understanding, I feel that if multiple threads need to use their own engine alone, they should be able to define multiple engine names and create multiple engine handles, at which point each thread must execute Engine_open () separately and manage its own engine handle.

B. VISA API
@ Create an Algorithm instance: *_create ()
After the codec engine cehandle_264 is created, you can use it to create your own algorithm instance, and you need to invoke *_create (), where * can be the name of the corresponding codec module for video or audio, for example:
static String Decodername = "H264dec"; /* Define the Decoding module name, used to identify the algorithm name, CEAPP.CFG will use the * *
Viddec_handle 264Handle; /* Create decoder handle * *
264Handle = Viddec_create (cehandle_264, Decodername, NULL); /* On the engine allocation and initial resolution of the code, the third parameter can be used to initialize the relevant parameters of the algorithm, these parameters control the various behavior of the algorithm, the parameter structure according to the visa encoding or decoder different, the specific structure of the content can refer to the header file * * *

@ Closes an algorithm instance: *_delete ()
Viddec_delete (264Handle); /* Note: The deletion algorithm can be invoked only when the memory slice associated with the algorithm is cleared.

@ Control An Algorithm instance: *_control ()
Viddec_control (264Handle, Xdm_setparame, Dynamicparamsptr, &encstatus);
The first parameter is an open algorithm instance handle; The second parameter is the command ID of an integral type, which is defined in xdm.h; The third parameter is the need to dynamically change the algorithm parameters, such as in Create the third parameter has already initialized some parameters for the decoder, where it can be modified, but the modification is conditional, the specific structure of the content can refer to the header file; The fourth parameter is a structural body variable, different modules have different structure, specific reference header file.

@ Processing data through algorithm instances: *_process ()
Status = Viddec_process (264Handle &inbufdesc,&outbufdesc, &inargs, &outargs);
The second and third parameters are the structure of the Xdm_bufdesc type, which contains the number of memory fragments and the start address and length information, and the fourth fifth parameter provides input and output addresses for the algorithm instance respectively.

All of the above structures can be found under: \OPT\DVEVM_#_#\XDAIS_#_#\PACKAGES\XDAIS\DM and can be modified. It is not yet known how these structures are used in particular.


C. Compiling the "one" codec engine----engine configuration file (ceapp.cfg)
The engine configuration file is stored as a *.cfg file, we currently have two *.cfg:app inside the project containing CEAPP.CFG, which contains the configuration of the engine, there is a video_ Copy.cfg, under Server, is one of the server's configuration files, which is described later. Ceapp.cfg uses PACKAGE.XDC to produce a *.c file and a linked command script file through the makefile file. An engine configuration file contains the name of the engine and the codecs and their names contained within the engine. It can be seen from here that the role of the name "H264dec", defined above, is used to identify the algorithm category in an application, and it is also possible to see that an engine can be shared by several codec modules. We take the contents of the Ceapp.cfg file as an example to illustrate the implications of configuration parameters:

/*--------------Set up osal----------------* *
var Osalglobal = xdc.usemodule (' Ti.sdo.ce.osal.Global ');
Osalglobal.runtimeenv = Osalglobal.dsplink_linux;
Note: These two sentences are to set the global module to make the configuration script effective, and then to set the engine's operating environment, that is, the Dsp/bios link and the Linux OS that need to be used.


/*--------------Get codec modules;i.e.implementation of codecs-------* *
var h264dec = xdc.usemodule (' Codecs.h264dec.H264DEC ');
Note: Set the codec that needs to be used, that is, we are going to use the H264DEC in the given directory. Note that we are currently using the codec directory of the videnc_copy provided by TI, in fact we can modify, the other front we define the name of the decoder used in the lowercase ' h264dec ', where the configuration changed to uppercase.

* *---------------Engine cofiguation---------------* *
var Engine = xdc.usemodule (' Ti.sdo.ce.Engine ');
var demoengine = engine.create ("Videodec", [
{Name: "H264dec", Mod:h264dec, Local:false},
/* {name: "H264enc", Mod:h264enc, Local:false} ... If there is one.
]);
Note: First make the engine in the Ti.sdo.ce directory available, and then create an engine with the created (). Each engine has a name that will be used by the developer (e.g., when the engine is turned on, the engine name we defined earlier is "H264dec"). The parameter of Create () is an array of algorithm descriptions, each of which contains the following fields:
>name: The name of the algorithm instance, in identifying the algorithm to use, Videc_creat () and other visa API parameters, such as the previous definition of the 264 decoder name "H264dec";
>mod: An algorithmic implementation module used to identify the actual, usually the upper case of name, such as H264dec.
>local: If True, the algorithm instance is implemented on the arm side, otherwise the algorithm instance of DSP end is created by codec server.

Demoengine.server = "./encodecombo.x64p";
Note: Used to indicate codec Server.

--------------------------------------------------------------------------------------------------------------- --------------------

Comparison of two cfg:
From the arm and DSP communication call mechanism can be seen, ARM end customer application instruction through the CE package by the osal layer through the Dsplink sent to the remote DSP server, the server, the first server skeleton through the osal layer to obtain instructions and specific codec applications, DSP Codec processing and then after the server packaged by the Osal layer by the Dsplink back to the local arm CE, thus, two CFG configuration files need to set up osal and communication environment Dsplink, and affirmed the use of a variety of codecs, affirmed by each encoder or decoder ( Usually the encoder s and decoder s are placed in two folders respectively, the encoder or decoder path declared in the two CFG files is consistent, such as: var viddec_copy = Xdc.usemodule (' Codecs.viddec_copy. Viddec_copy ');(. Represents a directory path, viddec_copy directory has a viddec_copy.xs file)

-

-

-Introduction of another person:

Codec Server (CS) is a binary file, it integrates codecs, framework components and some system code, when the CS running on the DSP, it uses the Dsp/bios as its core. CS also includes a related Dsp/bios thread for the customer request. CS can represent the actual DSP hardware, the mirrored files imported to the DSP, and the tasks that are running, and their configuration requires two steps:
> Configure Dsp/bios via TCF scripting language;
> Configuration of the remaining components through XDC, such as: FC Components, Dsp/bios Link, Codec engine.
The configured server mirroring file is used in the engine configuration file (CEAPP.CFG), as described above Demoengine.server = "./encodecombo.x64p";

A. Compiling a codec server
The process of creating a CS image file is accomplished through the XDC tool described earlier, and the CS requires a MAIN.C and associated BIOS configuration script when it is created. tcf file.
>TCF: script files are mainly configured for the Dsp/bios kernel, such as: Define the memory map of the DSP, set the interrupt vector table of the DSP, create and initialize other Dsp/bios data objects, etc., specifically see VIDEO_COPY.TCF, Notice that I added a parameter configuration to trace in it that was not originally.

>MAIN.C: As long as your algorithm to achieve the XDm interface, you need a MAIN.C program to initialize CE, and then use other configuration scripts to create a server mirror *.x64p. In addition to the call Ceruntime_init () initialization CE, is the trace-related function initialization and processing, this part of the MAIN.C. Another point to note here is that the cache reconfiguration can be implemented here because the cache configuration may not work in the TCF file, which can be matched in functional code here, which has not been noticed before. Here is a little understand is that in ceapp_init () has done a ceruntime_init (), why do you have to do at CS? (I think it is because the first compile CS, generate *.x64p, and then compile app end, this can be understood as: As long as your algorithm to achieve the XDm interface, you need to initialize the CE ceruntime_init (), and the CS compiler is called after the XDM package codec generated * . A64P's)

>XDC Related documents:
>>>package.xdc
/*--------------Declare the package name-----------------* *
Package server{}
Our current. XDC is: Package server.video.copy, this is \server\video_copy\. Xdc, should not be changed)

>>>PACKAGE.BLD: Declare the packages that must be included, link command scripts, TCF files and some source files, define compilation attributes, platforms, objects, and so on.

>>>server.cfg: This is the focus of CS configuration, described below.
/* First part: Declare the operating environment and various codec modules, and ce.cfg similar * *
/*--------------Set up osal----------------* *
var Osalglobal = xdc.usemodule (' Ti.sdo.ce.osal.Global ');
Osalglobal.runtimeenv = Osalglobal.dsplink_bios;
Note: These two sentences are set the global module to make the configuration script effective, and then set the engine's operating environment, that is, need to use the Dsp/bios Link, and ce.cfg a bit different.

/*---------------Server cofiguation---------------* *
var Server = xdc.usemodule (' Tisdo.ce.Server ');
Server.threadAttrs.stackSize = 16384;
Server.threadAttrs.priority = Server.minpri;

/*--------------Get codec modules;i.e.implementation of codecs-------* *
var h264dec = xdc.usemodule (' Codecs.h264dec.H264DEC '); With Ce.cfg, pay attention to the use of H264dec logo.

Server.algs = [
{name: ' H264dec ', mod:h264dec,threadattrs:{stacksize:4096,stackmemid:0,priority:server.minpri+1}}, {... if have.},
];

/* Part II: Configuration of DSKT2 and DMAN3: Xdais algorithm memory and DMA allocation, reference configuration file * *