[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