Opened 12 years ago

Closed 12 years ago

#935 closed defect (fixed)

Possible confusion in removal of pictures from DPB

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

Description

In section C.5.3 "Output and removal of pictures from the DPB" the text says that the bumping process is invoked (before decoding the current picture) until the number of pictures in the DPB is _strictly_ less than sps_max_dec_pic_buffering.

Sequences produced by the reference encoder (such as using 9.1rc1 with cfg/encoder_randomaccess_main.cfg) use 4 reference frames (num_negative_pics=4) and set sps_max_dec_pic_buffering to 4.

This causes a problem because the bumping process tries to reduce the DPB to 3, but 4 reference frames are needed.

The reference decoder does not have a problem because lines 178-184 of TDecTop.cpp read:

if ( !bBufferIsAvailable )
{
/ / There is no room for this picture, either because of faulty encoder or dropped NAL. Extend the buffer.
m_iMaxRefPicNum++;
rpcPic = new TComPic();
m_cListPic.pushBack( rpcPic );

}

and so the reference decoder simply increases the size of the decoded picture buffer without complaining. (Additionally, m_iMaxRefPicNum is initialised on line 143 to a larger value than should be necessary.)

My guess is that the text should change to say that the bumping should be invoked while the number of pictures is _greater_ than sps_max_dec_pic_buffering[TemporalId].

Change History (8)

comment:1 Changed 12 years ago by DefaultCC Plugin

  • Cc bbross wjhan jct-vc@… added

comment:2 Changed 12 years ago by yk

I think this is a software bug - when 4 reference pictures are used, then the DPB size must be at least 5, as the current picture after being decoded would also be stored into the DPB (as different than in AVC, where the current picture after being decoded is not stored into the DPB).

comment:3 Changed 12 years ago by jonatan

I don't think this is a software bug (only). The syntax elements in the RPS are bound so that the RPS can contain up to sps_max_dec_pic_buffering[ HighestTid ] number of pictures but in practice the RPS can not have more than sps_max_dec_pic_buffering[ i ] - 1 pictures since the following bitstream conformance condition would otherwise not be fulfilled.

"6. For each current picture that is decoded, after invocation of the process for removal of pictures from the DPB as specified in subclause C.3.2, the number of decoded pictures in the DPB, including all pictures n that are marked as "used for reference" or that have PicOutputFlag equal to 1 and tr( n ) < tr( currPic ), where currPic is the current picture, shall be less than or equal to Max( 0, sps_max_dec_pic_buffering[ HighestTid ] − 1)."

I would suggest to insert -1 in the following 4 places in the semantics section in order to have syntax element boundaries that corresponds to the bitstream requirement (and the bumping process).

num_negative_pics specifies the number of the following delta_poc_s0_minus1[ i ] and used_by_curr_pic_s0_flag[ i ] syntax elements. The value of num_negative_pics shall be in the range of 0 to sps_max_dec_pic_buffering[ sps_max_sub_layers_minus1 ] − 1, inclusive.

num_positive_pics specifies the number of the following delta_poc_s1_minus1[ i ] and used_by_curr_pic_s1_flag1[ i ] syntax elements. The value of num_positive_pics shall be in the range of 0 to sps_max_dec_pic_buffering[ sps_max_sub_layers_minus1 ] − num_negative_pics − 1, inclusive.

num_long_term_sps specifies the number of candidate long-term reference pictures specified in the active sequence parameter set that are included in the long-term reference picture set of the current picture. The value of num_long_term_sps shall be in the range of 0 to Min( num_long_term_ref_pics_sps, sps_max_dec_pic_buffering[ sps_max_sub_layers_minus1 ] −NumNegativePics[ StRpsIdx ] − NumPositivePics[ StRpsIdx ] − 1 ), inclusive. When not present, the value of num_long_term_sps is inferred to be equal to 0.

num_long_term_pics specifies the number of long-term reference pictures specified in the slice header, which are included in the long-term reference picture set of the current picture. The value of num_long_term_pics shall be in the range of 0 to sps_max_dec_pic_buffering[ sps_max_sub_layers_minus1 ] − NumNegativePics[ StRpsIdx ] − NumPositivePics[ StRpsIdx ] − num_long_term_sps − 1, inclusive. When not present, the value of num_long_term_pics is inferred to be equal to 0.

comment:4 Changed 12 years ago by yk

To me, the issue of the value ranges of the RPS syntax elements is a different one. JCTVC-L0323 covers this. I'd prefer to change *_max_dec_pic_buffering to _max_dec_pic_buffering_minus1, but let's discuss in Geneva and see what exactly should be done.

comment:5 Changed 12 years ago by bbross

  • Version changed from D9 (K1003) v13 to D10 (L1003) v1

comment:6 Changed 12 years ago by bbross

  • Milestone set to D10

comment:7 Changed 12 years ago by bbross

  • Version changed from D10 (L1003) v1 to D10 (L1003) v2

comment:8 Changed 12 years ago by bbross

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

This is fixed in JCTVC-L1003_v5 by the decisions noted under JCTVC-L0323.

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)
  • Jonatan Samuelsson(Participant)
  • karl.sharman@…(Always)
  • Karsten Suehring(Always)
  • Peter de Rivaz(Reporter)
  • Woo-Jin Han(Subscriber)
  • Ye-Kui Wang(Participant)