Good morning Michael, I made a restrict on count of slices because we have limited number of output NAL buffers. Every slices need a independent NAL, but the SPS/PPS/VPS will also allocate at least one of NAL, so I made slices limit to (MAX_NAL_UNITS - 1)
Best regards, Min At 2017-03-14 15:23:03,"Michael Lackner" <[email protected]> wrote: >Good morning! > >I applied the patch and rebuilt the code (2.3+9-820f4327ddac in this case). > >Invoking x265 on a 8292x3428 video with '--slices 20' now gives the following >warning: > >x265 [warning]: maxSlices can not be more than min(rows, MAX_NAL_UNITS-1), >force set to 15 > >And it shows: > >x265 [info]: Slices : 15 > >Just a laymans' question: I can see in source/encoder/nal.h, that >MAX_NAL_UNITS is 16. >Should maxSlices really be MAX_NAL_UNITS-1 and not MAX_NAL_UNITS in this case? >I'm just >asking because encoding with 16 slices seemed to work just fine before the >patch. > >Or are there issues with that? > >Thanks! > >Best, >Michael > >-- >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 > >On 03/14/2017 05:15 AM, Pradeep Ramachandran wrote: >> 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
_______________________________________________ x265-devel mailing list [email protected] https://mailman.videolan.org/listinfo/x265-devel
