Opened 5 years ago

Closed 4 years ago

#1018 closed defect (invalid)

Bug on calculation of dec_max_pic_buffering_minus1 in VTM

Reported by: vdrugeon Owned by:
Priority: minor Milestone:
Component: VTM Version: VTM-8.0
Keywords: Cc: ksuehring, XiangLi, fbossen, jvet@…

Description

According to the specification text, dec_max_pic_buffering_minus1 is supposed to signal the maximum size of the DPB in number of pictures:
"max_dec_pic_buffering_minus1[ i ] plus 1 specifies the maximum required size of the DPB in units of picture storage buffers when Htid is equal to i. "
And in Annex C:
"For each current picture, after invocation of the process for removal of pictures from the DPB as specified in clause 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 PictureOutputFlag equal to 1 and CpbRemovalTime[ n ] less than CpbRemovalTime[ currPic ], where currPic is the current picture, shall be less than or equal to max_dec_pic_buffering_minus1[ Htid ]."

With the GOP structure that is currently used in the CTC, the maximum DPB size is 7, but it is currently calculated and signalled in the bitstream as 6 (i.e. max_dec_pic_buffering_minus1 = 5 instead of 6). This is because the current calculation of max_dec_pic_buffering_minus1 (which is done in EncAppCfg::xCheckParameter) considers only the number of reference pictures for each picture, but ignores the pictures that are waiting in the DPB to be output.
 
I remember that this issue has been discussed in past meetings (see JVET-P0133 for example), but this issue has not been fixed in VTM (yet?). Is there any reason why this was not fixed in VTM? It seems that it would be an issue for conformance bitstreams, since the signalled value of the maximum DPB size would not conform to the specification.

I have implemented a possible fix to generate correct conformance bitstreams. If useful, I am happy to provide the fix as merge request, but I would prefer experts to check the code before.

Any comments (especially from authors of JVET-P0133)?

Change history (3)

comment:1 Changed 5 years ago by vdrugeon

PLease have a look at the following merge request:
https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/-/merge_requests/1514

comment:2 Changed 4 years ago by fbossen

As far as I can tell max_dec_pic_buffering_minus1 = 5 works for the CTC RA conditions when considering C.5.2. This shouldn't be much different from C.3.

Below are the DPB contents (POC values) after inserting each picture:

DPB>  0 
DPB> 16  0 
DPB>  8 16  0 
DPB>  4  8 16  0 
DPB>  2  4  8 16  0 
DPB>  1  2  4  8 16  0 
DPB>  3  2  4  8 16  0 
DPB>  6  3  4  8 16  0 
DPB>  5  6  4  8 16  0 
DPB>  7  6  4  8 16  0 
DPB> 12  7  6  8 16  0 
DPB> 10 12  7  8 16  0 
DPB>  9 10 12  8 16  0 
DPB> 11 10 12  8 16  0 
DPB> 14 11 12  8 16  0 
DPB> 13 14 12  8 16  0 
DPB> 15 14 12  8 16  0 
DPB> 32 15 14  8 16  0 
DPB> 24 32 15 14  8 16 
DPB> 20 24 32 15  8 16 
DPB> 18 20 24 32  8 16 
DPB> 17 18 20 24 32 16 
DPB> 19 18 20 24 32 16 
DPB> 22 19 20 24 32 16 
DPB> 21 22 20 24 32 16 
DPB> 23 22 20 24 32 16 
DPB> 28 23 22 24 32 16 
DPB> 26 28 23 24 32 16 
DPB> 25 26 28 24 32 16 
DPB> 27 26 28 24 32 16 
DPB> 30 27 28 24 32 16 
DPB> 29 30 28 24 32 16 
DPB> 31 30 28 24 32 16 

comment:3 Changed 4 years ago by vdrugeon

  • Resolution set to invalid
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.