Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
31st May 2019, 09:55 | #10 | Link | |
Registered User
Join Date: Jan 2019
Posts: 9
|
Quote:
Here's a quick&dirty test, using an admittedly peculiar content source. Lena_std.tif from lenna.org, RGB24 converted to 8-bit 4:2:0, both downscaled and then upscaled two times each (i.e. 256x256, 1024x1024) into 250 frames long videos. All encoders are the latest versions available today on Wolfberry's public GDrive. All encoding times are reported by Win10's PowerShell: Measure-Command {start-process process -argumentlist "args" -Wait}, and expressed in milliseconds. Code:
x264 common settings: --crf 15 --preset veryslow --tune stillimage 405 --threads 1: 03130.76 || 03142.22 || 03119.85 (03130.94) 405 --threads 2: 02101.52 || 02105.54 || 02105.00 (02104.02) 420 --threads 1: 26487.85 || 27508.10 || 26479.85 (26825.27) 420 --threads 2: 16336.86 || 15308.29 || 15327.17 (15657.44) x265 common settings: --crf 15 --preset veryslow --frame-threads 1 --lookahead-slices 1 505 --no-wpp: 05160.82 || 05161.18 || 05154.55 (05158.85) 505 --wpp: 04131.71 || 04142.67 || 04131.78 (04135.39) 520 --no-wpp: 68123.55 || 68134.36 || 67103.71 (67787.21) 520 --wpp: 36649.91 || 37674.62 || 34628.27 (36317.60) x265 common settings: --crf 15 --preset placebo --cu-lossless --rd-refine --tskip -qg-size 64 --ref 6 --bframes 16 --me sea --subme 7 --frame-threads 1 --lookahead-slices 1 505 --no-wpp: 063053.81 || 061024.00 || 062028.34 (062035.38) 505 --wpp: 039684.32 || 038664.65 || 038684.41 (039011.13) 520 --no-wpp: 796345.10 || 796345.10 || 796345.10 (796345.10) 520 --wpp: 235701.00 || 235701.00 || 235701.00 (235701.00) libvpx common settings: --lag-in-frames=25 --passes=2 --end-usage=q --cq-level=20 --good --cpu-used=0 --kf-max-dist=250 --auto-alt-ref=6 --tile-rows=0 --enable-tpl=1 --frame-parallel=0 --ivf 905 --tile-columns=0 --row-mt=0 --threads=1: 05167.92 || 05164.62 || 05167.18 (05166.57) 905 --tile-columns=5 --row-mt=1 --threads=2: 04133.40 || 04143.00 || 04147.51 (04141.44) 920 --tile-columns=0 --row-mt=0 --threads=1: 50871.23 || 49853.74 || 49845.72 (50190.23) 920 --tile-columns=5 --row-mt=1 --threads=2: 31568.60 || 31571.60 || 28518.96 (30553.05) XAB .. output type X .. 4 for x264, 5 for x265, 9 for libvpx AB .. 05 for 256x256, 20 for 1024x1024 Only one x265 beyondplacebo encode at each resolution due to appalling performance. The average values are reported in brackets, for each output type and encoding settings. 1. x264 is at least twice faster than either x265 or lipvpx, at comparable encoding complexity. 2. x265 parallelizes better than libvpx as encoding complexity increases. 3. x265 versylow is at best comparable with the slowest libvpx settings, lagging behind as the resolution increases. 4. x265 beyondplacebo is significantly slower than the slowest libvpx settings. As mentioned above, this is just one possible comparison. The enthusiasts should definitely do their own, and only then report whichever encoder to be the speed demon. It's very hard to conceive that chunk-based libvpx (the obvious caveats aside: logistical hassle and quality issues) is ever slower than x265 regardless of the hardware footprint, each of them at its highest encoding complexity. But instead of testing themselves (with whatever source they please, at whatever resolution and bit depth, on whatever encoding machine), people prefer to reiterate ad absurdum that libvpx is always slower than x265. And it was, indeed, years ago. Last edited by Asilurr; 31st May 2019 at 10:02. |
|
|
|