Corrupted decoding when using DGIndexNV

[squallmx]

Hi. I have a issue when decoding a file:

https://1drv.ms/v/s!AiCgDguh7E_Ogc4L5_z ... g?e=lgoOQf

When playing with DGIndexNV 251 there is a corrupted set of frames at 1818-1822, when decoding using LWLibavVideoSource it plays fine.





The file was encoded using x265 3.6 using these settings:

--colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --master-display "G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(40000000,50)" --crf 19 --fps 24000/1001 --sar 1:1 --profile main10 --output-depth 10 --preset slow --no-strong-intra-smoothing --no-rect --aud --limit-modes --aq-mode 2 --hdr10 --no-opt-ref-list-length-pps --hdr10-opt --no-opt-qp-pps --limit-sao --selective-sao 2 --sao-non-deblock --chromaloc 2 --keyint 60 --min-keyint 6 --log2-max-poc-lsb 8 --dynamic-refine --rskip 2 --rskip-edge-threshold 3 --rdoq-level 2 --rc-lookahead 24 --level-idc 5 --psy-rd 2.00 --psy-rdoq 1.00 --vbv-maxrate 54000 --vbv-bufsize 46000 --deblock -1 --nr-intra 0 --nr-inter 0 --no-info --ctu 64 --merange 57 --y4m

[Rocky]

It fails in MPC-HC using both DXVA2 native and NVDec HW but not when HW is turned off. So it's not solely an NVDec issue. Some coding parameter must be exceeding HW limits. You'll need to try to identify which parameter is causing it. I am not sufficiently familiar with x265 to speculate on that.

Another possibility is that there is an actual corruption in the stream and the software decoder has better error recovery. Does this happen with all streams encoded with those settings?

[squallmx]

It was encoded using the newer x265 3.6, if I use the old 3.5 build with the same settings the output plays perfectly, probably a bug in the newer build, thanks I will try to report it.

I will keep using 3.5 for the time being.

[Rocky]

Thank you for the update and information.

[Rocky]

Apparently, recent versions of x265 have "gone to sh*t".

https://forum.doom9.org/showthread.php? ... ost2006117

Not a DGDecNV issue so marking resolved.

[renols]

It was encoded using the newer x265 3.6, if I use the old 3.5 build with the same settings the output plays perfectly, probably a bug in the newer build, thanks I will try to report it.

I will keep using 3.5 for the time being.

Hi.

Which 3.6 build are you using? Am using 3.6+35 from http://msystem.waw.pl/x265/ myself, and haven't seen any issues with encodes. Could have missed it of course.

renols