On Wed, Feb 19, 2014 at 8:03 AM, Mario *LigH* Rohkrämer <cont...@ligh.de>wrote:
> Am 18.02.2014, 14:03 Uhr, schrieb Mario *LigH* Rohkrämer <cont...@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
_______________________________________________ x265-devel mailing list x265-devel@videolan.org https://mailman.videolan.org/listinfo/x265-devel