[Libva] gen7 h264 encode bitrate behaviour
Alexey
warpdest at gmail.com
Wed Aug 20 05:38:53 PDT 2014
Hi all,
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libva/attachments/20140820/25c37650/attachment-0001.html>
More information about the Libva
mailing list