Deep Space Nine upscale project

[JoelHruska]

I avoided that one on the basis of age. The current 32-bit DGDecode.dll is from 2011. Seemed better to look for a later source than the earlier DLL based on earlier code.

[Katie Boundary]

I will be running DS9 tests soon, but for now, I'm still using Andromeda as my guinea pig for various deinterlacing methods. Just to be ABSOLUTELY sure about the relative merits of NNEDI3+Yadifmod2 versus QTGMC, I put the following script together:

mpeg2source("212.d2v")

A=qtgmc(sourcematch=3,lossless=1).selecteven()
B=qtgmc(sourcematch=3,lossless=1).selectodd()
C=Tfm(field=1,mode=0,slow=2,mchroma=false,cthresh=1,MI=40,blockx=8,mthresh=2,clip2=A,micmatching=0)
D=Tfm(field=0,mode=0,slow=2,mchroma=false,cthresh=1,MI=40,blockx=8,mthresh=2,clip2=B,micmatching=0)

E=Interleave(C,D)

Y=nnedi3(field=-2,nsize=3,nns=4,qual=2,etype=1)

L=yadifmod2(mode=3,edeint=Y).selecteven()
M=yadifmod2(mode=3,edeint=Y).selectodd()
N=Tfm(field=1,mode=0,slow=2,mchroma=false,cthresh=1,MI=40,blockx=8,mthresh=2,clip2=L,micmatching=0)
O=Tfm(field=0,mode=0,slow=2,mchroma=false,cthresh=1,MI=40,blockx=8,mthresh=2,clip2=M,micmatching=0)
P=Interleave(N,O)

stackvertical(E,P)

(I kept the manually specified field arguments instead of using the complementparity approach because I know the field parity already)

This was the result:



Remember, that's "lossless" QTGMC at the top, and Yadifmod2+NNEDI3 at the bottom. HuRr DuRr MuH aLiAsInG.

Originally Posted by hello_hello

I didn't use something superficially similar. There's a sample encode using the exact method you posted.

No, you posted encodes using a lobotomized script that I provided for the purpose of demonstrating where Complementparity() would go. HUGE difference.

Originally Posted by hello_hello

I thought you'd be happy I showed it works. I was going to add micmatching=0 to it, to fix a glitch, but then of course I'd be accused of changing it and still calling it your method.

All of my ACTUAL methods use micmatching=0 and about a dozen other settings that I cut out of that particular bit of code because, as I stated, the complementparity demonstration code was NOT meant for actual use.

Originally Posted by JoelHruska

So what ought it be in?

For compatibility: AVI
For variable frame rate: MP4

MP4 is an official industry standard recognized by the International Organization for Standardization as ISO/IEC 14496-14:2003, whereas MKV is developed and supported by a couple of hackers in France in their spare time, so MP4 should offer slightly better compatibility than MKV. However, this is purely speculation, and I don't know of any software that works with MP4 but not MKV.

Originally Posted by JoelHruska

What app do you use for the frame-by-frame checking to see where TIVTC needs to be applied?

Just open an AVIsynth script in Virtualdub?

Not Virtualdubmod or Virtualdub2 or TheVirtualdubStrikesBack or MyOwnVirtualDubWithBlackjackAndHookers...

Originally Posted by manono

If 86% film, then that 86% is treated as if you used Force Film in DGIndex (giving you a progressive 23.976 video for those portions) and the rest undergoes a full IVTC (field-matching and decimation) with the whole thing winding up as progressive 23.976fps... If there's any real interlaced video or any progressive 29.97fps portions, that'll throw a monkey wrench into the whole procedure.

Ummm... are you assuming that the episode was encoded at 86% soft pulldown and 14% hard pulldown, just for shits and giggles? Because the DVD authors wanted to screw with us? I mean, that's not a totally insane assumption, and I've seen it before in Farscape and a few episodes of Captain Planet. It just happens to not be true in this particular case. The "real interlaced video or any progressive 29.97fps portions" make up almost the entirety of the other 14%.

Attempting to convert the whole episode to 23.976 is a very bad idea.

Originally Posted by JoelHruska

Let me break down exactly what I'm doing:

1). Rip the DVD in DVD Decrypter. This creates the following directory and populates it with VOB files: C:\DS9S6D2\VIDEO_TS
2). Load the VOB file into DGIndex. Confirm that DGIndex is set to honor pulldown flags.
3). Run the project through DGIndex. This creates a D2V file as output.
4). Load the D2V file into StaxRip. This opens the project file using MPEG2Source.

All right, cool. This is a pretty sane and simple workflow that we can replicate for the purpose of diagnosing any errors you encounter.

Originally Posted by JoelHruska

LoadPlugin("C:\Path\DGDecode.dll")
MPEG2Source("C:\Path\VTS_2_1.d2v")

Why are you manually loading an autoload plugin?

Originally Posted by JoelHruska

Can I rely on MPEG2DecPlus64.dll to provide equivalent MPEG2 decoding to DGDecode? I would prefer to use an x64 DLL if at all possible. If I need to specifically drop back to 32-bit for everything to make DGDecode work and there's no functional x64 equivalent, I can bring up a new system tomorrow.

Why are we now screwing around with 64-bit anything?

[manono]

Originally Posted by Katie Boundary

Ummm... are you assuming that the episode was encoded at 86% soft pulldown and 14% hard pulldown, just for shits and giggles?

As I've not seen so much as a sample, maybe it's just wishful thinking. However, I have seen combinations of hard and soft pulldown like that much more often than I've seen soft pulldown mixed with video at similar percentages.

Attempting to convert the whole episode to 23.976 is a very bad idea.

Then you make the case for bobbing it and calling it a day. That would be a helluva lot easier, that's for sure. Either that or doing a VFR encode, something for which I, personally, have no use.

Why are you manually loading an autoload plugin?

I do that myself. For one thing, it keeps a screwed up plugins folder from also screwing up your scripts, things such as multiple and conflicting versions of the same filter. Like you, I also thought it screwy that he was trying to do everything in 64-bit.

[Katie Boundary]

UPDATE: I have independently confirmed the existence of at least one instance of retrograde field behavior: when the "Star Trek - Deep Space Nine" logo first fades in near the beginning of the opening credits. In addition, I'm having a hard time finding a combination of blockx and MI settings that will stop TFM from incorrectly flagging large amounts of progressive content as interlaced while still catching real interlaced content. The penalty for this is high - it causes the stars to blink in and out during space shots. I may switch to recommending blending instead of interpolation. I'll keep you all updated.

EDIT: for the sake of fairness, I tested QTGMC's performance as well. One of these images is my traditional TFM+Yadifmod2+NNEDI3 method. One of them is a variation of my method, using TFM+"Lossless" QTGMC. One of them is a variation of my method with TFM set to blend instead of bobbing/interpolation. Can you guess which is which?



Finally, I recommend adding d2v="601.d2v",flags=1 to the TFM settings in both the C and D lines. This will prevent TFM from checking for interlacing during any soft pulldown, which cuts the false positive rate dramatically. The scene that benefits from this the most, by far, is the close-up of the comet's tail.


EDIT #2: Get ready because this next script is going to REALLY blow your damn minds...

Mpeg2source("601.d2v")

A=Tfm(field=1,mode=0,slow=2,pp=2,mchroma=false,cthresh=-1,micmatching=0).converttorgb().generalconvolution(matrix = "0 -1 0 0 4 0 0 -1 0",divisor=2,auto=false).converttoyv12()
B=Tfm(field=0,mode=0,slow=2,pp=2,mchroma=false,cthresh=-1,micmatching=0).converttorgb().generalconvolution(matrix = "0 -1 0 0 4 0 0 -1 0",divisor=2,auto=false).converttoyv12()
C=Tfm(field=1,mode=0,slow=2,mchroma=false,cthresh=-1,clip2=A,d2v="601.d2v",flags=1,micmatching=0)
D=Tfm(field=0,mode=0,slow=2,mchroma=false,cthresh=-1,clip2=B,d2v="601.d2v",flags=1,micmatching=0)

interleave(C,D)

Film content is, as usual, properly field-matched and then left the goddamn hell alone. Orphaned fields get blended with their nearest matches, then vertically sharpened to undo the resulting softness. This prevents the image from suddenly getting blurrier and sharper when transitioning between film content and interlaced content.

It will, of course, still spoil any true 60 hz content by creating ghosting and cutting the effective frame rate, but I think that's a fair price to pay here.

[hello_hello]

Originally Posted by Katie Boundary

I will be running DS9 tests soon, but for now, I'm still using Andromeda as my guinea pig for various deinterlacing methods. Just to be ABSOLUTELY sure about the relative merits of NNEDI3+Yadifmod2 versus QTGMC, I put the following script together:
(I kept the manually specified field arguments instead of using the complementparity approach because I know the field parity already)

This was the result:

It seems you found a frame where yadif/nnedi3 looks better while using ridiculously low threshold settings and sourcermatch etc for QTGMC. Well done. Here it is again, same TFM settings, no sourcematch or lossless for QTGMC.
Similar aliasing, and a tad sharper than Yadif/nnedi3.
Most of the time when QTGMC looks less sharp it'll be because it's removed noise, as it did for the example I posted earlier.

Originally Posted by Katie Boundary

No, you posted encodes using a lobotomized script that I provided for the purpose of demonstrating where Complementparity() would go. HUGE difference.

So I'll ask again. What difference would it have made using a non lobotomised version? Would TFM have taken more pixels from nnedi3 or less? Where's the sample of how you'd do it to show it's improved?

Originally Posted by Katie Boundary

All of my ACTUAL methods use micmatching=0 and about a dozen other settings that I cut out of that particular bit of code because, as I stated, the complementparity demonstration code was NOT meant for actual use.

And I already said micmatching=0 would have fixed a glitch towards the end. That's it.
Lets be fair though and check out the huge difference you can expect to see with Katie's TFM settings vs the defaults, with the exception of micmatching=0 both times. I'll confess I've only checked the same frame again. I'm sure you'll be able to post screenshots where your settings are a vast improvement, won't you?

Katie TFM, Yadif/nnedi3, vs Default TFM, Yadif/nnedi3.
http://www.framecompare.com/image-co...rison/77DPLNNX
I assume there's a difference, as the png files are slightly different sizes.

Are you not answering my question as to how you decimate for a VFR due to a lack of reading skills or because you're ignoring it?

Originally Posted by Katie Boundary

All of my ACTUAL methods use micmatching=0 and about a dozen other settings that I cut out of that particular bit of code because, as I stated, the complementparity demonstration code was NOT meant for actual use.

So I'll ask again. What difference would it have made. Shouldn't you check a non lobotomised version is going to look better before complaining? Where's your sample encode?

[manono]

Originally Posted by Katie Boundary

Finally, I recommend adding d2v="601.d2v",flags=1 to the TFM settings in both the C and D lines. This will prevent TFM from checking for interlacing during any soft pulldown, which cuts the false positive rate dramatically. The scene that benefits from this the most, by far, is the close-up of the comet's tail.

Stereodude said something similar a couple of pages ago, except he likes Flags=5:

Originally Posted by Stereodude

The problem is that TFM sees combing where there is none and deinterlaces large areas of the frames despite it being progressive with no real combing. 5 puts an end to that. I didn't seen any examples of combing (except in the occasional scene change) which 5 still checks and addresses.

[hello_hello]

Originally Posted by Katie Boundary

UPDATE: I have independently confirmed the existence of at least one instance of retrograde field behavior: when the "Star Trek - Deep Space Nine" logo first fades in near the beginning of the opening credits.

I can't see it. It looks fine to me if I change the field order.

N=Tfm(field=0,mode=0,micmatching=0)
O=Tfm(field=1,mode=0,micmatching=0)
Interleave(N,O)

I've no idea how you make your field order work at all for the DS9 sample.

Originally Posted by Katie Boundary

Film content is, as usual, properly field-matched and then left the goddamn hell alone. Orphaned fields get blended with their nearest matches, then vertically sharpened to undo the resulting softness. This prevents the image from suddenly getting blurrier and sharper when transitioning between film content and interlaced content.

The comet tail is noticeably mushy. The CGI shot just before it switches to film has horrible quality pumping. The quality pumping seems worse in general. The sharpening makes the aliasing more noticeable.
I'm looking at an encode using your exact settings, including the field order. I don't think switching the field order to stop the frames bouncing back and forth would change that. Edit: I checked and it didn't.

I assume the transitions between shots have been de-interlaced by TFM and treated as video, so the transitions need to be kept at 29.97fps to stay smooth for a VFR. How do you do about picking them out if you decimate?

[Katie Boundary]

All right, time to feed the troll one last time.

Originally Posted by hello_hello

Are you not answering my question as to how you decimate for a VFR due to a lack of reading skills or because you're ignoring it?

I'm ignoring it because I don't give a tenth of a rat's ass about VFR, and have been advocating against VFR from the very beginning.

Originally Posted by hello_hello

So I'll ask again. What difference would it have made.

The difference is that one is my method and the other isn't.

And now, back to serious discussion:

Originally Posted by manono

Stereodude said something similar a couple of pages ago, except he likes Flags=5

Flags=1 is even stricter than 5, because 5 will look for scene changes and then perform deinterlacing around those, whereas 1 will not look for interlacing in film content ever. If there are any orphaned fields around scene changes, then there will also be an interruption in the pulldown pattern, and TFM will start checking for interlacing again anyway. I'm therefore not sure what 5 would accomplish other than getting false positives around scene changes.

[hello_hello]

Originally Posted by Katie Boundary

All right, time to feed the troll one last time.

Ah.... a Katie classic. When the discussion doesn't go her way, out come the troll accusations. Why not participate in a discussion like an adult?

Originally Posted by Katie Boundary

I'm ignoring it because I don't give a tenth of a rat's ass about VFR, and have been advocating against VFR from the very beginning.

You've advised JoelHruska to output MP4 for a VFR. Where's the rest of the workflow? I'm sure you've even mentioned doing it yourself.

Originally Posted by Katie Boundary

The difference is that one is my method and the other isn't.

So lets ignore the screenshot showing the lack of difference shall we? And lets avoid explaining any specific differences while you're at it.

Originally Posted by Katie Boundary

And now, back to serious discussion:

Are you leaving the thread, or planning to finally upload a sample encode?

[videoh]

Originally Posted by JoelHruska

If I need to specifically drop back to 32-bit for everything to make DGDecode work and there's no functional x64 equivalent, I can bring up a new system tomorrow.

Don't you know that you can run 32-bit stuff on a 64-bit system? Or did I misunderstand you?

[hello_hello]

Originally Posted by manono

I do that myself. For one thing, it keeps a screwed up plugins folder from also screwing up your scripts, things such as multiple and conflicting versions of the same filter. Like you, I also thought it screwy that he was trying to do everything in 64-bit.

Not to mention that most GUI's have their own collection of plugins and load them automatically in scripts so they don't require Avisynth to be installed. The newer StaxRip comes in a 64 bit flavour only, with Avisynth and plugins to match, as far as I know, so I assume that's why he needs 64 bit plugins.

There's a 64 bit version of DGDecode here.
I know nothing about MPEG2DecPlus. I don't know which one StaxRip uses.
I guess videoh would know more about the different flavours.

Originally Posted by manono

Then you make the case for bobbing it and calling it a day. That would be a helluva lot easier, that's for sure. Either that or doing a VFR encode, something for which I, personally, have no use.

What's the disadvantage of VFR?
Avisynth outputs the average frame rate when you use TFM for the process, so you can still apply filtering to the output using a program that only supports a CFR if need be. It doesn't become VFR until the final encoding/muxing stage.

[videoh]

manono didn't say there were disadvantages, only that he has no personal use for it.

[hello_hello]

Originally Posted by videoh

manono didn't say there were disadvantages, only that he has no personal use for it.

His comment implied a bobbed CFR output suits him better, and therefore logically offers some advantage, even if it's only specific for his needs, so I found myself wondering what that might be.
Of course he may do something entirely different again, such as always converting to a 23.976 or 29.97 CFR, but as his comment implied otherwise, I thought I'd ask.

PS In case you missed the edit of my previous post, can you provide any insight regarding the different flavours of 64 bit DGDecode?

[huhn]

if you bob it you should do 60 fps.
if you have a problem with 3:2 judder in the source then you are totally doomed with 30 fps because it's not even possible to get a 3:2 judder in 30 progressive with 24p source you get something far worse.
in fields is 4:2:2:2.

[Boulder]

NTSC VFR is a problem if you playback content using Kodi.

[Katie Boundary]

Originally Posted by videoh

Don't you know that you can run 32-bit stuff on a 64-bit system? Or did I misunderstand you?

Joel writes for ExtremeTech about such topics as microwaves with built-in Wi-fi and smart toilets with personal butthole recognition so I assume he's aware that 64-bit versions of Windows have a 32-bit application compatibility layer.

Originally Posted by huhn

if you bob it you should do 60 fps.
if you have a problem with 3:2 judder in the source then you are totally doomed with 30 fps because it's not even possible to get a 3:2 judder in 30 progressive with 24p source you get something far worse. in fields is 4:2:2:2.

I've never found either to be noticeable, but it may be moot. If Joel goes with my blend approach, then there won't be any true 60 hz content left, and he might be able to safely decimate down to 48 without losing any unique frames.

[hello_hello]

Originally Posted by huhn

if you bob it you should do 60 fps.
if you have a problem with 3:2 judder in the source then you are totally doomed with 30 fps because it's not even possible to get a 3:2 judder in 30 progressive with 24p source you get something far worse.
in fields is 4:2:2:2.

Doesn't that depend how it was telecined?

ie a 3:3:2:2 pattern vs 3:2:3:2

https://en.wikipedia.org/wiki/Telecine#2:3_pulldown

This results in a 3:2 pattern using a progressive source.

AssumeFrameBased
SeparateFields
SelectEvery(8, 0,1, 2,3,2, 5,4, 7,6,7)
Weave
Yadif(mode=1)

[videoh]

Originally Posted by hello_hello

can you provide any insight regarding the different flavours of 64 bit DGDecode?

I haven't looked at any of them or tried them until now. I just now played around with the one here: https://github.com/Asd-g/MPEG2DecPlus (version 8). It seems to work very fine and I am impressed by the amount of work put in to create it. Bravo Chikuzen and others!

[huhn]

doesn't matter if the end product is progressive.

these 3:3:2:2 stuff is in field don't forget in progressive we don't have fields so they have to be a power of 2.

3:2 judder in 720p60 is a used term but it is meant in progressive frames.

[hello_hello]

Originally Posted by Katie Boundary

I've never found either to be noticeable, but it may be moot. If Joel goes with my blend approach, then there won't be any true 60 hz content left, and he might be able to safely decimate down to 48 without losing any unique frames.

I suspect he'll see it looks horrible. And probably wonder why the picture jitters back and forth.

PP=5 isn't blend de-interlacing as such.

Some of the CGI sections need to be treated as video to make them smooth, during fades between shots, or probably during some text overlays, even though they're technically hard telecine. That's exactly what your method is designed to achieve isn't it?
You can't bob them to 59.94fps and decimate to 48fps. Wouldn't that be much the same as de-interlacing them to 29.97 fps and decimating to 23.976?

Have you tried decimating your "blend approach" to 48fps to see how it looks?