Deinterlacing advice

[hello_hello]

I think MP Pipeline lets you use 32 bit and 64 bit dlls in the same script by running them in different processes.
http://avisynth.nl/index.php/MP_Pipeline

[flossy_cake]

Originally Posted by hello_hello

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

I was looking into this and saw this comment mentioning Fawlty Towers was shot on these EMI 2001 cameras. Their spec sheet can be found here, but it doesn't mention aspect ratio, only that it uses the 625-line CCIR system (page 10). But the CCIR spec says the aspect is 4:3.

So the Blu-ray cover and camera spec are saying 4:3, however active pixel area is about 1.29:1, and this German release of the Bluray mentions 1.29:1 also.

What do you think -- does it look a little wide when stretched to 4:3? On some shots I think it does, but on others it doesn't really. I think the cameras might have some geometry distortion going on stretching it out at the edges, so when actors are in dead center of frame they look skinnier.

Considering the Bluray is a BBC release and BBC made the EMI 2001 camera, you'd think they would know what the aspect should be.

[flossy_cake]

Interesting also on page 10 of the CCIR spec it says the display gamma should be 2.8 -- perhaps this explains the more contrasty image of the Blu-ray release.

[flossy_cake]

Hybrid bwdif & nnedi3

BWDIF(field=-2, edeint=nnedi3(field=-2))

The result is interesting, but some interpolated textures are not quite right. For example a pattern of circles becomes more diamond shaped. But lines are much smoother and far less aliased so it's quite nice. And the great news is it's still blazingly fast for realtime use -- 100fps on 1080i.

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.

[flossy_cake]

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.

My attempt:

SeparateFields()  
f1 = SelectEven()   # lines 0,2,4...
f2 = SelectOdd()    # lines 1,3,5...

# I should now have f1=720x288p, f2=720x288p
# but f2's image sits 1px lower, so...

# ...shift f2 1px down 
f2shifted = PointResize(f2, f2.Width, f2.Height, 0.0, -1.0, f2.Width, f2.Height)

# upscale both fields to 720x576p.  Bob() says it uses BicubicResize too.
p1 = BicubicResize(f1, 720, 576)
p2 = BicubicResize(f2shifted, 720, 576)

# display them one after another
Interleave(p1, p2)

Test clip: https://drive.google.com/file/d/1WfW...usp=share_link

I have tried other shift values like 0.5 and 0.25 without getting close to Bob() image quality.

The wiki says that we can use Bob(0.0, 0.1) to preserve original field lines, but even at default values it is still far better image quality than my attempt.

[flossy_cake]

Huh, this works:

p1 = BilinearResize(f1, 720, 576)
p2 = BilinearResize(f2, 720, 576, 0.0, -0.5, 720, 288)
Interleave(p1, p2)

But this doesn't work:

f2shifted = BilinearResize(f2, 720, 288, 0.0, -0.5, 720, 288)
p1 = BilinearResize(f1, 720, 576)
p2 = BilinearResize(f2shifted, 720, 576)
Interleave(p1, p2)

I thought they would be logically equivalent?

edit: it appears the resize functions first perform the resize, then does the cropping/shifting. That would explain it if true. Somehow the value -0.5 applies to the unresized image dimensions, even though it is performed after the resize. So it is really like doing a -1.0 shift after resize.

edit2: can confirm the result is the same with:

p1 = BilinearResize(f1, 720, 576)
p2 = BilinearResize(f2, 720, 576)
p2 = BilinearResize(p2, 720, 576, 0.0, -1.0, 720, 576)
Interleave(p1, p2)

[flossy_cake]

Hmm, nearest-neighbour bob looks a lot better than I thought:

p1 = PointResize(f1, 720, 576)
p2 = PointResize(f2, 720, 576, 0.0, -0.5, 720, 288)
Interleave(p1, p2)

The converging lines pattern in the grey circle @ bottom left of frame is surprisingly resolved (I thought it would just be an aliased mess). It is crucial to display at 50hz though otherwise some bobbed frames will get held on screen longer than others and it ruins the field-combining effect.

[hello_hello]

Originally Posted by flossy_cake

What do you think -- does it look a little wide when stretched to 4:3? On some shots I think it does, but on others it doesn't really. I think the cameras might have some geometry distortion going on stretching it out at the edges, so when actors are in dead center of frame they look skinnier.

Considering the Bluray is a BBC release and BBC made the EMI 2001 camera, you'd think they would know what the aspect should be.

The ambiguity comes from converting the analogue video to digital.
I'm far from an expert on analogue (or digital for that matter) but whether it was from the ITU spec or industry practice or a bit of both, there's a standard for converting analogue to digital which I think involves the frequency at which a scanline is sampled and how much of it is sampled (there's a lot of non picture stuff each end), and that produces 720 pixels per scanline, and from there the pixel aspect ratio can be calculated (for PAL, analogue 4:3 is technically 702 or 703 pixels rather than 704, but that's often ignored).

Assuming the end result is a DAR of 1.3636, the problem arises when the digitised image is used for DVDs that maybe should be exactly 4:3, but without accounting for the difference in aspect ratio, which seems to be what mostly happens. And it would appear, which is disappointing, that even for the Bluray version the 1.3636 DAR was just assumed to be 4:3.

As far as I know, that should be the only discrepancy (1.3636 v 1.3333). Anything else would be some other DAR fudging in the production process, but there's no way to determine what that might be. If you think neither 1.3636 and 1.3333 are correct you are of course free to assume any DAR you like, but that's personal preference, I guess.

Even though the actual picture is only 1.29, I don't think it necessarily means it should be 4:3. I've seen lots of old analogue stuff with a similar DAR, so maybe the 4:3 "picture area" takes over-scan into account. I don't know.

Ah.... while looking to see if BBC had some sort of standard for over-scan, I found this:
BBC Technical Standards for Network Television Delivery

4.1.5 AspectRatio
Active picture width is 52us/702 pixels. All aspect ratio calculations are based on this. Any processes based on 720 pixel width may introduce unwanted geometry or safe area errors.

I may have posted it before, but there's lots of good info here in PARs: https://lurkertech.com/lg/pixelaspect/
And from a discussion at VideoHelp, some info on the 702 pixel width for PAL and an explanation as to why square pixels aren't always square.
https://forum.videohelp.com/threads/...AL#post2646932

[flossy_cake]

Originally Posted by hello_hello

The ambiguity comes from converting the analogue video to digital

I was hoping to avoid all that and just look at what aspect the camera captured and target that. As long as no pixels were cropped in the Bluray mastering process, it shouldn't matter if it was distorted as long as all the pixels are there we can stretch it back to whatever aspect the camera captured.

All of this under the assumption the camera really was adhering to the spec and producing a true 4:3 active picture area, which now that I think about it is probably a very bad assumption

[flossy_cake]

Originally Posted by hello_hello

As far as I know, that should be the only discrepancy (1.3636 v 1.3333). Anything else would be some other DAR fudging in the production process, but there's no way to determine what that might be. If you think neither 1.3636 and 1.3333 are correct you are of course free to assume any DAR you like, but that's personal preference, I guess.

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. It doesn't look distorted to me, but I compared it with the Amazon streaming version and that is 640x480 square pixels 1.33:1 and has the same geometry as DVD within the active pixel area, but the active pixel area is 0.03 wider (showing slightly more visible area of the set off to the sides).

Also DVD Mad About You 720x576 1.33:1 in the MPEG headers but active pixel area is 704x576, plus actor's faces look a little stretched! Figure that one out

[hello_hello]

Originally Posted by flossy_cake

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]

Originally Posted by hello_hello

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



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/pr...deoinfoheader2

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]

Originally Posted by 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]

Originally Posted by hello_hello

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

Originally Posted by hello_hello

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]

Originally Posted by flossy_cake

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]

Originally Posted by flossy_cake

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.

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]

Originally Posted by Katie Boundary

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, clip2. 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 is sharper and higher resolution than the top field, 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]

Originally Posted by flossy_cake

Why 0.25? Personal preference?

Because it's the mathematically correct amount.

Originally Posted by flossy_cake

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.

Originally Posted by flossy_cake

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.