[Libva] gen7 h264 encode bitrate behaviour
Alexey
warpdest at gmail.com
Fri Aug 22 03:09:16 PDT 2014
Hi,
Yes its constant bit-rate control, that work better that existing for me. I
realize it's inside avcenc.c . I have not delved into driver sources, so
may be worth to do something like that in driver.
Best Regards,
Warp.
On Thu, Aug 21, 2014 at 4:48 AM, Zhao, Yakui <yakui.zhao at intel.com> wrote:
> On Wed, 2014-08-20 at 16:38 +0400, Alexey wrote:
> > Hi all,
> >
> >
>
> Hi, Alexey
>
> What is the purpose of your patch? I guees that it is for the
> Bit-rate control?
>
> If it is for constant bit-rate control, I don't think that it is
> necessary to put it in the avcenc test-case as the constant bit-rate
> control is done in low-level driver. Maybe it looks more reasonable that
> it is put into the driver.
>
> Thanks.
> Yakui
>
> > I decided that problem with small modify avcenc.c . After each encoded
> > frame i do :
> >
> > enc->needsize = ( enc->frame_bit_rate * 1024 ) / 8;
> > if ( *outlen ) {
> > float o = (float)( (float)*outlen) / ( (float)enc->needsize /
> > (float)enc->fps );
> > if ( o > 1.0f ) {
> > enc->slice_qp_delta_next += 2;
> > } else if ( o < 0.9f ){
> > enc->slice_qp_delta_next--;
> > }
> > if ( enc->slice_qp_delta_next < -33 ) enc->slice_qp_delta_next =
> > -33;
> > if ( enc->slice_qp_delta_next > 17 ) enc->slice_qp_delta_next =
> > 17;
> > }
> >
> >
> > *outlen its size of current encoded frame.
> >
> >
> >
> > And in void avcenc_update_slice_parameter(struct h264_vaapi_enc *enc,
> > int slice_type) i set slice_param->slice_qp_delta =
> > enc->slice_qp_delta;
> >
> >
> > Initial qp value enc->qp_value = 33;
> >
> >
> >
> > Best Regards,
> >
> > Warp.
> >
> >
> >
> > On Tue, Aug 19, 2014 at 7:09 PM, Chris Healy <cphealy at gmail.com>
> > wrote:
> > Hi Zhao,
> >
> >
> > Thanks for pointing out the QP adjustment logic. I made the
> > (bad) assumption previously that it would be in gen7_mfc.c.
> >
> > I will file a bug and make a YUV stream available in the
> > coming days.
> >
> > Thanks,
> >
> >
> > Chris
> >
> >
> >
> > On Mon, Aug 18, 2014 at 6:03 PM, Zhao, Yakui
> > <yakui.zhao at intel.com> wrote:
> > On Mon, 2014-08-18 at 11:19 -0600, Chris Healy wrote:
> > > Well after taking a look at the behaviour again this
> > morning, (it was
> > > real late for me last night), it does seem that this
> > change did not
> > > solve the issue. I'm still seeing the same
> > inconsistent frame rate.
> > >
> > > The encoder still seems to be trying to average
> > things over a 20
> > > second window.
> > >
> > >
> > > Where is the code that implements the per frame
> > adjustment of the QP?
> > > avcenc.c seems to just be responsible for setting up
> > some encoder
> > > preferences but does not do any dynamic QP
> > adjustment. Also, how can
> > > I enable some debugging to see what the QP is set to
> > for each frame?
> > >
> > >
> >
> >
> > Hi, Chris
> >
> > The QP adjustment is implemented in the function
> > of
> > intel_mfc_brc_postpack in gen6_mfc_common.c. (Sorry
> > that there is no
> > debug option to control whether the QP is printed for
> > every frame. You
> > can print the corresponding QP).
> >
> > Will you please help to create one bug in
> > https://bugs.freedesktop.org/ and then attach your
> > original YUV stream?
> > Then we can look at the issue.
> >
> > Thanks.
> > Yakui
> > >
> > >
> > > On Mon, Aug 18, 2014 at 6:27 AM, Gwenole Beauchesne
> > > <gb.devel at gmail.com> wrote:
> > > Hi Chris,
> > >
> > > 2014-08-18 11:55 GMT+02:00 Chris Healy
> > <cphealy at gmail.com>:
> > > > Hi Zhao,
> > > >
> > > > I just tested the new values you gave me.
> > This is a night
> > > and day
> > > > improvement in bitrate consistency. Based
> > on the small
> > > amount of testing I
> > > > have done, this seems to completely
> > address the problem!
> > > >
> > > > I have to understand why moving from 15
> > and 900 to 1 and 60
> > > makes the
> > > > bitrate so consistent. Both pairs of
> > values are the same so
> > > given the
> > > > following comment: /* Tc =
> > num_units_in_tick / time_sacle
> > > */ I have the
> > > > same Tc in both cases.
> > >
> > >
> > > This should make zero difference. If it
> > does, there should
> > > some arith
> > > error around, that needs to be investigated.
> > 900/15 or 60/1
> > > still
> > > yield 30 fps.
> > >
> > > Note: a tick is the minimum time slice that
> > can be represented
> > > in the
> > > coded data. Typically, a field. time_scale
> > is the frequency.
> > >
> > > > How is this changing things for the better
> > AND, what is the
> > > tradeoff in
> > > > using these values. (There must be some
> > downside otherwise
> > > these values
> > > > would have always been 1 and 2 * fps.)
> > > >
> > > > Regards,
> > > >
> > > > Chris
> > > >
> > > > (PS - Thank you!)
> > > >
> > > >
> > > > On Mon, Aug 18, 2014 at 1:36 AM, Chris
> > Healy
> > > <cphealy at gmail.com> wrote:
> > > >>
> > > >> Hi Zhao,
> > > >>
> > > >> I've done testing with both 30 and 24 fps
> > and received
> > > similar results.
> > > >>
> > > >> I will test with the values you
> > mentioned. Can you explain
> > > how
> > > >> num_units_in_tick and time_scale work?
> > (What is a tick?)
> > > >>
> > > >> Also, is there a good place in the Intel
> > driver to dump the
> > > QP value used
> > > >> for each frame? I'd like to add some QP
> > logging when an
> > > env variable is
> > > >> set.
> > > >>
> > > >> Regards,
> > > >>
> > > >> Chris
> > > >>
> > > >>
> > > >> On Mon, Aug 18, 2014 at 1:30 AM, Zhao,
> > Yakui
> > > <yakui.zhao at intel.com> wrote:
> > > >>>
> > > >>> On Mon, 2014-08-18 at 01:13 -0600, Chris
> > Healy wrote:
> > > >>> > Hi Zhao,
> > > >>> >
> > > >>> >
> > > >>> > I enabled LIBVA_TRACE recently and
> > grabbed a bunch of
> > > output. Here's
> > > >>> > a link to good size fragment of the
> > output:
> > > >>> >
> > > >>> > http://pastebin.com/KJYzGQAA
> > > >>> >
> > > >>> >
> > > >>> > Here's answers to the specific
> > questions you asked:
> > > (From LIBVA_TRACE
> > > >>> > output)
> > > >>> >
> > > >>> > [57113.237423] intra_period = 30
> > > >>> > [57113.237424] intra_idr_period = 30
> > > >>> > [57113.237425] ip_period = 1
> > > >>> > [57113.237427] bits_per_second =
> > 3700000
> > > >>> > [57113.237428] max_num_ref_frames = 2
> > > >>> > [57113.237469] num_units_in_tick = 15
> > > >>> > [57113.237470] time_scale = 900
> > > >>>
> > > >>> If the expected fps is 24, the setting
> > of
> > > num_units_in_tick/time_scale
> > > >>> is incorrect. It will be better that you
> > should use the
> > > following
> > > >>> setting in your tool:
> > > >>> num_units_in_tick = 1
> > > >>> time_scale = 2 * fps
> > > >>>
> > > >>>
> > > >>>
> > > >>> >
> > > >>> > I see avenc.c, but it's unclear to me
> > if I am dealing
> > > with an issue
> > > >>> > with the encoder application or
> > something lower down in
> > > libva or
> > > >>> > libva-driver-intel or the HW itself.
> > > >>> >
> > > >>> >
> > > >>> > Am I correct in believing (simplified)
> > that the HW is
> > > just given a raw
> > > >>> > video frame and a QP and the HW
> > returns a chunk of
> > > encoded data that
> > > >>> > is "some size" and that it is the
> > responsibility of the
> > > SW above the
> > > >>> > HW to dynamically adjust the QP to hit
> > the target
> > > bitrate to meet
> > > >>> > whatever the rate control algorithm
> > deems correct?
> > > >>> >
> > > >>>
> > > >>> When the CBR mode is used, the driver
> > will adjust QP
> > > dynamically so that
> > > >>> the encoded bitrate can meet with the
> > requirement of
> > > target bitrate
> > > >>> based on the input encoding
> > parameter(For example:
> > > intra_period,
> > > >>> ip_period, time_scale, num_units_in_tick
> > and so on).
> > > >>>
> > > >>>
> > > >>> > If this is the case, where is the code
> > that is
> > > dynamically adjusting
> > > >>> > the QP? Also, in the HW, where are
> > the registers and
> > > bits control the
> > > >>> > QP? (I'm looking at the "Intel ®
> > OpenSource HD Graphics
> > > Programmer’s
> > > >>> > Reference Manual (PRM) Volume 2 Part
> > 3: Multi-Format
> > > Transcoder – MFX
> > > >>> > (Ivy Bridge)" so a reference to the
> > registers might be
> > > helpful for me
> > > >>> > to understand better.)
> > > >>> >
> > > >>> >
> > > >>> > Regards,
> > > >>> >
> > > >>> > Chris
> > > >>> >
> > > >>> >
> > > >>> >
> > > >>> > On Sun, Aug 17, 2014 at 11:58 PM,
> > Zhao, Yakui
> > > <yakui.zhao at intel.com>
> > > >>> > wrote:
> > > >>> > On Sun, 2014-08-17 at 19:27
> > -0600, Chris Healy
> > > wrote:
> > > >>> > > I've done some further
> > analysis with our real
> > > stream and we
> > > >>> > experience
> > > >>> > > the same inconsistent
> > bitrate behaviour as
> > > with the test
> > > >>> > app. It
> > > >>> > > seems to me that the way the
> > bitrate control
> > > works doesn't
> > > >>> > do a good
> > > >>> > > job of handling certain
> > input video sequences
> > > and the
> > > >>> > encoded bitrate
> > > >>> > > subsequently spikes as a
> > result of this.
> > > >>> > >
> > > >>> > > To help understand what I'm
> > dealing with, I've
> > > posted a
> > > >>> > video on
> > > >>> > > youtube showing the video
> > being encoded:
> > > >>> > >
> > > >>> > >
> > www.youtube.com/watch?v=LpYS_9IB0jU
> > > >>> > >
> > > >>> > >
> > > >>> > > I've also posted a bitrate
> > graph online too
> > > that shows what
> > > >>> > happens
> > > >>> > > when encoding the video
> > referenced above:
> > > >>> > >
> > > >>> > > http://snag.gy/imvBe.jpg
> > > >>> > >
> > > >>> > >
> > > >>> > > In the above graph, I set
> > the targeted encode
> > > bitrate to
> > > >>> > 3.7Mbps, CBR,
> > > >>> > > and High Profile H.264.
> > Most of the time the
> > > bitrate hovers
> > > >>> > around
> > > >>> > > 3.7Mbps, but sometimes the
> > bitrate drops very
> > > low then
> > > >>> > spikes up very
> > > >>> > > high. I also notice that
> > when the bitrate
> > > drops down low
> > > >>> > then spikes
> > > >>> > > up real high, the "highness"
> > seems to be a
> > > function of how
> > > >>> > much and
> > > >>> > > long the bitrate was under
> > 3.7Mbps. It seems
> > > that the rate
> > > >>> > control
> > > >>> > > logic is taking a 20 second
> > running bitrate
> > > average and
> > > >>> > trying it's
> > > >>> > > best to keep the aggregate
> > bitrate at 3.7Mbps,
> > > so if the
> > > >>> > scene
> > > >>> > > complexity drops, the rate
> > control logic
> > > reacts by cranking
> > > >>> > the QP to
> > > >>> > > a very low value (high
> > quality) to bring the
> > > bitrate back
> > > >>> > up. This
> > > >>> > > behaviour combined with the
> > fact that the
> > > video goes to a
> > > >>> > simple fixed
> > > >>> > > image, then crossfades to
> > something complex in
> > > less than 20
> > > >>> > seconds
> > > >>> > > when the QP is a very low
> > value results in the
> > > massive spike
> > > >>> > in
> > > >>> > > bitrate. (This is my naive
> > understanding of
> > > what’s going
> > > >>> > on.)
> > > >>> > >
> > > >>> > > The code I'm using to encode
> > and stream is
> > > based in large
> > > >>> > part on
> > > >>> > >
> > libva/test/encode/h264encode.c. I'm not sure
> > > if the logic
> > > >>> > for doing
> > > >>> > > rate control is in libva,
> > libva-driver-intel,
> > > or supposed to
> > > >>> > be driven
> > > >>> > > by the code that uses libva.
> > Am I dealing
> > > with an issue
> > > >>> > with the
> > > >>> > > encoder itself or is it more
> > likely my code
> > > not correctly
> > > >>> > driving the
> > > >>> > > encoder?
> > > >>> >
> > > >>> >
> > > >>> > Hi, Chris
> > > >>> >
> > > >>> > Thank you for reporting
> > the issue.
> > > >>> > Will you please check the
> > encoding
> > > parameters required by
> > > >>> > CBR? (For
> > > >>> > example:
> > intra_period/ip_period/
> > > >>> >
> > num_units_in_tick/time_scale/bits_per_second in
> > > >>> >
> > VAEncSequenceParameterBufferH264.)
> > > >>> >
> > > >>> > Will you please take a
> > look at the example
> > > of
> > > >>> > libva/test/encode/avcenc.c and
> > see whether it is
> > > helpful?
> > > >>> > (There exist two h264 encoding
> > examples because
> > > of history
> > > >>> > reasons. The
> > > >>> > avcenc case is more consistent
> > with the
> > > libva-intel-driver.)
> > > >>> >
> > > >>> > Thanks.
> > > >>> > Yakui
> > > >>> >
> > > >>> > > What can be changed to keep
> > the actual bitrate
> > > from being so
> > > >>> > bursty
> > > >>> > > given the video behaviour?
> > > >>> > >
> > > >>> > >
> > > >>> > > Regards,
> > > >>> > >
> > > >>> > > Chris
> > > >>> > >
> > > >>> > >
> > > >>> > >
> > > >>> > >
> > > >>> > >
> > > >>> > >
> > > >>> > >
> > > >>> > >
> > > >>> > >
> > > >>> > > On Fri, Aug 15, 2014 at 6:03
> > PM, Chris Healy
> > > >>> > <cphealy at gmail.com>
> > > >>> > > wrote:
> > > >>> > > I've been encoding
> > h264 content using
> > > HD 4000 HW and
> > > >>> > am not
> > > >>> > > able to make heads
> > or tails of the way
> > > the encoder
> > > >>> > is behaving
> > > >>> > > from the standpoint
> > of the data size
> > > coming out of
> > > >>> > the
> > > >>> > > encoder.
> > > >>> > >
> > > >>> > > I have a 24 fps 720p
> > video that is the
> > > same image
> > > >>> > for ~8
> > > >>> > > seconds, then a 1.5
> > second fade to the
> > > next image
> > > >>> > followed by
> > > >>> > > another ~8 seconds
> > on that image.
> > > This goes on and
> > > >>> > on
> > > >>> > > indefinitely. I
> > would have expected
> > > that the
> > > >>> > bitrate would
> > > >>> > > have been pretty
> > low, then spike for
> > > 1.5 seconds
> > > >>> > then go back
> > > >>> > > to a similarly low
> > value.
> > > >>> > >
> > > >>> > >
> > > >>> > > When I look at the
> > data coming out of
> > > the encoder
> > > >>> > with a 4Mb/s
> > > >>> > > bitrate set and CBR,
> > I'm seeing almost
> > > the inverse
> > > >>> > where most
> > > >>> > > of the time, the
> > bitrate is pretty
> > > close to 4Mb/s
> > > >>> > then it
> > > >>> > > spikes above 4Mb/s
> > (presumably for the
> > > fade), then
> > > >>> > it drops
> > > >>> > > down to ~2Mbps for a
> > second or so
> > > before going back
> > > >>> > up to
> > > >>> > > ~4Mb/s.
> > > >>> > >
> > > >>> > > The strangest part
> > is that for the
> > > first ~30 seconds
> > > >>> > of
> > > >>> > > encode, across the
> > board, the bitrate
> > > is ~2x the
> > > >>> > bitrate from
> > > >>> > > second 31 -> end of
> > encode. (So, I'm
> > > hitting a
> > > >>> > typical rate
> > > >>> > > of 7Mbps and peaking
> > out at 13Mbps.)
> > > >>> > >
> > > >>> > >
> > > >>> > > Is this behaviour
> > expected with gen7
> > > HW? Is there
> > > >>> > something I
> > > >>> > > can do in the
> > initial setup that will
> > > cap the MAX
> > > >>> > bitrate
> > > >>> > > regardless of the
> > impact on encode
> > > quality?
> > > >>> > >
> > > >>> > > Regards,
> > > >>> > >
> > > >>> > > Chris
> > > >>> > >
> > > >>> > >
> > > >>> > >
> > > >>> >
> > > >>> >
> > > >>> >
> > > >>> >
> > > >>> >
> > > >>>
> > > >>>
> > > >>
> > > >
> > > >
> > >
> > > >
> > _______________________________________________
> > > > Libva mailing list
> > > > Libva at lists.freedesktop.org
> > > >
> > http://lists.freedesktop.org/mailman/listinfo/libva
> > > >
> > >
> > >
> > > Regards,
> > > --
> > > Gwenole Beauchesne
> > > Intel Corporation SAS / 2 rue de Paris,
> > 92196 Meudon Cedex,
> > > France
> > > Registration Number (RCS): Nanterre B 302
> > 456 199
> > >
> > >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Libva mailing list
> > Libva at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/libva
> >
> >
> >
> > _______________________________________________
> > Libva mailing list
> > Libva at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/libva
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libva/attachments/20140822/2f92b421/attachment-0001.html>
More information about the Libva
mailing list