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

[Tomo]

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