Opened 12 years ago Closed 12 years ago #980 closed defect (fixed)9.2.3.2.4: add end_of_sub_stream_one_bit case
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 12 years ago by DefaultCC Plugin
comment:2 Changed 12 years ago by bbrosscomment:3 follow-up: ↓ 4 Changed 12 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: ↓ 5 Changed 12 years ago by fbossen
Replying to PhuongNguyen:
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 12 years ago by PhuongNguyen
Replying to fbossen:
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 12 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: ↓ 8 Changed 12 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() {
}
When we decode end_of_sub_stream_one_bit :
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 12 years ago by fbossen
Replying to PhuongNguyen:
Once. comment:9 Changed 12 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 12 years ago by bbross
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
|
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."