Codec FAQ

Where can I find out what codecs are available from Texas Instruments?

The multimedia codec software portfolio available from Texas Instruments is available on the TI Digital Media Software Page

How can I evaluate the codecs available from Texas Instruments?

The multimedia codec evaluation program provides free 60-day evaluations. Request a free evaluation here.

If the evaluation codec is not received within one week, please contact support@ti.com

Are the evaluation codecs fully functional?

The evaluation codecs are fully functional however they are watermarked for digital protection.

I am evaluating audio codecs from TI and I hear a repetitive tone. Is this normal?

This is normal, this tone is present in the evaluation audio codecs.

Where can I get DVSDK combos with evaluation codecs?

This table describes the current state of c64P eval codecs in the various DVSDK programs: -

DVSDK Eval Codec inclusion matrix

DVSDK version	Eval Codecs incl in DVSDK?	Combo Version #
1.30 DM644x	No. Download eval combo here	>= v1.35
1.40 DM646x	No. Download eval combo here	>= v1.16
2.0 DM644x, DM646x	Yes
3.0 OMAP3	Yes

These eval combos should be "drop-in" i.e. the only difference is that the codecs are evaluation-codecs e.g. audio beep, video watermark or timeout after a certain # frames.

See the Codec Combos Evaluation wiki article for more information.

How do I flip between evaluation and production codecs?

You've just evaluated a codec and like it. Now you purchase the production version. What now?

One method for switching between eval and production is outlined below. It assumes you are on a Linux environment (since it leverages symbolic links).

Let's look at e.g. Dolby AC3 decoder XDM 1.0 (IAUDDEC1) version 1.20.001

• let's say we've got both eval and prod versions in a directory as follows: -

[alan@lab1 audio_combo_xdm1]$ ls -al ~/workdir/codecs/
drwxr-xr-x   4 alan alan 4096 Nov 19 08:09 c64xplus_dolbyac3dec_1_20_001_evaluation
drwxr-xr-x   4 alan alan 4096 Nov 19 07:21 c64xplus_dolbyac3dec_1_20_001_production

• assign a symbolic link to the base codec package directory

[alan@lab1 audio_combo_xdm1]$ cd packages/ti/sdo/codecs/
[alan@lab1 codecs]$ ln -s ~/workdir/codecs/c64xplus_dolbyac3dec_1_20_001_evaluation/packages/ti/sdo/codecs/dolbyac3dec .

When running pwd you should now see e.g.

[alan@lab1 codecs]$ ls -al
lrwxrwxrwx  1 alan alan  101 Nov 19 12:06 dolbyac3dec -> /home/alan/workdir/codecs/c64xplus_dolbyac3dec_1_20_001_evaluation/packages/ti/sdo/codecs/dolbyac3dec

• build the combo and evaluate it using the demos, DVTB, or DMAI for example.

Now let's switch to the production version.

• remove the previous symbolic link and assign a new link to the base codec package directory for the prod version.

[alan@lab1 audio_combo_xdm1]$ cd packages/ti/sdo/codecs/
[alan@lab1 codecs]$ rm dolbyac3dec
[alan@lab1 codecs]$ ln -s ~/workdir/codecs/c64xplus_dolbyac3dec_1_20_001_production/packages/ti/sdo/codecs/dolbyac3dec .

• build the combo.

Uh oh! It may have failed with a message like this: -

undefined                        first referenced
 symbol                              in file
---------                        ----------------
_DOLBYAC3DEC_TI_IDOLBYAC3DEC     package/cfg/audio_combo_evmdm6467_x64P.o64P
>>   error: symbol referencing errors - 'audio_combo_evmdm6467.x64P' not built

Traverse further up the build log and you'll see: -

will link with ti.sdo.codecs.dolbyac3dec:null

That's bad - no library got linked in (hence the unresolved references at link time).

• resolve the problem by fixing the server configuration.

The server/combo probably has something like this in the packages/ti/servers/audio_combo_evmdm6467/codec.cfg file (your cfg file may be named differently): -

<syntaxhighlight lang="javascript"> var DOLBYAC3DEC = xdc.useModule('ti.sdo.codecs.dolbyac3dec.ce.DOLBYAC3DEC');

       // Package Config
       DOLBYAC3DEC.alg.watermark = true;
       DOLBYAC3DEC.alg.codeSection = 'DDR2';
       DOLBYAC3DEC.alg.udataSection = 'DDR2';
       DOLBYAC3DEC.alg.dataSection = 'DDR2';

</syntaxhighlight>

Since we're now using the production version, change the watermark setting to: -

<syntaxhighlight lang="javascript">

       DOLBYAC3DEC.alg.watermark = false;

</syntaxhighlight>

Now it should build fine. Check the build log and you'll see e.g.

will link with ti.sdo.codecs.dolbyac3dec:lib/dolbyac3dec_ti.l64P

You might ask "Why not just have the same name for eval .v. prod so there's no extra work?". Fair question - however it would then be impossible to differentiate between eval and prod libraries by filename.

How do I use a codec in a non-RTSC based framework?

See How to use a RTSC codec package in a non-RTSC environment

How do I know if my server executable is using evaluation or production codecs?

There are several ways to check this.

• The simplest is simply by name. In DVSDK releases >= 2.0 the combos are as follows (example given for decode combo): -

Server/Combo contents

filename	contents	memory map file(s)
decodeCombo.x64P	production codecs	package/info/decodeCombo.x64P.info.js, package/info/decodeCombo.x64P.DataSheet.html
decodeCombo_e.x64P	evaluation codecs	package/info/decodeCombo_e.x64P.info.js, package/info/decodeCombo_e.x64P.DataSheet.html

The '_e' denotes evaluation.

• If the server/combo name is the same in both evaluation .v. production version then: -

Look at the generated package/cfg/*.map file.

You'll see e.g.

.text:H264VDEC_TI_cSect1
*          0    87a00000    00083c00
                  87a00000    00083c00     h264vdec_ti_e.l64P : h264vdec_ti_plink.l64P (.text:H264VDEC_TI_cSect1)

.text      0    87a83c00    00085600
                  87a83c00    000238c0     jpegdec_ti_e.l64P : jpegdec_ti_plink.o64P (.text:JPEGIDEC_TI_cSect)

Again '_e' denotes evaluation, otherwise it is a production version.

Look at the generated package/cfg/*.xdl file.

You'll see e.g.

-l"/home/workdir/omap3530_dvsdk_combos_3_16/packages/ti/sdo/codecs/h264dec/lib/h264vdec_ti_e.l64P"
-l"/home/workdir/omap3530_dvsdk_combos_3_16/packages/ti/sdo/codecs/jpegdec/lib/jpegdec_ti_e.l64P"

Run it!

As per above FAQs, the audio eval codecs typically emit a periodic beep, whilst the video codecs are either watermarked or incorporate a timeout after N frames.

My codec is built with TI CGT 6.1.x but the server/combo is built with CGT 6.0.x - will this work?

The 'standard' mechanism is typically that system integrators (server/combo-creators) should use CGT 6.1.x if any of the server's libraries are built with this version. For example, the implementation of the linker changed from CGT 6.0.x to 6.1.x. Also if any 6.1-specific-features were used in a library (such as Profile-based Optimization) then obviously CGT 6.0.x could not be used to build the final app (server/combo).

That said, upgrading to a new CGT often impacts many libraries, many sites, many 3rd parties on a single project. Hence a CGT 6.0.x patch exists via release 6.0.21 - the specific bugfix is SDSCM00029193 "Version 6.0.x linker generates incorrect relocation overflow messages when linking a partial link object file built with v6.1.X" as indicated in the 6.0.21 Release Notes.

You can now successfully link codecs built with CGT 6.1.x if you upgrade your server to use CGT 6.0.21 which is just a point/patch-release update and therefore low-risk. No other components (Codec Eng, Framework components, DSPLink etc) need to change.

To complete the story we show a use-case. Let's take the new TI H.264 Encoder for dm6446 v2.00.004. It's Release Notes indicate it was built with CGT 6.1.2. Let's also say we want to (re)build the standard loopback combo in the DVSDK 1.35 combos that came with DVSDK 1.30 using the DVSDK-recommended CGT 6.0.15.

The pre-step (Step 0) is obviously to copy in the new codec to the directory structure. This sounds obvious/trivial however you typically can't just rename the existing directory codecs/h264enc to codecs/h264enc_bak and copy in the new one to codecs/h264enc. That's because the top-level Makefile is typically invoking a command xdc -PR . which builds any RTSC package it finds underneath the current directory. The XDC tools will get confused when they meet h264enc_bak because the directory doesnt match the module name. So if you need to copy in a new codec then first move the previous one somewhere completely out of the current build environment. Or better still do something like this with symbolic links.

After adding the new codec we get an error like this in CGT 6.0.15: -

>> warning: creating output section $build.attributes without SECTIONS
            specification
>>   error: relocation overflow occurred at address 0x00013328 in section
            '.text:H264VENC_TI_cSect1' of input file 'h264venc_ti_plink.o64P

Step 1 is to upgrade to 6.0.21. Once you've installed it [linux codegen distrubtion used in this example] you need to modify your config.bld to use it e.g. <syntaxhighlight lang="javascript"> //C64P.rootDir = "/opt/dmsw/cg6x_6_0_16"; C64P.rootDir = "/home/alan/workdir/cgt_releases/cg6x_6_0_21"; </syntaxhighlight>

Now rebuild - in theory you're done. In practice, for this particular codec, you're not done since you likely hit the following error: -

>> warning: creating output section $build.attributes without SECTIONS
            specification
>> warning: can't find a memory area named 'undefined' on page 0 for allocation
            of '.const:H264VENC_TI_dSect1'
>>   error: can't find any memory areas for allocation of
            '.const:H264VENC_TI_dSect1'

Admittedly, from the error message, this is difficult to diagnose. What it's telling you is that the .const:H264VENC_TI_dSect1 linker output section was not assigned to a named memory range. Its 'hanging out there' with an incomplete assignment.

To fix this, step 2 is to modify packages/ti/sdo/servers/loopback/loopback.cfg.

Add the following (somewhere after the var H264ENC = xdc.useModule('ti.sdo.codecs.h264enc.ce.H264ENC'); instantiation statement)

<syntaxhighlight lang="javascript"> H264ENC.alg.dataSection = "DDR"; H264ENC.alg.udataSection = "DDR"; </syntaxhighlight>

This is necessary because the new H.264 Encoder introduced 2 more configuration parameters for finer-grain memory placement of data. You can verify this by comparing the new and old codecs/h264enc/link.xdt (this file represents the codecs contribution to the linking process )

Now it should rebuild and run correctly.

NOTES

• You may still get a benign warning >> warning: creating output section $build.attributes without SECTIONS specification. This is because the codec built with 6.1.x automatically brought in usage of this new (internal) section. The 6.1.x Codegen tools "know" about this section (so you don't need to modify your link.cmd files) but the 6.0.x Codegen tools do not.
• You may also get a warning Warning: incompatible use of package 'ti.sdo.ce': imported ti.sdo.ce [1,0,5,1200332924185], ti.sdo.codecs.h264enc.ce was built with ti.sdo.ce [1, 0, 6]. This is unfortunate. It occurs because the codec package producer did not fully adhere to the advice presented in Rule 5 of the Top 10 Codec Package Requirements list. In particular Build codec packages with the lowest common denominator XDC and Codec Engine versions unless a particular new feature is required. Essentially the codec was built against a "very new" version of Codec Engine. Since codecs sit at the bottom of the build tree (in relation to e.g. servers) mixing a codec that was built to a newer version of Codec Engine inside a server/combo using an older version of Codec Eng. In this case it is safe to ignore the warning since the codec package does not leverage/depend upon any of the features in the "new" Codec Engine. To eliminate the warning the safest option is to rebuild the codec package (remember its only really the "meta-data" we're talking about here - not the codec source code) with the same tools being used in the server build i.e. do make -f Makefile.eval clean and then make -f Makefile.eval. A list of which features were introduced in which Codec Eng versions (and its dependencies) can be found here.

A final note of caution - the above example was probably not the best to use because the H.264 Encoder v2.00.004 implements IVIDENC1 not IVIDENC as used in the DVSDK 1.30 demos. You cannot simply "drop in" a new codec that implements a new interface to an existing application that wasn't written to comprehend it. This topic shows you several methods to determine which interface the codec you received is using. Also note that the DMAI product (used in DVSDK 1.40, 2.0, 3.0 demos etc) attempts to mitigate the application impact of migrating to a new XDM interface. For example the dmai/apps/video_encode_io1 example is a useful, simple file-based reference for how to perform video encode using IVIDENC1. Note that although DMAI did not make it into DVSDK 1.30 it can be simply "dropped in on top" of it i.e. it is available standalone and, as indicated in the 1.16 Release Notes, it can be used successfully with DVSDK 1.30.

Useful info on upgrading to a new VISA interface can be found here.

I am using the jpegenc codec from TI and only the first frame are encoded. The others seems to be only 14 bytes in size. What is the solution ?

The jpegenc is not use correctly. After each frame, it is necessary to reload dynamic parameters. So the correct using sequence is : IMGENC_create -> IMGENC_control(XDM_SETPARAMS) -> IMGENC_control(XDM_GETBUFINFO) -> IMGENC_process -> IMGENC_control(XDM_SETPARAMS) -> IMGENC_process --...--> IMGENC_delete

There are no test sequences provided with the evaluation codecs. Where can I find test sequences to test the evaluation codecs?

• DM6446 DVEVM contains MPEG2, MPEG4, H264 encoded video streams.
• Some Raw YUV sequences are available from the Internet (Search with the key words "YUV video sequences").
• The Digital Video Test Bench (DVTB) is a utility included in the DM6446 DVSDK that enables to create encoded streams and raw YUV test sequences. The raw YUV sequences generated must have a resolution smaller or equal to VGA (640x480) because of bandwidth limitation.

Where can I find more information about the performance of the codecs available from Texas Instruments?

The documentation is included in the codec evaluation package. A free evaluation request must be submitted in order to have access to this documentation.

Which codecs use the Hardware Acceleration capabilities of the DaVinci devices?

Some devices from the DaVinci family have hardware accelaration capabilities to increase the processing power for video applications:

• DM6446 has a video coprocessor
• DM643x, DM6443 do not have any hardware accelerator

When a video coprocessor is present it is usually used for encoding functions that require more processing power. The codec datasheet documents if a codec uses the hardware accelerator. The datasheet is included in the codec evaluation package. A free evaluation request must be submitted in order to have access to this documentation. Request a free evaluation here.

Do the video codecs from Texas Instruments provide support for High Definition?

• DM644x codecs do not provide support for HD
• DM643x codecs do not provide support for HD
• DM648 codecs do not provide support for HD
• DM355 MPEG4 Encoder and Decoder support 720p30 HD.

Is the video codec input data format YUV or YCbCr?

The video codec documentation mentions that the input data format is YUV. However, to be technically correct, the input data format is YCbCr. The terms YUV and YCbCr are used interchangeably in the video litterature (even if technically they are not the same). Since the YUV notation is more commonly used, it was decided to use it in the codec documentation.

What is the YUV format used as input to the video codecs?

The YUV formats accepted as input by the TI video codecs are either "planar" or "interleaved".

• YUV Planar means that the data for each component Y,U,V is available in three different buffers.
• YUV Interleaved means that the three components Y,U,V are stored in a single buffer in interleaved fashion.

The DM644x and DM643x video drivers provide the input data in 422 Interleaved Little Endian format (YUV422ILE).

Each component (Y,U,V) has a 8-bit (byte) size:

  |U0|Y0|V0|Y1| - 32-bit for pixel 0 and pixel 1

The codecs can be configured to accept different YUV formats. The reader is referred to the datasheet for more information. It is important to notice that the conversion to a format different from YUV422ILE must be done in software or hardware (the resizer can be used for 422-> 420 conversion, see De-Interlacing and YUV 4:2:2 to 4:2:0 Conversion on TMS320DM6446 Using the Resizer )

What is the cycle overhead of using a YUV422 input instead of a YUV420 input?

The TI video encoders accept both a YUV422 and a YUV420 input. When a YUV422 input is provided to an encoder, the encoder will convert internally the YUV422 format to YUV420 format. This results in an overhead when using YUV422 inputs. In the H.264_E v1.1 release, the overhead is about 3%.

Which PC players can be used to decode the streams encoded with TI video encoders?

The TI video encoders H.264 Base Profile and MPEG4 Simple Profile generate standard elementary streams. Any PC Player that is able to decode standard elementary streams can be used to decode the sequences encoded with TI encoders. For example the VLC player can be used to decode H.264 BP streams and the Elecard player can be used to decode the MPEG4 streams. MPlayer is an open source media player available for Windows and Linux that can play MPEG2, MPEG4, H.264, YUV, and others.

Which XDAIS version should I use to build my codec and where can I get it?

XDAIS in included as part of the CCS windows installation or DaVinci DVSDK installation. If using the CCS version, you may want to upgrade XDAIS version using CCS update advisor feature to match that of the DVSDK you will be integrating with. For example, DVSDK 1.40 uses XDAIS 6.0, hence for compatibility reasons you want to upgrade your CCS to include XDAIS 6.0 if your plans include integration to DVSDK 1.40. As a rule of thumb, it is also better to use a recent version of XDAIS; for instance, XDAIS 6.0 includes a tool to help you validate your codecs called QualiTI XDAIS Compliance Tool. Note that you can run this tool on 'older codecs' i.e. the tool is fairly standalone (depends on XDC >= 2.95 but little else) so you dont need to 'upgrade everything' just to XDAIS-check your codecs.

One further note however - if you do choose to upgrade your codec to use XDAIS 6.0 (e.g. to implement a fairly recent interface like IVIDDEC2) you should take note of other dependencies - i.e. an upgrade in isolation may fail. One excellent way to ensure you have all the right versions and dependencies is to download a full Codec Engine and use the cetools/packages content. See this link for more details.

How do I configure the GOP structure with the TI codecs?

The GOP (Group Of Picture) structure defines the sequence of the I,P,B frames in the encoded video stream. For example IBBPBBPBBI could be a GOP structure. Depending on the profile supported an encoder may or may not support B frames. However I and P frames are always supported.

The GOP structure is usually configurable using parameters to define the I-Frame period or to force a frame to by an I-Frame. For the DM644x H264 Base Profile Encoder, the intraFrameInterval and forceIFrame dynamic parameters are used for this purpose. Similar parameters are supported by all the video encoders from TI. Please review the specific user guides for more detailed information.

While running a Video Decode sample application, most of the times one receives an error like:ERROR: Decode error; status=-1; extendedError=0x200. Document shows it as a concealment error. Is it a fatal one?How to overcome it?

The extended_error=0x200 corresponds to XDM_APPLIEDCONCEALMENT error. Since the input stream under consideration is an erroneous one, the decoder tries to conceal the errors and continue. We need to continue decoding in such a case unless or until we end up getting a FATAL_ERROR. Once decoder returns FATAL_ERROR we *MUST* stop decoding.

What value should be set for NumOfIterations, and NO_OF_BUFFERS in VPFE configuration to get one frame of image in interlaced mode for DM6437? For example in the case of CcdcallocFB[i % NO_OF_BUFFERS] how are they arranged?

The minimum number of buffers that should be used is two. One will be queued to the driver for capturing data and the other will be exchanged with driver for getting back the captured buffer and provide a free buffer to the driver. Therefore, the sequence should be "alloc one" ---> "queue", "alloc another" --->"exchange" Please refer to the APPENDIX A of BIOS_VPFE__Driver_UserGuide.pdf provided at: <dvsdk_xx_xx\dvsdk_xx_xx\psp_xx_xx\pspdrivers\drivers\vpfe\doc> for this sequence. This document is bundled with the DVSDK.

If you need only one captured frame, then NumOfIterations is one, and thus only one exchange happens in the loop and hence only one frame is obtained.

Is GStreamer package able to pack MPEG4 video stream generated on DaVinci DM6446 board into AVI file and will created AVI file be playable on windows media player?

This cannot be done with the bundled Gstreamer setup since it does only decode operations. There are no plugins for audio/video encode and AVI muxing.

Is it possible to configure two McASP serializers for capture in DM6467?

On DM6467 evm it is not possible to configure two serializers for capture since aic32 codec does not support this. There is only one DIN pin and one DOUT pin on aic32 codec which are hardwired to serializer 0 and serializer 1.

4:2:2 to 4:2:0 Conversion Algorithm

Offloading a 4:2:2 to 4:2:0 conversion of the DSP enables DSP cycles to be utilized for computationally expensive operations, such as video encoding or video analytics. The conversion entails vertically down-sampling all chroma buffers by a factor of 2 and unpacking the video data from an interleaved to a planar format. The vertical down-sampling can be achieved by using the DM6446 resizer in its intended use. The unpacking can be achieved by using the resizer to perform horizontal down-sampling coupled with specific filter coefficients that effectively mask out unwanted data. For example, because 4:2:2 data is stored in a U1Y1V1Y2 format, scaling this data down by a factor of 2 with appropriate coefficients yields Y1Y2. When applied to an entire row of 4:2:2 data, an entire row of 4:2:0 Y data is generated. A similar approach can be used to individually unpack the U and V buffers as well.

I want to save audio files on DM355 every quarter second in a non proprietary format. What could be the way to save and in which format?

Without any audio compression, one can save audio raw data as .wav file format. .wav is not supported by DVSDK but it would not be hard to implement it.

Can OMAP3 do 800x600 MPEG4 Encode?

OMAP3 MPEG4 SP Encoder will support up to WVGA - 800x480

Can the DM355 encode 2 camera streams (WVGA) at a time (assuming some McVFE-like FPGA in front of video port)?

With a 270Mhz DM355, the IPNC is able to do SXVGA, meaning 1280x960, 3.5 times WVGA. So 3 encodes could be possible.

I am not able to set the recording volume using SOUND_MIXER_VOLUME IOCTL in DMAI?

If your OSS version is 4.0 and above, you have a new set of IOCTLs named SNDCTL_DSP_SETRECVOL, SNDCTL_DSP_SETPLAYVOL. But the current LSP (LSP 1.20) has OSS 3.8 and hence these IOCTL are not declared. In this version there is an IOCTL with name SOUND_MIXER_IGAIN which is used to control the recording volume.

How can I tell whether the codecs I received are XDM 0.9 or 1.0?

Check out this wiki topic.

In a camera design on DM6435, I would like to use the AE feature of H3A; I could not find any document regarding this anywhere?

An NDA is required for this. With the NDA in place, we have additional documentation that further explains the AE feature of the H3A. You can contact the product group directly.

Similar to the VPIF_FRQ setting for the CCDC block, is it possible to throttle the data rate the resizer block consumes/generates?

You can use the SDR_REQ_EXP register in VPSS to slow down the resizer when it reads data from memory.

Is there a H.264 MP Encoder on DM6467? Does it support B picture encoding?

There is a H.264 MP encoder on DM6467 but it does not support B-frames.

Is DM355 able to output the same video to 18-Bit Digital LCD Port and Analog TV_Out simultaneously?

Yes, DM355 has the ability to output the same video to 18-Bit Digital LCD Port and Analog TV_Out simultaneously.

The DM642 technical overview states if using McASP, both VP0 and VP1 must be configured in McASP mode. Does this mean, that if one wants to use the McASP of one VP, they have to use the other one as well?

The McASP takes up half of VP0 and half of VP1. The McASP Control signals are muxed with one video port, the McASP Data signals are muxed with the other Video Port. Some Possible DM642 configurations using the McASP would be: VP0: 1 - McASP Control 1 - 10-bit Video Port VP1: 1 - McASP Data 1 - 10-bit Video Port VP2: 1 - 20-bit Video Ports or VP0: 1 - McASP Control 1 - McBSP VP1: 1 - McASP Data 1 - 10-bit Video Port VP2: 2 - 10-bit Video Ports

I have modified the jpegenc example in dvsdk to support 420P data input. When I try with DVTB with same parameters it works fine. What would be the reason?

The issue is because the memory allocation for input buffer might not be correct. Current JPEGENC example in dvsdk is for 422ILE YUV input and it only needs 1 input buffer, but for 420P we need 3 buffers. We need to use the info returned by GETBUFINFO call to set right number/size of buffers.

I am facing an audio hang issue that occurs when playing back mp3 audio for a long time (1 hour+); is there any known issue?

The issue is probably with sample rate settings. The Audio driver sets a default sample rate of 48KHz during init (before the McBSP is reset). The decode demo then sets the sample rate to 8KHz in run-time, using an IOCTL. When this IOCTL is called in the driver we just change the sample rate (on-the-fly), with McBSP is active. It seems we cannot set the sample rate while McBSP is still active, from a hardware perspective. If we do match the sample rate settings (init and run-time), there will be no hang issue. One possible solution should be to put the McBSP in reset, change the sample rate and then bring McBSP out-of-reset, when the IOCTL is called (similar to the init sequence).

When I try to run my application which uses DVSDK, I am able to open my codec but my IMGENC_Control() fails. What could be the possible solution?

For the control problem check that the input color format (set by base param inputChromaFormat) and the output color format (set by dynamic param forceChromaFormat) matches the note in the users guide:

The output formats supported for each input format are as follows:

 Input Format           Supported Output Formats
XDM_YUV_420P           XDM_YUV_420P, XDM_GRAY
XDM_YUV_422P           XDM_YUV_422P, XDM_GRAY
XDM_YUV_422ILE         XDM_YUV_422P, XDM_YUV_420P, XDM_GRAY
XDM_YUV_444P           XDM_YUV_444P, XDM_GRAY
XDM_YUV_411P           XDM_YUV_411P, XDM_GRAY
XDM_GRAY               XDM_GRAY

Also check your maxScans is set to XDM_DEFAULT (0).

Does TI provide an H263 encoder?

H263 is supported in the MPEG4 Encoder through the short video format. This mode is enabled using IMP4VENC_Params.EncodeMode = 0

note that on encoder rel. 1.20 you need also to set encodingPreset field of the VIDENC_Params to XDM_HIGH_QUALITY or to XDM_USER_DEFINED

How can I tell if a stream encoded with TI MPEG4 Encoder is encoded as H263 or MPEG4?

Use a stream analyzer to check the value of short_video_header. If short_video_header = 0 it is an MPEG4 stream, if short_video_header = 1 it is an H262 stream.

Other FAQs

For further FAQs see

• Codec engine FAQ
• DVEVM and DVSDK frequently asked questions
• TI official DaVinci FAQ
• Spectrum Digital (HW) FAQ