id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
1018	Bug on calculation of dec_max_pic_buffering_minus1 in VTM	vdrugeon		"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)?
"	defect	closed	minor		VTM	VTM-8.0	invalid		ksuehring XiangLi fbossen jvet@…