GNOME Bugzilla – Bug 719696
encoder: h264: add support for tuning parameters
Last modified: 2014-01-13 16:41:10 UTC
Now that we have key H.264 encoding features that could be specified, and target decoding constraints applied, it could also be interesting to have a way to easily express what we favor: encoding speed or smaller video. Suggested property for vaapiencode_h264: - "tune": encoder tuning based on usage (default: "none"). - Available values: "size", i.e. optimize for size (smaller encoded stream size). * Public APIs: - gst_vaapi_encoder_h264_set_tuning(). * Order of resolution: - If "tune" is not "none", then H.264 features are enabled accordingly (e.g. for "size"), based on the limits of the hardware. This means that tuning options override any other H.264 coding tools that was individually set. - Downstream element caps are applied to match the expected decoder limits. Tuning options can affect decode compatibility. Target decoder constraints could still be applied through downstream caps though. And the vaapiencode_h264 plug-in element shall still honour those.
I finally opted for "high-compression" instead of "size". There is also some other tunables: "low-latency", "low-power" but they are not implemented yet.
commit 7b1233faa8bb12b4ecb2e9e6dcdee72f94b468f4 Author: Gwenole Beauchesne <gwenole.beauchesne@intel.com> Date: Mon Jan 13 11:11:25 2014 +0100 encoder: h264: support "high-compression" tuning option. Add support for "high-compression" tuning option. First, determine the largest supported profile by the hardware. Next, check any target limit set by the user. Then, enable each individual coding tool based on the resulting profile_idc value to use. https://bugzilla.gnome.org/show_bug.cgi?id=719696