Problem with animation 2:3 pulldown mixed with 1 progressive 1 interlaced pattern

[shph]

Hello.
I noticed that a plenty of animation DVDs use some sort of special uncommon telecine logic. In some scenes used real 2:3 Pulldown pattern (3 progressive, 2 interlaced), but in some other scenes sometimes pattern changes and it looks like 4 progressive frames 1 interlaced. Sometimes pattern changes to 1 progressive 1 interlaced. In many cases progressive frames in those uncommon patterns have damaged jagged lines.

Usually there is no 2:3 Pulldown tags in those original VOB files.
MediaInfo detect files as:
29.970 (30000/1001) FPS NTSC
Scan type: Interlaced
Scan order: Top Field First

If i manually set input as Progressive and use TFM of VFM filters, i can output to 29.97 and in worst case scenario i can see that in those problematic scenes pattern consists of one normal deinterlaced nice looking frame and one similar original frame with jagged lines.

If i add sRestore - it randomly use those jagged frames instead of normal looking duplicates.

If i manually set input as telecine and use VIVTC or TIVTC - i can also see that sometimes jagged frames may appear.

VIVTC/TIVTC can remove most of those problematic frames, but some amount of jagged frames unfortunately remains. I tried different modes and settings and none of them really helps. Changing Block (x/y) and MI settings to large amounts helps to drop more jagged frames, but same time it adds blending artifacts to other normal frames. So it is not a real solution.

So the questions are:
Why sRestore and VIVTC or TIVTC sometimes select those low quality progressive jagged frames instead of nice looking deinterlaced frames?
Is it some global bug with plugins or with some settings?

Here is source clip example https://drive.google.com/file/d/1gIPkJMV3XR4ZVZG5drTkag_r10ijBIJo/view?usp=sharing
If use 29.970 framerate problem starts from frame 2342
If use 23.976 framerate problem starts from frame 1873

Input: Progressive
https://i.imgur.com/SZxaueZ.gif

Input: Progressive + TFM
https://i.imgur.com/ifBHjTK.gif

Input: Telecine + TIVTC
https://i.imgur.com/uiVWEFN.gif

[Yomiko]

"4 progressive frames 1 interlaced"
24 fps
Aa Bb Cc Dd -> Aa Bb Bc Cd Dd
12 fps
Aa Aa Cc Cc -> Aa Aa Ac Cc Cc

"1 progressive frames 1 interlaced"
The cut from frame 2342 was directed in 30 fps.

VIVTC/TIVTC issues:
VFM usually doesn't modify fields. TFM usually ignores minor aliasing, so frames even with jagged lines were marked as good ones for field matching.

[Julek]

For 1:1 scene you can freeze:

src = core.lsmas.LWLibavSource(r"D:\Downloads\Alien Nine [CROP].mkv")
ivtc = core.vivtc.VFM(src, 1)
bad_frames = list(range(2342, 2373, 2))
freez = core.std.FreezeFrames(ivtc, first=bad_frames, last=bad_frames, replacement=[i + 1 for i in bad_frames])

[shph]

It is not too realistic to manually check all movie frame by frame and detect sections that use different patterns than normal telecine.
I expected that maybe some autodetection exists?
But i will try to do some deeper frame by frame research and maybe look for some constant pattern logic for those 1:1 parts.

Guess the problem is not "1 progressive frames 1 interlaced" itself. IVTC detects that pattern and visually ok converts things to 23.976.
The problem is in those strange progressive jagged frames already existed in source video. IVTC detects them as good frames but in reality they are bad frames and should be ignored.
It is also unknown if those jagged duplicated frames where placed for some purpose or simply due some mistake during film-to-digital master copy transfer.
I noticed a lot of animation DVDs that have similar artifacts and unusual "variable" telecine pattern. In most cases those artifacts are placed in rare random single frames and not so extremely visible as in example provided here.

[shph]

By the way, i looked for some existing x264 DVD-rips made by other people from the same DVD release, and those rips don't have those jagged frames.
So in theory it is somehow possible to bypass those problematic jagged frames...

[shph]

I got some feedback from authors of DVD rips:

"Used the Yatta software, in which you can detect patterns and enforce them (for the 3:2 sections) as weell as do other manual stuff like freezeframing the cuts where one field is missing and you can also select the 30fps sections so that they don't get decimated, the software generates timecode files for you and the end file is VFR then - 24fps where it was IVTCed and 30fps elsewhere.
It was an awful lot of work to do it that way (besides watching out for 60i fades done on top of the ^ and having to apply debanding in places)"

Yatta software is some very special Avisynth tool https://forum.doom9.org/showthread.php?t=161653
So it is possible to autodetect those variable telecine patterns, but it is not a one click workflow...

P.S. There is also more resent YATTA for VapourSynth (real name: Wobbly) https://forum.doom9.org/showthread.php?t=172496

[Yomiko]

Wobbly is usually not mentioned because we don't believe it works well ;_;

[shph]

I checked Wobbly, and it looks rather complicated manual tool that needs some learning to understand how it works. Not a one click autodetection tool as i expected :)

I guess in more user friendly way it could be some extended option for VIVTC/TIVTC. Or some special "Variable Telecine" input mode that will autoedect frame patterns and tell to VIVTC/TIVTC/VDecimate how to process them correctly...

[Selur]

Wobbly/Yatta are tools that are meant for folks who have the time and motivation to tweak and know what they are doing, so without a good understanding of what's happening I would not recommend them, but simply live with the normal results.
It's like with most other scripts, they are meant as a usually good enough solution and allows users to not having to know each and every thing and tweak each possible parameter and filter combination.

[Julek]

if you want to automatically freeze when 1:1 you can use Eval:

src = core.lsmas.LWLibavSource(r"D:\Downloads\Alien Nine [CROP].mkv")
ivtc = core.vivtc.VFM(src, 1)

isComb = core.tdm.IsCombed(src)
prev = isComb[:1] + isComb[:-1]
next = isComb[1:] + isComb[-1:]

def freez(n, f, clip):
comb = f[0].props['_Combed'] + f[1].props['_Combed']
return clip[n+1] if comb == 2 else clip

from functools import partial
feval = core.std.FrameEval(ivtc, partial(freez, clip=ivtc), prop_src=[prev, next])

[PRAGMA]

Try with my PD2V (PD2V class of pvsfunc): https://github.com/rlaphoenix/pvsfunc

And use this:


from pvsfunc import PD2V, PKernel
from havsfunc import QTGMC

clip = PD2V(r"D:\...\the\file\container\doesnt\matter\trust\me\see\docs.mkv", verbose=True).\
ceil().\
deinterlace(kernel=functools.partial(QTGMC, FPSDivisor=2, Preset="Very Slow"), verbose=True).\
clip

clip.set_output()


This should give you all the information you need about the source, especially information like if its actually a mix of progressive and interlaced or not, and if so, how many are progressive, interlaced, and % of so.
This PD2V script creates an ACCURATE D2V with OPTIMAL settings forced onto it for you, no having to manually index. It then reads the .D2V file directly in python to understand the source better. It then applies fixes in certain scenarios that are caused by d2v_source plugin. Finally, only interlaced frames get thrown into a deinterlacer, meaning all progressive frames are as good as possible.

I hope this truly helps. Any feedback would be great (as an issue if possible as I dont go on here much).

[PRAGMA]

Why sRestore and VIVTC or TIVTC sometimes select those low quality progressive jagged frames instead of nice looking deinterlaced frames?
https://git.io/avoid-tdecimate

VIVTC/TIVTC are of the same, VIVTC is a port so refer to VIVTC as TIVTC the same. TIVTC is basically just an algorithm that by a bit of detections on frames it decides which ones are interlaced, combed (progressive interlaced/burned-in), and progressive. There are a few problems with it highlighted in that git.io link. tl-dr though; Noise (especially in old animation) can be a big problem for TIVTC and can completely throw it off its game on which frames to keep.

[PRAGMA]

As for the screenshots you show, Input: Progressive + TFM is basically just progressive recovering, you actually discarded information here which is why it looks so bad once TFM chews it up.

As for Input: Telecine + TIVTC, it's closer to what you actually want for multiple reasons.

First things first is this looks like the manufacturer chewed it up and spit it out in terms of FPS mangling. It looks as if it was converted from maybe 25.000 FPS (which may have already been a 24->24/1.001 -> 25 conversion) and then converted it to 30000/1001, but I honestly cannot say for sure atm. I would have a better answer for you if you run it through PD2V with verbose enabled.

Either way, the original is most likely 24 or 24000/1001. This error you see where its jaggy, then weirdly super-smoothed yet looks like it has line-doubled effect is actually most likely an editing mistake on the very original file. Family Guy S01-S04 (DVD Volumes 1-3 NTSC) has this very exact issue, so does Simpsons for basically the entire (good part) of the show, and also Spongebob S03 NTSC (but not PAL but it has its own issues).

What is the error happening here? Well, blame Adobe (yet again they still do this day dont properly handle interlaced matieral, especially mixed-scan material). Adobe Premiere 6 for Mac has a nasty nasty bug related to changing of speed and splicing clips that caused it to deinterlace, and reinterlace, and then deinterlace again, and reinterlace on media export in nasty nasty nasty ways. This shows out to me as this issue mostly as of how very very similar it is to SpongeBob S03, and Family Guy nearing S03/S04. Notice how in some frames you can faintly see content from the previous and/or next frame (yeah sometimes both), this is part of that issue.

Sadly, I do not know a fix for that as I'm still tryna hunt a good one down for SpongeBob S03 specifically as SpongeBob doesnt have it too bad (but its noticeable for sure), but Family Guy has it on almost every scene and 2x worse. Sad situation really.

Hope this helps.

EDIT: P.S. The reason you most likely see this issue only sometimes is because it may only be happening on scenes that went through some post-production edits like Pan & Scan, Zoom, or splicing/trimming.

[PRAGMA]

Here's my test results on the file you provided in the OP.

Your gif vs. Mine via PD2V (module of pvsfunc):

https://i.imgur.com/uiVWEFN.gif https://i.imgur.com/eOtve2k.gif

If you notice, there's no jagged lines, but there is a bit of "frozen" frames, this is essentially the result of manually freezing to replace the jagged frames like someone else suggested, but instead, it isnt needing to be manually done. Yet another benefit to properly reading the D2V file and applying manual fixes to d2v_source and such. This is a perfect example of why I made pvsfunc and PD2V, to solve stupid crap like this on DVDs, by researching interlacing, deinterlacing, frame matching, combing, etc. for ages.

Notice as well just how better quality the edges are, you don't see the weird blur double line shadow thing here (not sure exactly why). This did use QTGMC, which probably did something to help us here as well.

Here's my script:

from pvsfunc import PD2V
from havsfunc import QTGMC
import functools

clip = PD2V(r"C:\Users\redacted\Downloads\Alien Nine [CROP].mkv", verbose=True).\
ceil().\
deinterlace(kernel=functools.partial(QTGMC, FPSDivisor=2, Preset="Very Slow"), verbose=True).\
clip


Finally, look at the Verbose information text provided by PD2V. You can see it lists various information like progressive and interlaced count and % information, pulldown information (there was NONE in this clip you provided, no progressive information). You can also see it is NOT mixed scan type, only Interlaced, as VFR is False, meaning its only one scan type as DVDs must be mixed-scan-type to be able to have a frame-rate other than NTSC/PAL to switch between.

It's returning 720x480 30000/1001 yuv420p8. You may return 24000/1001 instead by replacing the ceil() line with floor() instead. Look into pd2v docs for information on what these both do, and when you shouldnt use it (depends on source basically). For this source, I would honestly recommend you to stick with ceil() because using floor() whenever there's even a slight risk of dodgy interlacing/scan going on, will mean it MAY desync with the audio. For example with Family Guy NTSC Volume 1 Disc 1 Episode 1 there's a scene where Peter drinks with his friends on a couch, that scene has mangled interlacing (burned in as progressive, so combing) which results in the scene actually being shorter than it was intended to be, but when played back its the right FPS for the audio, meaning the audio probably got mangled too. This means if you use floor() here, there will be LESS frames in that scene than intended, so on-playback it will end the scene before the audio ends, so the rest of the video is offset by a bit and delayed. The more this sort of thing happens the more desynced it is by the end of the video.

Because of this though it is easy to see if it has desynced or not at all by just going to the very end and seeing if it **perfectly** matches or not. If it doesnt perfectly match, don't use floor. Regardless, floor() will only be useful if your source is VFR. Meaning if its a DVD, it would need to be fully progressive or mixed scan. Floor() works by basically discarding frames (weaved fields) from interlaced sections to match their frame rate with the progressive sections which will be presumed to be lower-fps, as interlaced sections HAVE to match either NTSC or PAL, whereas progressive sections can be absolutely anything at it's raw thanks to pulldown.

Finally, with all of this said. With my code I provided above, the result looks very nice on playback. You don't notice the missing fields (which is what resulted in the "frozen" frames) and it plays quite smoothly. So if at all anything, this is probably a just fine enough result if you just need an encode done.

P.S. You can always also run a manual 30->24 fps conversion by decimating frames AFTER all the PD2V code has ran to get it as 24000/1001, which for this source I recommend. It does seem to be originally 24 FPS, and as per usual QTGMC isn't great for animation and the "smooth fps" is noticeable.

[PRAGMA]

As a little bonus, here's some frames of the clip you provided, after being ran through the script I showed earlier, and then ran through VSGAN with a 2x model I have (1440x960 output, basically modern anime HD):

(Click the images to get to full lossless image):
https://thumbs2.imgbox.com/2e/5e/DdRHGMNX_t.png (https://imgbox.com/DdRHGMNX) https://thumbs2.imgbox.com/bd/c2/pQvhIqHs_t.png (https://imgbox.com/pQvhIqHs) https://thumbs2.imgbox.com/e0/2e/gQjK9fDE_t.png (https://imgbox.com/gQjK9fDE) https://thumbs2.imgbox.com/1b/72/myONypeP_t.png (https://imgbox.com/myONypeP) https://thumbs2.imgbox.com/4b/38/qKHvfhqz_t.png (https://imgbox.com/qKHvfhqz)

[shph]

Thanks for info PRAGMA. That is really great result! VSGAN upscale also looks very nice. Lines are clean and textures are preserved. Guess it only need some small amount of HQ DeRing filter.

By the way i almost sure now that those progressive frames with jagged edges are part of master copy. Probably they are there due some editing mistake. The creators of that cartoon shared early US DVD release here https://archive.org/details/alien-9 That release is lower quality than Japan DVD and have a lot of rainbow chroma artifacts, but same progressive frames have same jagged edges.

[PRAGMA]

Thanks for info PRAGMA. That is really great result! VSGAN upscale also looks very nice. Lines are clean and textures are preserved. Guess it only need some small amount of HQ DeRing filter.

By the way i almost sure now that those progressive frames with jagged edges are part of master copy. Probably they are there due some editing mistake. The creators of that cartoon shared early US DVD release here https://archive.org/details/alien-9 That release is lower quality than Japan DVD and have a lot of rainbow chroma artifacts, but same progressive frames have same jagged edges.

Yeah as I said, this is almost evidence towards the (kinda common) Adobe Premiere 6 Mac bug. :/

[shph]

PRAGMA, so your function is Windows only because relies on DGIndex D2V project files?
How do you think, is it possible somehow use D2VWitch instead of DGIndex to make it work on macOS too?

[SaurusX]

One of the most hellacious animated titles to deal with interlacing on DVD is the TMNT 2003 series. I'm very inclined to install Vapoursynth to test out Pragma's program and see the results.

[poisondeathray]

Maybe I'm not using it correctly, but PD2V deinterlaces every frame in that clip, even ones where there was a good match. That degrades all the progressive frames. You can see it in the gif too

[Selur]

@PRAGMA: which model did you use?

[PRAGMA]

PRAGMA, so your function is Windows only because relies on DGIndex D2V project files?
How do you think, is it possible somehow use D2VWitch instead of DGIndex to make it work on macOS too?

It does support Linux and macOS, just download, install wine, add DGIndex.exe to system path.

I've had tons of inaccuracy and glitchy frame read issues with D2VWitch back in the day, so even on Linux I advise people to use DGIndex. All you need to do is download DGIndex, install Wine, and add the binary for DGIndex.exe to your system PATH environment variable (so not your shell environment variable).

That way the script will find DGIndex, detect you are on Linux, and will call DGIndex with Wine for you.

Btw, If you REALLY REALLY want to use D2VWitch or such (which I cannot personally recommend), then simply provide the input path directly to a .d2v and not an MKV, MPG, MP4, and such. This way it wont try to generate a D2V for you and will use the one provided. But remember that PD2V expects specific D2V settings and may have bad unintended behavior if D2VWitch doesnt generate with those settings. See https://github.com/rlaphoenix/pyd2v/blob/3ee8eafb31167439a72cb15fd8b1ebc2caea7778/pyd2v/d2v.py#L219

[PRAGMA]

Maybe I'm not using it correctly, but PD2V deinterlaces every frame in that clip, even ones where there was a good match. That degrades all the progressive frames. You can see it in the gif too

You must realize that the entire clip provided is in fact interlaced. There are no progressive frames found within. It may be possible to "recover" progressive frames by using something like TFM, but as mentioned before it doesnt work very well in most scenarios. And even then, the doubt that it could potentially mess up even one frame is enough for me not to use it. I'd prefer to let QTGMC or YADIF have at the original interlaced frames at that point.

Regardless, you CAN still use something like TFM with PD2V. Simply replace the .deinterlace(...) call which has for example QTGMC, with a TFM call. Then add ANOTHER .deinterlace() after that one, and add back in QTGMC.

Everything in PD2V is chainable, but once you add .clip it's no longer chainable as you now have the final clip output.

[PRAGMA]

@PRAGMA: which model did you use?

I used the model `2X_DigitalFilmV5_Lite`: https://anonfiles.com/n5X805Nfu9/2X_DigitalFilmV5_Lite_pth

[PRAGMA]

One of the most hellacious animated titles to deal with interlacing on DVD is the TMNT 2003 series. I'm very inclined to install Vapoursynth to test out Pragma's program and see the results.

I ran the same script I gave OP as an example for Alien Nine on TMNT 2003 Disc 1 (AOTM) and it doesn't seem to have much issues at all.

The entire thing is 30000/1001 Interlaced 100.00%. There is definitely a lot of recoverable frames in here, but as I told poisondeathray I don't like using TFM (but that's just me, you do you).

Regardless, after running it seems fine and totally grand so far. Nothing burnt in or anything (that I've seen so far anyway).

https://thumbs2.imgbox.com/cc/fa/F6sC1Fre_t.png (https://imgbox.com/F6sC1Fre) https://thumbs2.imgbox.com/6b/5a/sbkjdIdj_t.png (https://imgbox.com/sbkjdIdj) https://thumbs2.imgbox.com/fe/2e/gXk3i1W1_t.png (https://imgbox.com/gXk3i1W1) https://thumbs2.imgbox.com/28/9f/wSy7z5IL_t.png (https://imgbox.com/wSy7z5IL) https://thumbs2.imgbox.com/cf/b0/BWoM6ly4_t.png (https://imgbox.com/BWoM6ly4) https://thumbs2.imgbox.com/0d/5a/CoYOfAhP_t.png (https://imgbox.com/CoYOfAhP)

This show seems to be 24fps as I can notice duplicate frames every 1 in 5 frames. Since the interlacing here actually look clean, using .floor() instead of .ceil() might be OK, but you should always test for audio desync.

Since this source is 100.00% Interlaced, it is not VFR. And since it's not VFR .floor() won't actually do anything at all as it can not assume any cycle information. So, we must tell it the cycle information. I checked for you and it seems to be `floor(cycle=5, offsets=[0, 1, 3, 4])` (which is the most common for 24->NTSC, essentially discard every 3rd frame in every 5 frame cycle).

[PRAGMA]

Maybe I'm not using it correctly, but PD2V deinterlaces every frame in that clip, even ones where there was a good match. That degrades all the progressive frames. You can see it in the gif too

Ok so a bit of an update on this.
Since it seems a fair amount of people want to use VFM (or just recover progressive frames to be specific) I decided I would add support for this in pvsfunc/PD2V.

Support has started in the new v4.2.0.

There's now a `recover()` method that is just an optimizing wrapper over VFM. I would have made it work like `deinterlace()` where you can supply your own kernel/function, but since I dont know any other alternatives to VFM I didnt bother.

This wrapper deals with the clip and order params (though you can force override still) and lets you change any VFM argument you want still.

Speaking of `deinterlace()` it now supports dealing with clips that had VFM ran on it. Meaning if VFM could not recover a frame then no worries as you can chain on a .deinterlace() and deinterlace that frame (and that frame only, leaving the real progressive and recovered progressive alone).

What this means is that if you like to use TFM, but also like my PD2V setup, then yay :D just go use TFM via recover() instead of manually calling it.

The verbose options are also optimized between deinterlace() and recover() so that they both still show their information and optimized terminology to as to not confuse.

:D

Examples on TMNT 2003 Disc 1:
https://thumbs2.imgbox.com/a4/39/7pE1BWrg_t.png (https://imgbox.com/7pE1BWrg) https://thumbs2.imgbox.com/a5/83/VoXR5x16_t.png (https://imgbox.com/VoXR5x16) https://thumbs2.imgbox.com/5f/c8/QVn19t1C_t.png (https://imgbox.com/QVn19t1C) https://thumbs2.imgbox.com/a2/22/f7vgMBEH_t.png (https://imgbox.com/f7vgMBEH) https://thumbs2.imgbox.com/37/3f/DoZ5kfpK_t.png (https://imgbox.com/DoZ5kfpK) https://thumbs2.imgbox.com/71/28/sLgOegKt_t.png (https://imgbox.com/sLgOegKt)

Script:

import functools
from pvsfunc import PD2V
from havsfunc import QTGMC

clip = PD2V(r"C:\Users\phoenix\Videos\TMNT\title_t00.mkv", verbose=True).\
recover(mode=0, verbose=True).\
deinterlace(kernel=functools.partial(QTGMC, FPSDivisor=2, Preset="Very Slow"), verbose=True).\
clip


As you can see on the last image is that it isnt always perfect. The 4th image is a scenario of which VFM could not recover a progressive frame but it got passed to QTGMC for deinterlacing :)

Also, the whole "double-line" thing that I referred to a few days ago now seemingly was caused by VFM/TFM. I say this because when recovered I can notice it at the beginning of this TMNT on edges. So, it would see recovering progressive frames can sometimes cause that when QTGMC doesnt.

https://thumbs2.imgbox.com/8e/c6/3LwjpEja_t.png (https://imgbox.com/3LwjpEja) https://thumbs2.imgbox.com/f1/55/vmoapLtt_t.png (https://imgbox.com/vmoapLtt)

As you can see on the left image (default settings TFM call), near the top left you can see some double-line (aka thick line). Whereas on the right image (No TFM, QTGMC Very Slow), you don't, you only see a typical SD-era blurry line.

[shph]

That's interesting. I thought that "double-line" in Alien 9 was a semi-transparent film celluloid :) (At least it looked very similar to this). But in TMNT 2003 it is really looks like some unusual artifact generated by lack of deinterlacer.

[shph]

Btw, If you REALLY REALLY want to use D2VWitch or such (which I cannot personally recommend), then simply provide the input path directly to a .d2v and not an MKV, MPG, MP4, and such. This way it wont try to generate a D2V for you and will use the one provided. But remember that PD2V expects specific D2V settings and may have bad unintended behavior if D2VWitch doesnt generate with those settings. See https://github.com/rlaphoenix/pyd2v/blob/3ee8eafb31167439a72cb15fd8b1ebc2caea7778/pyd2v/d2v.py#L219

Ok, so maybe D2VWitch could be modified and improved in future versions to fully support PD2V? I will try to ask developers ...

[SaurusX]

https://thumbs2.imgbox.com/71/28/sLgOegKt_t.png
As you can see on the last image is that it isnt always perfect.

Thanks for taking a look at this series. I think using ceil() would be the way to go here, because there are plenty of areas that are not 24fps and are either 30fps or 60i. That image with Splinter being extremely aliased is not uncommon, either. It seems to be an artifact of whatever animation software was being used. Part of the frame will look low res like a bob deinterlace, while the rest remains sharp.

[Selur]

I used the model `2X_DigitalFilmV5_Lite
Thanks! Another model for my collection. :)

Cu Selur

[poisondeathray]

You must realize that the entire clip provided is in fact interlaced. There are no progressive frames found within. It may be possible to "recover" progressive frames by using something like TFM, but as mentioned before it doesnt work very well in most scenarios. And even then, the doubt that it could potentially mess up even one frame is enough for me not to use it. I'd prefer to let QTGMC or YADIF have at the original interlaced frames at that point.


The content is 99% all progressive (most animations are) but the type of encoding is interlaced on this DVD (as many DVD's are) - ie. it's encoded as fields, instead of native progressive with repeat field flags (the latter is "soft pulldown"). The d2v conveys encoding type, not necessarily any accurate info about content - the author, DG, will tell you basically the same thing. The content is what is important.

So on DVD's that are encoded interlaced, you'd advocate deinterlacing everything ? On something like that OP's DVD, that potentially degrades >99% frames, for fixing a handful <1%. As good as QTGMC is, you still soften the image and create *new* problems with aliasing and ghosting . Some of the QTGMC frames are almost as good as progressive, but some are much worse.

Since you're adverse to 1 bad frame - I'd argue that you shouldn't deinterlace progressive content at all - because you cause *new* additional problems that were not in the source. But hey it's your choice...

https://i.postimg.cc/7LB8w1wr/vfm001730.png
https://i.postimg.cc/WbRRN1Lz/pd2v001730-arrows.png

https://i.postimg.cc/qR9FvjFS/vfm001921.png
https://i.postimg.cc/rF2b6Zxt/pd2v001921-arrows.png

https://i.postimg.cc/8cZrb0Vn/vfm002088.png
https://i.postimg.cc/dtSykp6h/pd2v002088-arrows.png

Now, there are some other bad sections like interlaced fades that might not be detected by normal comb detection - but the "bad" sections on this DVD sample is <1%.

Some other DVD's might have some interlaced overlays or titles , a few true interlaced content sections; or on some very badly produced DVD's, you might get something like 90% bad frames (for various reasons). On those latter sorts of scenarios it might make sense to "blindly" QTGMC everything to smooth things over. But it' s nothing that the d2v can tell you about - you have to use your eyes

This d2v method might be more useful on DVD's that are mixed - that have soft pulldown (encoded progressive) and hard pulldown (encoded interlaced) on the same title



Ok so a bit of an update on this.
Since it seems a fair amount of people want to use VFM (or just recover progressive frames to be specific) I decided I would add support for this in pvsfunc/PD2V.

Support has started in the new v4.2.0.


Thanks for the updates, it's nice to have options.

But this option is basically the same as field matching (VFM or TFM in vapoursynth) + PP . If combing is not detected , it still allows passthrough of the "bad" frame . The garbage frames in the OP's source are not "combed", in the traditional sense, so they are not detected. A different type of detection is required, or human eye.

Eitherway there are compromises . I appreciate the work you are trying, keep it up

[shph]

Yep, i got same problems when attempt to deinterlace everything (D2VWitch+QTGMC). In other forum Selur also suggested just deinterlace everything, but i didn't like overall final result.
If PD2V deinterlaces every frame in that clip, sure QTGMC will generate new artifacts. When PRAGMA introduced that method i thought that DGIndex+PD2V deinterlace everything in some other "selective" way.

[PRAGMA]

Ok, so maybe D2VWitch could be modified and improved in future versions to fully support PD2V? I will try to ask developers ...

The sole problem with D2VWitch isn't the incompatibility with PD2V, it's the inaccuracy and reading issues I've personally encountered on various sources (both clean and dodgy scan situations) using a D2V from D2VWitch and d2v_source plugin.

If support for D2VWitch is REALLY wanted, then make an issue in pyd2v project (and not PD2V) and if enough people show their interest I may add in an option to use D2VWitch if DGIndex could not be found on the system.

[PRAGMA]

Thanks for taking a look at this series. I think using ceil() would be the way to go here, because there are plenty of areas that are not 24fps and are either 30fps or 60i. That image with Splinter being extremely aliased is not uncommon, either. It seems to be an artifact of whatever animation software was being used. Part of the frame will look low res like a bob deinterlace, while the rest remains sharp.

Yes correct. I've noticed this in the intro as well. Again, seems to be caused by the dreaded Adobe bug.

And I would agree with you, it seems for this show a ceil() would be best instead of flooring all the potential 60i post-prod. However, I have noticed a lot of scenes and such that could potentially have been post-prod, doesn't seem to be 60i/30p still. So I would honestly be OK if someone did do a floor() here, since there isnt THAT much 60i, and the benefits of lower file size would outweigh the pros of 10% at most being 60i/30p.

[PRAGMA]

The content is 99% all progressive (most animations are) but the type of encoding is interlaced on this DVD (as many DVD's are) - ie. it's encoded as fields, instead of native progressive with repeat field flags (the latter is "soft pulldown"). The d2v conveys encoding type, not necessarily any accurate info about content - the author, DG, will tell you basically the same thing. The content is what is important.

So on DVD's that are encoded interlaced, you'd advocate deinterlacing everything ? On something like that OP's DVD, that potentially degrades >99% frames, for fixing a handful <1%. As good as QTGMC is, you still soften the image and create *new* problems with aliasing and ghosting . Some of the QTGMC frames are almost as good as progressive, but some are much worse.

Since you're adverse to 1 bad frame - I'd argue that you shouldn't deinterlace progressive content at all - because you cause *new* additional problems that were not in the source. But hey it's your choice...

Now, there are some other bad sections like interlaced fades that might not be detected by normal comb detection - but the "bad" sections on this DVD sample is <1%.

Some other DVD's might have some interlaced overlays or titles , a few true interlaced content sections; or on some very badly produced DVD's, you might get something like 90% bad frames (for various reasons). On those latter sorts of scenarios it might make sense to "blindly" QTGMC everything to smooth things over. But it' s nothing that the d2v can tell you about - you have to use your eyes

This d2v method might be more useful on DVD's that are mixed - that have soft pulldown (encoded progressive) and hard pulldown (encoded interlaced) on the same title





Thanks for the updates, it's nice to have options.

But this option is basically the same as field matching (VFM or TFM in vapoursynth) + PP . If combing is not detected , it still allows passthrough of the "bad" frame . The garbage frames in the OP's source are not "combed", in the traditional sense, so they are not detected. A different type of detection is required, or human eye.

Eitherway there are compromises . I appreciate the work you are trying, keep it up

Hi, I was initially saying that I do not like to use TFM as the sources I tended to work with did not fair well at all.

However, as you pointed out this source and TMNT (which both are relatively clean sources) are working quite well with VFM in most frames.

You also pointed out how frames with fade in/out of either the entire frame or just text on-screen and such has problems being frame matched and yes that is true, that is one of the reasons I tended to skip out on TFM in some of my sources as even if I let it passthrough to QTGMC, the differences of the results were noticeable on said source (as in sharpness of lines, purity, and such).

After adding in recover() in v4.2.0 (and a regression fix in v4.2.1) and testing it on TMNT and Alien Nine, I will say I'm impressed with the results.

This is the type of thing I'd love to use for example on Sonic Underground PAL (10-disc set, not the 5-disc set that is WORSE!), as it has similar scan situation to TMNT, except that literally like 90% of every disc can be recovered without a hitch due to the animation being 25fps exactly, so every 2 fields would have made up one full frame without any time-displacement between them! The only times matching could not happen was with post-prod pan&scans, which were full 50i as in every 2nd field was 1 time-unit ahead of the previous, e.g. like Live-action soaps tend to do interlacing in PAL regions (e.g. IT Crowd).

I'm not saying that TFM/VFM shouldn't be used, but I do advise caution on testing and tuning the VFM call as it can be disastrous at times like with TMNT where I highlighted the double-line issue.

An update on said double-line issue, I actually know EXACTLY what the problem is here. Every few frames or so, in a smooth yet linear timeframe, that scene gets blurrier and sharper as it goes on (probably an error during a post-prod pan and scan), and when VFM is field-matching a frame that is e.g. blurrier to the current frame which may be e.g. either sharper or blurrier than the other field its matching with, it causes a noticeable mismatch effect which showcases itself as if the entire frame got sharpness+10 thrown on it. This is the kind of thing that I dont like VFM for, the almost invisible on paper mistakes that can happen.

Regardless I'm glad it's working out for some sources but just needs a little per-source TLC.

[PRAGMA]

Yep, i got same problems when attempt to deinterlace everything (D2VWitch+QTGMC). In other forum Selur also suggested just deinterlace everything, but i didn't like overall final result.
If PD2V deinterlaces every frame in that clip, sure QTGMC will generate new artifacts. When PRAGMA introduced that method i thought that DGIndex+PD2V deinterlace everything in some other "selective" way.

To be clear, PD2V does NOT do *any* deinterlacing at all.
PD2V is simply a D2V optimized func-chaining system, which is also more tailored specifically to MPEG DVD video files (some assumptions in the code are specifically made assuming that the input is valid for the DVD-Video Spec).

When you use .deinterlace(), you are providing .deinterlace a kernel (a function, e.g. QTGMC) with your OWN arguments (e.g. preset VerySlow, though it handles stuff like order and TFF automatically).

When .deinterlace actually uses the kernel you provided, it will ONLY be used on frames marked as interlaced by the D2V file. Any frame marked as progressive either by the D2V file, or e.g. by recover(), will NOT go through the kernel ever.

This is why chaining .recover().deinterlace() is possible and supported.

When PRAGMA introduced that method i thought that DGIndex+PD2V deinterlace everything in some other "selective" way.

This is true. It does that. It selectively deinterlaces only frames that should be, as told by the D2V file. Again, I stress about DGIndex over D2VWitch because PD2V (via pyd2v) generates D2V files with very specific settings. If any of the settings on-generation are different then a totally wrong or bad result may happen if used through PD2V.

Reminder that when PD2V loads a D2V, it also applies fixes to the loaded clip that d2v_source plugin returns. There are scenarios in which if a clip is VFR, d2v_source does not correctly load in the source, it loads it at either NTSC or PAL frame rates HARDCODED and NOT dynamic/VFR, it loads as constant only ever.

When PD2V loads the clip, it then fixes the loaded clip to be correct intended FPS, and when you do either .ceil() or .floor() you convert the VFR to CFR CORRECTLY. Without the fix, it would NOT convert to CFR correctly at all, nor would it be retained as VFR. (EDIT: When not fixed, the source will still be the right frame count, just the displayed FPS via clip properties would be completely wrong, it might as well say its 6969420.BlazeITUpL0L FPS in that state.)

[shph]

PRAGMA, If it helps to improve your function, here are 2 more very unusual short examples:
PHANTASMAGORIA_VTS_01_4-VC01 is possible to make it look more less ok if set input to progressive and VFM to 29.97 with field order set to 3 clip = core.vivtc.VFM(clip=clip, order=0, field=3), but after that in some places some moving objects sometimes show new interlaced artifacts. It also have a lot of additional rainbow/halo/ring artifacts, but this is not the subject of this discussion.
https://drive.google.com/file/d/1LDuu3lJpHETeJwiZBdcWSawubmWy74uH/view?usp=sharing

12OZMOUSE use some unknown pattern. it is 25fps PAL, but i gave up with that source because never was able to guess what is going on there. It looks like one type of interlaced layer was placed to other different type of interlaced layer during editing. As i know the source was DVD with Australian region.
https://drive.google.com/file/d/1K5WgoP39xTsHqXbAfM1kdQZWoSURC65U/view?usp=sharing

[SaurusX]

Yes correct. I've noticed this in the intro as well. Again, seems to be caused by the dreaded Adobe bug.

Can you expand upon this? Are you saying Adobe Premiere has a known flaw that's known to cause this low res frame problem and maybe even the aliased red chroma problem? I've been trying to find an explanation for this for a long time.

[poisondeathray]

Can you expand upon this? Are you saying Adobe Premiere has a known flaw that's known to cause this low res frame problem and maybe even the aliased red chroma problem? I've been trying to find an explanation for this for a long time.


It's not really an Adobe bug, per se. All NLE's will do something similar when the editor mishandles the source material. (You're supposed to remove pulldown before editing, and edit on a progressive timeline. But many editors are lazy, or don't know their job, or sometimes they are handed bad source material in the first place). The issue is most NLE's use a low quality deinterlace (something similar to a "bob" in avisynth, or just resizing a single field)

You can demonstrate the same degradation in vapoursynth or avisynth when you mishandle footage. It's essentially caused when you deinterlace a progressive frame, so only 1/2 the fields are used. 50% of the spatial information. (For the same reason, you don't want to QTGMC progressive frames, but QTGMC usually handles the issues more gracefully, usually, except when there are ghosting issues)

[PRAGMA]

Can you expand upon this? Are you saying Adobe Premiere has a known flaw that's known to cause this low res frame problem and maybe even the aliased red chroma problem? I've been trying to find an explanation for this for a long time.

Correct. Adobe Premiere 6 for Mac (specifically "Premiere 6 for Mac", Not "Premiere Pro 6" or anything, Mac-specific).

It has a weird bug in relation to slicing and speed adjustment to spliced clips causing weird deinterlacing, reinterlacing, re-deinterlacing, multiple times depending on how it was sliced and adjusted. It could even go through it multiple times if it was mixed-scan (VST) and if output as interlaced, it would have interlaced progressive frames.

Even on the latest Adobe software it STILL doesn't handle mixed-scan (VST) content very well at all. It's sad.

EDIT: To be even clearer, this isn't just a case of the software just discarding half of a frame for a lot of frames or anything. This is the case of it re-interpolating said frames, then re-discarding over and over multiple times. If you ever notice a "shadow" bouncing up and down an outline/edge or invariant but patterned flickering/"sparks" then thank Adobe Premiere 6 for Mac (and possibly other earlier or later versions, but I know for SURE it happened on this version).

[poisondeathray]

EDIT: To be even clearer, this isn't just a case of the software just discarding half of a frame for a lot of frames or anything. This is the case of it re-interpolating said frames, then re-discarding over and over multiple times. If you ever notice a "shadow" bouncing up and down an outline/edge or invariant but patterned flickering/"sparks" then thank Adobe Premiere 6 for Mac (and possibly other earlier or later versions, but I know for SURE it happened on this version).


If I'm thinking of what you're describing correctly, the "shadow" and edge outlines are from the original artifacts + low quality lossy encoding . Compressor on mac, but it happens in other programs too