View Issue Details

IDProjectCategoryView StatusLast Update
0000198JVT JM H.264/AVC reference softwareencoderpublic2010-05-27 14:09
Reporterllzzyynjupt Assigned ToKarsten Suehring  
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
Product VersionJM 16.2 
Fixed in VersionJM-17.0 
Summary0000198: several possible bugs in the case of lossles coding
DescriptionNow I'm trying to learn H.264 lossless coding, and I begin my learning with lossless intra coding. But when I study the source codes of JM16.2, I find there exist problems about the lossless coding part of the source codes, which are listed in the following.

Problem 1. In the function "rdcost_for_4x4_intra_blocks()" of the file "rdopt.c", there are codes like this:

Code Fragment Start:
  //===== perform DCT, Q, IQ, IDCT, Reconstruction =====
  //select_dct(currMB);

  if (currMB->mb_type == I4MB)
      *nonzero = dct_4x4 (currMB, PLANE_Y, block_x, block_y, &dummy, 1);
  else
      *nonzero = currMB->trans_4x4 (currMB, PLANE_Y, block_x, block_y, &dummy, 1);
Code Fragment End.

It's obvious in this function, "currMB->mb_type == I4MB" will always be "TRUE" and the second branch will never be executed. So if we want to perform I4x4 lossless coding, the lossy coding function "dct_4x4()" will be executed and an error will be encountered.
As far as I know, "currMB->trans_4x4" is a function pointer. If lossy coding is performed, it will point to the lossy coding function "dct_4x4()". But if lossless coding is performed, it will point to the lossless coding function "dct_4x4_ls()". In my opinion, the judgement statement can be removed, and the problem can be solved by retaining “*nonzero = currMB->trans_4x4 (currMB, PLANE_Y, block_x, block_y, &dummy, 1);” only. So I think the code fragment can be corrected like this:

Code Fragment Start:
  //===== perform DCT, Q, IQ, IDCT, Reconstruction =====
  //select_dct(currMB);

  *nonzero = currMB->trans_4x4 (currMB, PLANE_Y, block_x, block_y, &dummy, 1);
Code Fragment End.

Problem 2. In the function “dct_8x8_ls()” of the file “transform8x8.c”, there are codes like this:

Code Fragment Start:
if( (currMB->ipmode_DPCM < 2)&&(intra))
  {
    Residual_DPCM_8x8(currMB->ipmode_DPCM, mb_ores, mb_rres, block_y, block_x);
  }
Code Fragment End.

From the code fragment, we can see that when “(currMB->ipmode_DPCM < 2)&&(intra)” is “FALSE”, the variable “mb_rres”, which points to reconstructed residues, will point to uninitialized memory. And through experiments we found that when “(currMB->ipmode_DPCM < 2)&&(intra)” is “FALSE”, “mb_rres” pointed to stochastic values.

In contrast, in the function “dct_4x4_ls()” of the file “block.c”, the codes are written like this.

Code Fragment Start:
if( (currMB->ipmode_DPCM < 2) && (intra))
  {
    Residual_DPCM_4x4(currMB->ipmode_DPCM, mb_ores, mb_rres, block_y, block_x);
  }
  else
  {
    for (j=block_y; j < block_y + BLOCK_SIZE; ++j)
      for (i=block_x; i < block_x + BLOCK_SIZE; ++i)
        mb_rres[j][i] = mb_ores[j][i];
  }
Code Fragment End.

So I think the code fragments in the function “dct_8x8_ls()” of the file “transform8x8.c” can be corrected like this:

Code Fragment Start:
if( (currMB->ipmode_DPCM < 2)&&(intra))
  {
    Residual_DPCM_8x8(currMB->ipmode_DPCM, mb_ores, mb_rres, block_y, block_x);
  }
  else
  {
for (j=block_y; j < block_y + 8; ++j)
  for (i=block_x; i < block_x + 8; ++i)
    mbrres[j][i] = mb_ores[j][i];
}
Code Fragment End.



TagsNo tags attached.

Relationships

parent of 0000202 resolvedKarsten Suehring updated (possible) bug report about lossless intra coding 

Activities

2010-01-10 07:28

 

encoder.cfg (45,910 bytes)

Alexis Michael Tourapis

2010-01-26 18:42

developer   ~0000344

Bugs are being fixed in upcoming version 17.0

Karsten Suehring

2010-05-27 14:09

administrator   ~0000370

Has been fixed with bug 0000202 in JM 17.0

Issue History

Date Modified Username Field Change
2010-01-10 07:28 llzzyynjupt New Issue
2010-01-10 07:28 llzzyynjupt File Added: encoder.cfg
2010-01-26 18:42 Alexis Michael Tourapis Note Added: 0000344
2010-05-27 14:08 Karsten Suehring Relationship added parent of 0000202
2010-05-27 14:09 Karsten Suehring Note Added: 0000370
2010-05-27 14:09 Karsten Suehring Status new => resolved
2010-05-27 14:09 Karsten Suehring Fixed in Version => JM-17.0
2010-05-27 14:09 Karsten Suehring Resolution open => fixed
2010-05-27 14:09 Karsten Suehring Assigned To => Karsten Suehring