GNOME Bugzilla – Bug 779263
VAAPI encoding artifacts
Last modified: 2017-04-07 12:14:14 UTC
Hello, I'm testing VAAPI encoding and I noticed that when encoding with vaapih264enc it produces a lot of artifacts blocks on scene changes, and quality is not close to Media SDK's encoding. My hardware: i7-6700k Skylake OS: Ubuntu 16.04 vainfo: VA-API version: 0.39 (libva 1.7.3) vainfo: Driver version: Intel i965 driver for Intel(R) Skylake - 1.7.3 GStreamer: 1.10.3 pipeline: gst-launch-1.0 -v souphttpsrc location=http://213.32.7.71:80/ID/mpegts ! tsdemux ! h264parse ! vaapidecodebin ! vaapipostproc width=1280 height=720 deinterlace-method=1 scale-method=2 ! videorate ! video/x-raw,framerate=25/1 ! vaapih264enc rate-control=2 bitrate=2000 keyframe-period=50 tune=1 num-slices=2 cabac=true dct8x8=true cpb-length=2000 ! flvmux ! rtmpsink location='rtmp://213.32.7.71:1935/russchannel/testtaddasd' the only way you can get better results is when I don't set the bitrate and use CQP, but in our case I'm trying to use it for streaming and CBR and bitrate limit is a must. we tried many different options for vaapih264enc to try to improve quality but we are getting same results. How i know it is an encoder issue is because i replace vaapih264enc with x264enc and then no more quality issues.
*** Bug 779262 has been marked as a duplicate of this bug. ***
Could you let me know x264enc properties and values that you tested, so that I can figure out how different they are. Actually, as far as I tested with x264enc by default (2048k/CBR), I got result worse than vaapi. Probably, there's something missing for mine, that's why I am reqeusting.
Oops, forget comments #2. I found my fault and confirmed the issue :)
ok cool just so we are in the same page here 'x264enc pass=0 bitrate=2000' pipeline: gst-launch-1.0 -v souphttpsrc location=http://xxx:80/ID/mpegts ! tsdemux ! h264parse ! vaapidecodebin ! vaapipostproc width=1280 height=720 deinterlace-method=1 scale-method=2 ! videorate ! video/x-raw,framerate=25/1 ! x264enc pass=0 bitrate=2000 ! flvmux ! rtmpsink location='rtmp://xxx:1935/russchannel/testtaddasd'
also I did try same everything with file source and you mat download and see results below: Source: http://albcast.tv/source/testsrc.mp4 x264 out: http://albcast.tv/source/out_x264enc.ts VAAPI out: http://albcast.tv/source/out_vaapih264enc.ts VAAPI pipline: gst-launch-1.0 -v filesrc location=testsrc.mp4 ! qtdemux ! h264parse ! vaapidecodebin ! vaapipostproc width=1280 height=720 deinterlace-method=1 scale-method=2 ! videorate ! video/x-raw,framerate=25/1 ! vaapih264enc rate-control=2 bitrate=2000 ! mpegtsmux ! filesink location='out_vaapih264enc.ts' x264 pipline: gst-launch-1.0 -v filesrc location=testsrc.mp4 ! qtdemux ! h264parse ! vaapidecodebin ! vaapipostproc width=1280 height=720 deinterlace-method=1 scale-method=2 ! videorate ! video/x-raw,framerate=25/1 ! x264enc pass=0 bitrate=2000 ! mpegtsmux ! filesink location='/var/setrix/hls/encoding/8/out_x264enc.ts' as you can see VAAPI's output is very poor.
hello GST Community, just checking if anyone knows if there is any news regards to this issue or maybe if someone knows should I ask about this in another forum or Github of libva ?
(In reply to Benjamin from comment #6) > hello GST Community, just checking if anyone knows if there is any news > regards to this issue or maybe if someone knows should I ask about this in > another forum or Github of libva ? I haven't found time to work in this issue, perhaps Hyunjun have narrowed the issue, I don't know right now. We need to know if it is a problem in the driver (in such case we need to open an issue in libva-intel-driver github); or we need to expose a libva functionality in gstreamer-vaapi encoders.
ok I see, also I would like to confirm that we have tried the Media Studio SDK 2017 directly with this plugin https://github.com/ishmael1985/gstreamer-media-SDK and it gives much better Video quality results when CBR.
Hi Benjamin, I would recommend you to test with the latest vaapi-intel-driver from git master(https://github.com/01org/intel-vaapi-driver) which supposed to bring a lot of quality improvements in SKL, BXT and KBL platforms. This is not just the code optimization but we use new media kernels too. Unfortunately there is a bug in gstreamer-vaapi which caused b frame encoding artifacts with new media kernels, but it is fixed here: https://bugzilla.gnome.org/show_bug.cgi?id=780620
ok thank you for the update, I'm going to try it and let you know the results.
you can close this ticket now i can confirm the video quality now is much better.
(In reply to Benjamin from comment #11) > you can close this ticket now i can confirm the video quality now is much > better. Is it somewhat close to what you were getting with MediaSDK? :) or better? ;)
Closing as stated in comment 11. This was an issue in the intel-driver, not in gstreamer-vaapi.