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

[alexander tian]

Loren, thanks for your reply.

>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.
Yes, you are right. A NAL unit is only the type and contents. It doesn't
include the "start_code_prefix".

But I do not clearly know what you mean. Does the different container
correspond to different way? What does the container mean here? Could you
explain it in detail? Or give me some references please.

Why I change them is because of some experience results. I use the x264 to
produce h264 es file by using 1pass, CBR mode. I use the software "Elecard
Buffer Analyzer" to analyze these files. I find that the vbv buffer will
underflow if the time is above 60 seconds. I think the accumulative errors
for input size result in the end. The buffer would not underflow if I change
the input size from encoded frame size to the all data size. So I believe
that the vbv operation should be changed.

>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.
Oh, yes. Your way is simple. I will use this way.

Any advices will be welcome. Thanks in advance.

2007/3/28, Loren Merritt <lorenm at u.washington.edu>:
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/x264-devel/attachments/20070329/d40373c9/attachment.htm