<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Sep 29, 2013 at 10:01 PM,  <span dir="ltr"><<a href="mailto:idxa@sina.com" target="_blank">idxa@sina.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>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.</div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>When testing,  I adjusted parmeter --qp to get same bitrates of x265 and x264, and then compare the PSNR. </div>
<div>x264 --preset veryslow --sar 640:360 --fps 25 --tune psnr --no-mbtree --psnr -o out<u></u>.264 -q xx input<u></u>.yuv --dump-yuv recon.yuv</div>
<div>x265 --input input.yuv --input-res 640x360 --fps 25 --qp xx --recon recon.yuv -o out.hevc -F 6</div>
<div> </div>
<div>My question is what factors cause the performance difference between x265 and HM. I thought  of the following 3 reasons.</div>
<div>1. some feagures (like multiple refs, open-gop, pass more motion vector candidates to motion estimation, weighted bidir) are not included in x265</div></blockquote><div><br></div><div>multiple refs are supported in the x265 default tip (--refs N).  We don't have any presets yet and it defaults to --refs 1.</div>
<div>weightp is also currently disabled but it is in the process of getting fixed and re-enabled.  weighted bidir will come some time later.</div><div>x264's --preset veryslow is also enabling --b-adapt 2 with --rc-lookahead 60; those have to be manually enabled in x265</div>
<div>Plus it enables full trellis and extra RDO, we have nothing truly equivalent</div><div><br></div><div><a href="http://dev.beandog.org/x264_preset_reference.html">http://dev.beandog.org/x264_preset_reference.html</a></div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>2. x265 port x264 motion eastimation code which make some compression loss</div></blockquote><div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>3. the framework of wpp and frame parallelism reduce the coding efficiency</div></blockquote><div><br></div><div>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).</div>
<div><br></div><div>--</div><div>Steve Borho</div></div></div></div>