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 <[email protected]> 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 <[email protected]> > > 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 > > <[email protected]> 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 > > > <[email protected]> wrote: > > > Hi Chris, > > > > > > 2014-08-18 11:55 GMT+02:00 Chris Healy > > <[email protected]>: > > > > 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 > > > <[email protected]> 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 > > > <[email protected]> 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 > > > <[email protected]> > > > >>> > 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 > > > >>> > <[email protected]> > > > >>> > > 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 > > > > [email protected] > > > > > > 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 > > [email protected] > > http://lists.freedesktop.org/mailman/listinfo/libva > > > > > > > > _______________________________________________ > > Libva mailing list > > [email protected] > > http://lists.freedesktop.org/mailman/listinfo/libva > > >
_______________________________________________ Libva mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libva
