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

[alexander tian]

Hi, everyone:

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.

I want to know my idea is right. Give me some advice please.

Best wishes,

Alexander tian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/x264-devel/attachments/20070328/4a58baf1/attachment.htm