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. |
|
View Poll Results: For the size, do you find the encoded output acceptable? | |||
Yes | 0 | 0% | |
No | 4 | 66.67% | |
Other (please specify) | 2 | 33.33% | |
Voters: 6. You may not vote on this poll |
|
Thread Tools | Search this Thread | Display Modes |
27th July 2021, 05:48 | #1 | Link | ||
Video Fanatic
Join Date: Jul 2021
Location: Surrey
Posts: 89
|
Options to improve quality on this encode (without huge increase in time)?
If you vote in the poll, please put why you don't find the output acceptable. Votes are great, but no explanation doesn't help anyone understand your view.
I've chuffed Charmed has been released with the original music on Blu-ray, but as you can imagine, eight seasons of per-episode remuxes takes up quite a lot of space. It doesn't appear too grainy most of the time so thought it would be a good contender for x265. Whilst I would love an 8, 16, or 32-core CPU, it's not realistic. I'm using a 4C/4T Xeon (Skylake). Since there are so many episodes to encode, I'm trying to find a reasonable middle ground of quality:size:time. I have used nr-inter 150 in order to keep most detail, but reduce noise just a little bit as this seems to produce good results in terms of size:quality (and did with x264). Please bear this in mind as it's noticeable in most screenshots, but not to an extent that it removes all details (in my opinion). I'm looking for advice on what else I could do, but without massively increasing the time and size, to increase perceived quality. I'm happy with the size, but don't mind trying CRF19 (don't see much of a need from watching the encoded episode) and 90 minutes per encode is already slightly higher than I would like (I believe it's ~180 episodes). Quote:
Quote:
Last edited by tonemapped; 5th August 2021 at 03:36. |
||
27th July 2021, 10:07 | #2 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,718
|
Just an idea since you are looking for better performance - have you tested downscaling to 720p? I am quite sure the difference would be unnoticable upon playback, encoding much faster and requires less diskspace. Using something like BicubicResize(1280, 720, b=-0.5, c=0.25) or BicubicResize(1280, 720, b=-0.6, c=0.3) could well do the trick. If you encode at 720p, drop CTU to 32. It's also possible that you could switch to a slower preset, or at least test --rd 6.
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
27th July 2021, 11:15 | #3 | Link | |
Video Fanatic
Join Date: Jul 2021
Location: Surrey
Posts: 89
|
Quote:
|
|
27th July 2021, 12:47 | #4 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,718
|
You should test those BicubicResize ones as well. The trick is that it will keep detail and sharpness very well when reupscaling upon playback, a well known Avisynth wizard named Didée once came up with the idea. Normally Bicubic is used with b=0, c=0.5 or 0.6.
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
27th July 2021, 21:34 | #5 | Link | |
Video Fanatic
Join Date: Jul 2021
Location: Surrey
Posts: 89
|
Quote:
The previous 720p test with nr-inter 75 and BlackmanResize at CRF 21 only took 57m, but is too small 730MB). |
|
28th July 2021, 09:10 | #8 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,718
|
Why not do a 2-pass encode then? I find target sizes very dangerous unless you try to fill a DVD or something. Some sources compress really, really well, some require a lot of bits unless you DNR it to hell (which I won't). Also the aspect ratio matters, 1.78:1 has a lot more active pixels than 2.35:1. I always crop and resize accordingly since the existing black borders do contain garbage. It's not directly visible but can be seen for example when analyzing MVTools's vectors.
I use CRF 18 or 19 for 720p. Average bitrates are usually around 2-6 Mbps.
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
28th July 2021, 13:04 | #9 | Link | |
Video Fanatic
Join Date: Jul 2021
Location: Surrey
Posts: 89
|
Quote:
The test I've done with 1440x1080 with no noise NR looks great to my eyes. Obviously, there's always a difference between screenshots on a 4K Professional 10-bit display (the one I use) and my primary TV where I'm sitting about 3 metres away. |
|
28th July 2021, 13:19 | #10 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,718
|
I think your time would be spent best if you settled to the resolution you are going to use and then find the CRF value which gives you transparency during playback. Then just encode the whole series with that and you'll save plenty of time and possible a lot of diskspace as well. That's what I've done - CRF 19 was the spot where I couldn't find any obvious faults from about 2 metres to the 65" TV. Then I just added some headroom but still use 19 if the source is very noisy and the bitrate would shoot through the roof. Going down to 720p was a no-brainer after comparisons and using Zopti to optimize the Bicubic downsizing parameters per encode (something I haven't proposed since time is an important factor for you).
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
28th July 2021, 17:18 | #11 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
|
Quote:
Try the same settings at the full 1080p, and you'll probably land at about your target file size without having thrown away any data. |
|
29th July 2021, 07:33 | #14 | Link |
Herr
Join Date: Apr 2009
Location: North Europe
Posts: 556
|
Why not download the series from the Internet, that is encoded with better x265-settings than this? Because if you already own the series, it shouldn't infringe on copyright laws, right?!
Disregard this comment if it is still illegal to downloaded it from the Internet. Last edited by Forteen88; 31st July 2021 at 05:16. |
29th July 2021, 17:26 | #15 | Link | |
Moderator
Join Date: Jan 2006
Location: Portland, OR
Posts: 4,750
|
Quote:
|
|
31st July 2021, 20:07 | #17 | Link | |
Video Fanatic
Join Date: Jul 2021
Location: Surrey
Posts: 89
|
I've so far settled on (medium) --crf 18.5 --output-depth 10 --profile main10 --level-idc 4 --no-high-tier --psy-rd 2.15 --psy-rdoq 1.2 --rskip 2 --rskip-edge-threshold 3 --ctu 32 --dynamic-refine --nr-inter 150 --vbv-bufsize 12000 --vbv-maxrate 9000 --subme 4 --me umh --weightb --rc-lookahead 30 --deblock -3:-3 --no-sao --selective-sao 2.
Quote:
Without far higher bitrates than x264, it doesn't seem possible to produce realistic grain, and by that I mean grain that seems natural rather than oddly static in areas it's not in the source and isn't in x264 with a lower bitrate. A small nr of 150 seems to resolve that issue and, of course, produces a smaller file. Based on the fairly clean source with grain in some areas, but with nr-inter 150 removing most of it (i.e. not 'complicated' or high grain), what changes would you make to the above? The encode seems as though it needs more bitrate. Maybe a higher qcomp would help. Reducing nr doesn't as it re-introduces the problem that even 10mbps doesn't solve (as mentioned above). Screenshots (Spine36 -> 1920x1080). All b-frames. |
|
1st August 2021, 13:47 | #19 | Link |
Video Fanatic
Join Date: Jul 2021
Location: Surrey
Posts: 89
|
Do you mean this image?
__________________
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 |
1st August 2021, 14:31 | #20 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,718
|
Regarding the problems with red coloured frames, it's more or less a known issue. I think the encoder doesn't spend enough bits on them compared to other ones.
--crqpoffs and --cbqpoffs can be used to force some QP offsets. I personally use -3 for both, I think that is what x264 does internally.
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
Thread Tools | Search this Thread |
Display Modes | |
|
|