GNOME Bugzilla – Bug 766050
Add Low power, High performance h264 encoder support
Last modified: 2016-05-13 09:35:15 UTC
Intel Skylake platform has the support for low power/ high performance h264 encoder. Unlike the older platforms, SKL has dedicated encoder engine(VDENC) for doing low power encoding with out depending on EUs. We are not yet utilizing it since the driver doesn't had code path to enable VDENC. Now the patches landed in mailing list for libva and vaapi-intel-driver: https://lists.freedesktop.org/archives/libva/2016-May/003938.html https://lists.freedesktop.org/archives/libva/2016-May/003935.html https://lists.freedesktop.org/archives/libva/2016-May/003937.html https://lists.freedesktop.org/archives/libva/2016-May/003923.html As always we are the early enablers for most of the VA-API features :) Here is the corresponding gstreamer-vaapi support patches: https://cgit.freedesktop.org/~sree/gstreamer-vaapi/log/?h=vdenc My initial test cases showing ~40-50% faster encoding. This will really boost the live encoding use cases. GuC firmware needs to be updated for SKL. Skylake GuC - 6.1: https://01.org/linuxgraphics/downloads/skylake-guc-6.1 OR skl_guc_ver4_3: https://01.org/linuxgraphics/downloads/sklgucver43 How to update: https://01.org/linuxgraphics/intel-linux-graphics-firmwares It is pretty easy. I will push the patches (requires some minor changes) once the driver patches land in master branch.
commit d446013ae4dd2286b4bbe020443baaf3816a65f3 Author: Sreerenj Balachandran <sreerenj.balachandran@intel.com> Date: Wed May 11 12:06:38 2016 +0300 gstvaapiencoder:Use internal api to dervie configured VAEntrypoint https://bugzilla.gnome.org/show_bug.cgi?id=766050 commit 32ee78bc524e9a98785513d2f5befb436a112f8e Author: Sreerenj Balachandran <sreerenj.balachandran@intel.com> Date: Wed May 11 12:05:36 2016 +0300 encoder: h264: Add support of low power/high performance encoding mode Added a new property "low-power-enc" for enabling low power encoding mode. Certain encoding tools may not be available with the VAEntrypointEncSliceLP. https://bugzilla.gnome.org/show_bug.cgi?id=766050 commit c1abf37d0b6126166df2195ed51971d49d0aab88 Author: Sreerenj Balachandran <sreerenj.balachandran@intel.com> Date: Wed May 11 12:03:08 2016 +0300 gstvaapidisplay: Add VAEntrypointEncSliceLP support https://bugzilla.gnome.org/show_bug.cgi?id=766050 commit 7e4e597c6dd165940c90b5b4602763f0ccb98969 Author: Sreerenj Balachandran <sreerenj.balachandran@intel.com> Date: Wed May 11 11:59:59 2016 +0300 gstvaapiprofile : Add VAEntrypointEncSliceLP definitions This is for implementations that supports low_power/high_performance variant for slice level encode. https://bugzilla.gnome.org/show_bug.cgi?id=766050
Simple profiling: time gst-launch-1.0 videotestsrc num-buffers=1200 ! video/x-raw, format=NV12, width=3840, height=2160, framerate=60/1 ! vaapih264enc low-power-enc=FALSE ! filesink location=sample_4k.264 real 0m50.017s user 0m25.148s sys 0m0.964s time gst-launch-1.0 videotestsrc num-buffers=1200 ! video/x-raw, format=NV12, width=3840, height=2160, framerate=60/1 ! vaapih264enc low-power-enc=TRUE ! filesink location=sample_4k_lp.264 real 0m28.445s user 0m15.924s sys 0m0.832s
Out of curiosity, why was this not added as a flag to the existing "tune" property? Even more so seeing that it's part of the GstVaapiEncoderTune flags in the encoder API. If we keep the boolean property, do we need the '-enc' prefix in the property name? Isn't it already implicit? :)
(In reply to Tim-Philipp Müller from comment #3) > Out of curiosity, why was this not added as a flag to the existing "tune" > property? Even more so seeing that it's part of the GstVaapiEncoderTune > flags in the encoder API. > Damn, how did i miss it!! Somehow i was thinking tuning property only for Low/Medium/High compression which are based on coding tools like cabac, 8x8dct etc. low-power-mode is something which is using a new hardware block in lower level. Surely we should use "tune" options. Many thanks Tim!
(In reply to sreerenj from comment #4) > (In reply to Tim-Philipp Müller from comment #3) > > Out of curiosity, why was this not added as a flag to the existing "tune" > > property? Even more so seeing that it's part of the GstVaapiEncoderTune > > flags in the encoder API. > > > > Damn, how did i miss it!! Somehow i was thinking tuning property only for > Low/Medium/High compression which are based on coding tools like cabac, > 8x8dct etc. low-power-mode is something which is using a new hardware block > in lower level. > > Surely we should use "tune" options. Yes, you should use the tune=low-power option, that was designed as is for VDENC too. :) That way, you respect the constraints of VDENC wrt. the acceptable set of coding tools.
What about encoding quality? I have really bad experience with gstreamer-vaapi h264 and h265 encoder It looks like intel default vaapi settings don't provide comparable encoding quality. I wish we have settings from Intel® Media Server Studio(hw encoder variant) as they really tune it for best results. Can anybody ask Intel for something?
(In reply to Gwenole Beauchesne from comment #5) > (In reply to sreerenj from comment #4) > > (In reply to Tim-Philipp Müller from comment #3) > > > Out of curiosity, why was this not added as a flag to the existing "tune" > > > property? Even more so seeing that it's part of the GstVaapiEncoderTune > > > flags in the encoder API. > > > > > > > Damn, how did i miss it!! Somehow i was thinking tuning property only for > > Low/Medium/High compression which are based on coding tools like cabac, > > 8x8dct etc. low-power-mode is something which is using a new hardware block > > in lower level. > > > > Surely we should use "tune" options. > > Yes, you should use the tune=low-power option, that was designed as is for > VDENC too. :) That way, you respect the constraints of VDENC wrt. the > acceptable set of coding tools. Good to see the architect back :) After few discussion with Tim in IRC I was thinking about the possibility to use flags instead of enum for tuning options. But there is bit of architectural issue here: Right now it is not possible to use combination of tuning options . In theory it is right. As an eg: high-compression means we can enable more b-frames. low-latency means we shouldn't use or reduce nunbmer of bframes etc. We could have similar things in future too. So it doesn't make sense to use flags instead of enum. But, the usage of VDENC is different, it can be combined with any of the tuning options.And it is a needed feature too IMHO. So for me, the better solution seems to be keep a new property "high-performance" for enabling vdenc and keep all tuning options which are based on algorithamic features as it is (enums)
Found that the driver has not implemented B-frame support in "low-power" mode right now :) So better stick on with tune=low-power as Gwenole said in order to respect the coding tool restrictions for VDENC. We have to restrict the "max-bframe" option for low-power mode too.
Created attachment 327719 [details] [review] encoder: h264 : Use "tune=low-power" for enabling lowpower encode
Created attachment 327720 [details] [review] encoder : h264: Disable b-frame encode in low-power mode
Review of attachment 327719 [details] [review]: Pushed.
Review of attachment 327720 [details] [review]: Pushed.
(In reply to sreerenj from comment #2) > Simple profiling: New command to test: time gst-launch-1.0 videotestsrc num-buffers=1200 ! video/x-raw, format=NV12, width=3840, height=2160, framerate=60/1 ! vaapih264enc tune=low-power ! filesink location=sample_4k.264