https://bugs.freedesktop.org/show_bug.cgi?id=98005

--- Comment #1 from Andy Furniss adf.lists@gmail.com --- Continued on mesa-devel -

https://lists.freedesktop.org/archives/mesa-dev/2016-October/130385.html

https://bugs.freedesktop.org/show_bug.cgi?id=98005

--- Comment #3 from Andy Furniss adf.lists@gmail.com --- (In reply to Boyuan Zhang from comment #2)

Hi Andy,

The corruption/out of order issue has been reproduced locally. Root cause and fix can be found at https://lists.freedesktop.org/archives/mesa-dev/2016-October/132268.html

Please give a try.

Regards, Boyuan

Thanks, that does fix the out of order and corruption.

As you explained in the thread above, dual instance bitrate control is a separate issue, but this patch does change behavior a bit.

cbr is unaffected by patch and could be seen as OK (unless I find a better test to break it). md5sums may vary but the bitrate/file size is only different by a tiny amount and visually things seem OK.

vbr is different, before patch it may be OK, but there was a chance of some files being less that half size/rate than they should.

With the patch it seems that they are all now less than half rate. So at least it's consistent (md5sums do still vary).

Will test more tomorrow as it's late here.

https://bugs.freedesktop.org/show_bug.cgi?id=98005

--- Comment #5 from Andy Furniss adf.lists@gmail.com --- I normally test with raw, but this sample also shows the issue with transcode,

I tried harder and it is possible since the patch to get a normal size vbr - just a lot harder than before.

1080p50.mkv - https://drive.google.com/file/d/0BxP5-S1t9VEEczlMd2ZzUElldms/view?usp=sharin...

Here's a paste testing with your settings.

andy [vce-vbr-test]$ gst-launch-1.0 -f filesrc location=1080p50.mkv ! matroskademux ! vaapidecode ! vaapih264enc rate-control=vbr bitrate=21428 ! video/x-h264,profile=baseline ! filesink location=vbr.264 Setting pipeline to PAUSED ... libva info: VA-API version 0.39.2 libva info: va_getDriverName() returns 0 libva info: User requested driver 'radeonsi' libva info: Trying to open /usr/lib/dri/radeonsi_drv_video.so libva info: Found init function __vaDriverInit_0_39 libva info: va_openDriver() returns 0 Pipeline is PREROLLING ... Got context from element 'vaapiencodeh264-0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)NULL; Redistribute latency... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Got EOS from element "pipeline0". Execution ended after 0:00:05.440943972 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ...

andy [vce-vbr-test]$ gst-launch-1.0 -f filesrc location=1080p50.mkv ! matroskademux ! vaapidecode ! vaapih264enc rate-control=cbr bitrate=15000 ! video/x-h264,profile=baseline ! filesink location=cbr.264 Setting pipeline to PAUSED ... libva info: VA-API version 0.39.2 libva info: va_getDriverName() returns 0 libva info: User requested driver 'radeonsi' libva info: Trying to open /usr/lib/dri/radeonsi_drv_video.so libva info: Found init function __vaDriverInit_0_39 libva info: va_openDriver() returns 0 Pipeline is PREROLLING ... Got context from element 'vaapiencodeh264-0': gst.vaapi.Display=context, gst.vaapi.Display=(GstVaapiDisplay)NULL; Redistribute latency... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Got EOS from element "pipeline0". Execution ended after 0:00:05.162493127 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ...

andy [vce-vbr-test]$ ls -lh total 85M -rw-rw-r-- 1 andy andy 35M Sep 28 16:05 1080p50.mkv -rw-rw-r-- 1 andy andy 35M Oct 18 21:17 cbr.264 -rw-rw-r-- 1 andy andy 15M Oct 18 21:16 vbr.264

https://bugs.freedesktop.org/show_bug.cgi?id=98005

--- Comment #7 from Andy Furniss adf.lists@gmail.com --- (In reply to Boyuan Zhang from comment #6)

Hi Andy,

I just submitted 2 reviews for fixing the bit-rate issue. The 2 patches can be found at https://lists.freedesktop.org/archives/mesa-dev/2016-November/134944.html

0001-st/va: force to submit two consecutive single jobs 0002-st/va: fix gop size for rate control

Please give a try and let me know how it works.

Regards, Boyuan

Hi, I can't get those to apply to current mesa head.

Checking patch src/gallium/state_trackers/va/picture.c... Hunk #1 succeeded at 413 (offset 1 line). Hunk #2 succeeded at 568 (offset 1 line). Checking patch src/gallium/state_trackers/va/surface.c... error: while searching for:

if (context->decoder->entrypoint == PIPE_VIDEO_ENTRYPOINT_ENCODE) { int frame_diff; if (context->desc.h264enc.frame_num_cnt > surf->frame_num_cnt) frame_diff = context->desc.h264enc.frame_num_cnt - surf->frame_num_cnt; else frame_diff = 0xFFFFFFFF - surf->frame_num_cnt + 1 + context->desc.h264enc.frame_num_cnt; if (frame_diff < 2) context->decoder->flush(context->decoder); context->decoder->get_feedback(context->decoder, surf->feedback, &(surf->coded_buf->coded_size)); } pipe_mutex_unlock(drv->mutex);

error: patch failed: src/gallium/state_trackers/va/surface.c:119 error: src/gallium/state_trackers/va/surface.c: patch does not apply Checking patch src/gallium/state_trackers/va/va_private.h... Hunk #2 succeeded at 275 (offset 1 line).

and

Checking patch src/gallium/state_trackers/va/picture.c... Hunk #1 succeeded at 351 (offset 1 line). error: while searching for: context->desc.h264enc.not_referenced = false; context->desc.h264enc.is_idr = (h264->pic_fields.bits.idr_pic_flag == 1); context->desc.h264enc.pic_order_cnt = h264->CurrPic.TopFieldOrderCnt / 2; if (context->desc.h264enc.is_idr) context->desc.h264enc.i_remain = 1; else context->desc.h264enc.i_remain = 0;

context->desc.h264enc.p_remain = context->desc.h264enc.gop_size - context->desc.h264enc.gop_cnt - context->desc.h264enc.i_remain;

error: patch failed: src/gallium/state_trackers/va/picture.c:390 error: src/gallium/state_trackers/va/picture.c: patch does not apply Checking patch src/gallium/state_trackers/va/va_private.h...

https://bugs.freedesktop.org/show_bug.cgi?id=98005

--- Comment #9 from Andy Furniss adf.lists@gmail.com --- The transcoding test above now makes similar size to cbr.

There is a new issue though. The GOP patch (2) is problematic.

It doesn't show on the transcoding test, but after reading the patch comment about gop affecting rate control I tested with gstreamer default (30) and max =

keyframe-period=300

With vbr plus high bitrates this makes a large difference in file size.

This still happens if I disable dual instance in radeon_vce.c.

CBR seems to be unaffected, though dual instance encoding seems to come out a bit lower than single instance.

The vbr test =

gst-launch-1.0 -f filesrc location=/mnt/ramdisk/trees-1440p50.nv12 blocksize=5529600 ! video/x-raw,format=NV12,width=2560,height=1440,framerate=50/1 ! queue ! vaapih264enc rate-control=vbr bitrate=50000 keyframe-period=300 ! video/x-h264, profile=baseline ! filesink location=/mnt/ramdisk/out.264

Result = 9.4M file (source is 500 frames)

above with keyframe-period=30 = 42M which is close to expected result.

https://bugs.freedesktop.org/show_bug.cgi?id=98005

--- Comment #11 from Andy Furniss adf.lists@gmail.com --- It turns out with more time + different tests that these patches don't fix the original issue.

I can still get too low bitrates depending on timing/luck eg. forcing powerplay/cpufreq to high with the right test stream can get different results from auto. This is testing with the same GOP and (so far) disabling dual instance does seem to always produce the correct bitrate.

I also found another bug = ntsc framerates are not handled. I live in PAL land, so didn't notice this sooner, though we still get /1001 framerates on blu-ray which is how I belatedly noticed.

I made a hacky fix - maybe working out where (if anywhere) the players pass framerate den would be better, but I'll attach it anyway just to see what you think (it only applies to vanilla mesa). Seems to work OK with avconv and gstreamer.

https://bugs.freedesktop.org/show_bug.cgi?id=98005

--- Comment #13 from Boyuan Zhang boyuan.zhang@amd.com --- (In reply to Andy Furniss from comment #11)

It turns out with more time + different tests that these patches don't fix the original issue.

I can still get too low bitrates depending on timing/luck eg. forcing powerplay/cpufreq to high with the right test stream can get different results from auto. This is testing with the same GOP and (so far) disabling dual instance does seem to always produce the correct bitrate.

I also found another bug = ntsc framerates are not handled. I live in PAL land, so didn't notice this sooner, though we still get /1001 framerates on blu-ray which is how I belatedly noticed.

I made a hacky fix - maybe working out where (if anywhere) the players pass framerate den would be better, but I'll attach it anyway just to see what you think (it only applies to vanilla mesa). Seems to work OK with avconv and gstreamer.

Hi Andy,

Please take a look at the new patch set I just submitted: 1. https://lists.freedesktop.org/archives/mesa-dev/2016-November/135815.html 2. https://lists.freedesktop.org/archives/mesa-dev/2016-November/135813.html

With these 2 patches, the vbr dual instance bit-rate issue should be solved. Please give a try. If you still see bit-rate failure, please send me the command which can reproduce the issue.

In the meantime, I will look at the ntsc framerate.

Thanks

https://bugs.freedesktop.org/show_bug.cgi?id=98005

--- Comment #15 from Andy Furniss adf.lists@gmail.com --- (In reply to Boyuan Zhang from comment #13)

In the meantime, I will look at the ntsc framerate.

On this I looked what gstreamer and avconv were sending and both do send the denominator so a v2 (horrible looking) patch attached which tests OK for a variety of inputs.

I guess there's a more elegant way, but it works. Maybe over paranoid trying to avoid division by 0 in this case, but I notice that the gop patch can get one if the user asks for -g 0 with avconv.

https://bugs.freedesktop.org/show_bug.cgi?id=98005

--- Comment #17 from Andy Furniss adf.lists@gmail.com --- (In reply to Andy Furniss from comment #14)

Hi,

Initial testing seems good for vbr bitrates

More testing with longer transcoding type tests shows it is still possible to get low bitrates with the patches.

Input is derived from blu-ray = 13 minutes = 2.6 gig so a bit hard to upload.

Diference seen between gpu on perf and auto (uvd decode is faster with full clocks)

gst-launch-1.0 -f filesrc location=in-24fps.mp4 ! qtdemux ! queue ! vaapidecode ! queue ! vaapih264enc rate-control=vbr bitrate=10000 ! video/x-h264,profile=baseline ! filesink location=out24.264

https://bugs.freedesktop.org/show_bug.cgi?id=98005

--- Comment #19 from Boyuan Zhang boyuan.zhang@amd.com --- (In reply to Boyuan Zhang from comment #18)

(In reply to Andy Furniss from comment #14)

...

but I am afraid the patches regress cbr so the out of order frames near I frames issue is back.

The "out of order" issue was caused by sending last p and next i frame together for dual instance encoding, which has already been solved and shouldn't affect by this patch. I suspect the i-frame has less QP (quality) than p-frame in cbr case (to meet constant bit-rate) where bit-rate is not high enough, as a result you might see low picture quality for each i-frame. Please confirm with high bitrate or using analyser to check the order.

If you still see the out-of-order issue, please share the clip and command.

Thanks

Nevermind, the cbr issue was reproduced and fixed. Please try the latest patch I just send.

https://bugs.freedesktop.org/show_bug.cgi?id=98005

--- Comment #21 from Andy Furniss adf.lists@gmail.com --- Still the same issue with latest patches. I can sometimes get vbr to be affected as well.

I made a smaller test file, it's re-coded with software to 24 fps as the real master is /1001 and so would be wrong without an additional patch anyway.

I am just doing repeated decode/encode from/to ram and changing cpu/gpu settings to get unlucky timing - I guess on a different box you could luck out of seeing it, just initial testing with raw video input from ram seemed to work for me.

This transcode seems to be mostly wrong with my cpu on perf and gpu on auto.

for x in $(seq 1 20); do gst-launch-1.0 -f filesrc location=/mnt/ramdisk/in-24fps.mp4 ! qtdemux ! vaapidecode ! queue ! vaapih264enc rate-control=cbr bitrate=5000 ! video/x-h264,profile=baseline ! filesink location=/mnt/ramdisk/cbr-$x.264; done

in-24fps.mp4 - https://drive.google.com/file/d/0BxP5-S1t9VEEaWNkZXdmb01GYmM/view?usp=sharin...

https://bugs.freedesktop.org/show_bug.cgi?id=98005

--- Comment #23 from Andy Furniss adf.lists@gmail.com --- To clarify "Seems to always be the same place" I don't mean in the video - that's variable. I mean with gop = 30 after 00028 it will bail.

https://bugs.freedesktop.org/show_bug.cgi?id=98005

--- Comment #25 from Boyuan Zhang boyuan.zhang@amd.com --- (In reply to Boyuan Zhang from comment #24)

(In reply to Andy Furniss from comment #23)

...

To clarify "Seems to always be the same place" I don't mean in the video - that's variable. I mean with gop = 30 after 00028 it will bail.

Hi Andy,

Thanks for catching that issue. I debugged from my side and found the root cause. I made a fix and just submitted the updated 2 patches to mesa mailing list.

Both "out of order" and "vbr incorrect bitrate" issues are supposed to be fixed. Please give a try.

Thanks, Boyuan

Links are here: https://lists.freedesktop.org/archives/mesa-dev/2016-November/136460.html https://lists.freedesktop.org/archives/mesa-dev/2016-November/136458.html

https://bugs.freedesktop.org/show_bug.cgi?id=98005

--- Comment #27 from Boyuan Zhang boyuan.zhang@amd.com --- (In reply to Andy Furniss from comment #26)

So far the patches seem good :-)

cbr and vbr are behaving as expected - including md5sums always being the same.

Sounds cool! =)

Sorry for taking a long time to fully solve these issues. The two/three reported issues are caused by 2 root causes, however these 2 root causes can actually affect each other in certain way. Thanks for catching all these issues.

I will let you run more tests a bit. If everything seems fine, I will push the patches to upstream.

Regards, Boyuan

https://bugs.freedesktop.org/show_bug.cgi?id=98005

--- Comment #29 from Andy Furniss adf.lists@gmail.com --- Maybe not yet - Been testing cbr and vbr and these seem OK still.

There is an issue with cqp that I'll have to test further - it could be related to the source size, I am not sure yet.

With 2160p gstreamer is Ok with its default QP of 26 or 28, but any higher it bails with -

0:00:00.252952155 6716 0x7f8898002d90 ERROR vaapiencode gstvaapiencode.c:210:gst_vaapiencode_default_alloc_buffer: invalid GstVaapiCodedBuffer size (0 bytes) 0:00:00.253007252 6716 0x7f8898002d90 ERROR vaapiencode gstvaapiencode.c:316:gst_vaapiencode_push_frame: failed to allocate encoded buffer in system memory

It may be that there are other ways to hit this before the patches - I'll try more tomorrow.

https://bugs.freedesktop.org/show_bug.cgi?id=98005

--- Comment #31 from Andy Furniss adf.lists@gmail.com --- (In reply to Andy Furniss from comment #30)

Unerlated observation while testing related to perf = I guess it depends on stream, but on a raw 2160p60 input from ram, with or without patches, I am more than twice as fast with init-qp <= 28.

Timing luck loosing me dual instance? Or something more fundamental meaning the encoder works harder al lower rates?

I notice that unlike omx when using cqp, some rate control settings are still filled in.

Hacking them the same made no difference.

This turned out to be a gstreamer wierd because I didn't have a ! queue ! before the encoder.

omx is the same speed with higher qp - and produces bigger files for the same qp.

Still makes slightly bigger files (cabac is on for both)

https://bugs.freedesktop.org/show_bug.cgi?id=98005

--- Comment #33 from Andy Furniss adf.lists@gmail.com --- (In reply to Boyuan Zhang from comment #32)

Hi Andy,

To summarise your test results, basically you saw the following 3 issues with CQP, is it correct?

• Issue #1. For large clip, sometime you can "invalid GstVaapiCodedBuffer

size (0 bytes)" error.

Turns out I don't need a large clip.

Just running the transcode test above but with vaapih264enc rate-control=cqp init-qp=30 may give this error.

• Issue #2. Random corruption observed when using CQP. Corruption issue is

gone after disable the statement

Issue 1 and 2 are gone with that disabled.

"if (context->desc.h264enc.rate_ctrl.rate_ctrl_method !=PIPE_H264_ENC_RATE_CONTROL_METHOD_DISABLE"

• Issue #3. Encoding speed is twice faster when setting QP<=28

This one was my fault because I forgot to put a ! queue ! in my command and is nothing to do with the patches/not a real issue.

So far I'm lucky enough that my test haven't trigger any of the issue yet. I will spend more time to try from my side. Again, if you could share the commands you were using to trigger the above 3 issue, that would be very appreciated.

In the meantime, I would like to push the 2 patches to upstream first. Because this two patches don't change the behaviour of CQP, but only fixing VBR/CBR. Therefore, I believe CQP fix should be apart from these 2 patches.

CQP works perfectly with vanilla mesa, it is broken by patch 1.

https://bugs.freedesktop.org/show_bug.cgi?id=98005

--- Comment #35 from Andy Furniss adf.lists@gmail.com --- I need to test more, but it will have to be tomorrow.

While patch one seems OK now, the issue I mentioned about patch 2 being under rate with gop 300 vs gop 30 still persists at high bitrates.

I initially thought it was only a bit low, and it is with the right test, but it seems that it's possible to be a lot low sometimes. This is with really high rates, like 100mbit. I need to see if there are combinations of gop/framerate/bitrate that fail at normal rates.

https://bugs.freedesktop.org/show_bug.cgi?id=98005

--- Comment #37 from Andy Furniss adf.lists@gmail.com --- I see the patches are in now - Which I think is OK as they do AFAICT fix normal use cases.

Maybe in future the algorithm for increasing gop could take into account bits per picture as reducing gop size when this is very high could be a workaround.

There is still the question of why single instance avoids this, the commit message reads like the rate control system in general needs this and doesn't say it's just a dual instance requirement.

Though gstreamer is buggy above 100M ffmpeg isn't and 240M is a legal rate for level 5.2 baseline, and now is hard to reach with dual instance without going for abnormally low gop.

https://bugs.freedesktop.org/show_bug.cgi?id=98005

--- Comment #39 from Andy Furniss adf.lists@gmail.com --- While "normal" testing seems OK I've found a way to rarely get gstreamer to fail to allocate a buffer.

ERROR vaapi gstvaapiencoder.c:341:gst_vaapi_encoder_put_frame: failed to allocate coded buffer ERROR vaapiencode gstvaapiencode.c:558:gst_vaapiencode_handle_frame: failed to encode frame 559 (status -2)

This was a mean test - transcoding a 1080p file repeatedly with a couple of scripts running that after random 1 to 20sec sleeps turn cpu/gpu from perf to auto.

As long as nothing else is happening the results are good, but if I say run an opengl demo like Unigine Valley as well there's a chance that I get the above fail on say 1 out of 80 runs where a run is transcoding a 120 sec 24 fps sample.

I can reproduce this with cbr, vbr or cqp and single instance - so maybe it should get its own bug ....

Though using extreme tests to reproduce I initially noticed this without running gl as such = only glamor scrolling xterm very fast as I had a load of printfs in the code.