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

Steve Borho steve at borho.org
Thu Feb 20 00:19:18 CET 2014


On Wed, Feb 19, 2014 at 1:28 PM, Steve Borho <steve at borho.org> wrote:

>
>
>
> 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.
>

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.


> 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.
>

My fault, a fix for this was just pushed.

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.
>

Hot on the trail of this one.

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


More information about the x265-devel mailing list