This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DM6467T - H.264 encoder v01.10.02.x : clarification on information from extendedError bitfield? / Encoder generates incorrect slice header ?

Dear Codec team,

Could you please help with the below questions:
1. We want to know when exactly the functions Videnc1_process or Videnc1_control of the codec H264FHDVENC return an “extendedError” set to 1. Member “extendedError” is declared in the structure IVIDENC1_OutArgs for function Videnc1_process, and in the structure IVIDENC1_Status for the function Videnc1_control.

A value set to 1 (bit 0) is in the reserved internal error bits (bits 0-7), and is described in the pdf SPRUGN8D from May 2010 (Codec version 1.00.00.10) and SPRUGN8E from Oct 2010 (codec version 1.10.02.06 ) as meaning: “There is an overflow of the output buffer allocated by the application”. (Note: rateControlPreset is set in IVIDEO_LOW_DELAY mode).

Question: When does this overflow can occur?

2. Using H.264 ENC v01.10.02.03:
After approximately 4 to 5hours, H264FHDVENC codec sends incorrect slice headers. We can see out of range values, like a value set 67454 in idr_pic_id field. Standard specifies that idr_pic_id field is encoded with Exp-Golomb code which technically allows value higher than 2^16 but the standard forbid value greater than 65535 for idr_pic_id. If needed, we can send you a capture of the video stream with this kind of error.
Is it a know issue?

3. When we activate the “checked” parameter defined in the Settings.xdc file at the following place of the codec engine:
       codec_engine_2_26_02_11/packages/ti/sdo/ce/Settings.xdc
We can see logs telling that read-only members in structures used in ARM/DSP communication are overwritten by the codecs. We are refreshing our configuration parameters to be sure that we do not use a damaged structure, but we want to know if there are no side effects with theses overwrittings.

The DVSDK used is 3.10.00.19:

  • Codec Engine version 2.26.02.11,
  • Codec Server DM6467 version 1.00.00.10
  • Dsplink driver version 1.65.02.09,
  • Cmemk driver from linuxutils version 3.23.00.01,
  • Framework components version 2.26.00.01
  • DSPBIOS version 5.42.01.09
  • XDAIS version 7.24.00.04
  • XDCTOOLS version 3.24.07.73
  • CGT version 7.4.5

Thanks in advance,

Anthony

  • Anthony,

    I'm not on the codec team, but I have a little information regarding question #3. It looks like there is an issue with the codec. You need to identify the team which wrote the codec and notify them that the parameter checking has flagged an issue with their code.

    This feature is described on the CE CHECK wiki topic. Note that you should be enabling this feature using an environment variable on the ARM instead of directly modifying the Settings.xdc file.

    ~Ramsey