Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
|
|
Thread Tools | Search this Thread | Display Modes |
24th August 2024, 02:15 | #1 | Link | |
Special SeeD
Join Date: Nov 2002
Location: Mexico
Posts: 340
|
Corrupted playback when using Hardware decoding on a file created using x265
Hi. I'm having a issue when decoding a file created by x265 3.6:
https://1drv.ms/v/s!AiCgDguh7E_Ogc4L...SHuxg?e=lgoOQf When playing with HW acceleration of any kind there is a corrupted set of frames at 1818-1822, when decoding using LWLibavVideoSource or FFMPEG it plays perfectly. HW Decoding: SW Decoding The file was encoded using x265 3.6+13+1-726aec126:[Windows][GCC 14.1.0][64 bit] using the following settings: Quote:
https://1drv.ms/v/s!AiCgDguh7E_Ogc4N...FjxTg?e=5OSEVM |
|
27th August 2024, 22:51 | #2 | Link |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,878
|
Huh.
I'd start by stripping out a lot of the less essential parameters and see if that changes anything. If so, you can mix and match to see what is doing it. There's a lot of oddball stuff in there that could cause an edge case but isn't going to make any material difference at real-world bitrates. Like --no-opt-ref-list-length-pps, -log2-max-poc-lsb 8. And stuff like --no-strong-intra-smoothing, --deblock -1, -limit-sao, --sao-non-deblock I'm unaware of ever helping real-world content that I recall, while degrading compression efficiency in general. --deblock also gets two parameters; I'm not sure what happens if only one is used as in here. Lowering it was a good idea in x264, but HEVC's design is different, and the default is generally quite optimal. --chromaloc 2 is only appropriate if your source and/or output is Blu-ray, or is otherwise known to use --chromaloc 2. That said, I've seen some odd stuff with --rskip 2 lately; you might try with --rskip 0 or 1 and see if that helps. |
28th August 2024, 15:31 | #3 | Link | ||
Special SeeD
Join Date: Nov 2002
Location: Mexico
Posts: 340
|
Quote:
Quote:
|
||
28th August 2024, 21:10 | #4 | Link |
Registered User
Join Date: Mar 2020
Posts: 53
|
Maybe you can try with the official 3.6
I use Handbrake so i don't know much about x265 but i think this is the official page https://bitbucket.org/multicoreware/x265_git/downloads/ |
29th August 2024, 09:46 | #5 | Link | |
Lost my old account :(
Join Date: Jul 2017
Posts: 339
|
Quote:
And do not disable strong-intra-smoothing, it might sound bad, but I have never seen it affect any perceivable difference in details or sharpness, but disabling it creates issues with blocking. As can be seen here it can even result in more bluring with disabling it. And why limit-sao? If you wanna keep some sao (selective-sao 2), doesnt that just make the SAO filter worse (I thought this limits the analysis of the filter, and not the "effect" per se of SAO)? And just a note on --rskip 2, I was going a to create a thread on this a long time ago, but when I found this setting I was also impressed with the speed increase. But I found that it had an odd side-effect were it would create pixel-shifting. So if you toggled stills back and forth (input->output) you could see that some "pixels" was not in the same positions as the input, so it "moved" things, like strands of hair etc. So I stopped using it. Anyone else noticed this? Last edited by excellentswordfight; 29th August 2024 at 10:03. |
|
29th August 2024, 14:37 | #6 | Link | ||
Special SeeD
Join Date: Nov 2002
Location: Mexico
Posts: 340
|
Quote:
Quote:
|
||
29th August 2024, 20:24 | #7 | Link | |
Registered User
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,425
|
Quote:
Do you really like the look of --limit-sao more than the default SAO analysis?
__________________
madVR options explained |
|
2nd September 2024, 21:07 | #10 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,902
|
Quote:
I rarely encode anything that hasn't been run through GradFun3 or one of it's variants at the end of a script, so maybe that's why I'm not having banding issues, but --no-strong-intra-smoothing seemed to make a difference. Unless for the example below --no-sao made the difference and I'm mistaken, but I'm pretty sure I tested those two options independently at some stage. Maybe liking --no-strong-intra-smoothing comes down to personal taste, and maybe it depends on other settings, but here's the only results I still have from my initial testing. I've probably fiddled with some of the settings for my own encodes since (I no longer include --no-rect), but.... The source is included for completeness even though the video was lightly denoised and dithered on the way through, so none of the encodes would be expected to look exactly like the original. I also ran the video by x264, just because.... Source: https://gifyu.com/image/SiQqW Encode A: 1756 kb/s https://gifyu.com/image/SiQqg x265 --crf 20.0 --profile main10 --preset slow --deblock=-1:-1 --no-open-gop --rc-lookahead 80 --lookahead-slices 0 --psy-rdoq 1.7 --aq-strength 1.3 --no-strong-intra-smoothing --no-rect --no-sao --selective-sao 0 Encode B: 2516 kb/s https://gifyu.com/image/SiQqu x264 --crf 20.0 --level 4.1 --preset slow --tune film --b-adapt 2 --me umh --subme 9 --partitions all --no-fast-pskip --stitchable Encode C: 1605 kb/s https://gifyu.com/image/SiQqc x265 --crf 20.0 --profile main10 --preset slow --deblock=-1:-1 --no-open-gop --rc-lookahead 80 --lookahead-slices 0 --psy-rdoq 1.7 --aq-strength 1.3 Encode D: 1753 kb/s https://gifyu.com/image/SiQqQ x265 --crf 18.0 --profile main10 --preset slow The encodes above are ranked according to how closely they resembled the source to me, obsessing over the background in this case, as impossible as it was for them to match the source.... my logic at the time was to look at the results based on the filtering I'd normally use rather than something different. Last edited by hello_hello; 2nd September 2024 at 21:36. |
|
5th September 2024, 08:38 | #11 | Link | |
Lost my old account :(
Join Date: Jul 2017
Posts: 339
|
Quote:
Personally I use no-sao for most of my encodes, selective-sao 1 or 2 for cartoon and anime, and full sao for low-bitrate/trytocompressasmuchaspossible stuff. Last edited by excellentswordfight; 5th September 2024 at 08:47. |
|
9th September 2024, 17:02 | #13 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,878
|
Quote:
That said, x265 3.6 has support for more layers of B-frames, and I've not experimented to see if that makes --selective-sao 3 offer any marginal benefit now. SAO won't ever do anything for non-reference b frames, which are the majority of frames in most distribution encodes. |
|
9th September 2024, 17:30 | #14 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,878
|
Quote:
Still, VMAF is luma only, so won't catch chroma issues and is not great at comparing different adaptive quantization methods And as a per-frame metric, it is up to people to figure out how to aggregate those metrics to estimate overall quality. Saying "mean VMAF of 80" for a two hour movie could indicate a movie that is consistently mediocre, or one that oscillates between pristine and terrible quality. |
|
9th September 2024, 18:21 | #15 | Link | |
Acid fr0g
Join Date: May 2002
Location: Italy
Posts: 2,721
|
Quote:
That’s why I use the output graphs, feeding source as primary stream, not numbers.
__________________
@turment on Telegram |
|
18th September 2024, 10:13 | #16 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,878
|
Quote:
Harmonic mean of scores in a GOP seems less bad than others. Choice of a metric is also a challenge. VMAF was a big step forward, but still doesn't have that high a correlation with subjective quality ratings. |
|
18th September 2024, 13:08 | #17 | Link | ||
Lost my old account :(
Join Date: Jul 2017
Posts: 339
|
Quote:
Quote:
For people who dont really understand how big of an issue this is here is an example: In a test AMD:s VCN encoder recieved a VMAF of 95.39 and Nvidias Nvenc 96.13, so one would think that they are pretty much the same, right? Well the graph tells a completely different story: That an encoder can dip that much on big bunny is one thing , but the dips really demonstrate the flaw of trying to simple down quality to one number. Its a bit like the percentiles discussion that happened in gaming benchmark a few years ago, were now it standard to look at 1% and 5% lows aswell as the avrage. Last edited by excellentswordfight; 18th September 2024 at 13:14. |
||
Thread Tools | Search this Thread |
Display Modes | |
|
|