[x264-devel] Re: Is the input size wrong with the vbv buffer?

[Loren Merritt]

On Wed, 28 Mar 2007, alexander tian wrote:

> I have some questions about vbv buffer update in x264. The specification
> said that it is the data with the access units that flow into the CPB. The
> data include not only the coded frame size but also all the other NAL units
> flow into the CPB.
>
> Bellows are from h264 specification:
> "The HRD operates as follows. Data associated with access units that flow
> into the CPB according to a specified arrival schedule are delivered by the
> HSS. ¡­¡­"
> *"access unit*: A set of *NAL units *always containing exactly one *primary
> coded picture*. In addition to the *primary coded picture*, an access unit
> may also contain one or more *redundant coded pictures *or other *NAL units
> *not containing *slices *or *slice data partitions *of a *coded picture*.
> The decoding of an access unit always results in a *decoded picture*."
>
> So I think the function "update_vbv" has some bugs. The parameter "bits"
> should be equal to the total bits in the "h->out.nal[X264_NAL_MAX]". Such as
> bellows:
>
>   for(nNalLoop=0; nNalLoop<X264_NAL_MAX; nNalLoop++)
>   {
>      if(h->out.nal[nNalLoop].i_type > 0)
>         nRealBits += h->out.nal[nNalLoop].i_payload + 5;
>   }
>   rcc->buffer_fill += rcc->buffer_rate - nRealBits*8;
>
> The number 5 is that 4 bytes "start_code_prefix" add 1 byte
> "nal_unit_start". i.e.  "00 00 00 01 65".
>
> At the same time the "h->out.nal[nNalLoop].i_type" should be set as zero at
> the begin of the function "x264_encoder_encode" to avoid the influence of
> last frame.

A NAL unit is just the type and contents, not including the "00 00 00 01".
Startcode could be considered "data associated with an access unit", but
it might not be present at all, depending on what container is used. And
libx264 can't possibly know what container you're putting the output
stream in.

Plus, you count bytes in a variable called "bits", and you use a 
complicated loop depending on nal type when it could just count up to 
h->out.i_nal.

--Loren Merritt