[Mp4-tech] [H.264 Video] DPB and DPB bumping

Mon Apr 2 14:48:41 EDT 2007

Tomo Tohara-san et al,
I am copying a few key experts on this reply.  I again suggest that whoever the nameless person is that you are hearing this information from is simply wrong.  The decoder buffering requirement for a real decoder (aside from any extra buffering used to cover implementation-specific decoding speed variability issues) should not need to substantially exceed what is stated as the DPB requirement in section A.3 of the standard (which I verify is about 3 Mbytes for Level 3 of the Baseline, Main, Extended and High profiles).
I can confirm that those are the correct names of a couple of bitstreams in our conformance test set (see http://ftp3.itu.ch/av-arch/jvt-site/draft_conformance/).  If those bitstreams violate the DPB constraints in the standard then they are bad bitstreams and should be disregarded.  But I doubt that is the case.
If you can obtain a description of the picture width and height dimensions and POC values (and perhaps Buffering Period SEI and Picture Timing SEI values) for the pictures in those bitstreams, and point at where you believe there is a troublesome spot in such data, I will take a look at the data.
But at this point it sounds to me like you are just spreading around a false rumor.
Best Regards,
Gary Sullivan
+> -----Original Message-----
+> From: mp4-tech-bounces lists.mpegif.org 
+> [mailto:mp4-tech-bounces lists.mpegif.org] On Behalf Of Tomo
+> Sent: Sunday, April 01, 2024 11:43 PM
+> To: Gary Sullivan; mp4-tech lists.mpegif.org
+> Subject: RE: [Mp4-tech] [H.264 Video] DPB and DPB bumping
+> 
+> Thank you Gary for the reply.
+> 
+> Now, I got further information.
+> They say the following bistreams (a part of conformance tests)
+> are problematic to decode with the decoding buffer size of
+> DPB + some extra (for actual decoding as actual decoder is not
+> ideal decoder depicted in the standard).
+> 
+> AVCMR-11 HHI HCBP1_HHI_A
+> AVCMR-12 HHI HCBP2_HHI_A
+> 
+> I am not familiar with these bitstreams but if you or some one
+> who read this message have any comments, would you please
+> let me know? 
+> 
+> I hope not 2*DPB + alpha (+alpha is in a sense decoder jitter
+> removal purpose) for actual decoder design as DPB is already
+> quite large (for level 3, over 3Mbytes).
+> 
+> 
+> Regards
+> Tomo
+> 
+> --- Gary Sullivan <garysull windows.microsoft.com> wrote:
+> 
+> > 
+> > 
+> > To provide a further explanation about what happens when an IDR
+> > picture arrives:
+> > 
+> > Actually, that seems like a pretty good question.
+> > 
+> > When an IDR picture arrives, all pictures that were 
+> previously in the
+> > DPB are marked as "not used for reference".  But that doesn't mean
+> > that they are not counted against the total DPB capacity.  
+> They still
+> > count until their output times arrive, in timing conformance
+> > scenarios. 
+> > 
+> > This means that an IDR picture does not entirely "wipe clean" the
+> > internal state of a (time-driven) decoder (except when the
+> > no_output_of_prior_pics_flag is equal to 1 or is inferred 
+> to be equal
+> > to 1).  It only wipes clean the ability to use prior pictures as
+> > references.
+> > 
+> > Now there are differences between timed decoding and 
+> bumping decoding
+> > that are relevant here too.  Most decoders would probably want to
+> > achieve timed decoding conformance, not just output order
+> > conformance.  For output order conformance, there is no (official)
+> > need to worry about the extra pictures in the DPB when and IDR
+> > picture arrives, because they can all be bumped out once the IDR
+> > arrives.  It is guaranteed that the output time of any picture that
+> > arrived prior to the IDR picture must precede the output 
+> time of the
+> > IDR picture and any pictures that follow it.
+> > 
+> > But timing conforming decoders need to keep pictures around until
+> > their output times arrive, which may be after the decoding times of
+> > the IDR picture and some pictures that follow it.
+> > 
+> > Best Regards,
+> > 
+> > Gary Sullivan
+> > 
+> > +> -----Original Message-----
+> > +> From: mp4-tech-bounces lists.mpegif.org 
+> > +> [mailto:mp4-tech-bounces lists.mpegif.org] On Behalf Of Gary
+> > Sullivan
+> > +> Sent: Wednesday, March 28, 2024 5:00 PM
+> > +> To: Tomo; mp4-tech lists.mpegif.org
+> > +> Subject: RE: [Mp4-tech] [H.264 Video] DPB and DPB bumping
+> > +> 
+> > +> 
+> > +> Who is telling you these things?  I think that is wrong.
+> > +> 
+> > +> Supporting the max DPB capacity, plus perhaps one or two 
+> > +> more frames, should be enough for a hardware decoder.  For a 
+> > +> real-time software decoder that has trouble running fast 
+> > +> enough, you might want more, but only for purposes of 
+> > +> smoothing out the processing time of different pictures.  
+> > +> For correct decoding, e.g., for non-real-time, operation 
+> > +> purposes, it should not be necessary to significantly exceed 
+> > +> the quoted DPB capacity in an implementation
+> > +> 
+> > +> Best Regards,
+> > +> 
+> > +> Gary Sullivan
+> > +> 
+> > +> +> -----Original Message-----
+> > +> +> From: mp4-tech-bounces lists.mpegif.org 
+> > +> +> [mailto:mp4-tech-bounces lists.mpegif.org] On Behalf Of Tomo
+> > +> +> Sent: Wednesday, March 28, 2024 1:29 PM
+> > +> +> To: mp4-tech lists.mpegif.org
+> > +> +> Subject: [Mp4-tech] [H.264 Video] DPB and DPB bumping
+> > +> +> 
+> > +> +> Hi
+> > +> +> 
+> > +> +> I have questions regarding DPB and its bumping.
+> > +> +> Standard specifies max DPB per level.
+> > +> +> HRD assumes buffer management (CPB, DPB) is done 
+> > +> instantly (meaning
+> > +> +> zero delay), but actually it is not possible (for physical
+> > +> +> implementation).
+> > +> +> 
+> > +> +> Now, in case DBP, DBP needs to be managed as described in the
+> > +> +> standard. 
+> > +> +> 
+> > +> +> They say for actual decoder design, decoder needs to 
+> have 2xDPB
+> > +> +> to handle worst case DPB bumping. I guess it could happen at
+> > the
+> > +> +> boundary of IDR, perhaps because IDR makes DBP reset, but
+> > +> +> all the frames in DPB have not yet been displayed and those
+> > +> +> not-yet-displayed frames need to be saved outside of DPB.
+> > +> +> Is my understanding correct?
+> > +> +> If yes, then can this extream case actually happen?
+> > +> +> I mean within standard  and actual (well, some pathological
+> > +> +> encoder might make such case...).
+> > +> +> 
+> > +> +> Any comment?
+> > +> +> 
+> > +> +> Thanks
+> > +> +> 
+> > +> +> 
+> > +> +> Tomo
+> > +> +> _______________________________________________
+> > +> +> NOTE: Please use clear subject lines for your posts. Include 
+> > +> +> [audio, [video], [systems], [general] or another 
+> > +> +> apppropriate identifier to indicate the type of question you
+> > have.
+> > +> +> 
+> > +> +> Note: Conduct on the mailing list is subject to the 
+> > +> +> Antitrust guidelines found at 
+> > +> +> http://www.mpegif.org/public/documents/vault/mp-out-30042-Ant
+> > +> +> itrust.php
+> > +> +> 
+> > +> 
+> > +> _______________________________________________
+> > +> NOTE: Please use clear subject lines for your posts. Include 
+> > +> [audio, [video], [systems], [general] or another 
+> > +> apppropriate identifier to indicate the type of 
+> question you have.
+> > +> 
+> > +> Note: Conduct on the mailing list is subject to the 
+> > +> Antitrust guidelines found at 
+> > +> http://www.mpegif.org/public/documents/vault/mp-out-30042-Ant
+> > +> itrust.php
+> > +> 
+> > 
+> 
+> 
+> Tomo
+> _______________________________________________
+> NOTE: Please use clear subject lines for your posts. Include 
+> [audio, [video], [systems], [general] or another 
+> apppropriate identifier to indicate the type of question you have.
+> 
+> Note: Conduct on the mailing list is subject to the 
+> Antitrust guidelines found at 
+> http://www.mpegif.org/public/documents/vault/mp-out-30042-Ant
+> itrust.php
+>