Opened 11 years ago

Closed 11 years ago

#849 closed defect (fixed)

Entropy coding typos

Reported by: laurent.birtz@… Owned by: bbross
Priority: minor Milestone: HM-9.1
Component: Text Version: D9 (K1003) v9
Keywords: Cc: bbross, wjhan, jct-vc@…


Table 9-28 is not referred to anywhere.

In Table 9-63, missing value for i == 15 (and typo Specifcation).

Change History (6)

comment:1 Changed 11 years ago by DefaultCC Plugin

  • Cc bbross wjhan jct-vc@… added

comment:2 Changed 11 years ago by laurent.birtz@…

As per Karsten suggestion, I'm copy-pasting a comment sent by email:

"I assume you mean table 9-39? Position 15 is not needed since xC and yC can only both be 3 when the last x/y position is 3,3, and in that case the significant_coeff_flag is inferred to be 1, not CABAC coded."

I am using OpenOffice. It's very possible that it is renumbering the
tables incorrectly. My apologies for the discrepancy.

The table "9-28" I am referring to is "Association of ctxIdx and syntax
elements for each initializationType in the initialization process".

The Table "9-63" I am referring to is "Specifcation of ctxIdxMap[ i ]".

Answering specifically to your comment. It's possible that I do not
understand the encoding correctly, my apologies if that's the case. My
understanding is as follow. Suppose there is a 8x8 TB. Then, there are
four 4x4 sub blocks, scanned in some order.

8x8 transform block
01 <= 4x4 sub block.

last_significant_coeff points somewhere in the TB. Suppose it's pointing
in sub block 3 in the example above. Now, sub block 0 may have 16
non-zero coefficients. Suppose all coefficients are non-zero.

Then, I don't see why a significant_coeff_flag value would be inferred.
As I understanding it, significant_coeff_flag can be inferred when
last_significant_coeff points at it or when coded_sub_block_flag is true
and all the other coefficients are zero.

comment:3 Changed 11 years ago by pieterkapsenberg

In your example 8x8 case, the array ctxIdxMap isn't used, that is only for 4x4 TUs.

comment:4 Changed 11 years ago by laurent.birtz@…

Correct. Sorry about that.

comment:5 Changed 11 years ago by bbross

Re: Table 9-28 is not referred to anywhere.
Right, I suggest to add a similar paragraph as in H.264/AVC and replace
"The variable initType in is derived as follows:"
"In Table 9-4, the ctxIdx for which initialization is needed for each of the three initialization types, specified by the variable initType, are listed. Also listed is the table number that includes the values of initValue needed for the initialisation. For P and B slice type, the derivation of initType depends also on the value of the cabac_init_flag syntax element. The variable initType is derived as follows:"

Re:(and typo Specifcation)
Table 9-38 "Specifcation of ctxIdxInc using left and above syntax elements" has the same typo.

comment:6 Changed 11 years ago by bbross

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.

This list contains all users that will be notified about changes made to this ticket.

These roles will be notified: Reporter, Owner, Subscriber, Participant

  • Benjamin Bross(Owner, Subscriber, Participant)
  • jct-vc@…(Subscriber)
  • karl.sharman@…(Always)
  • Karsten Suehring(Always)
  • laurent.birtz@…(Reporter, Participant)
  • Pieter Kapsenberg(Participant)
  • Woo-Jin Han(Subscriber)