Options to improve quality on this encode (without huge increase in time)?

[tonemapped]

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).

x265:
Preset: Medium
Tune: None
Format/Info: High Efficiency Video Coding
Format profile: Main 10@L4@Main
Duration: 44 min 21 s
Bit rate: 4 334 kb/s
Frame rate: 23.976 (24000/1001) FPS
Stream size: 1.34 GiB (94%)
Writing library: x265 3.5+9+14-6c69ed37d:[Windows][GCC 10.2.0][64 bit] 10bit

Changed from the preset:

--crf 20 --output-depth 10 --profile main10 --psy-rd 2.15 --rdoq-level 1 --psy-rdoq 1.75 --rskip 2 --rskip-edge-threshold 3 --nr-inter 150 --ipratio 1.35 --pbratio 1.25 --weightb --bframes 6 --rc-lookahead 25 --ref 4 --colorprim bt709 --colormatrix bt709 --transfer bt709 --range limited --deblock -3:-3 --no-sao --

Time Taken: 90m (acceptable)

Blu-ray Source (Left) - x265 output (Right). The most interesting comparison, in my opinion, is the final one. It seems that scene has issues compared to the rest.

https://i.ibb.co/Bcp1S04/01-charmed-source-f498.png (https://i.ibb.co/XjQwvcy/01-charmed-source-f498.png) https://i.ibb.co/dpBLs4H/02-charmed-encode-f498.png (https://i.ibb.co/3F1M5mP/02-charmed-encode-f498.png)

https://i.ibb.co/JFjBQmt/03-charmed-source-f856.png (https://i.ibb.co/S7wsr5y/03-charmed-source-f856.png) https://i.ibb.co/C7Fch8G/04-charmed-encode-f856.png (https://i.ibb.co/VS81294/04-charmed-encode-f856.png)

https://i.ibb.co/B21pknY/05-charmed-source-f11247.png (https://i.ibb.co/YBrCg0V/05-charmed-source-f11247.png) https://i.ibb.co/TqjYhHd/06-charmed-encode-f11247.png (https://i.ibb.co/4gvKNj3/06-charmed-encode-f11247.png)

https://i.ibb.co/mHXKPPg/07-charmed-source-f21517.png (https://i.ibb.co/NLmqGGb/07-charmed-source-f21517.png) https://i.ibb.co/TqHHHBc/08-charmed-encode-f21517.png (https://i.ibb.co/7NGGGJv/08-charmed-encode-f21517.png)

https://i.ibb.co/JKr4wg3/09-charmed-source-f25681.png (https://i.ibb.co/KXVkpSK/09-charmed-source-f25681.png) https://i.ibb.co/3NvnL5W/10-charmed-encode-f25681.png (https://i.ibb.co/0MKxdpZ/10-charmed-encode-f25681.png)

https://i.ibb.co/d401kBt/11-charmed-source-f36900.png (https://i.ibb.co/xqSPzhY/11-charmed-source-f36900.png) https://i.ibb.co/F8rrxHG/12-charmed-encode-f36900.png (https://i.ibb.co/vLFFwX2/12-charmed-encode-f36900.png)

https://i.ibb.co/pzMkGyw/13-charmed-source-f40697.png (https://i.ibb.co/swNXkHR/13-charmed-source-f40697.png) https://i.ibb.co/RHYZQwq/14-charmed-encode-f40697.png (https://i.ibb.co/DKzsw2Z/14-charmed-encode-f40697.png)

https://i.ibb.co/h2rnks0/15-charmed-source-f48805.png (https://i.ibb.co/TPJnZcy/15-charmed-source-f48805.png) https://i.ibb.co/2yKJd6r/16-charmed-encode-f48805.png (https://i.ibb.co/HVgZq2y/16-charmed-encode-f48805.png)

:thanks:

[Boulder]

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.

[tonemapped]

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.

Testing a 720p encode with BlackmanResize. Also testing (out of curiosity as it was a lazy way I did some encodes with only 2C/2T in 2011 - provided better results - to my eyes - than 720p with only slightly longer times) 1440x1080.

[Boulder]

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.

[tonemapped]

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.

Doing two more tests, one with the suggested BicubicResize(1280, 720, b=-0.6, c=0.3) and no nr-inter, and one with BicubicResize(1440, 808, b=-0.6, c=0.3) and no nr-inter. I know 1440x808 is an unorthodox resolution, but it's worked well before, as has 1440x1080 with DAR of (obviously) 1.777778.

The previous 720p test with nr-inter 75 and BlackmanResize at CRF 21 only took 57m, but is too small 730MB).

[benwaggoner]

"Too small" is an unusual complaint in encoding ;).

[tonemapped]

"Too small" is an unusual complaint in encoding ;).The output produced at the CRF was too small as I do have an approximate size target per episode (~1.5GB avg. using CRF). Perhaps that would have been a better way of putting it!

[Boulder]

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.

[tonemapped]

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.

Time is the main concern. With 8 seasons, that's a lot of episodes (otherwise I would do 3-pass encodes as I sometimes do with x264)

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.

[Boulder]

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).

[benwaggoner]

The output produced at the CRF was too small as I do have an approximate size target per episode (~1.5GB avg. using CRF). Perhaps that would have been a better way of putting it!
If your files are coming out with file sizes below what you've budgeted, but meet your quality targets, that's Winning Compression!

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.

[RanmaCanada]

I would have to agree with benwaggoner. If you are getting smaller file sizes and meeting or exceeding your quality targets, that is a total win.

[GMJCZP]

I would have to agree with benwaggoner. If you are getting smaller file sizes and meeting or exceeding your quality targets, that is a total win.

+2, This would have made Didée very happy.

[Forteen88]

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.

[benwaggoner]

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 is still illegal to downloaded it from the Internet.
IANAL, but that is not a safe presumption to make without checking laws in any given jurisdiction.

[Gravitator]

Blu-ray Source (Left) - x265 output (Right). The most interesting comparison, in my opinion, is the final one. It seems that scene has issues compared to the rest.
Hm... I would first of all think on the meager --aq-strength.

[tonemapped]

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.

x265 [INFO]: frame I: 908, Avg QP:17.84 kb/s: 25345.65
x265 [INFO]: frame P: 15111, Avg QP:19.53 kb/s: 8447.17
x265 [INFO]: frame B: 47797, Avg QP:23.43 kb/s: 1473.92
x265 [INFO]: Weighted P-Frames: Y:10.7% UV:5.2%
x265 [INFO]: consecutive B-frames: 10.5% 2.5% 5.2% 41.6% 40.2%
encoded 63816 frames in 4612.85s (13.83 fps), 3464.77 kb/s, Avg QP:22.42


Resolution is 1440x1080 @ 1.777778. With Boulder's Bicubic suggestions above (modified) it looks great. The file size is 1.17GB/@3466 kbps and took 1h17m.

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.

https://i.ibb.co/khxRmVT/17-charmed-encode-f498.png (https://ibb.co/P5N7Dsy) https://i.ibb.co/sPSn7YG/17-charmed-encode-f856.png (https://ibb.co/cv50qnH)

https://i.ibb.co/XCM8B0w/18-charmed-encode-f11247.png (https://ibb.co/kSv1nbd) https://i.ibb.co/Qk9nvHY/19-charmed-encode-f21517.png (https://ibb.co/zFsbV2P)

https://i.ibb.co/DKsgMSS/20-charmed-encode-f25681.png (https://ibb.co/QmzjH11) https://i.ibb.co/kJpgvmZ/21-charmed-encode-f36900.png (https://ibb.co/qCzMVJ6)

https://i.ibb.co/T8rV9bw/22-charmed-encode-f40697.png (https://ibb.co/XsVhc3W) https://i.ibb.co/PG4PHjd/23-charmed-encode-f48805.png (https://ibb.co/N2pJBCM)

[Gravitator]

The girl has a defect in the left elbow, which looks like a white dot and stripe (the last scene) :confused:

[tonemapped]

The girl has a defect in the left elbow, which looks like a white dot and stripe (the last scene) :confused:

Do you mean this image? https://i.ibb.co/TPJnZcy/15-charmed-source-f48805.png

[Boulder]

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.

[tonemapped]

What I'm finding hard to 'fix' in x265, compared to x264, is the level of 'edge movement' and the lack of smoothness. It's hard to describe. Here's an animated gif - the compression doesn't detract from the issue. If you look at the guy's head moving in front of the red surface, you can see movement around the head that isn't smooth. The same for the guy dancing behind the man in the front eating nuts/with the jacket. I understand this is to increase compression, but it's really noticeable even with a high bitrate.

https://i.ibb.co/H49B1dH/ezgif-2-26f7d34571d9.gif (https://i.ibb.co/JtSm0Qs/ezgif-2-26f7d34571d9.gif)

[Gravitator]

What I'm finding hard to 'fix' in x265, compared to x264, is the level of 'edge movement' and the lack of smoothness.
This should help.
--tu-intra-depth 4 --tu-inter-depth 4 --tskip --max-merge 5 --hme --hme-search hex,umh,star

[tonemapped]

This should help.
--tu-intra-depth 4 --tu-inter-depth 4 --tskip --max-merge 5 --hme --hme-search hex,umh,star

Cheers. Going to try those out. Do those add a lot of extra time?

[tonemapped]

This should help.
--tu-intra-depth 4 --tu-inter-depth 4 --tskip --max-merge 5 --hme --hme-search hex,umh,star

That absolutely does not work. Look at the blocks!

https://i.ibb.co/p0jdJKV/Charmed-S03-E05-Sight-Unseen-out-hevc-snapshot-00-07-508.png (https://ibb.co/TvMtm0j) https://i.ibb.co/nnKcmBV/Charmed-S03-E05-Sight-Unseenout-hevc-snapshot-00-13-513.png (https://ibb.co/4Y0Tt2D)

[tonemapped]

OK, after ~50 test encodes I'm starting to find a fair ratio of quality:size:speed. I've mostly (but certainly not completely) solved the odd problem above by reducing aq-mode to 1. The final complication is scene fades. It's not that noticeable, but when it is, it's horrific. Just look at the example. This is fading in to a new scene (I've brightened the same frame to show the issue).

I'm assuming --scenecut-aware-qp and --scenecut-window should help with this. Is there a 'golden rule' to help 'force' x265 to allocate more bitrate to scene fades, as with x264?

https://i.ibb.co/7jcPD2q/scene-fade.png (https://ibb.co/Nth5qZM) https://i.ibb.co/wyb5ptv/scene-fade-brightened.png (https://ibb.co/mJYfhpx)

[Gravitator]

Treat problems with edges by disabling --rskip 0. How do you understand the action of rskip mode? This is a double-edged sword :o

[tonemapped]

Treat problems with edges by disabling --rskip 0. How do you understand the action of rskip mode? This is a double-edged sword :o

I've been encoding for 20 years (since my first PC at boarding school at 12), but only just got into HEVC so still uncertain of many of the options. I'll try another encode with rskip disabled. Thank you for helping me learn.

[Boulder]

OK, after ~50 test encodes I'm starting to find a fair ratio of quality:size:speed. I've mostly (but certainly not completely) solved the odd problem above by reducing aq-mode to 1. The final complication is scene fades. It's not that noticeable, but when it is, it's horrific. Just look at the example. This is fading in to a new scene (I've brightened the same frame to show the issue).

I'm assuming --scenecut-aware-qp and --scenecut-window should help with this. Is there a 'golden rule' to help 'force' x265 to allocate more bitrate to scene fades, as with x264?

https://i.ibb.co/7jcPD2q/scene-fade.png (https://ibb.co/Nth5qZM) https://i.ibb.co/wyb5ptv/scene-fade-brightened.png (https://ibb.co/mJYfhpx)
--fades is the option you could try. Scenecut-aware QP reduces bitrate inside the window in others than the actual keyframe.

How are the fades in the source? If there's blocking there, it will get amplified when re-encoding.

[tonemapped]

--fades is the option you could try. Scenecut-aware QP reduces bitrate inside the window in others than the actual keyframe.

How are the fades in the source? If there's blocking there, it will get amplified when re-encoding.

Fades in the source (retail Blu-ray) are smooth. As with many things, It's most noticeable when a foot from the monitor looking frame-by-frame, but not so much when watching on a TV. I have a new encode queued up with --fades.

[benwaggoner]

It'd be helpful if you could share your full command line.

Using --weightb also helps with fades.

[benwaggoner]

Fades in the source (retail Blu-ray) are smooth. As with many things, It's most noticeable when a foot from the monitor looking frame-by-frame, but not so much when watching on a TV. I have a new encode queued up with --fades.
Ah. As a video encoder, x265 doesn't worry much about what can be seen paused on a frame versus how it will look in motion.

[tonemapped]

It'd be helpful if you could share your full command line.

Using --weightb also helps with fades.

medium --crf 19 --output-depth 10 --profile main10 --level-idc 4 --no-high-tier --psy-rd 2.15 --rdoq-level 1 --psy-rdoq 1.75 --rskip 2 --rskip-edge-threshold 3 --aq-mode 1 --aq-strength 0.75 --nr-inter 75 --vbv-bufsize 12000 --vbv-maxrate 12000 --ipratio 1.35 --pbratio 1.25 --me umh --weightb --bframes 6 --rc-lookahead 30 --ref 4 --fades --deblock -3:-3 --no-sao

I know many here would disapprove, but that's @ 1440*1080 with a DAR of 1.777778, Sharpen(0.1), and BlackmanResize(). The Sharpen(0.1) is due to the 1440*1080 encoding resolution.

Here's the full output from mediainfo

cpuid=1111039 / frame-threads=2 / numa-pools=4 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / interlace=0 / total-frames=63816 / level-idc=40 / high-tier=0 / uhd-bd=0 / ref=4 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=23 / keyint=250 / gop-lookahead=0 / bframes=6 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=30 / lookahead-slices=6 / scenecut=40 / hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=1 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=75 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=3 / no-limit-modes / me=2 / subme=2 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / weightb / no-analyze-src-pics / deblock=-3:-3 / no-sao / no-sao-non-deblock / rd=3 / selective-sao=0 / early-skip / rskip / rskip-edge-threshold=0.030000 / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.15 / psy-rdoq=1.75 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=19.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / vbv-maxrate=12000 / vbv-bufsize=12000 / vbv-init=0.9 / min-vbv-fullness=50.0 / max-vbv-fullness=80.0 / crf-max=0.0 / crf-min=0.0 / ipratio=1.35 / pbratio=1.25 / aq-mode=1 / aq-strength=0.75 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=14 / overscan=0 / videoformat=5 / range=0 / colorprim=1 / transfer=1 / colormatrix=1 / chromaloc=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / hist-threshold=0.03 / no-opt-cu-delta-qp / no-aq-motion / no-hdr10 / no-hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 / scenecut-aware-qp=0conformance-window-offsets / right=0 / bottom=0 / decoder-max-rate=0 / no-vbv-live-multi-pass


And here are some screens from an encode with the above used. It's not 1:1, but it's certainly subjectively 85% of the quality for a fraction of the size (1.35GB-1.60GB per episode, compared to 7GB-14GB. For that sort of reduction, I think the results are good, though open to suggestions before setting all episodes in a queue).

Left: ENCODE (Blu-ray disc -> muxed to mkv) / Right: SOURCE (1440*1080, using Bicubic for comparisons)

https://i.ibb.co/5GRbHdN/100-enc-f2064.png (https://ibb.co/BcC0MmX) https://i.ibb.co/CmNshPV/100-source-f2064.png (https://ibb.co/dj1JGmk)

This is the probably an example of the most detail lost (that I can notice). See the dress and chest area (glitter). It's still not noticeable when watching on an actual TV.
https://i.ibb.co/rQD8Brv/101-enc-f2471.png (https://ibb.co/K5T4tvm) https://i.ibb.co/2s0wttb/101-source-f2471.png (https://ibb.co/pR6gzzm)
https://i.ibb.co/4SH4FxJ/102-enc-f3515.png (https://ibb.co/T0sPw5r) https://i.ibb.co/Mhkf9sP/102-source-f3515.png (https://ibb.co/W3v0s6B)
https://i.ibb.co/qdPGdfn/103-enc-f8896.png (https://ibb.co/SP9TP8x) https://i.ibb.co/cXpcrSG/103-source-f8896.png (https://ibb.co/Nnk6yd8)
https://i.ibb.co/dLJqFPM/104-enc-f20045.png (https://ibb.co/CMsZgb8) https://i.ibb.co/FbVHWwW/104-source-f20045.png (https://ibb.co/3yzRsNs)
https://i.ibb.co/5MPP40v/105-enc-f36249.png (https://ibb.co/3rnnd3W) https://i.ibb.co/312sdBK/105-source-f36249.png (https://ibb.co/R2fSbz8)

[benwaggoner]

Are you happy with your updated results now?

And anamorphic 1440x1080 isn't crazy for this content. It was originally a 4:3 480i show, so they weren't shooting or doing VFX with 16:9 1080p24 in mind. I don't know the technical details of the remaster, but 720p might have been sufficient even.

When downscaling, I would want to ensure that I was using a >8-bit scaling algorithm to shrink the source 8-bit into the smaller 10-bit, to avoid another round of dithering.

[tonemapped]

Are you happy with your updated results now?

I think the results look good, although I do value opinions on here. The episode (screenshots above) took 128 minutes. That's slightly longer than I would like, but it's still not bad and means I can probably leave my server queued up and producing ~11 episodes per day, or a season every two days.

I know the quality isn't up to Amazon standards (Amazon having the highest streaming quality available), but for 1.60GB and just over two hours per encode, I believe it's good.

Given your profession, what's your honest opinion on the quality based on the recent screenshots?

And anamorphic 1440x1080 isn't crazy for this content. It was originally a 4:3 480i show, so they weren't shooting or doing VFX with 16:9 1080p24 in mind. I don't know the technical details of the remaster, but 720p might have been sufficient even.It was a 480i programme, but the remaster has been done correctly - it seems only a few areas have missing film and used upscaled footage instead - and the VFX appear to have been redone for the release. And some might say, most importantly, the original music in included.

720p looked fine, but it did lack the sharpness 1080p provides, even with a horizontal resolution of 1440. In terms of time, the difference is about 25%.

When downscaling, I would want to ensure that I was using a >8-bit scaling algorithm to shrink the source 8-bit into the smaller 10-bit, to avoid another round of dithering.For 720p, or for 1440*1080 as well?

Here's a a few screenshots of the UK (R2, PAL) DVD (crf 17, tesa, ref 8 encode, ~2.3mbps) vs the remaster:

https://i.ibb.co/hcWkQCH/200-dvd.png (https://ibb.co/Jq7N6C2) https://i.ibb.co/7tGdrVQ/200-remaster.png (https://ibb.co/RTCkQPN)

https://i.ibb.co/VL8t1Xt/201-dvd.png (https://ibb.co/tH54Gy4) https://i.ibb.co/g6kS53T/201-remaster.png (https://ibb.co/cx46G1F)

https://i.ibb.co/Fwq5P6H/203-dvd.png (https://ibb.co/cFX6mJY) https://i.ibb.co/xMrG0zx/203-remaster.png (https://ibb.co/tb1ctYV)

https://i.ibb.co/rfGGNCw/204-dvd.png (https://ibb.co/0VjjvgG) https://i.ibb.co/L8Prcwm/204-remaster.png (https://ibb.co/2y6SC2x)

https://i.ibb.co/XppmzDV/205-dvd.png (https://ibb.co/822FjbX) https://i.ibb.co/N2w5BJF/205-remaster.png (https://ibb.co/Xxm1RKW)

https://i.ibb.co/9nCVkgw/207-dvd.png (https://ibb.co/y0bYcPh) https://i.ibb.co/mtyG7z6/207-remaster.png (https://ibb.co/Cv9zF0h)

https://i.ibb.co/Rj0GPXr/208-dvd.png (https://ibb.co/bbBjL4w) https://i.ibb.co/tLB5ptd/208-remaster.png (https://ibb.co/6XY50xd)

[Gravitator]

I know the quality isn't up to Amazon standards

What do you know about the Amazon quality standard?

[tonemapped]

What do you know about the Amazon quality standard?

That Amazon suggests good practices for its Prime Video Direct service (some specs here (https://videodirect.amazon.com/home/help?topicId=G202129880) - e.g. customers submitting ProRes @ 220 mbps) and arguably provides the highest quality (served to the customer) out of any streaming service (more information here (pdf) (https://m.media-amazon.com/images/G/01/CooperWebsite/dvp/downloads/Prime-Video-Global-Content-Guide-v6.pdf) - slightly out of date, but don't have a link for the most recent pdf) with almost excessive bitrates in some cases. The files served by Amazon Prime can be probed for bitrate information.

Why? :confused: :confused:

[Gravitator]

For you, the source quality is Amazon :)

[benwaggoner]

What do you know about the Amazon quality standard?
And before anyone asks, I am not able to share specific information about Prime Video that isn't already public knowledge. Everything I say here on Prime Video are my personal opinion and views.

[tonemapped]

For you, the source quality is Amazon :)No, for me the source quality is the Blu-ray discs purchased/pre-ordered two months ago...

[benwaggoner]

No, for me the source quality is the Blu-ray discs purchased/pre-ordered two months ago...
Blu-rays are generally good, but are still only 8-bit 4:2:0. Mezzanines are generally 10-bit 4:2:2, and use visually-lossless-over-multiple-generations intraframe only codecs.

[tonemapped]

Blu-rays are generally good, but are still only 8-bit 4:2:0. I'm one of the few who doesn't like really like HDR video and who doesn't really care about native 10-bit video, although I do insist on 10-bit (or 12-bit for my next one) professional displays for work. I do like 10-bit HEVC as it reduces banding.

Mezzanines are generally 10-bit 4:2:2, and use visually-lossless-over-multiple-generations intraframe only codecs.
And that's why I wish more streaming companies sold video downloads, not just streaming (although I wouldn't want to stream or particularly download a ProRes TV episode!). I do have a few ProRes files (from work) and the sizes are obscene, but that's what you get for intra-only video. At least it's easy to scrub through and can edited on a potato (even my HTPC - see sig. - can edit 4K ProRes).

[benwaggoner]

I'm one of the few who doesn't like really like HDR video and who doesn't really care about native 10-bit video, although I do insist on 10-bit (or 12-bit for my next one) professional displays for work. I do like 10-bit HEVC as it reduces banding.
If you don't care for HDR, you've not experienced good HDR. HDR is a superset of SDR, so it can't be technically worse, only worse in implementation.

[tonemapped]

If you don't care for HDR, you've not experienced good HDR. HDR is a superset of SDR, so it can't be technically worse, only worse in implementation.

My parents have an LG 65" 4K OLED HDR10 (Dolby Vision IQ, HLG) TV and I've watched HDR content when visiting, but it's really not for me. I realise I'm in a minority there, but I find HDR more of a gimmick for TV - far less so for films - but still meh.

[benwaggoner]

My parents have an LG 65" 4K OLED HDR10 (Dolby Vision IQ, HLG) TV and I've watched HDR content when visiting, but it's really not for me. I realise I'm in a minority there, but I find HDR more of a gimmick for TV - far less so for films - but still meh.
What model year is the LG? There were some issues with the earlier ones.

What content were you watching, and in what picture mode? Cinema Home is a good starting point for general purpose viewing.

[tonemapped]

What model year is the LG? There were some issues with the earlier ones.

What content were you watching, and in what picture mode? Cinema Home is a good starting point for general purpose viewing.

They bought the TV this year, so I think it's either a 2020 model or 2021. The picture mode is the calibrated one (installer came out and manually adjusted settings using a box - can't remember what it's called).