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. |
|
17th November 2021, 07:51 | #1 | Link |
Video Fanatic
Join Date: Jul 2021
Location: Surrey
Posts: 89
|
Still trying to work out x265's 'static grain' issue
It's really hard to demonstrate this with anything other than high quality video, but ever since using x265, I've found that grain is treated very differently - which makes sense - apart from when there is a medium grainy scene with moving content (people in a nightclub) and the grain seems 'stick' around the moving person, yet appear normal/transparent (CRF 16/1080p) everywhere else.
With my new CPU, I have decided to start encoding Supernatural (retail Blu-ray release, with heavy grain in earlier seasons) in 1080p and even setting a CRF of 16 and --tune grain (+disabling SAO) sees the problem persist. Even setting a CRF so low that the output is higher than the source seems the problem persist. I realise without video to see the issue, it's hard to explain, but the best way I can describe is a sort of fuzz around moving objects such as a person. SAO removes this issue, but also removes grain/perceived detail. If you had a very grainy source (which could have done with more bitrate from the studio), what would you do? I can then produce a test encode. Edit: I would be happy to produce 2 test encodes - one with recommended flags and one with --tune grain -- both at three-pass 6000kbps and then clip 30s from the three clips (source, encode 1, encode 2) to post here (if the rules allow, which is uncertain). Edit: I have provided 15s video examples in this post.
__________________
PC: R9 5900X | 32GB 3600 MT/s RAM | 2*1TB NVMe | RTX 3080 | water-cooled NAS: SM 48-bay 240TB+ storage | Xeon 1220 | 32GB DDR4 ECC HTPC: Pentium J5005 | 16GB RAM | 256GB SSD | 15W Last edited by tonemapped; 19th November 2021 at 14:25. |
17th November 2021, 23:05 | #2 | Link |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
--tune grain is a pretty thermonuclear option these days. It was required to get decent grain quality with x265 back 4-5 years ago, but grain handling has been much improved even without it. And --tune grain takes a lot of bits. it's possible you're still seeing quality issues at --crf 16 because VBV limits are kicking in with QP spikes in that region (you'll see that if ABR is getting close to your peak bitrate). And it's slow without rskip.
Can you share your full command line? Were I to make a new "does well with most grain" setting today, I might start with: --preset slower --ipratio 1.2 --pbratio 1.1 --no-sao --hme --rskip 2 --psy-rd 3 --psy-rdoq 8 --nr-inter 100 --tskip --tskip-fast |
19th November 2021, 07:18 | #3 | Link | |
Video Fanatic
Join Date: Jul 2021
Location: Surrey
Posts: 89
|
Quote:
__________________
PC: R9 5900X | 32GB 3600 MT/s RAM | 2*1TB NVMe | RTX 3080 | water-cooled NAS: SM 48-bay 240TB+ storage | Xeon 1220 | 32GB DDR4 ECC HTPC: Pentium J5005 | 16GB RAM | 256GB SSD | 15W Last edited by tonemapped; 19th November 2021 at 09:30. Reason: Updated encoding fps |
|
18th November 2021, 14:36 | #4 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,733
|
I'd simply try --preset slower --no-sao --deblock -1:-1 --rskip 2 --rskip-edge-threshold 2 --psy-rd 4 --psy-rdoq 15 --aq-mode 1 and see how it looks.
Of course, it would help to see a sample of the source video.
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
19th November 2021, 14:36 | #5 | Link |
Video Fanatic
Join Date: Jul 2021
Location: Surrey
Posts: 89
|
Added your suggestions to the list of encodes in the post above. Thank you to you and Ben.
__________________
PC: R9 5900X | 32GB 3600 MT/s RAM | 2*1TB NVMe | RTX 3080 | water-cooled NAS: SM 48-bay 240TB+ storage | Xeon 1220 | 32GB DDR4 ECC HTPC: Pentium J5005 | 16GB RAM | 256GB SSD | 15W |
19th November 2021, 01:15 | #6 | Link |
Registered User
Join Date: May 2009
Posts: 331
|
I refuse to encode anything with noticeable grain, in HEVC. H.264 is still far superior. AV1 is supposed to be better, eventually, but until that happens, I'll just keep remuxing grainy sources and storing the discs on a shelf.
|
19th November 2021, 01:47 | #7 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,770
|
Quote:
So it's not encoding the grain better, but degraining the source, parameterizing the removed grain, encoding, and putting the parameters into metadata. On playback the degrained frames are decoded and the parameters fed into a grain synthesis filter to generate new grain which hopefully looks like the original grain. Which is utterly brilliant and should drop bitrates by >50% for grainy content! But it's not like we've figured out optimal fully automated grain removal and parameterization technology! And that is out-of-band of the actual codec itself, and not something codec engineers are particularly skilled with or interested in. During AV1 development it was largely a "and someone else can implement..." feature. I'm not aware of anyone actually using FGS in deployed AV1 yet. A cool thing is that the degraining process, metadata, and grain synthesis tech is all codec agnostic. SoC vendors are implementing it generically, so any AV1 decode capable HW should be able to use the same technique with HEVC, VVC, AV2, etc. |
|
20th November 2022, 00:26 | #8 | Link | |
Registered User
Join Date: May 2018
Posts: 3
|
Quote:
|
|
31st December 2022, 20:41 | #9 | Link | |
Registered User
Join Date: Apr 2022
Posts: 28
|
Quote:
x265 added support for side-band grain synthesis data a while back, and multicoreware released their own utility for generating noise data. Technically it was in the spec for H.264 too...and it looks like now it's MPEG-C/9 It looks like ffmpeg might have decode support for film grain synthesis SEI messages in HEVC bitstreams as well? https://lists.ffmpeg.org/pipermail/f...st/128333.html ITU calls it "H.274" now as well. TL;DR Grain synthesis sounds cool, I've played with it before with AV1, and it's still got a long way to go Back to HEVC and grain synthesis, at least with x265, an immediate observation comparing it with the aforementioned reference/test tool that you can compile alongside AOMEnc is that:
On paper, I liked how AOM's test implementation sounded, since it meant I could use an obnoxious chain of AVISynth filters to degrain in a way that looked pleasing to me. It also meant I could "clean up" the grainy source a little bit first without actually doing any de-graining, like trying to remove any macroblocking introduced by compressing grain from 80+ year old film at 15 Mbps using AVC and use the difference between that and the "fully de-grained" input .yuv to "generate" the grain parameters. In practice? I only tested it once, but the grain synthesis parameters AOM's tool generated were...not great. Speaking of grain that's compressed so much that it's turned into macroblocks...shame on you WHV...you could've given us an extra couple of discs and bumped the bitrate, these weren't exactly cheap for 80+ year old cartoons. You could've fixed the pitch issues on "very musical" shorts like Rabbit of Seville that you introduced somewhere in the restoration process instead of forcing me to hunt down older DVD copies and yoink the audio from there. You could've thrown in a TrueHD track as well, since DTS-HD MA 2.0, even with a smaller 768 kbps "core", would've likely wasted more space than TrueHD 2.0 + the mono AC-3 that's already on here. Really makes me chuckle that neither lossless audio format has any provision for actual mono sound, DTS doesn't have support for 1.0 channel sound at all, but at least newer TrueHD encoders seem to be a bit more clever about what I can only assume is using things like joint-stereo coding internally and saving some more bits on tracks like that, not that I have access to one for testing, but I digress... Was it better than trying to make the resulting ~2-4 Mbps AV1 encode (I forget) that I ended up making with the grain left intact as is from the already bit-starved ~15 Mbps Blu-Ray source? YES, no question. I also deliberately picked a test clip that you could see "elsewhere" in any number of different places and formats. With WB uploading the same clip in a longer video presumably "unfiltered" to YouTube - you can see how poorly YouTube's 1-2 Mbps AV1, AVC, and VP9 compression fared with grain that heavy. In addition to places like Amazon and iTunes, I think the same short is probably on Boomerang or HBO Max or both, with the former seemingly using nearly identical files, with very similar bitrates to their Blu-Rays in my experience (but usually 25 fps PAL masters meant for European terrestrial broadcast - no speed-up, just frame duplicated) and the latter using lower bit-rate x264 or x265 (they keep the SEI messages in there...lol, just like Netflix) from the same masters as either of the other two. Amazon and iTunes obviously do their own thing as well. There's very clearly only one "newly restored master" for all of these old shorts, but how "early on" in the generational loss chain either of the three, WHV/WBHE, Boomerang, or HBO Max, got their hands on the material is only something they'd be able to tell you. benwaggoner, will you get in trouble if you hint at what kind of files WBHV might have given Amazon in the past? Was it better than letting AOMenc try to de-noise on its own and generate grain parameters? Absolutely. Did it look any good? Eh...it was certainly "as noisy" when comparing side-by-side with the source, but I could see..."grain macroblocks" if that makes sense. Clear boundaries in the areas of the drawn grain pattern, which make more sense when you look at the actual information the utility spits out, it's just frame/timestamps, regions, and what I think are seed numbers. You could also very easily see the "synthetic" structure of it all. I haven't actually looked at what the SEI data looks like, or if it's any different from the information the utility made. It didn't look like natural film grain, it looked like an overlay. I mean, I know it already is technically nothing more than an overlay, but it took a long ass time to generate, so I certainly had higher expectations than that. I wouldn't be surprised if somebody writes some kind of GPGPU plug-in (please make it platform agnostic, and not bound to CUDA...) to generate its own synthetic grain in real-time that looks better than you could ever signal in tiny little sideband/SEI messages. Did I ever use it again? No. My poor results might've been entirely on me, with just how grainy the source was, and how spotless the "no grain" comparison file was I made this time around. I'm not very skilled with making "good" filter chains for this kind of thing, and it was also contrasharpened. When I normally de-grain old animation like this, I tend to prefer sharper output over either completely removing all of the grain or saving the most amount of bits when I encode it at the end. I just want it to look "how I think it ought to." Everybody who worked on these is long since dead, may they rest in peace, and it's really old, at times not well preserved, film. I get to decide what I like, purists pls cry elsewhere - if the "source" material available was better then maybe I'd be more of a "purist" about it... There was a third option I didn't explore, using two slightly different "de-grained" files, one with no additional processing to generate the grain, and one with more of the filters I'd probably be applying to material like this - a little bit of contrasharp, etc. for the encode. If I ever find the extra hard-drive space for a bunch of .yuv video and the time to play with it some more, I might try it again with the sharpened file only being used for the final encode, and the "de-grained" parameter generation file being completely un-sharpened, but I'd probably wait for an improvement in the utilities themselves before considering it. |
|
19th November 2021, 13:23 | #12 | Link |
Video Fanatic
Join Date: Jul 2021
Location: Surrey
Posts: 89
|
When you say 30s threshold, is that forum rules? I'm trying to find an exact scene and do proper control encodes (two- or three-pass, 6000kbps) and as it's motion-dependant, it'll need more than 5s to demonstrate it.
__________________
PC: R9 5900X | 32GB 3600 MT/s RAM | 2*1TB NVMe | RTX 3080 | water-cooled NAS: SM 48-bay 240TB+ storage | Xeon 1220 | 32GB DDR4 ECC HTPC: Pentium J5005 | 16GB RAM | 256GB SSD | 15W |
19th November 2021, 13:21 | #13 | Link |
Video Fanatic
Join Date: Jul 2021
Location: Surrey
Posts: 89
|
The encode has completed and I mistakenly used CRF rather than two- or three-pass for it, so it's created a file that's over 4GB and 13.5mbps. I'll do another encode using the suggested options above, but two-pass, and do a fresh encode of what I think *should* work but doesn't. 6,000 kbps should be more than enough in theory.
__________________
PC: R9 5900X | 32GB 3600 MT/s RAM | 2*1TB NVMe | RTX 3080 | water-cooled NAS: SM 48-bay 240TB+ storage | Xeon 1220 | 32GB DDR4 ECC HTPC: Pentium J5005 | 16GB RAM | 256GB SSD | 15W |
19th November 2021, 14:24 | #14 | Link |
Video Fanatic
Join Date: Jul 2021
Location: Surrey
Posts: 89
|
OK, I have cut a segment from the source file (just under 15s long) and encoded it thrice.
Where to find the issue A fair example (not a perfect example) of the problem can be seen with the woman's head movement at ~11s in to the clip for approximately 2500ms. Please note the background being 'merged' into her head movement. It's partially there in this x264 encode as well, but this is only there for a comparison to show that, in my eyes looking one frame at a time and comparing, the x264 encode at the same bitrate as the x265 produces a better result. I have completed about a dozen test encodes of full episodes and find x265 to be far better in general, but it's just this bloody grain issue that's stopping me from proceeding with x265 (my general tests have shown a 35% reduction in file size with x265 compared to x264, apart from this grain issue). Files provided I've provided four files - all the same 14s 919ms long:
Opinion Looking frame-by-frame, I believe the best result is (just about) produced with Boulder's suggestion parameters. What do you think? Technical Specifications
The Files - these will be deleted at some point Source: _Supernatural_source_VC1.mkv x265 custom: _Supernatural_encode_3pass_custom_x265.mkv x265 Waggoner: _Supernatural_encode_3pass_Waggoner_x265.mkv x265 Boulder: _Supernatural_encode_3pass_Boulder_x265.mkv.mkv x264 custom: _Supernatural_encode_3pass_custom_x264.mkv Disclaimer: I own the original Blu-ray discs and do not condone piracy. I offer these 15 second clips for evaluation in order to help me legally back-up purchased content for my viewing. If I have unknowingly broken any forum rules, I apologise and ask that this post is deleted.
__________________
PC: R9 5900X | 32GB 3600 MT/s RAM | 2*1TB NVMe | RTX 3080 | water-cooled NAS: SM 48-bay 240TB+ storage | Xeon 1220 | 32GB DDR4 ECC HTPC: Pentium J5005 | 16GB RAM | 256GB SSD | 15W Last edited by tonemapped; 19th November 2021 at 14:41. Reason: Added a link to Boulder's suggestion encode |
19th November 2021, 18:59 | #15 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,733
|
6000 kbps is actually not much for a grainy 1080p source so x265 will definitely start eating the grain. It might do for a 720p encode, depending on the aspect ratio.
You could also try using Avisynth and some filtering. SPresso at some very light settings can be undistinguishable but reduces the required bitrate by 5-15%.
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
19th November 2021, 21:38 | #16 | Link | |
Video Fanatic
Join Date: Jul 2021
Location: Surrey
Posts: 89
|
Quote:
__________________
PC: R9 5900X | 32GB 3600 MT/s RAM | 2*1TB NVMe | RTX 3080 | water-cooled NAS: SM 48-bay 240TB+ storage | Xeon 1220 | 32GB DDR4 ECC HTPC: Pentium J5005 | 16GB RAM | 256GB SSD | 15W |
|
20th November 2021, 08:46 | #17 | Link |
Registered User
Join Date: Dec 2013
Posts: 349
|
Well for grain and such a good rate for HD is around 3.5-4 Mbit with HEVC. I dont know where you guys take that "6Mbit, use x264" from.
Now we do not have the actual source. The "Source" provided here has around ~13Mbit video which is already compressed hard and in an inferior codec. My guess is that most bits are spent on compression artifacts. The Grain is stuck to the hair in this "Source" already, an encoder cannot magically unstuck it. |
27th November 2021, 08:32 | #18 | Link | |
Video Fanatic
Join Date: Jul 2021
Location: Surrey
Posts: 89
|
Quote:
Please zoom in and you'll see the problem is far more pronounced in the encodes.
__________________
PC: R9 5900X | 32GB 3600 MT/s RAM | 2*1TB NVMe | RTX 3080 | water-cooled NAS: SM 48-bay 240TB+ storage | Xeon 1220 | 32GB DDR4 ECC HTPC: Pentium J5005 | 16GB RAM | 256GB SSD | 15W |
|
27th November 2021, 11:51 | #19 | Link | |
Registered User
Join Date: Dec 2013
Posts: 349
|
Looks like I have to be happy your "source" is not in H.262. What I meant is that you did not provide the snippet from the mezzanine the Blu-Ray was made from. Sorry but your source is Not So Good.
Quote:
I tried encoding your VC-1 snippet and got this at 4Mbit video with a differenct encoder: https://drive.google.com/file/d/1HrT...ew?usp=sharing While the hard blocks from VC-1 got smoothed out due to rate I see no additional problems introduced around the hair ? |
|
20th November 2021, 12:33 | #20 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,733
|
At lower bitrates, you are better off with aq-mode 2 and SAO (maybe selective SAO could be used). Yes, SAO does eat grain for breakfast but you can't have both detail and a low bitrate if the source is not easy to compress. HEVC blurs while AVC creates blocking when the bitrate is not enough to keep the details. Blocking may look better in motion, depending on your viewing distance etc.
A lot of people think that HEVC is better because it is newer, but in fact the use cases are more or less related to being able to create a watchable video at a low bitrate at higher resolutions, at least for x265. You can easily see how most of the actual development is done on that part, and that is why I've always taken the developers' fancy new things with a grain of salt. I myself use x265 because of HW support for 10bit encodes and of course HDR encodes pretty much require using it.
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
Tags |
grain, x265 |
Thread Tools | Search this Thread |
Display Modes | |
|
|