<div dir="ltr"><div><div>Hi Zhao,<br><br></div>I enabled LIBVA_TRACE recently and grabbed a bunch of output. Here's a link to good size fragment of the output:<br><br><a href="http://pastebin.com/KJYzGQAA" target="_blank">http://pastebin.com/KJYzGQAA</a><br>
<br></div>Here's answers to the specific questions you asked: (From LIBVA_TRACE output)<br><br><div>[57113.237423] intra_period = 30</div><div>[57113.237424] intra_idr_period = 30</div><div>
[57113.237425] ip_period = 1</div><div>[57113.237427] bits_per_second = 3700000</div><div>[57113.237428] max_num_ref_frames = 2</div><div><div>[57113.237469] num_units_in_tick = 15</div>
<div>[57113.237470] time_scale = 900</div><br></div><div>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.<br>
<br></div><div>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? <br>
<br>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.)<br>
<br></div>Regards,<br><br>Chris<div class=""><div id=":18n" class="" tabindex="0"><img class="" src="https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif"></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Sun, Aug 17, 2014 at 11:58 PM, Zhao, Yakui <span dir="ltr"><<a href="mailto:yakui.zhao@intel.com" target="_blank">yakui.zhao@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Sun, 2014-08-17 at 19:27 -0600, Chris Healy wrote:<br>
> I've done some further analysis with our real stream and we experience<br>
> the same inconsistent bitrate behaviour as with the test app. It<br>
> seems to me that the way the bitrate control works doesn't do a good<br>
> job of handling certain input video sequences and the encoded bitrate<br>
> subsequently spikes as a result of this.<br>
><br>
> To help understand what I'm dealing with, I've posted a video on<br>
> youtube showing the video being encoded:<br>
><br>
> <a href="http://www.youtube.com/watch?v=LpYS_9IB0jU" target="_blank">www.youtube.com/watch?v=LpYS_9IB0jU</a><br>
><br>
><br>
> I've also posted a bitrate graph online too that shows what happens<br>
> when encoding the video referenced above:<br>
><br>
> <a href="http://snag.gy/imvBe.jpg" target="_blank">http://snag.gy/imvBe.jpg</a><br>
><br>
><br>
> In the above graph, I set the targeted encode bitrate to 3.7Mbps, CBR,<br>
> and High Profile H.264. Most of the time the bitrate hovers around<br>
> 3.7Mbps, but sometimes the bitrate drops very low then spikes up very<br>
> high. I also notice that when the bitrate drops down low then spikes<br>
> up real high, the "highness" seems to be a function of how much and<br>
> long the bitrate was under 3.7Mbps. It seems that the rate control<br>
> logic is taking a 20 second running bitrate average and trying it's<br>
> best to keep the aggregate bitrate at 3.7Mbps, so if the scene<br>
> complexity drops, the rate control logic reacts by cranking the QP to<br>
> a very low value (high quality) to bring the bitrate back up. This<br>
> behaviour combined with the fact that the video goes to a simple fixed<br>
> image, then crossfades to something complex in less than 20 seconds<br>
> when the QP is a very low value results in the massive spike in<br>
> bitrate. (This is my naive understanding of what’s going on.)<br>
><br>
> The code I'm using to encode and stream is based in large part on<br>
> libva/test/encode/h264encode.c. I'm not sure if the logic for doing<br>
> rate control is in libva, libva-driver-intel, or supposed to be driven<br>
> by the code that uses libva. Am I dealing with an issue with the<br>
> encoder itself or is it more likely my code not correctly driving the<br>
> encoder?<br>
<br>
</div></div>Hi, Chris<br>
<br>
Thank you for reporting the issue.<br>
Will you please check the encoding parameters required by CBR? (For<br>
example: intra_period/ip_period/<br>
num_units_in_tick/time_scale/bits_per_second in<br>
VAEncSequenceParameterBufferH264.)<br>
<br>
Will you please take a look at the example of<br>
libva/test/encode/avcenc.c and see whether it is helpful?<br>
(There exist two h264 encoding examples because of history reasons. The<br>
avcenc case is more consistent with the libva-intel-driver.)<br>
<br>
Thanks.<br>
<span class="HOEnZb"><font color="#888888"> Yakui<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> What can be changed to keep the actual bitrate from being so bursty<br>
> given the video behaviour?<br>
><br>
><br>
> Regards,<br>
><br>
> Chris<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> On Fri, Aug 15, 2014 at 6:03 PM, Chris Healy <<a href="mailto:cphealy@gmail.com">cphealy@gmail.com</a>><br>
> wrote:<br>
> I've been encoding h264 content using HD 4000 HW and am not<br>
> able to make heads or tails of the way the encoder is behaving<br>
> from the standpoint of the data size coming out of the<br>
> encoder.<br>
><br>
> I have a 24 fps 720p video that is the same image for ~8<br>
> seconds, then a 1.5 second fade to the next image followed by<br>
> another ~8 seconds on that image. This goes on and on<br>
> indefinitely. I would have expected that the bitrate would<br>
> have been pretty low, then spike for 1.5 seconds then go back<br>
> to a similarly low value.<br>
><br>
><br>
> When I look at the data coming out of the encoder with a 4Mb/s<br>
> bitrate set and CBR, I'm seeing almost the inverse where most<br>
> of the time, the bitrate is pretty close to 4Mb/s then it<br>
> spikes above 4Mb/s (presumably for the fade), then it drops<br>
> down to ~2Mbps for a second or so before going back up to<br>
> ~4Mb/s.<br>
><br>
> The strangest part is that for the first ~30 seconds of<br>
> encode, across the board, the bitrate is ~2x the bitrate from<br>
> second 31 -> end of encode. (So, I'm hitting a typical rate<br>
> of 7Mbps and peaking out at 13Mbps.)<br>
><br>
><br>
> Is this behaviour expected with gen7 HW? Is there something I<br>
> can do in the initial setup that will cap the MAX bitrate<br>
> regardless of the impact on encode quality?<br>
><br>
> Regards,<br>
><br>
> Chris<br>
><br>
><br>
><br>
<br>
<br>
</div></div></blockquote></div><br></div>