On 13/01/17 00:02, Xiang, Haihao wrote: > > Thanks for the detailed info, I will look into the issue. BTW can you try > other vaapi based tools, such as yamitranscode?
Yes, I can now reproduce this with yamitranscode as well. Given the video below, extract the H.264 stream and then: ./yamitranscode -i in.h264 -f 60 --rcmode CBR --ow 1920 --oh 1080 -c VP8 -b 500 -N 1000 -o out.ivf consistently gives both a broken output stream (though partially playable) and a GPU hang somewhere in the middle on Skylake. Example GPU error dump: <http://ixia.jkqxz.net/~mrt/libva/vp8/sys_class_drm_card0_error_yami>. Thanks, - Mark >> -----Original Message----- >> From: Mark Thompson [mailto:s...@jkqxz.net] >> Sent: Friday, January 13, 2017 6:11 AM >> To: libva@lists.freedesktop.org; Xiang, Haihao <haihao.xi...@intel.com> >> Subject: Re: [Libva] [PATCH 2/4] Set the pipeline to use the new VP8 encoding >> shaders on BSW >> >> On 12/01/17 07:30, Xiang, Haihao wrote: >>> >>> Hi Mark, >>> >>> Can you reproduce the issue you mentioned below? If yes, I would like >>> to fix it in the new version of the patch series. >> >> Hi, >> >> Yes, I can reproduce it consistently on both Skylake and Kaby Lake. Some >> detailed instructions follow... >> >> >> Get standard test input: >> <http://distribution.bbb3d.renderfarming.net/video/mp4/bbb_sunflower_10 >> 80p_60fps_normal.mp4>. (The input file does matter somewhat: I tried some >> others and found it harder to reproduce. Maybe the highly variable >> complexity here helps to show the problem.) >> >> Get current libav from git: <git://git.libav.org/libav.git>. >> >> Apply patches adding framerate configuration and VP8 encode support to >> libav: <http://ixia.jkqxz.net/~mrt/libva/vp8/0001-vaapi_encode-Pass- >> framerate-parameters-to-driver.patch>, >> <http://ixia.jkqxz.net/~mrt/libva/vp8/0002-vaapi_encode-Add-VP8- >> support.patch>. >> >> Configure libav with --enable-vaapi and build. >> >> >> Now run a transcode from the H.264 of the input file to VP8. What happens >> varies with the bitrate selected (this is now on Skylake GT2, 6300): >> >> >> ./avconv -y -threads 1 -vaapi_device /dev/dri/renderD128 -hwaccel vaapi - >> hwaccel_output_format vaapi -i bbb_sunflower_1080p_60fps_normal.mp4 - >> an -c:v vp8_vaapi -r 60 -b:v 5M out.webm >> >> (CBR at 5Mbps) Everything works and the output looks good: yay! (This is an >> immense improvement over the current driver - if you run the same >> command there, the output is working but terrible quality.) >> >> >> ./avconv -y -threads 1 -vaapi_device /dev/dri/renderD128 -hwaccel vaapi - >> hwaccel_output_format vaapi -i bbb_sunflower_1080p_60fps_normal.mp4 - >> an -c:v vp8_vaapi -r 60 -b:v 5M out.webm >> >> (CBR at 2Mbps) Mostly works, but the output is broken at times and the >> bitrate target is often missed by a long way. >> >> >> ./avconv -y -threads 1 -vaapi_device /dev/dri/renderD128 -hwaccel vaapi - >> hwaccel_output_format vaapi -i bbb_sunflower_1080p_60fps_normal.mp4 - >> an -c:v vp8_vaapi -r 60 -b:v 1M out.webm >> >> (CBR at 1Mbps) Consistently hangs at around frame 570. >> >> >> [1321697.079583] drm/i915: Resetting chip after gpu hang [1321697.081571] >> [drm] GuC firmware load skipped [1321699.063831] [drm] RC6 on >> >> /sys/class/drm/card0/error for one case: >> <http://ixia.jkqxz.net/~mrt/libva/vp8/sys_class_drm_card0_error>. >> >> Backtrace of userspace at the hang point: >> >> #0 0x00007ffff6351cc7 in ioctl () at ../sysdeps/unix/syscall-template.S:84 >> #1 0x00007ffff5821708 in drmIoctl () from /usr/lib/x86_64-linux- >> gnu/libdrm.so.2 >> #2 0x00007ffff48e3e00 in ?? () from /usr/lib/x86_64-linux- >> gnu/libdrm_intel.so.1 >> #3 0x00007ffff48e4036 in ?? () from /usr/lib/x86_64-linux- >> gnu/libdrm_intel.so.1 >> #4 0x00007ffff4bded57 in intel_batchbuffer_flush (batch=0x555556c03240) >> at ../../src/intel_batchbuffer.c:147 >> #5 0x00007ffff4b9c821 in i965_run_kernel_media_object >> (ctx=0x555556ad15b0, encoder_context=0x555556bfff10, >> gpe_context=0x555556b6da38, media_function=11, param=0x7fffffffd5f0) >> at ../../src/i965_encoder_vp8.c:2174 >> #6 0x00007ffff4baa044 in i965_encoder_vp8_pak_tpu (ctx=0x555556ad15b0, >> encode_state=0x555556ae5cd0, encoder_context=0x555556bfff10) >> at ../../src/i965_encoder_vp8.c:6503 >> #7 0x00007ffff4baa5a7 in i965_encoder_vp8_pak_pipeline >> (ctx=0x555556ad15b0, profile=VAProfileVP8Version0_3, >> encode_state=0x555556ae5cd0, encoder_context=0x555556bfff10) >> at ../../src/i965_encoder_vp8.c:6620 >> #8 0x00007ffff4b988b3 in intel_encoder_end_picture (ctx=0x555556ad15b0, >> profile=VAProfileVP8Version0_3, codec_state=0x555556ae5cd0, >> hw_context=0x555556bfff10) at ../../src/i965_encoder.c:1313 >> #9 0x00007ffff4b8aa23 in i965_EndPicture (ctx=0x555556ad15b0, >> context=33554433) at ../../src/i965_drv_video.c:3588 >> #10 0x00007ffff76744ca in vaEndPicture (dpy=0x555556ad1540, >> context=33554433) at ../../git/va/va.c:1285 >> #11 0x0000555555df76d8 in vaapi_encode_issue (avctx=0x555556b5f100, >> pic=0x555556c64d20) at >> /home/mrt/video/libav/vp8/libavcodec/vaapi_encode.c:387 >> #12 0x0000555555df7f29 in vaapi_encode_step (avctx=0x555556b5f100, >> target=0x555556c64d20) at >> /home/mrt/video/libav/vp8/libavcodec/vaapi_encode.c:608 >> #13 0x0000555555df8be9 in ff_vaapi_encode2 (avctx=0x555556b5f100, >> pkt=0x555556b19380, input_image=0x555556b188c0, >> got_packet=0x7fffffffdcfc) at >> /home/mrt/video/libav/vp8/libavcodec/vaapi_encode.c:895 >> #14 0x00005555557a409b in avcodec_encode_video2 (avctx=0x555556b5f100, >> avpkt=0x555556b19380, frame=0x555556b188c0, >> got_packet_ptr=0x7fffffffdcfc) at >> /home/mrt/video/libav/vp8/libavcodec/encode.c:231 >> #15 0x00005555557a4280 in do_encode (avctx=0x555556b5f100, >> frame=0x555556b188c0, got_packet=0x7fffffffdcfc) at >> /home/mrt/video/libav/vp8/libavcodec/encode.c:278 >> #16 0x00005555557a444a in avcodec_send_frame (avctx=0x555556b5f100, >> frame=0x555556b188c0) at >> /home/mrt/video/libav/vp8/libavcodec/encode.c:327 >> #17 0x00005555555c3c5c in do_video_out (of=0x555556c61ba0, >> ost=0x555556c61680, in_picture=0x555556b188c0, frame_size=0x7fffffffe1cc) >> at /home/mrt/video/libav/vp8/avconv.c:579 >> #18 0x00005555555c43ce in poll_filter (ost=0x555556c61680) at >> /home/mrt/video/libav/vp8/avconv.c:718 >> #19 0x00005555555c4753 in poll_filters () at >> /home/mrt/video/libav/vp8/avconv.c:792 >> #20 0x00005555555cab23 in transcode () at >> /home/mrt/video/libav/vp8/avconv.c:2730 >> #21 0x00005555555cb063 in main (argc=20, argv=0x7fffffffe438) at >> /home/mrt/video/libav/vp8/avconv.c:2898 >> >> >> avconv there also supports CQP mode as well as CBR (pass "-qindex N" for N >> between 0 and 127 instead of the "-b:v M" above): this is always fine for me. >> >> Can you reproduce a hang with that? Is there any other information I can >> provide to help? >> >> Thanks, >> >> - Mark >> >> >>>>> On Tue, Jan 10, 2017 at 4:21 PM, Mark Thompson <s...@jkqxz.net> wrote: >>>>>> On 10/01/17 22:02, Sean V Kelley wrote: >>>>>>> From: "Xiang, Haihao" <haihao.xi...@intel.com> >>>>>>> >>>>>>> Currently only one temporal layer is supported >>>>>>> >>>>>>> Signed-off-by: Xiang, Haihao <haihao.xi...@intel.com> >>>>>>> Reviewed-by: Sean V Kelley <sea...@posteo.de> >>>>>>> --- >>>>>>> src/Makefile.am | 3 + >>>>>>> src/gen8_encoder_vp8.c | 140 + >>>>>>> src/gen8_mfc.c | 8 +- >>>>>>> src/gen8_vme.c | 5 + >>>>>>> src/i965_defines.h | 10 + >>>>>>> src/i965_encoder.c | 2 + >>>>>>> src/i965_encoder_vp8.c | 6697 >>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++ >>>>>>> src/i965_encoder_vp8.h | 2643 +++++++++++++++++++ >>>>>>> 8 files changed, 9507 insertions(+), 1 deletion(-) >>>>>> >>>>>> I had a go with this on Kaby Lake. In general, big win - looks >>>>>> like it can be under half the bitrate at comparable quality (though >>>>>> it was pretty terrible before...). >>>>>> >>>>>> However, the rate control seems to do odd things at low bitrate >>>>>> relative to the frame size? I can get GPU hangs and wildly varying >>>>>> output bitrate with it, though it seems ok at high bitrate. >>>>> That's a concern. Please report the If it really is a GPU hang, I >>>>> need the error report for the DRM card0 log. >>>>> >>>>> cat /sys/class/drm/card0/error >>>>> >>>>> Please rerun and capture the DRM (i915) card0 error log. >>>>> >>>>>> >>>>>> I had a look around the rate control and found two minor issues in >>>>>> the RC configuration, though I don't think either of them are >>>>>> relevant to my problem (see below). I can try to make a reproducer >>>>>> if this is not already known? >>>>>> >>>>> Please do attempt to reproduce. That's why I've put the patches out >>>>> here to test. >>>> >>>> Thanks for testing the patch, could you detail the steps to reproduce >>>> this issue? >>>> >>>> >>>>> >>>>> Thanks, >>>>> >>>>> Sean >>>>> >>>>>> Thanks, >>>>>> >>>>>> - Mark >>>>>> > _______________________________________________ Libva mailing list Libva@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libva
