[x265] [PATCH] Added support for multiple references

[Steve Borho]

On Wed, Sep 25, 2013 at 6:22 PM, Olivier Lapicque <olapicque at nvidia.com>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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20130925/3c352545/attachment-0001.html>