Deinterlacing advice

[hello_hello]

I'm looking at my DVD of Garth Marenghi's Darkplace which has MPEG header flags saying 1.30:1 & 702x576. MadVR obeys this and scales accordingly to produce 1.30 of active pixel area.

I had no idea DVD video ever contained that sort of info. The consensus here has always been they're just 4:3 or 16:9 without any other info, especially something that specific.

[flossy_cake]

I had no idea DVD video ever contained that sort of info. The consensus here has always been they're just 4:3 or 16:9 without any other info, especially something that specific.

So I'm ripping my DVD's using MakeMKV (https://www.videohelp.com/software/MakeMKV). This just remuxes the MPEG2 stream into a mkv file without touching the video or transcoding it in any way. LAV Video decoder then reports info like this:

https://i.ibb.co/qpPRGVK/lav.png

I am not sure if that metadata is coming from the container (mkv) or the MPEG2 stream itself.

The VIDEOINFOHEADER2 structure seems to be part of the windows api: https://learn.microsoft.com/en-us/previous-versions/windows/desktop/api/dvdmedia/ns-dvdmedia-videoinfoheader2

So I'm not sure where the data actually originates from. My guess is that MakeMKV is probably creating it during the ripping process and then LAV is perhaps reading it out through the Windows API.

[flossy_cake]

I still think bwdif is far too quick to interpolate at the slightest bit of camera noise or movement. Perhaps a combination of TDeint & nnedi would do the trick, since TDeint is far better at weaving 1:1.

Author of BWDIF has kindly added a threshold param: https://github.com/Asd-g/AviSynth-BWDIF/issues/4

Seems to work well with a value of 3-5: the 1px pattern on Public Senat clip is no longer flickering, and static shots in The IT Crowd are now weaving despite the animating camera noise.

[hello_hello]

I've no idea where that extra aspect ratio info would be coming from then, given your screenshot only shows 4:3.

I'll check out the new version of BWDIF.

[flossy_cake]

I've no idea where that extra aspect ratio info would be coming from then, given your screenshot only shows 4:3.

Yeah that DVD is 4:3. Here's the other one ("Garth Marenghi's Darkplace")

https://i3.lensdump.com/i/R08fx1.png



I'll check out the new version of BWDIF.

The author has also just added debug param to highlight interpolated pixels.

It's interesting though cause if we set thr to a high value like 95 it seems like bwdif is using DoubleWeave() behind the scenes, so the fps still "looks" double rate even when it's weaving. Whereas when TDeint weaves I'm only seeing 25fps which kind of makes combing artefacts more visible for double rate content.

[poisondeathray]

Not sure where the dwPixelAspectRatio is from, but for MPEG2 streams (and DVD-video), there can be additional information in the sequence_display_extension . It specifies the portion of the frame that is scaled to 4:3 or 16:9 . You can parse the sequence_display_extension of an mpeg2 elementary stream in gspot

[hello_hello]

Yeah that DVD is 4:3. Here's the other one ("Garth Marenghi's Darkplace")

Interesting. The consensus has always been DVD video doesn't contain that sort of information. I don't think any encoding GUIs look for it. I'll check any DVDs I encode from now on.

[Katie Boundary]

Just for the fun of it I'm trying to manually implement bob deinterlacing with an Avisynth script.

It seems my concept of bob deinterlacing is wrong as I can't reproduce the same quality image as Avisynth's internal Bob() function. (http://avisynth.nl/index.php/Bob)

I raised this idea a long time ago: https://forum.doom9.org/showthread.php?t=174658

However, nowadays I'd use Lanczos4 rather than Spline64. So, my script would look like:

mpeg2source("whatever.d2v").converttorgb(interlaced=true).separatefields()

A=selecteven().lanczos4resize(720,480,src_left=0,src_top=0.25,src_width=720,src_height=240)
B=selectodd().lanczos4resize(720,480,src_left=0,src_top=-0.25,src_width=720,src_height=240)

interleave(A,B)

[flossy_cake]

However, nowadays I'd use Lanczos4 rather than Spline64. So, my script would look like:

mpeg2source("whatever.d2v").converttorgb(interlaced=true).separatefields()

A=selecteven().lanczos4resize(720,480,src_left=0,src_top=0.25,src_width=720,src_height=240)
B=selectodd().lanczos4resize(720,480,src_left=0,src_top=-0.25,src_width=720,src_height=240)

interleave(A,B)

Why 0.25? Personal preference?

I'm asking as I'm reasonably confident that 0.5 is the amount of shift required if the goal is to preserve the alignment of the original fields (this may not be your goal). In my tests this was the same as upscaling field 2 to double height and then shifting it down 1.0 lines. edit: oops, didn't notice the first one was positive -- does that make any difference image-quality wise vs 0.5?

On a separate note, I just bought The Office on DVD (2020 version) and wow it's a mess. They've added 1:1 cadence intros to every episode (like commentary extras but mandatory) then the theme song intro is proper 2:2 with full 576p res (top field first, doesn't require any deinterlacing), then the show itself looks like it was shot at 1:1 cadence and then had every second field discarded to make 2:2 cadence with only 288p actual res. Then for season 2 it's the same deal except the show itself contains 2:2 576p res but only when the camera is still -- anything that moves drops to 288p (this is baked into the source, as if the DVD authors had needlessly applied a bwdif-style motion compensated deint at some point in the production chain). edit: clip1 (https://drive.google.com/file/d/1vnkI505_OOUOYJ9QVh89WDtkFHiugbOF/view?usp=share_link), clip2 (https://drive.google.com/file/d/1inJLUTbTf01YRCVBqENdoc-gjXL05soy/view?usp=share_link). Debating whether it would benefit from some smooth style interpolating of the 2nd field like nnedi3 -- I figure it's better than the junk BBC put in there... but then it would be discarding resolution for the intro.

edit: and for some reason the bottom field (https://i.ibb.co/vJNXMJs/bottom-field.png) is sharper and higher resolution than the top field (https://i.ibb.co/VS25pzb/top-field.png), so it works better keeping the bottom and interpolating the top. edit: maybe it's a form that interlace filtering thing to reduce flicker on CRTs.

[Katie Boundary]

Why 0.25? Personal preference?

Because it's the mathematically correct amount.

I'm asking as I'm reasonably confident that 0.5 is the amount of shift required if the goal is to preserve the alignment of the original fields (this may not be your goal). In my tests this was the same as upscaling field 2 to double height and then shifting it down 1.0 lines.

If you shift one field up or down and hold the other field right where it is, that results in moving the entire image up or down, as well as destroying all of the original scanlines. My method keeps the image perfectly still and preserves the original scanline data.

edit: oops, didn't notice the first one was positive -- does that make any difference image-quality wise vs 0.5?.

It makes a difference in terms of shifting the whole image up or down.

Imagine for a moment that you're doing this:

mpeg2source("whatever.d2v").separatefields().selecteven().lanczosresize(720,576)

Do you think that the resulting image will still be exactly in the same place? Or did you cut a row of pixels off the bottom of the image without cutting a row of pixels off the top, thus shifting the whole image downward by a fraction of a pixel?

Your top fields need to be shifted back up a bit and your bottom fields need to be shifted back down a bit if you want to put everything back in its original place.

[Katie Boundary]

Actually, here's a fun experiment for you to try, with the numbers adjusted for PAL/SECAM material :)

A=mpeg2source("whatever.d2v").bob()

B=mpeg2source("whatever.d2v").converttorgb(interlaced=true).separatefields()

C=B.selecteven().bicubicresize(720,576,src_left=0,src_top=0.25,src_width=720,src_height=288)
D=B.selectodd().bicubicresize(720,576,src_left=0,src_top=-0.25,src_width=720,src_height=288)

E=interleave(C,D)

Compare(A,E)

You'll find naught but rounding errors :)

[flossy_cake]

What I meant was, you're shifting the top field up by 0.25 and the bottom field down by 0.25, which in theory should be equivalent to shifting only the bottom field down by 0.5, which is how I was doing it (which is equivalent to shifting it down by 1.0 after the field is upscaled 2x vertically, which helps me visualise in my mind that the field alignment is preserved).

I was just curious to know why you did the 0.25/-0.25 split instead of 0/-0.5 split, whether that had any benefits (I was thinking, maybe that would help with line flicker at the top and bottom most rows of pixels?)

[flossy_cake]

Actually, here's a fun experiment for you to try, with the numbers adjusted for PAL/SECAM material :)

You'll find naught but rounding errors :)

Test clip: https://drive.google.com/file/d/1WfW3yXmGhIvUCiexQGYD18gSiXRe2bze/view?usp=share_link

Script

clip = "576i 1-1 cadence.ts"
source = LWLibavVideoSource(clip)

A=source.bob()

B=source.separatefields()
C=B.selecteven().bicubicresize(720,576,src_left=0,src_top=0.25,src_width=720,src_height=288)
D=B.selectodd().bicubicresize(720,576,src_left=0,src_top=-0.25,src_width=720,src_height=288)
E=interleave(C,D)

Compare(A,E)


Result

https://i.ibb.co/mNG2VQc/debug-avs-snapshot-00-28-743.png

I am not sure why PSNR is showing that value or what it means exactly, but if I replace last line with Compare(A,A) I get the same result.

Then compared the 0.25/-0.25 split vs 0/-0.5 split and they are not the same, obviously. But I think that is just because both bobbed frames are sitting 0.25 higher in the former.

[flossy_cake]

Are you familiar with the resizing mess for DVDs?
The short story is DVDs can have a generic aspect ratio, which makes a 4:3 DVD exactly 4:3, or an ITU aspect ratio which follows the standard for digitising video, and as a result the aspect ratio could be ~1.36 instead of 1.33 (before any cropping). I'm pretty sure I went with an ITU aspect ratio for the DVD version, and the first thing I noticed when comparing it to the Bluray was the difference in aspect ratio, which looks to be exactly the difference between a generic and ITU aspect ratio for DVDs. Here's a couple of screenshots. Have a look at the clock-face on the left. I'll leave you to decide in which screenshot it looks round, or for that matter, if it's even supposed to be round.

https://i.ibb.co/tJXf43p/DVD-Encode.png
https://i.ibb.co/61qLbTy/Bluray.png


Out of curiosity I bought the newest version of the DVD ("remastered" one, specifically this one (https://www.jbhifi.com.au/products/fawlty-towers-the-complete-series-remastered-1975-dvd) which was referenced here (https://forum.blu-ray.com/showthread.php?p=18016046#post18016046) as being superior to the BD).

Well, the DVD aspect is identical to the BD, except the BD is slightly zoomed in to remove a few pixels of blanking at the bottom edge present on the DVD.

Oddly though, the external shots are a lot worse on DVD in terms of colour and resolution, except for the intro sequence.

Edge enhancement seems present in the DVD too, but diminished probably as a result from the downscale from 1080 to 576. Noise reduction is not present in the DVD it seems.

Screenshots:

DVD: https://i.lensdump.com/i/RR6Hyr.png
BD: https://i2.lensdump.com/i/RR6Oe7.png

DVD: https://i3.lensdump.com/i/RR6S73.png
BD: https://i1.lensdump.com/i/RR6zRF.png

DVD: https://i2.lensdump.com/i/RR6eU0.png
BD: https://i.lensdump.com/i/RR6vID.png

Clips:

DVD: https://drive.google.com/file/d/1qcUZfszQWAqUrbrrbQ8-j0cmC63k7btC/view?usp=share_link
BD: https://drive.google.com/file/d/1a-NQopT83Lg-PUZ1AbLvUO0WVVwssL02/view?usp=share_link

DVD: https://drive.google.com/file/d/1pAwnnQsL0fBpAZgXbzxbbZqPXpW_xmYX/view?usp=share_link
BD: https://drive.google.com/file/d/1tw9NTWUcrEUyLTJLuA4NmH_R7bUQvI1p/view?usp=share_link

[hello_hello]

Yeah it looks like they started again with the outside shots for the Bluray but not for the DVD. Like they decided to go back to the original film negative or something.

The inside shots do seem to have the same display aspect ratio but the outside shots are a tad different. The Bluray version is a little wider, but not 1.36 vs 1.33 wider. It's something in-between. Sigh....

[flossy_cake]

Well, on balance I think I prefer the bluray version. What do you think?

[hello_hello]

I haven't tried de-interlacing the DVD sample to see if de-interlaces more "cleanly", but assuming it doesn't, yes I'd prefer the bluray, at least for the outside shots.

[flossy_cake]

For those screenshots I was using AMD DXVA deint, and now that I look closely I'm seeing some weird squiggly line patterns in the video noise on Basil's coat. BWDIF(thr=2) doesn't have that and seems to be producing a better result. imo the best fast real-time video mode deinterlacers are, from best to worst:

1. BWDIF(thr=2) (can optionally add edeint=nnedi3 for antialiasing on moving pixels... but I don't like the shapes it makes on certain patterns...but still impressive what it can do)
2. TDeint
3. DXVA (AMD/NVidia implementation... I can only get this through MadVR... maybe someone should make an Avisynth filter for this? )

But without the thr param I would pick TDeint over BWDIF as it weaves a lot more.

[hello_hello]

3. DXVA (AMD/NVidia implementation... I can only get this through MadVR... maybe someone should make an Avisynth filter for this? )

Is cuvid still I thing? I'm using on old version of MPC-HC as the newer flavours don't support XP. DXVA2 doesn't work but Cuvid DXVA does in LAV filters and the deinterlacing works but my old video card can barely de-interlace to 25fps at 1080p.

For funzies I enabled the old ffdshow DXVA decoder and it worked. I couldn't get it to decode with MADVR rendering for some reason, but using WMR9 it did (EVR doesn't play on XP any more). The video was being de-interlaced and it played a 1080p source smoothly even though I'm pretty sure it was de-interlacing to 50fps, although it has no de-interlacing options. It also only supports h264 and VC1.

It's been so long since I've wanted to watch interlaced video I had to work out why MPC-HC wasn't de-interlacing any video at all before I started.... given my "de-interlace once, do it properly, re-encode as progressive and it's done for good" philosophy. :)

Now I've had another look with de-interlacing enabled I'll take back what I said about the DVD quality. The video sections look better on the bluray too. Less noise and artefacts etc.

PS Did you try my decoding and deinterlacing suggestion in the TIVTC thread? Even if you just use TDeint and none of the other filtering I'm curious to learn if it works for the whole video. I think the sample encode I uploaded looks better in general than the original DVD, although there's probably still some room for a slight improvement. I didn't experiment much with filter options.

[flossy_cake]

Interesting. The consensus has always been DVD video doesn't contain that sort of information. I don't think any encoding GUIs look for it. I'll check any DVDs I encode from now on.

You were right about this -- it must have been the ripping software that changed the aspect ratio for Garth Marenghi's Darkplace to 1.30:1 as I have the original DVD disc now and the dwpictAspectRatioX/Y is 4/3, 720x576 with active picture area 704x576.

[flossy_cake]

Well, on balance I think I prefer the bluray version.

Reconsidering this. It looks like BBC has upscaled for the BD in such a way that for static parts of the image, both fields are upscaled independently of eachother and then weaved back together. Ideally they should be weaved first before upscaling.

I've seen this artefact before - TV broadcasters sometimes use it in my area and it's bad cause it screws up the field alignment and gives a mice teeth effect on static unmoving parts of the image:

DVD
https://i3.lensdump.com/i/R43nVe.png

BD
https://i1.lensdump.com/i/R43eAa.png

Source images: DVD (https://i2.lensdump.com/i/R43Tn9.png), BD (https://i3.lensdump.com/i/R43RQo.png)

Both taken from remux sources & deinterlaced with BWDIF(field=-2, thr=2).

And yeah, the BD version *still* manages to look cleaner and subjectively "better". DVD version has too much compression artefacting imo.

edit: hmm, I'm wondering if it's possible to repair the BD with Avisynth... perhaps something like reverse deinterlacing where we pick out the 1920x540 fields and downscale them to back to 720x288, weave to 720x576, then deint.

edit: looks like it only affects S01E02, S01E03 & S02E03.

[flossy_cake]

edit: hmm, I'm wondering if it's possible to repair the BD with Avisynth... perhaps something like reverse deinterlacing where we pick out the 1920x540 fields and downscale them to back to 720x288, weave to 720x576, then deint.

edit: looks like it only affects S01E02, S01E03 & S02E03.

This seems to work


SeparateFields() # 1920x1080i25 -> 1920x540p50
LanczosResize(1920, 288) # 1920x540p50 -> 1920x288p50
Weave() # 1920x288p50 -> 1920x576i25
BWDIF(field=-2, thr=2) # 1920x576i25 -> 1920x576p50
Sharpen(0, 0.5) # compensate for softening caused by excess scaling
LanczosResize(1920, 1080) # aspect


The resulting image is smooth and gets rid of the mice teeth artefacts on the test scene, but still looks softer than the DVD on fine details like the wreath pattern on the floor.

Worse still is that many scenes in the same episode don't have the mice teeth artefacts and the above code ends up destroying the image quality on those scenes (effectively 288p on everything).

[Katie Boundary]

I am not sure why PSNR is showing that value or what it means exactly, but if I replace last line with Compare(A,A) I get the same result.

A PSNR value of ~107 means that there's no difference between the two video streams.

Reconsidering this. It looks like BBC has upscaled for the BD in such a way that for static parts of the image, both fields are upscaled independently of eachother and then weaved back together. Ideally they should be weaved first before upscaling.

I've seen this artefact before - TV broadcasters sometimes use it in my area and it's bad cause it screws up the field alignment and gives a mice teeth effect on static unmoving parts of the image:

Yeah, he DVD releases of Babylon 5 had the same issue as a result of cropping everything to 360i widescreen and then upscaling back to 480i. There are at least two threads on the subject if you're willing to hunt for them.

[flossy_cake]

Yeah, he DVD releases of Babylon 5 had the same issue as a result of cropping everything to 360i widescreen and then upscaling back to 480i. There are at least two threads on the subject if you're willing to hunt for them.

As someone who is recently getting into DVDs and could have easily accidentally purchased them instead of the Blurays, I'm glad I got the Blurays instead! But the HD resolution makes it look a bit more like "actors on a set" :rolleyes:

I was reading through your "in defence of bob" thread from 2016. I just wanted to comment that I think if it's bobbed from say 576i to 576p50 and then not scaled any more after that, then it should appear close to true 576p. The reason I think so is because the field alignment is preserved, and "persistence of vision" gives the effect of weaving the two fields when they are flashed rapidly at 20ms (this won't be visible in a static screenshot of a single bobbed frame). It's basically like it would appear on a CRT but with the black lines replaced with interpolated lines.

But, I think if we take the bobbed 576p50 and then scale it to something else like say 1080p50, the alignment of the fields inside the bobbed frames is not preserved anymore and I wouldn't really call it 576p. But I wouldn't call it 288p either. imo it's like somewhere in between.

[flossy_cake]

A lot of these late 90's early 00's shot on video camera TV series use this horrid technique where they shoot at 576i50 or 480i60 and then in post production use "drop field" to make it into 576p25 or 480p30 where field1 is a carbon copy (or thereabouts) of field2. Basically just copy pasting field1 into field2.

The problem with this isn't just that the vertical resolution is halved. It seems to create an additional problem where it can create deinterlacing artefacts, because if we interpolate field1 and interpolate field2, and show them consecutively, the whole frame will jump up and down by 1px because of them being identical images spaced 1px vertically apart. So if you're using Bob() then the whole frame will jump up and down much more severely than usual, and even mocomp deint like BWDIF(field=-2) or TDeint(mode=1) will jump up and down 1px on just the moving parts of the image only which is still a bit noticeable.