GNOME Bugzilla – Bug 648144
[vp8enc] Add more granularity to the speed levels
Last modified: 2012-09-16 08:29:48 UTC
Created attachment 186225 [details] [review] 0001-vp8enc-Add-more-granularity-to-the-speed-levels.patch The following patch uses the cpu_used parameter to add more granularity to the speed levels. Using the dummy test attached I get the following results: speed=7 -> 17.34user 1.04system 0:08.25elapsed 222%CPU speed=6 -> 19.43user 1.24system 0:09.26elapsed 223%CPU speed=5 -> 23.92user 0.98system 0:12.39elapsed 200%CPU speed=4 -> 42.06user 1.67system 0:14.59elapsed 299%CPU speed=3 -> 48.77user 1.94system 0:19.36elapsed 261%CPU speed=2 -> 64.79user 2.71system 0:23.22elapsed 290%CPU speed=1 -> 102.61user 4.62system 0:34.21elapsed 313%CPU speed=0 -> 151.23user 6.52system 0:47.42elapsed 332%CPU
The dummy test consists in running the following pipeline with the new range of speed levels: time gst-launch filesrc location=/home/andoni/Vídeos/big_buck_bunny_720p_h264.mov num-buffers=1000 ! decodebin2 ! vp8enc speed=7 threads=4 ! fakesink
Combining the cpuused and speed parameters doesn't make that much sense IMHO. cpuused will only use parts of the available CPU resources while the other speed parameter will change the quality
IMHO, speed and quality are directly related, as in every encoder, and for vp8 this value has a different meanings depending on the deadline used, but it affects quality by disabling several blocks of the encoding process to increase the speed. For the BEST deadline, the cpu_used parameter can only take a value of 0, which combined with the infinite deadline, will let the encoder takes as much as it needs to encode a frame. It translates to "do all the steps and take all the time you need for it". For the GOOD deadline, the cpu_used can take values from 0 to 5, disabling progressively blocks of the encoding process for each cpu_used level, with a very high deadline. It translates to "Do x blocks of the encoding process, but try to do them in before the deadline". For REALTIME, the cpu_used defines the target of cpu utilization and the number of steps done will be be changing dynamically depending on the complexity of a section and the resources available in a computer. It translates to "Do all the steps you targetting a x% of cpu usage" At least this is what I understand from: http://www.webmproject.org/tools/encoder-parameters/#2_encode_quality_vs_speed
Note that in the examples the only difference between the presets "1-Pass Good Quality VBR Encoding" and "1-Pass Fast VBR Encoding" is the cpu_used parameter (from 0 to 3)
Maybe we should simply expose all libvpx parameters directly, that will help people who look at the libvpx documentation to map them to GStreamer.
In my opinion using presets for the speed property, as it's done for the x264 encoder, is probably a better option, rather than exposing all the available properties. At least this what I understood in https://bugzilla.gnome.org/show_bug.cgi?id=641729 regarding unifying the encoders properties. But instead of a simple range, we could have an enum with a brief description of each level.
I don't really know what's best here, sorry. Maybe we should expose all encoder settings and use GstPreset for user-friendly presets, no idea
Any feedback on this? I think the proposed range covers most of the use cases, while the current one is hard to use for realtime encoding at high resolutions. It breaks the API, but the element is still in bad.
I just found this change. May bad. I'm not really agree with this change. For VPX_DL_BEST_QUALITY and VPX_DL_GOOD_QUALITY cpu usage do not really meter. It is not real time encoding.
And any way it is not up to date. Current git use other, newer logick.
The speed property is no more, all the properties were reworked to be more in line with the upstream API and the vpxenc tool. What the speed property did can now be changed with the deadline and cpu-used properties.