On Sun, Sep 29, 2013 at 10:01 PM, <[email protected]> wrote: > Hi, I have compared x265 with x264, and find that coding efficieny of the > two encoders is in the same level and is less about 20%-30% than HM11.0. >
the distance from the HM is pretty unexpected; but without having your input clip I can't comment much. It might be mostly a weightp and multi-refs issue. > When testing, I adjusted parmeter --qp to get same bitrates of x265 and > x264, and then compare the PSNR. > x264 --preset veryslow --sar 640:360 --fps 25 --tune psnr --no-mbtree > --psnr -o out**.264 -q xx input**.yuv --dump-yuv recon.yuv > x265 --input input.yuv --input-res 640x360 --fps 25 --qp xx --recon > recon.yuv -o out.hevc -F 6 > > My question is what factors cause the performance difference between x265 > and HM. I thought of the following 3 reasons. > 1. some feagures (like multiple refs, open-gop, pass more motion vector > candidates to motion estimation, weighted bidir) are not included in x265 > multiple refs are supported in the x265 default tip (--refs N). We don't have any presets yet and it defaults to --refs 1. weightp is also currently disabled but it is in the process of getting fixed and re-enabled. weighted bidir will come some time later. x264's --preset veryslow is also enabling --b-adapt 2 with --rc-lookahead 60; those have to be manually enabled in x265 Plus it enables full trellis and extra RDO, we have nothing truly equivalent http://dev.beandog.org/x264_preset_reference.html 2. x265 port x264 motion eastimation code which make some compression loss > this hasn't been my experience; our default search length (60) is much longer than x264s because our default CTU size is 64 vs their macroblock size. Our (default) "star" search adopted from the HM's three-step search seemed to work pretty well relative to x264's UMH; but I'm still not sure UMH is working correctly within x265. > 3. the framework of wpp and frame parallelism reduce the coding efficiency > frame parallelism should have very little effect on coding efficiency, and WPP should result in a loss of about 1% compression (with no consistent effect on quality). You can test this yourself with --no-wpp and/or --F1 (note: single frame thread is currently the default). -- Steve Borho
_______________________________________________ x265-devel mailing list [email protected] https://mailman.videolan.org/listinfo/x265-devel
