If this is the case, shouldnt you be changing maxRefL0 to maxNumReferences - 1 ??
On Thu, Sep 26, 2013 at 10:55 AM, Deepthi Devaki Akkoorath < [email protected]> wrote: > > The current implementation is like this: > > numNegPics + numPosPics = maxNumReferences. > For P slices: numNegPics = maxNumReferences > For B slices: numNegPics = maxNumReferences - 1, numPosPics = 1 > > With the above logic , maxDecPicBuffering = 1(current) + > maxNumReferences seems to be correct > > - Deepthi > > > On Thu, Sep 26, 2013 at 7:05 AM, Steve Borho <[email protected]> wrote: > >> >> >> >> On Wed, Sep 25, 2013 at 6:22 PM, Olivier Lapicque >> <[email protected]>wrote: >> >>> Yeah, it seems like it should be more like:**** >>> >>> MaxDecPicBuffering = 1 (Current) + MaxNumNegativePics (=MaxForwardRefs) >>> + MaxNumPositivePics (=MaxBackwardRefs)**** >>> >>> ** ** >>> >>> With assuming **** >>> >>> MaxNumNegativePics = maxNumReferences (really MaxNumForwardReferences)** >>> ** >>> >>> MaxNumPositivePics = limited by gop structure (reordering) **** >>> >>> ** ** >>> >>> For a standard GOP structure with non-reference B-frames (coded >>> order=Pbbb):**** >>> >>> MaxDecPicBuffering = 1 (Current) + maxNumReferences + 1 ( 1P available >>> as backward reference, limiting NumPositivePics to 1) = 2+maxNumReferences >>> **** >>> >>> ** ** >>> >>> For 1-deep B-pyramid where the middle-B is a reference (display >>> order=bBbP, coded order=PBbb):**** >>> >>> MaxDecPicBuffering = 1 (Current) + maxNumReferences + 2 (1P + 1B >>> available as backward references, limiting NumPositivePics to 1) = >>> 3+maxNumReferences >>> >> >> I think the current logic is correct. We don't yet support B-pyramid so >> I believe: >> >> maxPositivePics = 1 >> maxNegativePics = max(1, maxNumReferences - maxPositivePics). >> >> The max consecutive bframes count (--bframes) doesn't influence >> MaxDecPicBuffering since non-referenced B frames can be flushed from the >> DPB as soon as they are displayed. >> >> Deepthi D, can you confirm this is true? >> >> Thanks, >> >> -- >> Steve Borho >> >> _______________________________________________ >> x265-devel mailing list >> [email protected] >> https://mailman.videolan.org/listinfo/x265-devel >> >> > > _______________________________________________ > x265-devel mailing list > [email protected] > https://mailman.videolan.org/listinfo/x265-devel > >
_______________________________________________ x265-devel mailing list [email protected] https://mailman.videolan.org/listinfo/x265-devel
