Bad decoding with --multi-pass-opt-rps
Bad decoding with --multi-pass-opt-rps
Hello.
When i decode a raw .hevc stream result of encoded with x265 with --multi-pass-opt-rps output is total garbage. If i mux to mkv and play with VLC or MPC-HC, there is no garbage. If i decode the mkv there is garbage like the raw stream.
I don't know if it's an issue with DGDecNV, a bug in x265 or just the fact that the option --multi-pass-opt-rps produces a compliant H265 stream, but not compliant with HW decode.
I have a small clip.
Do you think you can take a look and check it ?
If yes, how can i provide you the file ?
Edit :
I can PM you the informations of my FTP server where i've put the file if you want.
When i decode a raw .hevc stream result of encoded with x265 with --multi-pass-opt-rps output is total garbage. If i mux to mkv and play with VLC or MPC-HC, there is no garbage. If i decode the mkv there is garbage like the raw stream.
I don't know if it's an issue with DGDecNV, a bug in x265 or just the fact that the option --multi-pass-opt-rps produces a compliant H265 stream, but not compliant with HW decode.
I have a small clip.
Do you think you can take a look and check it ?
If yes, how can i provide you the file ?
Edit :
I can PM you the informations of my FTP server where i've put the file if you want.
Bad decoding with --multi-pass-opt-rps
Yes, please PM me a link to the file on your FTP. Also, please tell me what --multi-pass-opt-rps does. Thank you.
Bad decoding with --multi-pass-opt-rps
At work for now, so i don't have the information of my ftp server, will provide you later when back home.
In the meantime, from https://x265.readthedocs.io/en/master/cli.html :
--multi-pass-opt-rps, --no-multi-pass-opt-rps
Enable storing commonly used RPS in SPS in multi pass mode. Default disabled.
Edit
I think i can get back the informations of my FTP server... Checking...
Edit 2
PM sent.
In the meantime, from https://x265.readthedocs.io/en/master/cli.html :
--multi-pass-opt-rps, --no-multi-pass-opt-rps
Enable storing commonly used RPS in SPS in multi pass mode. Default disabled.
Edit
I think i can get back the informations of my FTP server... Checking...
Edit 2
PM sent.
Bad decoding with --multi-pass-opt-rps
Thank you. Can't get to it until tomorrow.
Bad decoding with --multi-pass-opt-rps
It fails the same way with a recent Video SDK. I get error messages and then the file when viewed with RawSource() has the same errors as DGIndexNV. So it is not a DGDecNV issue.
I do not know what this means:
"Enable storing commonly used RPS in SPS in multi pass mode."
It doesn't make any sense given what RPS and SPS mean. You must have a reason for using this option, so please explain.
I'll have to do some checking at the nVidia forum to see if anyone knows about this. It's several years since I worked privately with nVidia engineers.
EDIT: Nothing at the nVidia forum of any relevance to this issue.
EDIT2: With more information on what the option actually does some progress could be possible, but otherwise, all I can do is advise you to not use that option.
Code: Select all
D:\Don\Programming\C++\Video_Codec_SDK_11.1.5\Samples\build\Debug>appdec -i Test.hevc -outplanar
GPU in use: NVIDIA GeForce RTX 3090
Decode with demuxing.
[INFO ][16:15:15] Media format: raw HEVC video (hevc)
[hevc @ 000001BB1DF83940] Stream #0: not enough frames to estimate rate; consider increasing probesize
Session Initialization Time: 26 ms
[INFO ][16:15:15] Video Input Information
Codec : H.265/HEVC
Frame rate : 24000/1001 = 23.976 fps
Sequence : Progressive
Coded size : [3840, 2080]
Display area : [0, 0, 3840, 2076]
Chroma : YUV 420
Bit depth : 10
Video Decoding Params:
Num Surfaces : 9
Crop : [0, 0, 0, 0]
Resize : 3840x2080
Deinterlace : Weave
Decode Error occurred for picture 74
Decode Error occurred for picture 73
Decode Error occurred for picture 72
Decode Error occurred for picture 77
Decode Error occurred for picture 76
Decode Error occurred for picture 75
Decode Error occurred for picture 80
Decode Error occurred for picture 81
Decode Error occurred for picture 78
Decode Error occurred for picture 85
Decode Error occurred for picture 83
Decode Error occurred for picture 89
Decode Error occurred for picture 87
Decode Error occurred for picture 93
Decode Error occurred for picture 91
Decode Error occurred for picture 167
Decode Error occurred for picture 168
Decode Error occurred for picture 169
Decode Error occurred for picture 166
Decode Error occurred for picture 170
Decode Error occurred for picture 171
Decode Error occurred for picture 172
Decode Error occurred for picture 165
Decode Error occurred for picture 175
Decode Error occurred for picture 176
Decode Error occurred for picture 174
Decode Error occurred for picture 173
Decode Error occurred for picture 477
Decode Error occurred for picture 476
Decode Error occurred for picture 478
Decode Error occurred for picture 481
Decode Error occurred for picture 480
Decode Error occurred for picture 482
Decode Error occurred for picture 479
Decode Error occurred for picture 483
Decode Error occurred for picture 487
Decode Error occurred for picture 493
Decode Error occurred for picture 492
Decode Error occurred for picture 491
Decode Error occurred for picture 553
Decode Error occurred for picture 583
Decode Error occurred for picture 584
Decode Error occurred for picture 582
Decode Error occurred for picture 585
Decode Error occurred for picture 586
Decode Error occurred for picture 581
Decode Error occurred for picture 587
Decode Error occurred for picture 594
Decode Error occurred for picture 595
Decode Error occurred for picture 593
Decode Error occurred for picture 592
Total frame decoded: 643
Saved in file out.planar in yuv420p16 format
Session Deinitialization Time: 12 ms
"Enable storing commonly used RPS in SPS in multi pass mode."
It doesn't make any sense given what RPS and SPS mean. You must have a reason for using this option, so please explain.
I'll have to do some checking at the nVidia forum to see if anyone knows about this. It's several years since I worked privately with nVidia engineers.
EDIT: Nothing at the nVidia forum of any relevance to this issue.
EDIT2: With more information on what the option actually does some progress could be possible, but otherwise, all I can do is advise you to not use that option.
Bad decoding with --multi-pass-opt-rps
The only reason i use this option is that according the name it optimises encode, and i want to use any optimisation possible, but producing playable stream...
If i mux the file to mkv and play with software decode (VLC, mpc-hc), it plays almost properly... I just have 2 or 3 unexpected "hicup" but there is not the garbage output. Playing the mkv in DGIndexNV produces the same result than the raw file, so muxing to mkv doesn't "fix" things.
I'm still trying to see if i can have more feedback with people who have analyse tools, because i'm still wondering if :
- Stream is broken and not H265 compliant (so, a bug in x265).
- Stream is H265 compliant but unfortunately just not compatible with HW decoding.
Anyway, thanks for your investigating time and feeback information.
Edit:
The only other information i have is the following, no idea if it can help :
If i mux the file to mkv and play with software decode (VLC, mpc-hc), it plays almost properly... I just have 2 or 3 unexpected "hicup" but there is not the garbage output. Playing the mkv in DGIndexNV produces the same result than the raw file, so muxing to mkv doesn't "fix" things.
I'm still trying to see if i can have more feedback with people who have analyse tools, because i'm still wondering if :
- Stream is broken and not H265 compliant (so, a bug in x265).
- Stream is H265 compliant but unfortunately just not compatible with HW decoding.
Anyway, thanks for your investigating time and feeback information.
Edit:
The only other information i have is the following, no idea if it can help :
This option results in different PPS's for different GOPs, which is perfectly legal. If a decoder assumes that PPS does not change, it will end up incorrectly decoding at some point.
Bad decoding with --multi-pass-opt-rps
Ah, it makes more sense if RPS was a typo for PPS. However, the option name includes rps, making it hard to believe it is a typo. Anyway, NVDec has no problem with changing PPSs. Given that and the glitches with other decoders my money is on a bug in x265.
Bad decoding with --multi-pass-opt-rps
If you can make available a clip encoded with and without the option (no other changes), I can compare and analyze them using some tools I have. It may shed some light on things.
Bad decoding with --multi-pass-opt-rps
Your stream has different PPSs with the same PPS id. That could well be a problem. I'll have to look into that.
Bad decoding with --multi-pass-opt-rps
I have allready an encode running on my PC video. I have to wait it to finish in 4-5 days i think, before making an encode without the option. I can't run 2 encodes on it, and i have no other PC whith enough memory to run the encode.
Otherwise, thanks again for the investigation. Waiting for the feedback of different PPSs with same Id legal or not. Will try to ask on my side.
Otherwise, thanks again for the investigation. Waiting for the feedback of different PPSs with same Id legal or not. Will try to ask on my side.
Bad decoding with --multi-pass-opt-rps
I thought you could do a small clip, no need for a full movie. I tried it and the streams were identical with and without the option, and both played fine. But I used all defaults except for this option and don't know if other options may be relevant.
Bad decoding with --multi-pass-opt-rps
I was indeed talking of making a small clip. I can't for now, the only PC i can encode the clip with is allready running an encode, and i can't run 2 encodes on it, it's allready 100% CPU and 90% memory used by the current encode.
Otherwise, i got this :
Otherwise, i got this :
in 7.4.2.4.2 of the HEVC standard ("Order of VPS, SPS and PPS RBSPs and their activation"):
Any PPS NAL unit containing the value of pps_pic_parameter_set_id for the active PPS RBSP for a coded picture (and consequently
for the layer containing the coded picture) shall have the same content as that of the active PPS RBSP for the coded picture,
unless it follows the last VCL NAL unit of the coded picture and precedes the first VCL NAL unit of another coded picture.
Bad decoding with --multi-pass-opt-rps
I've also put in the directory everything (at least almost) necesseray to redo the encode.
So, another possibility for the encode without the option if needed before i can do it myself, is to get the following files from the FTP directory :
Encode_Test.bat
Test.avs
Test_Chapters_x265.txt
Video_x265_Pb.avi
x265_Test.bat
x265_x64.exe
You'll need MagicYUV codec for the video.
Edit "Encode_Test.bat" and at the end of the CALL line, remplace "K:\" by the directory path you want to ouput the result.
Edit "x265_Test.bat" and remove the option.
Run "Encode_Test.bat". It tooks around 1h on my PC.
So, another possibility for the encode without the option if needed before i can do it myself, is to get the following files from the FTP directory :
Encode_Test.bat
Test.avs
Test_Chapters_x265.txt
Video_x265_Pb.avi
x265_Test.bat
x265_x64.exe
You'll need MagicYUV codec for the video.
Edit "Encode_Test.bat" and at the end of the CALL line, remplace "K:\" by the directory path you want to ouput the result.
Edit "x265_Test.bat" and remove the option.
Run "Encode_Test.bat". It tooks around 1h on my PC.
Bad decoding with --multi-pass-opt-rps
According to spec the PPS id re-use is OK as long as the new PPS comes exactly between coded pictures. I doubt that would ever not be the case but it would have to be laboriously checked. Let's assume it is OK.
However, I believe this PPS stuff is a red herring, given the name of the option and what the documentation says. Let's get further data comparing the dual encodes, which I will wait for you to complete.
How do you even know that this option is the cause of the issue?
However, I believe this PPS stuff is a red herring, given the name of the option and what the documentation says. Let's get further data comparing the dual encodes, which I will wait for you to complete.
How do you even know that this option is the cause of the issue?
Bad decoding with --multi-pass-opt-rps
When i discovered the issue, i checked removing the options i "guessed" one at once.
I removed option A, still not OK, i put back A and removed B, still not Ok, i put back B and removed...
until i arrived to this option, and when i removed it, it became Ok, issue gone.
According these results, it was for me the guilty one.
It was long, because even on a small clip, each test took around 1h, the time to encode.
I also tried to do a only 2 pass instead of 3 pass encode, just in case it was doing 3 pass which caused the issue, but not, doing only 2 pass didn't change things, output was still not Ok.
I removed option A, still not OK, i put back A and removed B, still not Ok, i put back B and removed...
until i arrived to this option, and when i removed it, it became Ok, issue gone.
According these results, it was for me the guilty one.
It was long, because even on a small clip, each test took around 1h, the time to encode.
I also tried to do a only 2 pass instead of 3 pass encode, just in case it was doing 3 pass which caused the issue, but not, doing only 2 pass didn't change things, output was still not Ok.
Bad decoding with --multi-pass-opt-rps
Got it, thank you. With the two streams I can compare them to see the differences.
Bad decoding with --multi-pass-opt-rps
Hello, finaly my encode finished...
To be 100% sure of having the exact same parameters (except the guilty option) and x265 version, i've redone the encode, so trash the previous file, and download the both new hevc files.
To be 100% sure of having the exact same parameters (except the guilty option) and x265 version, i've redone the encode, so trash the previous file, and download the both new hevc files.
Bad decoding with --multi-pass-opt-rps
The stream encoded without the option is smaller and plays fine, so don't use the option! Also, you should submit a bug report to x265.
Bad decoding with --multi-pass-opt-rps
The issue, is :
If i mux to mkv, it plays fine in VLC, MPC-HC, but still not in DGIndexNV (meanings muxing to mkv doesn't change things).
So, software decoding works, and from the other side, the answer is :
"The option is fine, don't use HW decoding or DGIndexNV, use SW decoding...", also some people saying using the option without issue.
So, for now, i'm still trying to figure out where is realy the issue.
Real not H265 compliancy (so bug in x265 trigged because of very specific conditions) ? H265 compliant but not HW compliant ? An issue with DGIndexNV ? An issue with NVidia ?![Thinking :scratch:](./images/smilies/icon_scratch2.gif)
Anyway, thanks for your time and investigation, i'll continue to investigate from the other side.
If i mux to mkv, it plays fine in VLC, MPC-HC, but still not in DGIndexNV (meanings muxing to mkv doesn't change things).
So, software decoding works, and from the other side, the answer is :
"The option is fine, don't use HW decoding or DGIndexNV, use SW decoding...", also some people saying using the option without issue.
So, for now, i'm still trying to figure out where is realy the issue.
Real not H265 compliancy (so bug in x265 trigged because of very specific conditions) ? H265 compliant but not HW compliant ? An issue with DGIndexNV ? An issue with NVidia ?
![Thinking :scratch:](./images/smilies/icon_scratch2.gif)
Anyway, thanks for your time and investigation, i'll continue to investigate from the other side.
Bad decoding with --multi-pass-opt-rps
Hello.
Just for giving you informations.
The stream and my settings were provided to Multicoreware team.
I don't know why removing "--multi-pass-opt-rps" fixed the issue, but the real troublemakers were otherwise, i've got the following :
Unfortunately, my PC for encoding is out of order...
I think my watercooling is down, CPU goes up to 90°C just 1 minute after power up. I've order a new one, and i hope it will fix things.
Just for giving you informations.
The stream and my settings were provided to Multicoreware team.
I don't know why removing "--multi-pass-opt-rps" fixed the issue, but the real troublemakers were otherwise, i've got the following :
I'll stop using "--opt-ref-list-length-pps --opt-qp-pps", and will make a test without them to check.We have observed PPS change with these two options "--opt-ref-list-length-pps --opt-qp-pps" , not with --multi-pass-opt-rps
Is this expected? - YES
Should a PPS change have the same ID in the stream? - YES because of these two options
Is there a way to prevent PPS from changing? - we can disable these two options "--opt-ref-list-length-pps --opt-qp-pps", we have disabled these two options in x265 repo by default as there is no much improvement in bits saving for low res and low bitrates. May I know the use case of these two options ?
x265 Commit: ca1db359f5d84986cb9e261ca7a913087d706805 [ca1db35]
param: Disable opt-qp-pps and opt-ref-list-length-pps by default
The bits saved by these options are very miniscule, and not observable in most
tests focusing on low bitrates, and low resolutions; this was the goal of these
two options. Also, since these options change the PPS, the muxer has to ensure
that the headers are sent every frame which seems to trouble some mixers and
users.
Unfortunately, my PC for encoding is out of order...
![Sad :(](./images/smilies/icon_e_sad.gif)
I think my watercooling is down, CPU goes up to 90°C just 1 minute after power up. I've order a new one, and i hope it will fix things.
Bad decoding with --multi-pass-opt-rps
Interesting! Thank you for the information. Sorry to hear about your PC. Hoping you can get it up and running soon and looking forward to your findings.
Bad decoding with --multi-pass-opt-rps
Hello.
For my PC, "fortunately", it was just the watercooling. After ordering and installing a new one, my PC is back again.
I made a new encode without --opt-ref-list-length-pps --opt-qp-pps and with --multi-pass-opt-rps, no luck for this one...
Still have the issue. I've put on the server the new result file, if you think you can take a look...
In the meantime, i'm bothering again the Multicoreware team, saying that it wasn't what they thought (even if according the informations provided it seems indeed better to remove the pps options stuff).
For my PC, "fortunately", it was just the watercooling. After ordering and installing a new one, my PC is back again.
I made a new encode without --opt-ref-list-length-pps --opt-qp-pps and with --multi-pass-opt-rps, no luck for this one...
![Sad :(](./images/smilies/icon_e_sad.gif)
Still have the issue. I've put on the server the new result file, if you think you can take a look...
In the meantime, i'm bothering again the Multicoreware team, saying that it wasn't what they thought (even if according the informations provided it seems indeed better to remove the pps options stuff).