[Libva] gen7 h264 encode bitrate behaviour
Sreerenj
sreerenj.balachandran at intel.com
Mon Aug 18 14:40:00 PDT 2014
I have noticed some issues with CBR mode encoding in gstreamer-vaapi too.
This is tracking here:
https://bugzilla.gnome.org/show_bug.cgi?id=734992
https://bugzilla.gnome.org/show_bug.cgi?id=722734
On 18.08.2014 20:19, 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?
>
>
>
> On Mon, Aug 18, 2014 at 6:27 AM, Gwenole Beauchesne
> <gb.devel at gmail.com <mailto:gb.devel at gmail.com>> wrote:
>
> Hi Chris,
>
> 2014-08-18 11:55 GMT+02:00 Chris Healy <cphealy at gmail.com
> <mailto: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
> <mailto: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 <mailto: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 <mailto: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
> <http://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 <mailto: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 <mailto: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
--
Thanks
Sree
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libva/attachments/20140819/d1b3156b/attachment-0001.html>
More information about the Libva
mailing list