[Libva] gen7 h264 encode bitrate behaviour
Chris Healy
cphealy at gmail.com
Tue Aug 19 08:09:59 PDT 2014
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
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libva/attachments/20140819/48fbfb1c/attachment-0001.html>
More information about the Libva
mailing list