Problem with running CLient demo on 6437 (in reply please be specific to the machine )

Jacek, it would help to get more details on where the code is hanging within the application code. 

Also, please confirm you have changed the H264VDecApp.cmd file to reflect the memory map of DM6437. By default, it is set to memory map of C64x+ in DM6446. For DM6437 memory map, refer to Table 2.3 Page 14 of DM6437 Datasheet

Regards,

Prateek

Thanks for the reply.

1. Using the debugger I confirm that the system hangs in the first frame - it accepts data and then stops.

2. Memory map is the next logical thing to do.  When I started the CCS I  first run CCS Setp and made sure that I am using 6437. I thought that this will take care of the map since it should have been automatically generated. (http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/3160.aspx). After your post I looked into data sheet which provides a hardware Memory Map for 6437 and I checked H264VDecApp.cmd. How do you link both together?

Thanks,

Ja

Here is additional info:

A memory map from workin gprogram is the following:

OUTPUT FILE NAME:   <./Release/dm6437_demo.out>
ENTRY POINT SYMBOL: "_c_int00"  address: 843efc00


MEMORY CONFIGURATION

         name            origin    length      used     unused   attr    fill
----------------------  --------  ---------  --------  --------  ----  --------
  CACHE_L2              10800000   00020000  00000000  00020000  RWIX
  CACHE_L1P             10e08000   00008000  00000000  00008000  RWIX
  L1DSRAM               10f04000   00010000  00010000  00000000  RWIX
  CACHE_L1D             10f14000   00004000  00000000  00004000  RWIX
  SRAM                  42000000   00200000  00000000  00200000  RWIX
  DDR2                  80000000   08000000  04461a18  03b9e5e8  RWIX

I am not sure how it is related to H264VDecApp.cmd which probably looks for values for the following lines:

-stack 0x3000
-heap  0xD00000

MEMORY
{       
    UDRAM                : o = 0x11f04000, l = 0x00010000 /* Uninitialized Data RAM */  /// changed to 0 = 42000000 1 = 200000
    ERAM                 : o = 0x80000000, l = 0x0A000000                               /// changed to 1 = 08000000
}

/* Sections related to BP H.264 decoder library */
SECTIONS
{ 
        .const:H264VDEC_TI_dSect1 > ERAM, align=0x80
        .far:H264VDEC_TI_uSect1   > ERAM, align=0x80
        .text:H264VDEC_TI_cSect1  > ERAM, align=0x10000
}

are my comments in red about changes correct? any hints?

ja

Bad memory map is a culprint. (Prateek thanks for the hint) For 6437 eval board I am using:

    UDRAM                : o = 0x10F04000, l = 0x00010000  /*Uninitialized Data RAM */
    ERAM                 : o = 0x80000000, l = 0x0A000000

it generate the following output

*******************************************
uv - Read Configuration Set 1
*******************************************
Running in Output Dump Mode
FileSize = 69161
Input File read successfully...
Creating Algorithm Instance...
Algorithm Instance Creation Done...

 Decoded Frame # 0      Decode Time = 8661594
 Decoded Frame # 1      Decode Time = 7981141
 Decoded Frame # 2      Decode Time = 8264678
 Decoded Frame # 3      Decode Time = 8308282
 Decoded Frame # 4      Decode Time = 8253304
 Bitstream Ended... 
 --------------  SUMMARY --------------------
 Decoder output dump completed
     Total number of Frames              = 5
     Bit Rate at 30 frames/Sec           = 3319 Kbps
     Width and Height                    = 640, 480
     Total Decode Cycles                 = 41468999
     Average Decode Cycles per Frame     = 8293799
     Worst Case Decode Cycles per Frame  = 8661594
     Average MCPS for 30 Frames/Sec      = 249
     Worst MCPS for 30 Frames/Sec        = 260
 --------------    END   --------------------

 End of execution

overall execution is slow probably because data must be transferred through JTAG

Ja

Input file foreman_vga.264 has 1 I frame followed by 4 P frames. The resulting foreman_vga.yuv has 6 (?) frames.

Unfortunately, the result has nothing to do with initial image. There are no errors during execution.

Elecard, yuv_viewer renders pictures that unfortunately have nothing to do with the originals.

Here is a summary:

1. I have downloaded the h264 rev.2.0 codec from TI,
2. I am using dvsdk 1_11 with all the components from dvSDK 2.0. 
3. I am using Elecard yuv_viewer
4. No building errors or execution errors.
5. Bad resulting pictures, very slow execution

Any suggestions?

After some tweaking with output file it seems that there is a picture in the noise.

Just playing with (so far) width:hight parameters got a bit of a scrambled  image.

1280:960 displays two pictures on a top of each other. This may indicate that decoder was set to interlaced pictures.

So more work is needed to get the right configuration.

ja

Jacek,

Have you looked at testparams.cfg file under app/Client/Test/TestVecs? The configuration file by default is set for interlaced pictures -

# New Input File Format is as follows

# <ParameterName> = <ParameterValue> # Comment

#

##########################################################################################

# Parameters

##########################################################################################

ImageWidth = 720 # Image width in Pels, must be multiple of 16

ImageHeight = 576 # Image height in Pels, must be multiple of 16

ChromaFormat = 4 # 1 => XMI_YUV_420P, 3 => XMI_YUV_422IBE, 4 => XMI_YUV_422ILE

FramesToDecode = 600 # Number of frames to be coded

InputStreamFormat = 0 # 0 = > ByteStreamFormat, 1 => NAL unit format

You need to change the ChromaFormat to 1 to work with 420P (planar data format). Previously it was set for 422 interleaved data. Do make sure if you chose ChromaFormat=1, the input data is in 4:2:0 planar format.

Prateek

Prateek,

Confirmed, codec rev.2.00 is now configured and it is working as demonstrated by correct operation of the Client project.

To evaluate the codec I have run few video clips and it is not working well when IDR attribute is missing in the first I frame. Was this the same conclusion you have seen when testing the codec (baseline profile)?

Thanks for your help,

Jacek

Jacek,

Prateek provided me with a clip called test_9_Delta_Encoder_D1_1_minute_765kbps.h264 that I was able to decode with h264dec v2.00 on dm6446.

I think the output should be similar on dm6437 even if the processing time may be longer.

What do you mean "it is not working well?" Are you able to decode the stream? Is the quality not good?

Thanks

Cesar

I am getting a green screen... unless I am doing something wrong - but it is a really nice solid color green screen.

It takes longer because I am running it using a JTAG, so this is not an issue.

Thanks for your reply - it is an encouragement because it indicates that the codec is able to decode it.

Jacek

Jacek,

Please see below the params I am using.

Thanks

Cesar

const VIDDEC2_Params Vdec2_Params_DEFAULT = {
    sizeof(VIDDEC2_Params),             /* size */
    576,                                /* maxHeight */
    720,                                /* maxWidth */
    30000,                              /* maxFrameRate */
    6000000,                            /* maxBitRate */
    XDM_BYTE,                           /* dataEndianess */
   XDM_YUV_422ILE,                       /* forceChromaFormat */
};

const VIDDEC2_DynamicParams Vdec2_DynamicParams_DEFAULT = {
    sizeof(VIDDEC2_DynamicParams),      /* size */
    XDM_DECODE_AU,                      /* decodeHeader */
    0,                                  /* displayWidth */
    IVIDEO_NO_SKIP,                     /* frameSkipMode */
    IVIDDEC2_DISPLAY_ORDER,             /* frameOrder */
    0,                                  /* newFrameFlag */
    0,                                  /* mbDataFlag */
};

The only difference in the parameters is the maxHeight which is 480 instead of 576 (I stepped with the debugger to assure that it is true to the action of the program). It worked with the rest video clips (they all come from the same source), but I will force it to be 576.

It is still  puzzle why it works on 4664 and not on 4637 - it must be a setup error.

Your advice on this matter will be highly appreciated.

thanks,

Jacek

Can you provide more details about the error -a) what you see at the console output, b) where it is breaking up in the code, etc? We can not infer much information on why is it failing based on the data provided above.

Thanks,

Prateek

In addition to error details, can you please provide information on

a) testparams.cfg file

By default, here is what I have -

##########################################################################################

# Parameters

##########################################################################################

ImageWidth = 720 # Image width in Pels, must be multiple of 16

ImageHeight = 576 # Image height in Pels, must be multiple of 16

ChromaFormat = 4 # 1 => XMI_YUV_420P, 3 => XMI_YUV_422IBE, 4 => XMI_YUV_422ILE

FramesToDecode = 600 # Number of frames to be coded

InputStreamFormat = 0 # 0 = > ByteStreamFormat, 1 => NAL unit format

b) dynamicParams initialization under function TestApp_SetDynamicParams in the file TestAppDecoder.c

By default here is what I have -

   IH264VDEC_DynamicParams *extParams = (IH264VDEC_DynamicParams *)dynamicParams;
    /* Set IVIDDEC Run time parameters */
    dynamicParams->decodeHeader  = XDM_DECODE_AU;
 //dynamicParams->decodeHeader  = XDM_PARSE_HEADER; 

    /*-----------------------------------------------------
    * If Display width is set to 0, decoder takes value
    * of image width as Display width. Any non-zero value
    * will be honoured by the decoder.
    * Note: Displaywidth needs to be an even number.
    *
    -----------------------------------------------------*/

#ifdef DISPLAY_WIDTH_CHANGES
    dynamicParams->displayWidth  = 0;             //Supported now.
#else
    dynamicParams->displayWidth  = 0;             //Not Supported: Set to default value
#endif
    dynamicParams->frameSkipMode = IVIDEO_NO_SKIP;//Not Supported: Set to default value
   
   dynamicParams->frameOrder    = IVIDDEC2_DISPLAY_ORDER;

   dynamicParams->newFrameFlag  = XDAS_FALSE;

   dynamicParams->mbDataFlag    = XDAS_FALSE;

   /*---------------------------------------------------------------------*/
      /* MB_ERROR_STAT                                                       */
   /* The global buffer size is passed to algorithm,                      */
   /* The error status for each MB of the frame is copied to the buffer,  */
   /* returned as output bufDesc[4]    .                                  */
   /* Init the flag with TRUE to get these datas                          */
   /*---------------------------------------------------------------------*/
      extParams->mbErrorBufFlag  = FALSE; //TRUE;
      extParams->mbErrorBufSize  = ((IMAGE_WIDTH * IMAGE_HEIGHT)/256);

   /*---------------------------------------------------------------------*/
   /* Collecting the status of SEI and VUI structure and returned the     */
   /* pointer through output bufDesc[5]                                   */
   /* Init the flag with TRUE to get these datas                          */
   /*---------------------------------------------------------------------*/
      extParams->Sei_Vui_parse_flag = FALSE; //TRUE;

   /* Should be set to zero for byte stream format */
   extParams->numNALunits = 0;
    return;

Prateek,

To debug the issue during runtime I went to the debugger and set the breakpoints before and after (near line 722)

      /*---------------------------------------------------------------------*/
      /*  Start the decode process for one frame/field by calling process    */
      /*  function.                                                          */
      /*---------------------------------------------------------------------*/
      retVal = ividDecFxns->process((IVIDDEC2_Handle)handle,
                                    (XDM1_BufDesc *)&inputBufDesc,
                                    (XDM_BufDesc *)&outputBufDesc,
                                    (IVIDDEC2_InArgs *)&inArgs.viddecInArgs,
                                    (IVIDDEC2_OutArgs *)&outArgs);

the retVal = -1

there is little more available to track the flow through the codec. This configuration works for other video clips. We have generated proper yuv files that render good video clips.

I am attaching below other files you have requested.

Here are key files:

Testparams.cfg

# New Input File Format is as follows
# <ParameterName> = <ParameterValue> # Comment
#

##########################################################################################
# Parameters
##########################################################################################
ImageWidth     = 720       # Image width in Pels, must be multiple of 16
ImageHeight    = 576       # Image height in Pels, must be multiple of 16
ChromaFormat    = 4        # 1 => XMI_YUV_420P, 3 => XMI_YUV_422IBE, 4 => XMI_YUV_422ILE
FramesToDecode  = 600       # Number of frames to be coded
InputStreamFormat = 0     # 0 = > ByteStreamFormat, 1 => NAL unit format

Initialization procedures:

  XDAS_Void TestApp_SetInitParams(IVIDDEC2_Params *params) 
  {
      IH264VDEC_Params *extParams = (IH264VDEC_Params *)params;
    /* Set IVIDDEC parameters                                                   */
   
    /* Max Frame Rate: Not currently used in the algorithm                      */
      params->maxFrameRate    = 30000;

    /* Max Bit Rate: Not currently used in the algorithm                        */
      params->maxBitRate      = 10485760;

    /* Data Endianness (0: Little, 1: Big) :                                    */
    params->dataEndianness  = XDM_BYTE;   

#ifdef SUPPORT_PIC_REORDERING
      /* Must be set between 0 and 16 for successful decoding */
      extParams->maxDisplayDelay = 0;
#else
      extParams->maxDisplayDelay = 0;
#endif //SUPPORT_PIC_REORDERING
    return;
  }
 
  /*
  //==============================================================================
  // TestApp_SetDynamicParams
  //  setting of run time parameters
  */
 
  XDAS_Void TestApp_SetDynamicParams(IVIDDEC2_DynamicParams *dynamicParams)
  {
      IH264VDEC_DynamicParams *extParams = (IH264VDEC_DynamicParams *)dynamicParams;
    /* Set IVIDDEC Run time parameters */
    dynamicParams->decodeHeader  = XDM_DECODE_AU;
    //dynamicParams->decodeHeader  = XDM_PARSE_HEADER; 


    /*-----------------------------------------------------
    * If Display width is set to 0, decoder takes value
    * of image width as Display width. Any non-zero value
    * will be honoured by the decoder.
    * Note: Displaywidth needs to be an even number.
    *
    -----------------------------------------------------*/

#ifdef DISPLAY_WIDTH_CHANGES
    dynamicParams->displayWidth  = 0;             //Supported now.
#else
    dynamicParams->displayWidth  = 0;             //Not Supported: Set to default value
#endif
    dynamicParams->frameSkipMode = IVIDEO_NO_SKIP;//Not Supported: Set to default value
   
      dynamicParams->frameOrder    = IVIDDEC2_DISPLAY_ORDER;

      dynamicParams->newFrameFlag  = XDAS_FALSE;

      dynamicParams->mbDataFlag    = XDAS_FALSE;

      /*---------------------------------------------------------------------*/
      /* MB_ERROR_STAT                                                       */
      /* The global buffer size is passed to algorithm,                      */
      /* The error status for each MB of the frame is copied to the buffer,  */
      /* returned as output bufDesc[4]    .                                  */
      /* Init the flag with TRUE to get these datas                          */
      /*---------------------------------------------------------------------*/
      extParams->mbErrorBufFlag  = FALSE; //TRUE;
      extParams->mbErrorBufSize  = ((IMAGE_WIDTH * IMAGE_HEIGHT)/256);

      /*---------------------------------------------------------------------*/
      /* Collecting the status of SEI and VUI structure and returned the     */
      /* pointer through output bufDesc[5]                                   */
      /* Init the flag with TRUE to get these datas                          */
      /*---------------------------------------------------------------------*/
      extParams->Sei_Vui_parse_flag = FALSE; //TRUE;

      /* Should be set to zero for byte stream format */
      extParams->numNALunits = 0;
    return;
  }

In theory I am in agreement with you that the DSP part of the 6446 should also test 6437 and perhaps it is indeed a proper parameter setup problem. But we must show it in order to move to the next phase of the conversion.

Thanks for your help.

Ja

Jacek,

Thanks for the details. In order to further debug this, can you get extendedError flag information that is part of argument IVIDDEC2_Status under the control call (near line  793) right after the process call fails.

    /* Optional: Read status via control()                                 */
      ividDecFxns->control((IVIDDEC2_Handle)handle,
                           XDM_GETSTATUS,
                           (IVIDDEC2_DynamicParams *)&dynamicParams,
                           (IVIDDEC2_Status *)status);

The structure for (IVIDDEC2_Status *)status) will have extendedError flag that is set to XDM_ErrorBit enumeration class. The details of XDM_ErrorBit enumeration can be found on page 44 of the User Guide under docs folder.

More details on error handling can be found on Page 88 Section 4.4 Error handling. Please note that there is likely a documentation error - the second bullet on this page says -

The type of the detected error will be indicated in the extendedError field of OutArgs. See XDM_ErrorBit enumeration for details.

It should be really extendedError field of IVIDDEC2_Status argument.

Prateek

Prateep,

The following are the info from the debugger:

retVal = -1;
(IVIDDEC2_Status *)status = (location: 0x80D92214    content: 000000DC    000020CD

extended error field is = 0x000020CD

which

0x20 =
XDM_FATALERROR (0 - Recoverable error) XDM_UNSUPPORTEDINPUT,
is a recoverable error (bit 15) which is specific to the H264 codec.

0xCD
H264D_ERR_IMPL_NOTSUPPORTED_GAPSI
0xCD = NFRAMENUM Gaps in frame number or wrong frame number coded. [0xCD]

Willl this help?

Jacek

Hi,

Please find few suggestions regarding the following error code,

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

0x20CD
H264D_ERR_IMPL_NOTSUPPORTED_GAPSINFRAMENUM - Gaps in frame number or wrong frame number coded. [0xCD]

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

The stream "test_9_Delta_Encoder_D1_1_minute_765kbps.h264" is encoded starting with wrong "frame_num" value, hence the decoder returns this error code.

Even after returning the error code, if the decoder continue decoding then it's a warning error code, hence application can ignore such type of error code and try to continue.

Application can consider only the error codes where the decoder exits without decoding further, i.e. for the case when the decoder is not able to recover.

Welcome for any further clarifications.

Regards,

Mahantesh

Mahantesh,

Thanks for your reply. As I have posted, I understand that it is a recoverable error and I have also decoded the type of the error.

What I am wondering about here is the fact that as it was earlier reported (Posted by Prateek Bansalon 03-29-2010 3:24 AM) TI was able to decode the video clip (with same errors, on the same decoder)  on 6446.

Does it mean that the codec is not working in the same way on 4637? It is important for us to understand it.

Thanks for your help.

Ja

Hi Jacek,

We have attached a log of running DMAI application on DM6446 using v2.00 codec for the clip mentioned above. As you will see, we do see these recoverable errors on DM6446 as well - however the decoded YUV file played correctly. 

My understanding is you were getting fatal errors with older version of codec v1.10 with regards to non-IDR support. I believe those errors are no longer present. Let me know if this is not the case.

Regards,

Prateek

Prateek,

Thanks for the reply. Both on 6446 and 6437 the codec continue to work when encounters a non fatal error as it is in the case of the video clip used in this test.

Our problem lies in the fact that the clip plays AND it is correctly rendered on on some PC players.

Does the 6446 renders the correct image or it plays (i.e., continue to operate in the presence of errors) but it is a green screen that is being rendered?

Thanks,

Ja

Jacek,

In my email dated Thu 4/1 3:11PM PST, I sent you a link to FTP site which has DM6446 decoded clip in YUV format test_9_Delta_Encoder_D1_1_minute_765kbps.yuv

Let me know if you see a green screen on it.

Prateek