The limit check was checking against the wrong variable - it should've checked against slicesLimit and not against numRows. Can you please check if https://patches.videolan.org/patch/15905/ solves your issue?
Pradeep Ramachandran, PhD Solution Architect at www.multicorewareinc.com/ Adjunct Faculty at www.cse.iitm.ac.in/ pradeeprama.info/ Ph: +91 99627 82018 On Mon, Mar 6, 2017 at 4:30 PM, Michael Lackner < [email protected]> wrote: > Greetings, > > During my experimentation with creating a x265-based benchmark, I found > out that x265 > segfaults and/or freezes when giving it more than 16 frame slices to > encode (e.g. --slices > 17 or --slices 20 or --slices 32 or similar). > > It seems easy to reproduce as well. In my case, I'm feeding raw 16-bit YUV > 4:4:4 content > to it (16-bit per channel, 48-bit per pixel, no chroma subsampling). The > resolution is > 8192×3428, an upscale of the free movie "Tears of Steel". > > It works perfectly fine with <=16 slices on all my systems though, here's > the ones I've > tested it on: > > Environments / software versions: > > * x265 2.2+22-20217c8af8ac > > CentOS 6.8 Linux x86_64, x265 built by GCC 6.2.0 + yasm 1.3.0 > => Segmentation fault > > * x265 2.3+9-820f4327ddac > > o CentOS 6.8 Linux x86_64, x265 built by GCC 6.2.0 + yasm 1.3.0 > => Segmentation fault > > o FreeBSD 10.3 UNIX x86_64, x265 built by clang 3.8.1 + yasm 1.3.0 > => Process locks up in STOP state and becomes unkillable, even > to SIGKILL > > o Windows XP Professional x64 Edition (NT5.2), x265 built by > MSVC2010 SP1, cl.exe 16.00.40219.01 + yasm 1.3.0 > => Terminates with %ERRORLEVEL% still set to 0, so this crash is > completely uncaught > > As said, it works fine on all platforms with --slices [1..16]. > > Here's some sample output of the crash from Linux, it's supposed to be a > 2-pass encode: > > 29163 Segmentation fault (core dumped) nice -n19 x265 ./raw8k.yuv > --frames 500 > --input-depth 16 --dither --input-res 8192x3428 --input-csp i444 -D 10 > --fps 24 --slices > 20 -p veryslow --pmode --pme --open-gop --ref 6 --bframes 16 --b-pyramid > --weightb > --max-merge 5 --b-intra --bitrate 50000 --rect --amp --aq-mode 2 --no-sao > --qcomp 0.75 > --no-strong-intra-smoothing --psy-rd 1.6 --psy-rdoq 5.0 --rdoq-level 1 > --tu-inter-depth 4 > --tu-intra-depth 4 --ctu 32 --max-tu-size 32 --pass 1 --slow-firstpass > --stats v.stats > --sar 1 --range full -o pass1.h265 > > I don't have any debug builds of x265 right now and I don't really know > how to even do any > debugging, but if you can tell me if you need anything, I can always try > to build a debug > version to generate more helpful output / dump files. > > Or maybe 16 frame slices are supposed to be the maximum, but it's just not > handled > correctly yet?! > > Is there any information available on that behavior? > > -- > Michael Lackner > Lehrstuhl für Informationstechnologie (CiT) > Montanuniversität Leoben > Tel.: +43 (0)3842/402-1505 | Mail: [email protected] > Fax.: +43 (0)3842/402-1502 | Web: http://institute.unileoben.ac. > at/infotech > _______________________________________________ > x265-devel mailing list > [email protected] > https://mailman.videolan.org/listinfo/x265-devel >
_______________________________________________ x265-devel mailing list [email protected] https://mailman.videolan.org/listinfo/x265-devel
