Opened 12 years ago

Closed 12 years ago

#712 closed defect (fixed)

wrong initValue for split_transform_flag ctxIdx

Reported by: louis.lee Owned by:
Priority: major Milestone: HM-9.2
Component: HM Version: HM-8.0
Keywords: Cc: fbossen, ksuehring, davidf, jct-vc@…

Description

according to DRAFT8, Table 9-22, there is 9 CABAC init context elements for split_transform_flag like below,
{153, 138, 138, 124, 138, 94, 224, 167, 122}
and the ctxIdxOffset is 0,3,6 for each initType 0,1,2.

But in HM, for every initType(0,1,2), init value written like below

static const UChar
INIT_TRANS_SUBDIV_FLAG[3][NUM_TRANS_SUBDIV_FLAG_CTX] =
{

{ 153, 138, 138, },
{ 124, 138, 94, },
{ 224, 167, 122, },

};

Because of SLICE_TYPE_ORDER in previous HM, I think that we need to reorder this array..

Change History (5)

comment:1 Changed 12 years ago by DefaultCC Plugin

  • Cc fbossen ksuehring davidf jct-vc@… added

comment:2 Changed 12 years ago by Wenhao.Zhang

According to the adoption of J0133 on Stockholm meeting, the initvalue of split_transform_flag in HM8.0 is in correct order.

So this mismatch should be fixed by revising the table 9-22 as proposed by J0133. The order is {224, 167, 122, 124, 138, 94, 153, 138, 138}.

comment:3 Changed 12 years ago by bbross

I can confirm that the values proposed in JCTVC-J0133 differ from the ones in current D8.

But I think that this was introduced when the init values in D8 got updated and it was assumed that, like for the other syntax elements, the first row represents init type 0, the second type 1 and the third type 2.

To avoid the unnecessary confusion which may, as we have seen, lead to bugs, I think this should hold true for the subdivision flag too so:

  • HM should be changed in a way that the first row corresponds to init type 0,... so it complies with the representation of the other init arrays, i.e.

static const UChar
INIT_TRANS_SUBDIV_FLAG[3][NUM_TRANS_SUBDIV_FLAG_CTX] =
{
{ 224, 167, 122, },
{ 124, 138, 94, },
{ 153, 138, 138, },
};

  • Draft should be changed to match the proposed init values, i.e.

{224, 167, 122, 124, 138, 94, 153, 138, 138}

comment:4 Changed 12 years ago by Wenhao.Zhang

It seems that the initValue of sao_type also has the same problem.

In general, two matching rules are observed in current HM8.0 and D8.

  1. For most syntax, e.g. split_cu_flag, prev_intra_luma_pred_flag, and etc.,

1st row in HM8.0 ----> init type 2 in D8
2nd row in HM8.0 ----> init type 1 in D8
3rd row in HM8.0 ----> init type 0 in D8

  1. For sao_type and transform_split_flag,

1st row in HM8.0 ----> init type 0 in D8
2nd row in HM8.0 ----> init type 1 in D8
3rd row in HM8.0 ----> init type 2 in D8

I think the former one is correct because the slicetype defined in HM8.0 is
enum SliceType
{

B_SLICE,
P_SLICE,
I_SLICE

};
But can we unify the ordering rules in HM and spec in order to avoid the unnecessary confusion?

comment:5 Changed 12 years ago by fbossen

  • Milestone set to HM-9.2
  • Resolution set to fixed
  • Status changed from new to closed

Fixed in r3171

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(Participant)
  • David Flynn(Subscriber)
  • Frank Bossen(Subscriber, Participant)
  • jct-vc@…(Subscriber)
  • karl.sharman@…(Always)
  • Karsten Suehring(Subscriber, Always)
  • Wenhao Zhang(Participant)