Opened 5 years ago

Last modified 3 years ago

#1013 reopened defect

missing read_bits(1) when pcm_flag is decoded as 1

Reported by: PhuongNguyen Owned by:
Priority: major Milestone:
Component: Text Version: D10 (L1003) v2
Keywords: Cc: fbossen, ksuehring, davidf, jct-vc@…

Description

The spec (9.2.3.2.4) requires that if we decode pcm_flag and it is one, no renormalization is done and a bit is read from the bitstream and it must be one.

It seems that the reference software has not implemented the reading of this bit one yet when we decode value one of pcm_flag.

As far as I understand, the decoding of pcm_flag is done in Void TDecSbac::parseIPCMInfo. In this function, m_pcTDecBinIf->decodeBinTrm(uiSymbol) is called to decode pcm_flag. There is no bit reading from the bitstream if pcm_flag is one in the function decodeBinTrm(uiSymbol). Then m_pcTDecBinIf->decodePCMAlignBits() is called to read bits until byte-alignment. m_pcTDecBinIf->decodePCMAlignBits() is equal to the following pseudo-code in the spec :

while (!byte_aligned())

pcm_alignment_zero_bit.

Change History (5)

comment:1 Changed 5 years ago by DefaultCC Plugin

  • Cc fbossen ksuehring davidf jct-vc@… added

comment:2 Changed 5 years ago by fbossen

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

I believe you are misreading 9.2.3.2.4: where does it say that a bit has to be read? The "last bit" refers to the most recently read bit, not one that you have to read additionally.

comment:3 Changed 3 years ago by Parabola

  • Component changed from HM to Text
  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Version changed from HM-9.2 to D10 (L1003) v2

I think this may still be an issue.

In our parser, which is written in a domain-specific language very similar to the syntax tables in the text, code looks more-or-less exactly like that in chapter 7 of the text. There is one exception in the syntax for coding unit:

if (pcm_flag[x0][y0)]) {
    pcm_alignment_one_bit()         f(1)     <-- not in the text
    while (!byte_aligned())
	pcm_alignment_zero_bit()    f(1)

This allows pcm_flag to be handled by the exact same termination routine as elements end_of_slice_segment and end_of_subset_one_bit. The latter two elements are always followed by rbsp_stop_one_bit and alignment_bit_equal_to_one respectively. I can't see why pcm_flag doesn't also get a "one bit" in the text.

Unless someone can explain how pcm_flag is special (in which case I apologise for reopening a can of worms), the coding unit syntax could be incorrect.

comment:4 Changed 3 years ago by dthoang

I am looking at the published edition 1.0 specification Rec. ITU-T H.265 (04/2013) and see this.

if( pcm_flag[ x0 ][ y0 ] ) {
    while( !byte_aligned( ) )
        pcm_alignment_zero_bit f(1)
    pcm_sample( x0, y0, log2CbSize )
} else {

This is not that same as what you quoted.

comment:5 Changed 3 years ago by Parabola

Yes, that is the problem. I think the text may be incorrect and so proposed a correction. Your published excerpt is different to my proposed. My theory is that there should be a pcm_alignment_one_bit in the text (all versions). Since this text has been reviewed so much now, I am hesitant to believe that this theory could be correct. But Parabola may be the only company that has "compiled" and run the syntax tables in the text of the standard..?

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

  • David Flynn(Subscriber, Always)
  • Dzung Hoang(Participant)
  • Frank Bossen(Subscriber, Participant)
  • jct-vc@…(Subscriber)
  • John Funnell(Participant)
  • Karl Sharman(Always)
  • Karsten Suehring(Subscriber, Always)