[x265] APPCRASH in x265 0.7+207 while encoding in preset 'slow' or slower...

[Steve Borho]

On Wed, Feb 19, 2014 at 8:03 AM, Mario *LigH* Rohkrämer <contact at ligh.de>wrote:

> Am 18.02.2014, 14:03 Uhr, schrieb Mario *LigH* Rohkrämer <contact at ligh.de
> >:
>
>
>  I ran a loop of encodes through all presets (all default options) with
>> Sintel Trailer in 640x272 as Y4M source (YUV 4:2:0).
>>
>> 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.
>>
>> All faster presets passed without crash.
>>
>
> Probably fixed by patch 6190 (591ca91f0501)?
>
> 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).
>

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.


> But quality in default CRF 28 is now a lot worse, files now even about
> half the size as before, in presets {fast..placebo}.
>
> --preset faster: 544.26 kbps, 20.311 dB SSIM
> --preset fast: 56.79 kbps, 13.542 dB SSIM
> --preset slow: 51.78 kbps, 13.493 db SSIM
>
> (Sintel trailer, 640x272, no additional options except logging)


will look into this next, thanks for reporting.

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.

--
Steve Borho
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20140219/be99fad7/attachment.html>