[x265] coding efficieny comparision between x265 and x264(also include HM)

[Steve Borho]

On Sun, Sep 29, 2013 at 10:01 PM, <idxa at sina.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20131001/f678c447/attachment-0001.html>