Opened 9 years ago

Closed 9 years ago

#980 closed defect (fixed)

9.2.3.2.4: add end_of_sub_stream_one_bit case

Reported by: stefane Owned by: bbross
Priority: minor Milestone:
Component: Text Version: D10 (L1003) v2
Keywords: Cc: bbross, wjhan, jct-vc@…

Description

In 9.2.3.2.4 Decoding process for binary decisions before termination, the sentence

When decoding end_of_sub_stream_one_bit, this last bit inserted in register codIOffset is interpreted as alignment_bit_equal_to_one.

should be added after

When decoding end_of_slice_segment_flag, this last bit inserted in register codIOffset is interpreted as rbsp_stop_one_bit.

Change History (10)

comment:1 Changed 9 years ago by DefaultCC Plugin

  • Cc bbross wjhan jct-vc@… added

comment:2 Changed 9 years ago by bbross

Good catch. Due to changed variables names I added the following sentence:

"When decoding end_of_sub_stream_one_bit, this last bit inserted in register ivlOffset is interpreted as alignment_bit_equal_to_one."

And in the informative encoding section:

"When encoding end_of_sub_stream_one_bit, this last bit is interpreted as alignment_bit_equal_to_one."

comment:3 follow-up: Changed 9 years ago by PhuongNguyen

In the current version of the text, I find that in the sentence "The last bit inserted in register codIOffset is equal to 1", the term "the last bit" was not defined or mentioned earlier on.

In order to clarify the text, I suggest to rewrite this part as followed :

If codIOffset is greater than or equal to codIRange, the variable binVal is set equal to 1, no renormalization is carried out, and CABAC decoding is terminated. The value of codIOffset is doubled, i.e. left-shifted by 1 and a single bit is shifted into codIOffset by using read_bits( 1 ). The last bit inserted in register codIOffset is equal to 1 ...

comment:4 in reply to: ↑ 3 ; follow-up: Changed 9 years ago by fbossen

Replying to PhuongNguyen:

In the current version of the text, I find that in the sentence "The last bit inserted in register codIOffset is equal to 1", the term "the last bit" was not defined or mentioned earlier on.

In order to clarify the text, I suggest to rewrite this part as followed :

If codIOffset is greater than or equal to codIRange, the variable binVal is set equal to 1, no renormalization is carried out, and CABAC decoding is terminated. The value of codIOffset is doubled, i.e. left-shifted by 1 and a single bit is shifted into codIOffset by using read_bits( 1 ). The last bit inserted in register codIOffset is equal to 1 ...

The suggested clarification is incorrect. The "last bit" refers to the most recently read bit, not one that you have to read additionally.

comment:5 in reply to: ↑ 4 Changed 9 years ago by PhuongNguyen

Replying to fbossen:

Replying to PhuongNguyen:

In the current version of the text, I find that in the sentence "The last bit inserted in register codIOffset is equal to 1", the term "the last bit" was not defined or mentioned earlier on.

In order to clarify the text, I suggest to rewrite this part as followed :

If codIOffset is greater than or equal to codIRange, the variable binVal is set equal to 1, no renormalization is carried out, and CABAC decoding is terminated. The value of codIOffset is doubled, i.e. left-shifted by 1 and a single bit is shifted into codIOffset by using read_bits( 1 ). The last bit inserted in register codIOffset is equal to 1 ...

The suggested clarification is incorrect. The "last bit" refers to the most recently read bit, not one that you have to read additionally.

If the last bit is the bit inserted before the decoding of termination, then I find it strange to have for example two alignment_bit_equal_to_one when we decode end_of_sub_stream_one_bit : one coming from this last bit and the other coming from byte_alignment(). I believe that the intention of alignment_bit_equal_to_one is a marker in the bitstream so the presence of two consecutive markers may not be necessary.

Also, if we have many MPS without renormalization before having this termination with value equal to one, it will be hard for the encoder to choose the right bit in the most recent renormalization to satisfy the last bit equal to one in the termination.

comment:6 Changed 9 years ago by stefane

The clarification suggested by PhuongNguyen does not look correct. A possible alternative to

The last bit inserted in register ivlOffset is equal to 1.

would be:

The last bit inserted in register ivlOffset prior to invoking this subclause shall be equal to 1.

comment:7 follow-up: Changed 9 years ago by PhuongNguyen

In the current version of the text (L1003-v23), when we detect an end of slice segment, the procedure described in 7.3.2.9, 7.3.2.10 and 7.3.2.11 is :

slice_segment_layer_rbsp() {

slice_segment_header()
slice_segment_data()
rbsp_stop_one_bit
while( !byte_aligned( ) )

rbsp_alignment_zero_bit

while( more_rbsp_trailing_data( ) )

cabac_zero_word

}

When we decode end_of_sub_stream_one_bit :

end_of_sub_stream_one_bit
alignment_bit_equal_to_one
while (!byte_aligned())

alignment_bit_equal_to_zero

According to this ticket, the last bit inserted in register ivlOffset before decoding the termination bin with value equal to 1 shall be equal to 1 and interpreted as rbsp_stop_one_bit or alignment_bit_equal_to_one in the cases end_of_slice_segment_flag or end_of_sub_stream_one_bit respectively. This can lead to a confusion on how the last bit should be present once or twice :

+ Once : the "last bit" and rbsp_stop_one_bit or alignment_bit_equal_to_one is the same bit.

+ Twice : the "last bit" and rbsp_stop_one_bit or alignment_bit_equal_to_one are two different bits.

I would ask for a clarification on this point to avoid any difference in the encoder/decoder behavior when encoding/decoding termination bin with value equal to 1.

comment:8 in reply to: ↑ 7 Changed 9 years ago by fbossen

Replying to PhuongNguyen:

In the current version of the text (L1003-v23), when we detect an end of slice segment, the procedure described in 7.3.2.9, 7.3.2.10 and 7.3.2.11 is :

slice_segment_layer_rbsp() {

slice_segment_header()
slice_segment_data()
rbsp_stop_one_bit
while( !byte_aligned( ) )

rbsp_alignment_zero_bit

while( more_rbsp_trailing_data( ) )

cabac_zero_word

}

When we decode end_of_sub_stream_one_bit :

end_of_sub_stream_one_bit
alignment_bit_equal_to_one
while (!byte_aligned())

alignment_bit_equal_to_zero

According to this ticket, the last bit inserted in register ivlOffset before decoding the termination bin with value equal to 1 shall be equal to 1 and interpreted as rbsp_stop_one_bit or alignment_bit_equal_to_one in the cases end_of_slice_segment_flag or end_of_sub_stream_one_bit respectively. This can lead to a confusion on how the last bit should be present once or twice :

+ Once : the "last bit" and rbsp_stop_one_bit or alignment_bit_equal_to_one is the same bit.

+ Twice : the "last bit" and rbsp_stop_one_bit or alignment_bit_equal_to_one are two different bits.

I would ask for a clarification on this point to avoid any difference in the encoder/decoder behavior when encoding/decoding termination bin with value equal to 1.

Once.

comment:9 Changed 9 years ago by PhuongNguyen

After following this ticket, I also understand that rbsp_stop_one_bit or alignment_bit_equal_to_one is present only once when we decode end_of_slice_segment_flag or end_of_sub_stream_one_bit equal to 1. However, the way the text is written leads the readers to deduce that there are two : one in the last bit inserted to ivlOffset before invoking the termination bin decoding and the other in byte_alignment() or rbsp_trailing_bits( ). It seems that I was not the only person who misunderstood this point (cf ticket #1018).

comment:10 Changed 9 years ago by bbross

  • Resolution set to fixed
  • Status changed from new to closed

Fixed in current version v28.

Regarding the other possible misleading wording of the last bit inserted, we already have that wording in AVC so I would not like to make last minute changes that may break the spec here. Therefore, I will leave it as it is.

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)
  • Frank Bossen(Participant)
  • jct-vc@…(Subscriber)
  • karl.sharman@…(Always)
  • Karsten Suehring(Always)
  • Woo-Jin Han(Subscriber)