[x264-devel] Need help to understand a piece of code

BugMaster BugMaster at narod.ru
Tue Feb 2 06:56:08 UTC 2021


On Tue, 2 Feb 2021 13:55:07 +0800, Lingjiang Fang wrote:
> On Mon, 1 Feb 2021 22:39:36 +0300
> BugMaster <BugMaster at narod.ru> wrote:

>> On Mon, 1 Feb 2021 23:04:12 +0800, Lingjiang Fang wrote:
>> 
>> 
>> > The code below puzzled me for a long time, can any give an
>> > explanation for it ?  
>> 
>> > ...  
>> 
>> > I think this code want to solve the vbv overflow after
>> > the current miniGOP, space is the predicted overflow size if there
>> > is no consumption. 
>> > But if we discard the cost of bbits, it means we tend
>> > to decrease q and leak more bits from vbv buffer, won't it leads to
>> > vbv underflow?  
>> 
>> Hi. By discard of the bbits do you mean this part?
>> 
>>             if( bbits * nb > bframe_cpb_duration * rcc->vbv_max_rate )
>>                 nb = 0;
>> 
>> Yes, this part looks incorrect and was broken in:
>> https://code.videolan.org/videolan/x264/-/commit/bb9b16b4722a1273885367f13f448516efe47ed1#2774abc5b23616ba88d9b08fa263902575a84d75_1714_1865
>> It zeros B-frame bits in pbbits but doesn't zeros their duration in
>> minigop_cpb_duration. Here is patch to fix it:
>> https://code.videolan.org/BugMaster/x264/-/commit/a7e2c6ab8ff884e90f47a03258756fb0ad9f2e06

> By zero bframe_cpb_duration, do you mean we don't need to consider
> bframes if their consumptions larger than max input bits, and just
> guarantee p frame won't cause overflow? 

Yes. At least that was the algorithm before it was broken.



More information about the x264-devel mailing list