View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000300 | JVT JM H.264/AVC reference software | decoder | public | 2012-05-02 13:02 | 2013-09-02 19:59 |
| Reporter | Diego Manas | Assigned To | Karsten Suehring | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Fixed in Version | JM 18.6 | ||||
| Summary | 0000300: Discordance in coded_block flag between reference decoder and spec | ||||
| Description | Hi all, I believe to have found discordance between the spec and the reference decoder but I will need people with more expertise in order to confirm it. It happens when decoding coded_block_flag for luma_8x8. This is what the H.264 spec says: Otherwise, if ctxBlockCat is equal to 5, the following ordered steps are specified: 1. The derivation process for neighbouring 8x8 luma blocks specified in subclause 6.4.10.2 is invoked with luma8x8BlkIdx as input and the output is assigned to mbAddrN, luma8x8BlkIdxN (with N being either A or B). 2. The variable transBlockN is derived as follows. – If mbAddrN is available, the macroblock mbAddrN does not have mb_type equal to P_Skip, B_Skip, or I_PCM, ( ( CodedBlockPatternLuma >>luma8x8BlkIdx) & 1 ) is not equal to 0 for the macroblock mbAddrN, and transform_size_8x8_flag is equal to 1 for the macroblock mbAddrN, the 8x8 luma block with index luma8x8BlkIdxN of macroblock mbAddrN is assigned to transBlockN. – Otherwise, transBlockN is marked as not available. To calculate ctxIdxInc: Let the variable condTermFlagN (with N being either A or B) be derived as follows. 1. If any of the following conditions is true, condTermFlagN is set equal to 0: - mbAddrN is not available and the current macroblock is coded in an Inter macroblock prediction mode, - mbAddrN is available and transBlockN is not available and mb_type for the macroblock mbAddrN is not equal to I_PCM, - The current macroblock is coded in an Intra macroblock prediction mode, constrained_intra_pred_flag is equal to 1, the macroblock mbAddrN is available and coded in an Inter macroblock prediction mode, and slice data partitioning is in use (nal_unit_type is in the range of 2 through 4, inclusive). 2. Otherwise, if any of the following conditions is true, condTermFlagN is set equal to 1: - mbAddrN is not available and the current macroblock is coded in an Intra macroblock prediction mode, - mb_type for the macroblock mbAddrN is equal to I_PCM. - Otherwise, condTermFlagN is set equal to the value of the coded_block_flag of the transform block transBlockN that was decoded for the macroblock mbAddrN. The variable ctxIdxInc( ctxBlockCat ) is derived by ctxIdxInc( ctxBlockCat ) = condTermFlagA + 2 * condTermFlagB However the reference decoder code does this: else { if (block_b.available) { if((type==LUMA_8x8 || type==CB_8x8 || type==CR_8x8) && !mb_data[block_b.mb_addr].luma_transform_size_8x8_flag) {} // Leave defaults values which are depending upon intra decode else if(mb_data[block_b.mb_addr].mb_type==IPCM) upper_bit=1; else{ …} … } } The issue is that applies 1 depending upon intra mode even though mbAddrN is available and I think it should not to. Any thoughts about this? Many thanks, Diego | ||||
| Steps To Reproduce | Any stream where the first coded_block_flag (all previous transform_size_8x8_flag are 0) is using intra prediction. It will result in ctxinc = 3 no matter what. I think it does not matches what the spec says. | ||||
| Tags | No tags attached. | ||||
|
|
This miss-match was introduced between JM 18.0 and JM 18.1. Previous versions worked as stated in h.264 specification. Any major change committed in this matter since 18.0? |
|
|
There are more references to this bug in jvt-experts mailing list, see: http://mailman.rwth-aachen.de/mailman/private/jvt-experts/2012-June/006440.html |
|
|
Better late than never: The bug is finally confirmed and fixed in my development branch. I hope it won't take long until the next release. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-05-02 13:02 | Diego Manas | New Issue | |
| 2012-05-28 11:49 | Diego Manas | Note Added: 0000534 | |
| 2012-06-18 17:12 | Diego Manas | Note Added: 0000535 | |
| 2013-09-02 19:59 | Karsten Suehring | Note Added: 0000590 | |
| 2013-09-02 19:59 | Karsten Suehring | Status | new => resolved |
| 2013-09-02 19:59 | Karsten Suehring | Fixed in Version | => JM 18.6 |
| 2013-09-02 19:59 | Karsten Suehring | Resolution | open => fixed |
| 2013-09-02 19:59 | Karsten Suehring | Assigned To | => Karsten Suehring |
