My DVDs to déinterlace > x265 (placebo like)

[KlemNT]

Hello,

i had a few DVDs, ripped all on an SSD, that i kept one audio language (French), except for Thriller in dual eng/swe with fr sub.

It's 576p PAL DvDs, except Thriller and Girlfight (480p is in sample filename). Girlfight is 4:3 (full image) the 16:9 BluRay/HdtV is crappy (proof, A-R not set).


A-R has to be managed by media player, a lot of the rendered DvDs i have output wrongly ! SShots of the A-R's:
https://drive.google.com/drive/folders/1CNj1fP_WHoeYw4ojMJdGLqEd6Wopevbs?usp=drive_link

I made 10 minutes samples of each too (when a serie, first episode) using direct steream copy, MediaInfo in txt aside:
https://drive.google.com/drive/folders/1e25nKmFb92agbQio7th43SJR1WW3DANC?usp=drive_link

How do i manage to encode all this stuff correctly, i'd like to get rid of the MPeg2 originals but want perfect copies, even if size is same idc.

I'll use x265, deinterlace (decomb for 480p) and fix aspecxt ratio (LoL).

Help

MakeMKV, StaxRip, VidCoder/HandBrake, or even MeGUI are my tools.......

Thanks

[KlemNT]

Looks like makeMKV direct stream copy (from my mkv) fix some of the A-R output in MPlayer:

Atomik Circus
Girlfight
Miel
3AM
Thriller
GTO
H

Oh and, i'm on 7800x3d & 4070ti.

[KlemNT]

Looks like CRF 15 approx keeps quality equal to DvD ! So on this quality side i'm done decided.

Interlacing is so confusing that's where i would need help, for each source.

[Selur]

with a quick glance I didn't see anything exotic,...

10min_Miel is progressive => don't deinterlace
10min_H ist normal tff interlacing => QTGMC
10min_GTO looks like PAL content created from NTSC => QTGMC+sRestore
10min_Girlfight-(480p) is (soft) telecine => either apply pulldown through DGDecNV or use TIVTC
10min_Feebles is field-shifter => TFM
10min_Atomik Circus is progressive => don't deinterlace
10min_3am is progressive => don't deinterlace
10min_Thriller-(480p) is (soft) telecine => either apply pulldown through DGDecNV or use TIVTC

[KlemNT]

Thanks a thousand, i'll try this deinterlacing methods.

It will take some time

[hello_hello]

KlemNT,
How are you setting the aspect ratios? Your sample pictures are confusing me.
It doesn't matter if you crop the picture, but as long as you don't resize you should set the original sample (pixel) aspect ratio when encoding.
If you resize it changes the sample aspect ratio, although when resizing it's common to resize so the sample aspect ratio becomes 1:1.

That's what I did for the screenshots below. The CropResize function is resizing the width for square pixels dimensions (after applying the specified cropping), and that's how the picture should look on playback, whether you resize before you encode or don't resize and set the correct sample aspect ratio for encoding. The sample aspect ratio you'd use for encoding is the InSAR used with CropResize below, assuming you only crop, or don't crop, but don't resize. For example InSAR=12.0/11.0 would be --sar 12:11 in the x265 command line.

# 3am frame 211
CropResize(0,0, 10,2,-6,-4, InSAR=12.0/11.0, ResizeWO=true)


[Attachment 92053 - Click to enlarge]


# Atomik Circus frame 7270
CropResize(0,0, 2,72,-2,-70, InSAR=65.0/45.0, ResizeWO=True)


[Attachment 92054 - Click to enlarge]


# Feeble frame 1004
TFM()
CropResize(0,0, 4,2,-28,-2, InSAR=12.0/11.0, CropDAR=4.0/3.0, ResizeWO=True)


[Attachment 92055 - Click to enlarge]


# Girlfight frame 3626
TFM().TDecimate()
CropResize(0,0, 10,2,-6,-4, InSAR=10.0/11.0, ResizeWO=true)


[Attachment 92056 - Click to enlarge]


# GTO frame 7181
TDeint(Mode=1)
SRestore()
CropResize(0,0, 10,4,-18,-4, InSAR=12.0/11.0, CropDAR=4.0/3.0, ResizeWO=true)


[Attachment 92057 - Click to enlarge]


# H frame 9490
QTGMC(Preset="very slow")
CropResize(0,0, 10,62,-2,-62, InSAR=12.0/11.0, ResizeWO=true)


[Attachment 92058 - Click to enlarge]


# Miel frame 3313
CropResize(0,0, 12,2,-8,-2, InSAR=12.0/11.0, ResizeWO=true)


[Attachment 92059 - Click to enlarge]


# Thriller frame 4477
TFM().TDecimate()
CropResize(0,0, 26,2,-26,-2, InSAR=40.0/33.0, ResizeWO=true)


[Attachment 92060 - Click to enlarge]

[KlemNT]

Hello hello,

the mkv (sources of the samples) A:R look to be stored in a state that don't give good/real info to software media players !
Those are DvD discs direct-stream copy (clone DvD used), but i can't remember how i made VOB to MKV, perhaps AviDemux.

Using MakeMKV from this mkv files in direct-stream copy mode fixed the mkv files (i did this just after uploaded samples, sorry) A:R displayed in media players.

But it doesn't matters, it's just container meta that changed.

//

Yes, 1:1 is what uses PC encoding, i know bc i did some subtitle translation in DivX times (eMule time).
Great thanks i will be able to check my encoded videos outputs, with your sshots and be sure to have done it correctly.

I understand... if i don't crop i don't resize, bc of DvD black bars. If i crop it needs to be ressissed to keep his original/intended shape.

What i'm the most interested in is to deinterlace all those DvD in the best possible/available way, i think i'll use RF of 13 in x265, i need to never have to recode this stuff again.
Strange, MeGUi gives CQuality and CQuantizer choices (and ABR too) for x265, not Handbrake.

I don't think NVenc is a good idea, am i wrong ?

It's an image comparing mkv source after MakeMKV direct-stream copy (fix).
https://ibb.co/j9VSNqsJ

//

i think i should use grain opti in x265 for some of this DvDs, and anime for the animated ones.

Film Grain https://x265.readthedocs.io/en/master/presets.html
--tune grain aims to encode grainy content with the best visual quality. The purpose of this option is neither to retain nor eliminate grain, but prevent noticeable artifacts caused by uneven distribution of grain. --tune grain strongly restricts algorithms that vary the quantization parameter within and across frames. Tune grain also biases towards decisions that retain more high frequency components.

[KlemNT]

Oh well, i found one good encoder GUi, :

Hybrid
https://www.videohelp.com/software/Hybrid

I'll try this right now

[hello_hello]

I understand... if i don't crop i don't resize, bc of DvD black bars. If i crop it needs to be ressissed to keep his original/intended shape.

You can do either, neither, or both.

Cropping on it's own doesn't change the shape (aspect ratio) of the remaining pixels, so if you only crop you'd use the original sample (pixel) aspect ratio for encoding. Same if you don't crop or resize at all.

Resizing changes the aspect ratio of the original pixels. The one exception being if you resize the width by the same proportion as the height. For example a 720x576 PAL DVD with a 12:11 sample aspect ratio would still have a 12:11 sample aspect ratio if you resized to 1440x1152 as both the width and height have simply been doubled.

Based on a 12:11 sample aspect ratio, if you wanted to resize the height to 1080 (as an example), and you wanted to resize the width for a 1:1 sample aspect ratio, one way to go about it is to calculate the display aspect ratio first, which would be:
720 x 12 / 11 = 785.454545455
The display aspect ratio is
785.454545455 / 576 = 1.36363636364
and
1080 X 1.36363636364 = 1472.72727273
So you could round that to 1472 x 1080

If you cropped 10 pixels from both the left and right, and 2 from the top and bottom, leaving you with 700 x 572 (as an example) you'd use the same formula, and for this example the height is resized back to 576 (although you don't have to resize it).
700 x 12 / 11 = 763.636363636
763.636363636 / 572 = 1.33502860776 (new display aspect ratio after cropping)
576 x 1.33502860776 = 768.976478067
So you could round that to 768 x 576

Most GUI's, and I imagine that includes Hybrid, should calculate all that for you. You just need to ensure they're using the sample aspect ratio for the source you believe is correct.

Here's a zip file with some quick encodes of the first 2 minutes of each sample, using CropResize to resize the width to square pixel dimensions. The heights have only been cropped while the widths are cropped and then resized based on the appropriate sample aspect ratio (cropped width x SAR). They should match the screenshots I posted. Personally I prefer to remove the noise rather than encode it, so some of the included scripts use QTGMC in progressive mode (not de-interlacing) for noise removal. I'm not claiming any of it's the definitive way to do it. It's mainly so you can compare the aspect ratios on playback, whichever way you decide to go about it.

PS If you crop differently, or don't crop, or don't resize etc, the display dimensions / aspect ratio will be different, but the shape of objects in the picture should hopefully be the same on playback.