Deinterlacing advice

[flossy_cake]

Hello, I am interested in deinterlacing the Bluray release of classic comedy show Fawlty Towers. The Bluray is 1080i at mostly 1:1 cadence for the indoor shots, and rarely has some outdoor shots at 2:2.

My goal is to convert it to 1080p50 files, preserving the full framerate of the 1:1 cadence sections. I am not bothered if the 2:2 cadence sections aren't weaved to true 1080p frames since they are rare.

In researching I came across this ranking site for deinterlacers: https://videoprocessing.ai/benchmarks/deinterlacer.html

Highlighted in red are the ones with seemingly acceptable frame rates, otherwise it seems I would have to leave my PC on for several days at 100% CPU load which is not practical for me.

https://i2.lensdump.com/i/1Mvzbc.png

So far these are my findings of the deinterlacers highlighted in red:

Bob
I didn't find this acceptable since it is too flickery and wastes vertical resolution. It does preserve the full framerate of 1:1 cadence though, so I would still prefer it to any half framerate deinterlacer.

Vapoursynth EEDI3, Vapoursynth TDeintMod
I haven't tried these as I'm not familiar with Vapoursynth yet. Can I use them through ffmpeg? I'm new to all this and my understanding is limited.

Weston 3-field, Yadif, Bob-weave
I was able to test these as they are included with ffmpeg.

Weston 3-field: seems to be identical to bob? I can't see a significant improvement vs bob. I'm not sure if this is due to incorrect implementation in ffmpeg as there are articles saying it was developed by a BBC engineer so it really should be better than bob.

Yadif: seems decent but fails to resolve high contrast 1px patterns in vertical direction, and has some wrong colour pixels on certain patterns. It is also very old.

Bob-weave: seems decent. Resolves high contrast 1px vertical patterns albeit with some random flickering/glitches. But apart from that it seems to fit the bill.

.zip file with some short video clips comparing the above 3
https://drive.google.com/file/d/1aL_8kyOLhhfgNz9_w4swoEgOulbU7e6I/view?usp=sharing

_____________________________________________________

Before I commit to using ffmpeg's bob-weave deinterlacer, are there any others that might suit my requirements?

For example, my Nvidia GPU has its own DXVA2 deinterlacing which is ok -- is it possible to somehow use that deinterlacer during the transcoding process?

Thanks

[Emulgator]

QTGMC ?
But thanks for the MSU comparison, MFDIN-L seems the way to go if AI can be used.
Open Source Soon it says.

[Katie Boundary]

Fawly Towers was made in the freaking SEVENTIES, dude. 1080i didn't exist back then. Who the hell authored those Blu-Rays?

Actually, it doesn't matter. Shows were shot and edited 100% on film back then so there's little to no chance of any orphaned fields. Just run it through tfm(mode=0,pp=0,slow=2,mchroma=false,micmatching=0) in AVIsynth and you should be good to go.

[hello_hello]

I'd be interested to see a sample of the Bluray version of Faulty Towers. The DVD version isn't great quality, but if it's been interpolated to 1080i from PAL it might be hard to de-interlace and require a better/slower de-interlacer.

QTGMC would require a crash course in Avisynth (or VapourSynth) and it is slow, but there's a fair difference compared to the samples you uploaded.

Avisynth script:

DGDecode_mpeg2source("D:\1 - original interlaced.d2v")
QTGMC()

QTGMC 1.mkv (https://files.videohelp.com/u/210984/QTGMC%201.mkv)

The test pattern thingy at the beginning and end isn't exactly a real-world example of interlaced video, but because there's no movement, in a perfect world you'd treat it as progressive and just duplicate each frame.

DGDecode_mpeg2source("D:\1 - original interlaced.d2v")
Trim(0, 81).ChangeFPS(50) ++ \
Trim(82, 647).QTGMC() ++ \
Trim(648, 0).ChangeFPS(50)

QTGMC 2.mkv (https://files.videohelp.com/u/210984/QTGMC%202.mkv)

[flossy_cake]

I'd be interested to see a sample of the Bluray version of Faulty Towers.

Here is a transition from outdoor 2:2 to indoor 1:1
https://drive.google.com/file/d/1k8Mor-gd6hN1hDE1WumzqhCCxfBFFn0e/view?usp=sharing

Thank you for the QTGMC sample, it looks really good. I'm not sure why it's bobbing the 1px pattern -- most deinterlacers on TV's and PVRs weave that section, but they have a lot more aliasing on moving parts of image.

Fawly Towers was made in the freaking SEVENTIES, dude. 1080i didn't exist back then. Who the hell authored those Blu-Rays?

Actually, it doesn't matter. Shows were shot and edited 100% on film back then so there's little to no chance of any orphaned fields. Just run it through tfm(mode=0,pp=0,slow=2,mchroma=false,micmatching=0) in AVIsynth and you should be good to go.

The indoor scenes were shot on 1970s video cameras at interlaced 1:1 cadence, the outdoor scenes look like film 2:2 cadence.

They still shouldn't have authored it at 1080i as scaling from interlaced to interlaced requires deinterlacing otherwise you get mice teeth. So they should have authored it at 1080p50 and avoided a second round of deinterlacing at the user's end. Maybe they used 1080i for compatibility reasons I don't know.

[flossy_cake]

The test pattern thingy at the beginning and end isn't exactly a real-world example of interlaced video, but because there's no movement, in a perfect world you'd treat it as progressive and just duplicate each frame.

I'd really like to get into writing my own deinterlacer as I have all these ideas in my head which I'd like to try out and see if they're any good in practice.

One idea was to simply weave fields and compare that frame with previous 1 or 2 frames and if the pixels are the same (or similar within some threshold) then there was no change in those pixels and they can stay weaved. By this rule the 1px pattern should get weaved. BWDIF has some random flickering on the 1px pattern -- perhaps its algorithm sees some slight change in those pixels, maybe just compression noise?

I'd also like to have cadence detection working in the background to detect the overall cadence, and if it detects 2:2 it switches to weaving full frames.

But then there is the difficulty of handling a scene with mixed cadences. In that case all I can think of is to just treat it as 1:1 cadence probably. Unless maybe I could split the raster up into zones and perform cadence detection within each zone. But I'm not good enough with code and math/geometry to know how to implement something like this.

[flossy_cake]

Sorry to ramble on a bit, but I've got another issue I'm working on which is kind of related to deinterlacing.

I've come across some TV shows that were shot at 24p, then interlaced to 30i (3:2 cadence, aka "hard telecine", aka "24p as 60i"). Then this 30i was deinterlaced to 30p at half framerate. The problem is that it ends up as something like a 1:1:1:2 cadence. The interesting part is that the 24p frames still exist inside the 30p stream, so in theory it is possible to pull them back out again and create a true 24p stream from it. Has anyone ever made a script that can do something like this? I've seen there is a function called decimate() -- should I look at trying to use that or will I run into issues?

edit: clip https://drive.google.com/file/d/1t03cFuPWvaqUqTm3wcqmEP1RVgPk8_1Q/view?usp=sharing

edit: oh wow it seems MadVR can do this in realtime by tagging the file with [deint=film]. In its debug screen (ctrl+j) it reports that it detected a 4:2:2:2 cadence in the above clip. Result is true 24p @ 1:1 cadence outputting as 24hz over HDMI -- amazing. edit: but it only seems to work if HDMI is outputting 24hz. With 60hz output it's still displayed as 1:1:1:2 (or 4:2:2:2 as MadVR calls it) even though stepping through each frame with ctrl+arrows shows a 1:1 cadence. edit: after further scrutiny @ 24hz output, the cadence detection is not getting it quite right after certain scene changes where it may stutter for a bit before correcting itself so it's not quite a solution unfortunately. Whatever the solution, I think it would need a very high quality cadence detection (with "bad edit" detection or whatever it's called when the cadence changes on a scene splice) and perhaps end up as a 60p stream to hide them well enough to not cause big stutters.

[hello_hello]

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

By the way, the DVD encode was actually resized to 640x480 after cropping and de-interlacing, and resized to full-screen for the screenshot. The Bluray version definitely looks better but based on the amount of detail you're not going to lose anything by resizing down to 720p. Anyway....

Here's a couple of sample encodes for you. To help you possibly be indecisive, I stretched the Bluray to match my DVD encode (you can decide if it's correct) and cropped a few pixels top and bottom for exactly 4:3, because I'm OCD about 4:3 being the minimum aspect ratio. That's just me though....

Based on that sample BWDIF seems to do a pretty good job. There's a tad less shimmering with QTGMC but whether that's worth the speed reduction is up to you. Probably not.

FFVideoSource("D:\ft.mkv", cachefile="D:\ft.mkv.ffindex")
Crop(266,0,-266,0)
Trim(0,152).ChangeFPS(50) ++ \
Trim(153,0).BWDIF(field=-2).AssumeFPS(50)
CropResize(1440,1080, 0,0,-2,0, InDAR=1419.55/1080.0)

ft BWDIF.mkv (https://files.videohelp.com/u/210984/ft%20BWDIF.mkv)

FFVideoSource("D:\ft.mkv", cachefile="D:\ft.mkv.ffindex")
Crop(266,0,-266,0)
Trim(0,152).ChangeFPS(50) ++ \
Trim(153,0).QTGMC().AssumeFPS(50)
CropResize(1440,1080, 0,0,-2,0, InDAR=1419.55/1080.0)

ft QTGMC.mkv (https://files.videohelp.com/u/210984/ft%20QTGMC.mkv)

I'll have to dig out the original DVDs at some stage to make sure I didn't do anything odd to the aspect ratio.

Edit: I just noticed the very first frame in the video section is combed in both samples (check her left foot). That was my fault. The Trims in the script were off by a frame. It should've been:

FFVideoSource("D:\ft.mkv", cachefile="D:\ft.mkv.ffindex")
Crop(266,0,-266,0)
Trim(0,151).ChangeFPS(50) ++ \
Trim(152,0).QTGMC().AssumeFPS(50)
CropResize(1440,1080, 0,0,-2,0, InDAR=1419.55/1080.0)

[hello_hello]

Sorry to ramble on a bit, but I've got another issue I'm working on which is kind of related to deinterlacing.

I've come across some TV shows that were shot at 24p, then interlaced to 30i (3:2 cadence, aka "hard telecine", aka "24p as 60i"). Then this 30i was deinterlaced to 30p at half framerate. The problem is that it ends up as something like a 1:1:1:2 cadence. The interesting part is that the 24p frames still exist inside the 30p stream, so in theory it is possible to pull them back out again and create a true 24p stream from it. Has anyone ever made a script that can do something like this? I've seen there is a function called decimate() -- should I look at trying to use that or will I run into issues?

edit: clip https://drive.google.com/file/d/1t03cFuPWvaqUqTm3wcqmEP1RVgPk8_1Q/view?usp=sharing

edit: oh wow it seems MadVR can do this in realtime by tagging the file with [deint=film]. In its debug screen (ctrl+j) it reports that it detected a 4:2:2:2 cadence in the above clip. Result is true 24p @ 1:1 cadence outputting as 24hz over HDMI -- amazing. edit: but it only seems to work if HDMI is outputting 24hz. With 60hz output it's still displayed as 1:1:1:2 (or 4:2:2:2 as MadVR calls it) even though stepping through each frame with ctrl+arrows shows a 1:1 cadence. edit: after further scrutiny @ 24hz output, the cadence detection is not getting it quite right after certain scene changes where it may stutter for a bit before correcting itself so it's not quite a solution unfortunately. Whatever the solution, I think it would need a very high quality cadence detection (with "bad edit" detection or whatever it's called when the cadence changes on a scene splice) and perhaps end up as a 60p stream to hide them well enough to not cause big stutters.

3:2 pulldown (https://en.wikipedia.org/wiki/Three-two_pull_down) duplicates two fields every eight, so eight fields are spread out over ten fields. The field matching part of inverse telecine usually throws one of the duplicate fields away while the other duplicates are both matched. The end result is 5 progressive frames, one of which is a duplicate. When it's removed you're back to 24p. For the TIVTC Avisynth plugin, TFM does the field matching and/or de-interlacing, and TDecimate removes the duplicates. It can also convert interlaced sections to 24p, or 24p sections to 30p. It also has a 2 pass mode for variable frame rate encoding.

For typical NTSC inverse telecine the defaults usually work fine, so all you need in a script is

TFM()
TDecimate()

If the field matching is already done and there's a duplicate frame in every five, then you only need

TDecimate()

Decimate() does the same thing.

[hello_hello]

I'd really like to get into writing my own deinterlacer as I have all these ideas in my head which I'd like to try out and see if they're any good in practice.

One idea was to simply weave fields and compare that frame with previous 1 or 2 frames and if the pixels are the same (or similar within some threshold) then there was no change in those pixels and they can stay weaved. By this rule the 1px pattern should get weaved. BWDIF has some random flickering on the 1px pattern -- perhaps its algorithm sees some slight change in those pixels, maybe just compression noise?

I'd also like to have cadence detection working in the background to detect the overall cadence, and if it detects 2:2 it switches to weaving full frames.

But then there is the difficulty of handling a scene with mixed cadences. In that case all I can think of is to just treat it as 1:1 cadence probably. Unless maybe I could split the raster up into zones and perform cadence detection within each zone. But I'm not good enough with code and math/geometry to know how to implement something like this.

For de-interlacing to double frame rate (50p for PAL) bob de-interlacers usually extract each field, which is every second scan line, then interpolate the missing scan lines for a full frame. So 50i becomes 50p.
For that 1x pattern, every second scan line is black and the others are white, so the black scan lines are interpolated to a full frame by creating additional black scan lines, and the white scan lines are interpolated with additional white scan lines. The result is one frame of pure black and the next is pure white and so on... As the black and white scan lines are offset for each half, they alternate black and white.
That's definitely not a real world de-interlacing job though, but how BWDIF avoids it in double frame rate mode I don't know. Hopefully someone who does will come along.

When de-interlacing to the original frame rate, some de-interlacers weave the fields and check for combing, and only repair the pixels where combing is found. For TFM(), which can field match and de-interlace, the default is to check for combed pixels and only repair those. The rest are left alone. You can even take the pixels to be used to repair combing from an externally de-interlaced clip if you wish. An Avisynth script could look something like this:

Some Telecined Or Interlaced Video
A = last
B = A.QTGMC(FPSDivisor=2)
C = A.TFM(Clip2=B)
return C

[poisondeathray]

An alternative to BWDIF is Tdeint as motion adaptive deinterlacer to weave progressive content sections . You can use edeint with a 2nd clip for the replacement pixels for either BWDIF or TDeint, such as QTGMC or NNEDI3, which will produce better results on the interlaced content sections, but slower. But it should be faster than pure QTGMC

The BW in BWDIF stands for Bob Weaver (so it weaves static content,in theory, similar to TDeint) - but you can see the distortions and glitches mentioned in the OP in that patterns when using BWDIF, or the text in the clip section. TDeint is much cleaner on that test pattern and diagonals (such as the eyeglasses) on the actual clip in terms of aliasing artifacts

tdeint(order=1, mode=1, edeint=nnedi3(field=3))
prefetch(something)

This will produce good results on a test pattern, but it will usually produce worse results on typical interlaced content compared to full QTGMC in terms of aliasing and flicker artifacts. On the other hand, the weaved progressive sections will have full resolution compared to QTGMC. Distributed interlaced content is usually low passed in a dumb manner (even static sections which shouldn't be low passed), so you often never have 1 pixel vertical resolution content. But TDeint is a good alternative, if you have full resolution progressive sections, where you don't want QTGMC smoothing details too much

The other option is VFR, where progressive sections are weaved and decimated, and interlaced sections are deinterlaced, everything runs at it's native content framerate. (25p at 25p, 29.97p at 29.97, 50p at 50p etc...) . I think ctools can do this, but I havent tested it fully yet. The original TIVTC VFR had issues with 50p/59.94p timecodes

[flossy_cake]

Thanks for the explanations and all the helpful code snippets, much appreciated.

And yes I did notice the squished aspect in Fawlty Towers! Also had a similar issue with the Family Guy DVD where some episodes are stretched to 1.36:1 and the character faces look a bit wide. The solution I'm currently using is to tag those files with [profile='aspect 1.36 to 1.33'] which tells MadVR to squish it back to 1.33. This way I don't have to re-encode anything, although MPC-HC does support opening .avs files and applying them in real time which is fantastic -- I'll try using TDecimate() on that Oz clip if I can get it working (currently it's giving me an error message saying Decimate function not found... probably need to update my Avisynth & dependencies).

For Fawlty Towers I measured a screenshot in Photoshop which came out to 1386x1080 of "active" pixels. 4:3 would be 1440x1080, so under the assumption the active pixels are meant to cover a 4:3 area, the MadVR "stretch factor" would be 1386/1440.

But of course this calculation could be wrong as I don't know the relationship between active pixels and the intended DAR with that 1970's equipment, eg. there could be some intentional "blanking" down the sides. But looking at it subjectively, the actor's faces look subjectively "better" to my eyes with the 1386/1440 correction. Although hello_hello matched it to the DVD with a correction factor of 1419.55/1440 so maybe that is the correct one. Interlace & non-square pixels -- what a disaster :)

[flossy_cake]

I'll try using TDecimate() on that Oz clip if I can get it working (currently it's giving me an error message saying Decimate function not found... probably need to update my Avisynth & dependencies).

Got it working!

But now I have a new problem :)

The show also contains some sections at true 30p 1:1 cadence, and TDecimate is now causing those sections to become stuttery.

I tried adding ChangeFPS(60) before/after the TDecimate() which according to MadVR's ctrl+j debug screen really did create a 60fps stream, but for some reason the 30fps 1:1 sections are stuttery. I would have thought TDecimate would have seen that there were no duplicates in that section and left them alone?

Clip: https://drive.google.com/file/d/10pqePJ3oYjwDmKES233k7Il61sufzIy-/view?usp=sharing

The first 8 seconds are 1:1:1:2, followed by 5 seconds of 1:1. If you are using MPC-HC you can step through each frame with ctrl+arrows to count the cadence manually.

[flossy_cake]

The show also contains some sections at true 30p 1:1 cadence, and TDecimate is now causing those sections to become stuttery.


It seems I have 2 options:

Option 1. Use TDecimate(hybrid=1) to "blend decimation of 30p sections into 24p and leave 24p untouched (http://avisynth.nl/index.php/TIVTC/TDecimate)". In practice this doesn't seem to work as I'm not observing any blended frames in the 30p section (cop walking up the stairs). Maybe I need to play with some other params like vidThresh.

Option 2. Try to somehow convert it to 60p so that the 24p sections end up at 3:2 and 30p sections at 2:2. This would be my preferred option but I can't get it to work for the 2:2 sections, only the 3:2 sections. I'm sure this is possible to achieve it's just a matter of finding the right settings.


edit: managed to force Option1 to work with a manual override to tell TDecimate the frames with the cop walking up the stairs to treat as video and blend to 24p:

TDecimate(mode=0,cycle=5,cycleR=1,hybrid=1,ovr="override.txt",display=true)

contents of override.txt:
275,417 v


It works and I can see the blending, but I'm not satisfied with the way it looks (too blurry). So my goal will be Option2.

[poisondeathray]

Option 2. Try to somehow convert it to 60p so that the 24p sections end up at 3:2 and 30p sections at 2:2. This would be my preferred option but I can't get it to work for the 2:2 sections, only the 3:2 sections. I'm sure this is possible to achieve it's just a matter of finding the right settings.


TFM().ChangeFPS(60000,1001)

This is encoded progressively, so you don't even need TFM(). Just ChangeFPS

But the duplicates in "1-1-1-2 to 1-1.mkv" are not "true" duplicates in the source 1st section - they are sort of blended encoding artifacts, eitherway you're just duplicating frames with ChangeFPS



It seems I have 2 options:


Option 3 is VFR. TIVTC 2pass VFR (TDecimate mode 4+5). Everything runs at their content frame rate, no "physical" duplicates (if you run a 60Hz display, your display will be adding effective duplicates), timestamps(timecodes) keep everything in sync

[flossy_cake]

TFM().ChangeFPS(60000,1001)
This is encoded progressively, so you don't even need TFM(). Just ChangeFPS


It's not working for me -- the 1:1:1:2 sections are just ending up as 2:2:2:4 @ 60hz. I'm checking this by manually stepping through each frame with ctrl+arrows.

And yes, it isn't quite perfect 1:1:1:2 as there is a very slight diff between the "2" frames at the end of the cycle, but I think that's just an encoder artefact based on 1:1:1 leading up to it.

[flossy_cake]

Option 3 is VFR. TIVTC 2pass VFR (TDecimate mode 4+5). Everything runs at their content frame rate, no "physical" duplicates (if you run a 60Hz display, your display will be adding effective duplicates), timestamps(timecodes) keep everything in sync

Yes I saw that and it seems ideal, but the problem is that TDecimate can't seem to detect the cop walking up the stairs is 1:1 and fails to identify it as "video" so that section will still be VFR'd to 24p and look stuttery.

Debug output is showing that it identified duplicate frames in that stairs sequence . I tried that denoise filter and playing with the vid thresh parameter without success. There must be some settings I'm not getting right.

[poisondeathray]

It's not working for me -- the 1:1:1:2 sections are just ending up as 2:2:2:4 @ 60hz. I'm checking this by manually stepping through each frame with ctrl+arrows.

You're right, my bad

Yes I saw that and it seems ideal, but the problem is that TDecimate can't seem to detect the cop walking up the stairs is 1:1 and fails to identify it as "video" so that section will still be VFR'd to 24p and look stuttery.

Debug output is showing that it identified duplicate frames in that stairs sequence . I tried that denoise filter and playing with the vid thresh parameter without success. There must be some settings I'm not getting right.

The other option is dedup. You can use show=true, dec=false to debug it. You need about a threshold of 1.5 on this clip. I'd use decwhich=0, because the 1st frame is the higher quality duplicate, the other is more blended on this clip. Personally, I like dedup better for VFR, because it can handle non standard cadences and framerates

[flossy_cake]

The other option is dedup. You can use show=true, dec=false to debug it. You need about a threshold of 1.5 on this clip. I'd use decwhich=0, because the 1st frame is the higher quality duplicate, the other is more blended on this clip. Personally, I like dedup better for VFR, because it can handle non standard cadences and framerates

Cheers, I gave it a try and got it to remove frames but either it caused the video to speed up or just replaced the "bad" duplicate with a copy of the "good" dup without changing the cadence.

With TDecimate I am able to convert it to a 60p stream containing 30p @ 2:2 and 24p @ 3:3:2:2 (https://en.wikipedia.org/wiki/Three-two_pull_down#Modern_alternatives) like so:


ChangeFPS(120000,1001)
TDecimate(mode=1,hybrid=0,cycle=4,cycleR=2,vidThresh=1.1,display=true)


The result is "ok". Certainly better than 1:1:1:2 @ 30fps but not quite as smooth as 3:2 @ 60fps. Still dissatisfied & I'm trying to add a second pass of TDecimate to smooth the 3:3:2:2 section without affecting the 2:2 section.

[hello_hello]

Thanks for the explanations and all the helpful code snippets, much appreciated.

And yes I did notice the squished aspect in Fawlty Towers! Also had a similar issue with the Family Guy DVD where some episodes are stretched to 1.36:1 and the character faces look a bit wide. The solution I'm currently using is to tag those files with [profile='aspect 1.36 to 1.33'] which tells MadVR to squish it back to 1.33. This way I don't have to re-encode anything, although MPC-HC does support opening .avs files and applying them in real time which is fantastic.

With a video open in MPC-HC, one tap of the 6 key on the numeric keypad stretches the video by pretty much the same amount as the difference between 1.33 and 1.36. The 4 key does the same in the other direction. The 5 key always resets it.

For Fawlty Towers I measured a screenshot in Photoshop which came out to 1386x1080 of "active" pixels. 4:3 would be 1440x1080, so under the assumption the active pixels are meant to cover a 4:3 area, the MadVR "stretch factor" would be 1386/1440.

I went with the assumption the difference was the same as the difference between a generic and ITU/mpeg4 aspect ratio for DVDs and it seemed to work out that way. So....

(15/11) / (4/3) = 1.0227

Assuming you cropped 272 pixels each side that leaves you with 1376 x 1080 and a display aspect ratio of
1376 x 1.0227 / 1080 or 1407.27 / 1080.
That's only 1.30303 so if you want 4:3 you need to crop a bit top and bottom. The DVDs were exactly the same (they needed some extra height cropping for 4:3). The DAR of 1419.55/1080.0 I used earlier was calculated the same way, but based on different cropping.

Assuming that stretch is correct and always the same though, it means the Bluray would have a pixel/sample aspect ratio of 45:44 (1.0227) which you can use for each episode regardless of the cropping. No need to calculate a new DAR if the cropping changes. I'm not sure why I didn't just do it that way in the first place.

Using my CropResize (https://forum.doom9.org/showthread.php?t=176667) function....
By default if you don't specify an output DAR it'll resize to square pixels, and if you specify both an output width and height it'll crop what it needs to so as not to distort the picture. If you only specify a width or height it'll resize the other accordingly.

With 4:3 output dimensions and the above cropping the script needs to crop 12.273 pixels top and bottom for 4:3, but of course a 4:3 output is your choice.

Normally I'd do all the cropping with CropResize but in this case you don't need to be de-interlacing all that black. You can always add it back later if you want to. Info=true displays detailed information on what the script is doing.

Crop(272,0,-272,0)
CropResize(1440,1080, InSAR=45.0/44.0, Info=true)
https://i.ibb.co/pwrK0BQ/1.png

Crop(272,0,-272,0)
CropResize(0,1080, InSAR=45.0/44.0, Info=true)
https://i.ibb.co/hHDxn3g/2.png

Crop(272,0,-272,0)
CropResize(1920,1080, CropDAR=4.0/3.0, InSAR=45.0/44.0, Borders=true, Info=true)
https://i.ibb.co/nnV0phg/3.png

Crop(272,0,-272,0)
CropResize(1920,1080, InSAR=45.0/44.0, Borders=true, Info=true)
https://i.ibb.co/1QFwCFD/4.png

So that's probably how I'd stretch it, based on your sample.


Edit: I forgot to mention that the script also has an option to prevent any height resizing, although it'll probably change the width cropping a little.

Crop(272,0,-272,0)
CropResize(InSAR=45.0/44.0, ResizeWO=true, Info=true)
https://i.ibb.co/7tWm9nt/5.png

or you can still aim for something close to 4:3
Crop(272,0,-272,0)
CropResize(InSAR=45.0/44.0, CropDAR=4.0/3.0, ResizeWO=true, Info=true)
https://i.ibb.co/L6W0W6Z/6.png

or add borders
Crop(272,0,-272,0)
CropResize(1920, InSAR=45.0/44.0, ResizeWO=true, Borders=true, Info=true)
https://i.ibb.co/4gnB9Rc/7.png

[poisondeathray]

With TDecimate I am able to convert it to a 60p stream containing 30p @ 2:2 and 24p @ 3:3:2:2 (https://en.wikipedia.org/wiki/Three-two_pull_down#Modern_alternatives) like so:


ChangeFPS(120000,1001)
TDecimate(mode=1,hybrid=0,cycle=4,cycleR=2,vidThresh=1.1,display=true)


The result is "ok". Certainly better than 1:1:1:2 @ 30fps but not quite as smooth as 3:2 @ 60fps. Still dissatisfied & I'm trying to add a second pass of TDecimate to smooth the 3:3:2:2 section without affecting the 2:2 section.




If the primary concern is "smoothness", how about retiming using optical flow or equivalent for interpolation of "in between" frames?

RIFE is in avisynth now ( not just vapoursynth) and it tends to do a cleaner, better job than mvtools2 on most content.

a) retiming the 1st part to 29.97p ? Smooth, no judder.

b) Or if you don't like the 29.97 "look", retime 29.97p stairs section to 23.976p ? ie. leave the entire thing at 3:2 to keep the judder consistent like a normal film

c) or the 59.94 "soap opera" look ?

rife@29.97
https://www.mediafire.com/file/mgy529quy6t3x67/rife_29.97.mkv/file

rife@23.976
https://www.mediafire.com/file/33qpj0m90g9zf3x/rife_23.976.mkv/file

rife@59.94
https://www.mediafire.com/file/hfgt72lxk05vtxc/rife_59.94.mkv/file

Rife 4+ models allow for arbitrary framerates, but <4 can only produce powers of 2 (so you have to call them multiple times and selectevery, or use other interpolation at 2nd step) . The best model overall is 2.3 or 2.4 on most content, but models 4+ are faster and are easier to use because of the fpsnum / fpsden . Interpolation is not perfect, there can be artifacts, and you have to manually identify the sections with trim()

[Katie Boundary]

The indoor scenes were shot on 1970s video cameras

Jesus, the first season was made in literally the same year in which the first Betamax devices were released in Japan. How cutting-edge they must have thought they were being :D

I think any reasonable solution to this issue would require ripping the episodes from DVD, not Blu-Ray.

[hello_hello]

Jesus, the first season was made in literally the same year in which the first Betamax devices were released in Japan. How cutting-edge they must have thought they were being :D

Video tape has been used since the late 50's.
https://en.wikipedia.org/wiki/Videotape#Broadcast_video

I think any reasonable solution to this issue would require ripping the episodes from DVD, not Blu-Ray.

The Bluray version looks better.

[flossy_cake]

I went with the assumption the difference was the same as the difference between a generic and ITU/mpeg4 aspect ratio for DVDs and it seemed to work out that way. So....

(15/11) / (4/3) = 1.0227



I recognise that number -- it's also the diff between 704 and 720 width: 704 * 1.0227 = 720. Could be a coincidence though, I don't really know.

[flossy_cake]

If the primary concern is "smoothness", how about retiming using optical flow or equivalent for interpolation of "in between" frames?

RIFE is in avisynth now ( not just vapoursynth) and it tends to do a cleaner, better job than mvtools2 on most content.

a) retiming the 1st part to 29.97p ? Smooth, no judder.

b) Or if you don't like the 29.97 "look", retime 29.97p stairs section to 23.976p ? ie. leave the entire thing at 3:2 to keep the judder consistent like a normal film

c) or the 59.94 "soap opera" look ?

rife@29.97
https://www.mediafire.com/file/mgy529quy6t3x67/rife_29.97.mkv/file

rife@23.976
https://www.mediafire.com/file/33qpj0m90g9zf3x/rife_23.976.mkv/file

rife@59.94
https://www.mediafire.com/file/hfgt72lxk05vtxc/rife_59.94.mkv/file



That's awesome, I can't even see any blended frames. The question is, can it be done in realtime, i.e opening .avs file directly in MPC-HC? If not, then I'd have to transcode which means generation loss. But maybe it's worth it.

It's really weird with that show Oz cause they always switched to 30fps for locations whenever there are CRT monitors in the scene. I figured it's something to do with syncing to the 60hz of the CRTs for anti flicker reasons. I seem to recall the TV broadcast versions were full framerate 1:1 interlaced cadence for those sections, but it was a long time ago.

[flossy_cake]

Rife 4+ models allow for arbitrary framerates, but <4 can only produce powers of 2 (so you have to call them multiple times and selectevery, or use other interpolation at 2nd step) . The best model overall is 2.3 or 2.4 on most content, but models 4+ are faster and are easier to use because of the fpsnum / fpsden . Interpolation is not perfect, there can be artifacts, and you have to manually identify the sections with trim()

Just reading through the docs now... which model did you use for the 23.976 one and did you have to manually identify the scene change with trim()?

[flossy_cake]

The Bluray version looks better.

It's a bit contentious actually! On other forums some are saying the "remastered DVD" is still better as it doesn't have DNR and sharpening of the BD version (plus the aspect isn't squished, but they didn't notice that).

Personally I am satisfied with the BD version but only because we can unsquish the aspect. If all I had was a BD player without fine-tuning of the aspect then I probably wouldn't find it acceptable.

Is your DVD the original or remastered?

[poisondeathray]

That's awesome, I can't even see any blended frames. The question is, can it be done in realtime, i.e opening .avs file directly in MPC-HC? If not, then I'd have to transcode which means generation loss. But maybe it's worth it.



Unlikely in realtime, especially not with the vulkan avs version. The cuda version in vapoursynth is significantly faster if you have a Nvidia card

You can try FrameRateConverter with mvtools2 as well - that might be able to do realtime with multithreading enabled on a decent system. Many settings and has built in artifact masking, and blend fallback when artifacts are severe. Pure flow output can be called with output="flow"



Just reading through the docs now... which model did you use for the 23.976 one and did you have to manually identify the scene change with trim()?


Yes, you have to manually identify sections and use Trim() for differential filtering. I don't know of a way to automate that

For the 23.976 version, the 1st part used TDecimate , 2nd part used model=9


o=LWLibavVideoSource("1-1-1-2 to 1-1.mkv")

a=o.trim(0,274).tdecimate()

o.trim(275,0)
z_ConvertFormat(pixel_type="RGBPS", resample_filter="bicubic", colorspace_op="709:709:709:l=>rgb:709:709:f")
rife(model=9, fps_num=24000, fps_den=1001)
z_ConvertFormat(pixel_type="YV12", resample_filter="bicubic", colorspace_op="rgb:709:709:f=>709:709:709:l")
b=last

a+b


I used model=9 so rife-v4, because it was easier with fpsnum/fpsden. Otherwise you have to apply rife twice, then downsample every 5th. e.g. 29.97 x4 => 119.88 , then selectevery(5) for every 5th frame, so they are evenly spaced in time. There are newer models in one of the vapoursynth versions, but they haven't been transferred over yet. Each model is slightly different and may produce better/worse results in some frames

You can try FrameRateConverter with mvtools2 as well - that should be able to do realtime with multithreading enabled on a decent system. Many settings and has built in artifact masking. Pure flow output can be called with output="flow"

[flossy_cake]

Thanks, I think I would prefer a decimate-based solution then.

I did manage to get Rife working and yeah it's definitely not real time -- I'm getting around 2-3 fps at 100% GPU load on old R9 380.


rife.avs:
DirectShowSource("1-1-1-2 to 1-1.mkv")
z_ConvertFormat(pixel_type="RGBPS", colorspace_op="709:709:709:limited=>rgb:709:709:full")
RIFE(model=9,fps_num=24000,fps_den=1001)

ffmpeg -i rife.avs -c:v libx264 -preset medium -b:v 4000000 -pix_fmt yuv420p10le -profile:v high10 -r 59.940 -c:a copy result.mkv


Result: https://drive.google.com/file/d/16Og64-DGzNKVipXr_V8nMZhmPbzuHGo6/view?usp=sharing

Was expecting a 23.976 output but got 59.94 @ 1:1:1:1:1:1:1:3 & 1:1

[poisondeathray]

T


rife.avs:
DirectShowSource("1-1-1-2 to 1-1.mkv")
z_ConvertFormat(pixel_type="RGBPS", colorspace_op="709:709:709:limited=>rgb:709:709:full")
RIFE(model=9,fps_num=24000,fps_den=1001)

ffmpeg -i rife.avs -c:v libx264 -preset medium -b:v 4000000 -pix_fmt yuv420p10le -profile:v high10 -r 59.940 -c:a copy result.mkv


Result: https://drive.google.com/file/d/16Og64-DGzNKVipXr_V8nMZhmPbzuHGo6/view?usp=sharing

Was expecting a 23.976 output but got 59.94 @ 1:1:1:1:1:1:1:3 & 1:1


-r 59.940 as output option in ffmpeg will add duplicates 23.976=>59.94

If you do not decimate the 1st part in the script, it will not be as smooth because rife will be interpolating from those weird duplicates

Be careful with directshowsource as a source filter - it's not necessarily frame accurate and might give you weird results, especially with temporal filtering or any filter chain that requests multiple frames

-c:a copy from an avs script will output uncompressed audio. Avisynth frameserves uncompressed audio and video. You'd probably want to use the original audio stream and -map arguments for each stream when using -c:a copy . Assuming the original stream map for original.mkv is stream 1 for the audio, stream 0 for the video, it would look something like this:

ffmpeg -i video.avs -i original.mkv -map 0:0 -map 1:1 .... -c:a copy....

[flossy_cake]

Thanks. I tried with -r 23.976 and still get a bad result for the stairs section: https://drive.google.com/file/d/1Efxt2lx3TIBo4uFnVn3SRv_Y9noFELZb/view?usp=sharing

My previous attempt with -r 59.94 resulted in 1:1 60fps on stairs not duplicate.

Anyway it's a moot point as I can't use this filter due to practical constraints.

[poisondeathray]

Thanks. I tried with -r 23.976 and still get a bad result for the stairs section: https://drive.google.com/file/d/1Efxt2lx3TIBo4uFnVn3SRv_Y9noFELZb/view?usp=sharing


result2.mkv iss different, with slightly different artifacts, but still 23.976 unique frames /s on the stair section . It might be source filter differences, and I'm unsure if GPU makes a difference (it shouldn't with vulkan)

[hello_hello]

I recognise that number -- it's also the diff between 704 and 720 width: 704 * 1.0227 = 720. Could be a coincidence though, I don't really know.

No co-incidence. Using a generic PAR (there's a list of PAR's here (https://forum.doom9.org/showthread.php?p=1058927#post1058927)).

720 x (16/15) / 576 = 4:3

For an mpeg4 PAR

704 x (12/11) / 576 = 4:3
or
720 x (12/11) / 576 = 15:11

The mpeg4 PARs are the mpeg4 equivalent of the original ITU PARs derived from the standard for digitising analogue video. They're almost the same as ITU but easier to remember and work with because they only result in two DARs for both NTSC and PAL DVDs, 20:11 and 15:11 (the mpeg4 equivalent of 16:9 and 4:3).

[hello_hello]

It's a bit contentious actually! On other forums some are saying the "remastered DVD" is still better as it doesn't have DNR and sharpening of the BD version (plus the aspect isn't squished, but they didn't notice that).

Personally I am satisfied with the BD version but only because we can unsquish the aspect. If all I had was a BD player without fine-tuning of the aspect then I probably wouldn't find it acceptable.

Is your DVD the original or remastered?

I haven't dug them out yet but I'm pretty sure they're not the remastered version. They're pretty old.
I prefer the Bluray because it's obviously been remastered for modern displays. The gamma and contrast looks better. Apparently back in the dark ages the BBC were obsessed with the picture being bright. Some of the actors on my classic Doctor Who DVDs complained about that in the commentary.

The other DAR issue is the HDMI spec which says PAL and NTSC should be exactly 16:9 or 4:3, so modern players/displays resize that way. Apparently DVD players with analogue outputs tend to use ITU resizing for analogue and generic resizing for HDMI, so the DAR could be mpeg4 for the remastered DVD version and it's generally being viewed a bit squished too, so it looks the same as the Bluray.

I'm not a fan of video that looks sharpened, but just based on the small sample I've seen I don't think the sharpening was too over the top. I haven't seen the remastered DVDs though, so I can't comment on those.

PS I don't actually know, but I suspect the bluray was created using some sort of interpolation method rather than it being de-interlaced and re-interlaced. I have some NTSC DVDs of classic Doctor Who that were created that way. They look like standard interlaced NTSC but they don't de-interlace well. Lots of aliasing and only QTGM seemed to do a decent job. If the Bluray version was created the same way you might find it's a job for QTGMC once you get to scenes with objects with sharp edges etc, even though BWDIF seemed to do a decent job with the sample. For HD you could probably get away with speeding QTGMC up a fair bit, ie QTGMC(Preset="Medium") and it'll still do a better job than most de-interlacers.

[flossy_cake]

the problem is that TDecimate can't seem to detect the cop walking up the stairs is 1:1 and fails to identify it as "video"

Solved this with viddetect=2. The motion blur is a bit ugly but still better than the harsh stuttering without it. This opens the possibility of creating a VFR file with native rates for both cadences, if I can figure out how to do it...

[flossy_cake]

Found this post by hello_hello explaining it somewhat (thanks): https://forum.doom9.org/showthread.php?p=1783153#post1783153

It sounds like applying the mkv timecode file requires re-encoding (generation loss) though -- is this correct?

But other stuff I read seemed to imply the file can be remuxed into a new mkv file without having to re-encode? edit: actually no that can't be right now that I think about it since TDecimate is removing frames so as soon as you change any frame it all needs to be re-encoded. The problem is this degrades image quality (generation loss) and takes a very long time. Is it possible for avisynth to do the VFRing in real time? I'd imagine at least 1 pre-pass would be required to generate the timecode file, but then after that can avisynth take the timecode file + the original file and produce a VFR output from it in realtime?

[hello_hello]

I'd imagine at least 1 pre-pass would be required to generate the timecode file, but then after that can avisynth take the timecode file + the original file and produce a VFR output from it in realtime?

Not in realtime as Avisynth only supports a constant frame rate (I'm not sure about VapourSynth). Typically the CFR is the average frame rate and the timecodes are used when muxing to make it VFR, or for x264 you can add the timecodes file to the command line and encode in VFR mode (I don't use x265 so I don't know if it has a VFR mode).

[flossy_cake]

Ok cool.

I think I'll just use TDecimate to 24p in real time and live with the motion blur on the 30p->24p converted sections as they aren't very common in this show. Plus an added benefit is that the native 24p sections can be output natively at multiple of 24hz instead of baking in the 3:2 judder @ 60p. I have mixed feelings about 3:2... I suppose it's kind of interesting and charming in a way, but also a bit jarring on panning shots. My main display isn't sample-and-hold so maybe that's exacerbating it. When there's not much camera movement though it does seem to imbue a kind of dream-like feel though which I find amusing. I sort of want to watch it and pretend I'm living in a 60hz country haha

For Fawlty Towers I saw that LAV Video Decoder has recently added bwdif so I might just deinterlace in realtime and save some storage space. DXVA deint is not bad also (tag file with [deint=video] in madvr) but it has this weird delay on the 1px patterns in the 576i25 clip in the OP.

Thanks again for all the help and code examples, which sped up my learning a lot. Because of this thread I also discovered the AssumeFPS() function to slow PAL stuff to 24p in realtime. This is really quite amazing to me but I'm still getting used to actors' voices being low and slow after hearing them chipmunked for the last 2 decades.

[hello_hello]

Given you use MPC-HC, have you tried ReClock (https://www.videohelp.com/software/ReClock-Directshow-Filter)? I'm still using it on XP but I assume it works for newer Windows. It'll slow PAL down to 24fps and/or pitch correct the audio without changing the video speed. I think it's 32 bit only though.

[flossy_cake]

Given you use MPC-HC, have you tried ReClock (https://www.videohelp.com/software/ReClock-Directshow-Filter)? I'm still using it on XP but I assume it works for newer Windows. It'll slow PAL down to 24fps and/or pitch correct the audio without changing the video speed. I think it's 32 bit only though.

Yeah that's why I'm not using it as I'd need to run a separate 32-bit MPC just for those videos which clashes a bit with the way I've got things set up.

Although there's a lot of AVS dll's which are 32-bit and those won't work with 64-bit MPC-HC either so maybe I need to figure something out.

The AssumeFPS(24,1,true) seems to do the trick though -- it slows down both the video and audio to 24. It's not just the pitch that's wrong, it's the whole speed of dialogue, the intonation of actors speaking feels slower or something. For sitcoms it seems to make things seem... less comedic? Also have a look at this (https://www.youtube.com/watch?v=-y3RGeaxksY&t=443s).

[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]

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 (https://forum.blu-ray.com/showthread.php?p=17074348#post17074348) mentioning Fawlty Towers was shot on these EMI 2001 cameras (https://www.youtube.com/watch?v=uGvO29NQ8xs). Their spec sheet can be found here (https://www.tvcameramuseum.org/pdfs/emi/emi2001broc.pdf), but it doesn't mention aspect ratio, only that it uses the 625-line CCIR system (page 10). But the CCIR spec (https://www.blunham.com/Radar/Teletext/PDFs/TV625lineUKspec.pdf) 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 (https://www.amazon.com/Fawlty-Towers-komplette-Erstmals-remastered/dp/B08GFRWHH4/) 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. (http://avisynth.nl/index.php/Bob)

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/1WfW3yXmGhIvUCiexQGYD18gSiXRe2bze/view?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.

:thanks:

[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]

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 (https://web.archive.org/web/20100331085936/http://www.bbc.co.uk/guidelines/dq/pdf/tv/tv_standards_london.pdf)

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/404626-How-do-i-upscale-PAL#post2646932

[flossy_cake]

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

[flossy_cake]

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