<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 19, 2014 at 1:28 PM, Steve Borho <span dir="ltr"><<a href="mailto:steve@borho.org" target="_blank">steve@borho.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="">On Wed, Feb 19, 2014 at 8:03 AM, Mario *LigH* Rohkrämer <span dir="ltr"><<a href="mailto:contact@ligh.de" target="_blank">contact@ligh.de</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am 18.02.2014, 14:03 Uhr, schrieb Mario *LigH* Rohkrämer <<a href="mailto:contact@ligh.de" target="_blank">contact@ligh.de</a>>:<div>


<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I ran a loop of encodes through all presets (all default options) with Sintel Trailer in 640x272 as Y4M source (YUV 4:2:0).<br>
<br>
During all presets {slow..placebo}, x265 0.7+207-1be6b8c8b9ed [GCC 4.8.2, Win64] crashed at different frames, usually around 120/1247, already at 29/1247 for preset placebo.<br>
<br>
All faster presets passed without crash.<br>
</blockquote>
<br></div>
Probably fixed by patch 6190 (591ca91f0501)?<br>
<br>
x265 0.7+216-591ca91f0501 [Windows][GCC 4.8.2][64 bit] 8bpp does not crash anymore in all presets, except placebo (crash during the final statistics summary).<br></blockquote><div><br></div></div><div>verified; if you encode about 100 frames at placebo it reports heap corruption at exit.  Verified with a debug build in MSVC as well.  I'll see if valgrind can catch the root cause.</div>
</div></div></div></blockquote><div><br></div><div>valgrind finds that transform-skipped chroma blocks are copying too much data; we're still investigating but I expect this will be fixed by tomorrow.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

But quality in default CRF 28 is now a lot worse, files now even about half the size as before, in presets {fast..placebo}.<br>
<br>
--preset faster: 544.26 kbps, 20.311 dB SSIM<br>
--preset fast: 56.79 kbps, 13.542 dB SSIM<br>
--preset slow: 51.78 kbps, 13.493 db SSIM<br>
<br>
(Sintel trailer, 640x272, no additional options except logging)</blockquote><div><br></div></div><div>will look into this next, thanks for reporting.</div></div></div></div></blockquote><div><br></div><div>My fault, a fix for this was just pushed.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>We currently still have one known hash-mistake bug, reproducible with the sintel 480 clip and preset slower.  There's a number of pixels on frame 720 that are off-by one.  Seems to be a rounding issue somewhere, we're investigating.</div>
</div></div></div></blockquote><div><br></div><div>Hot on the trail of this one. </div></div><div><br></div>-- <br>Steve Borho
</div></div>