[x265] [PATCH] Added support for multiple references

Deepthi Nandakumar deepthi at multicorewareinc.com
Thu Sep 26 08:28:15 CEST 2013


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 <
deepthidevaki at multicorewareinc.com> 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 <steve at borho.org> wrote:
>
>>
>>
>>
>> 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
>>
>> _______________________________________________
>> x265-devel mailing list
>> x265-devel at videolan.org
>> https://mailman.videolan.org/listinfo/x265-devel
>>
>>
>
> _______________________________________________
> x265-devel mailing list
> x265-devel at videolan.org
> https://mailman.videolan.org/listinfo/x265-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20130926/86b5699b/attachment.html>


More information about the x265-devel mailing list