Deep Space Nine upscale project

[JoelHruska]

What are your QTGMC calls specifically? QTGMC is great and can be used on progressive material, but most of this series does not need it. There are a handful of 60i sequences throughout and that's it.

My intended tutorial workflow doesn't require scene-by-scene editing, and applying QTGMC in repair mode smooths certain AA issues that otherwise crop up. For example, the horizontal grid on the bottom of the Miranda-class saucer:

https://www.youtube.com/watch?v=RC_VQ_n0kA0

Set for 4K, look at the 4-second mark, and you'll see the shimmering pattern. This can be completely eliminated.

https://www.youtube.com/watch?v=oSOR2Uk1aCg

It can actually be eliminated even better than *that*, but with worse judder control. But regardless, QTGMC repair is a functional necessity for that kind of visual improvement. I've tested leaving it off. Unfortunately, I'm losing a bit of detail to YT in a rather important spot, but for a comparison between running just QTGMC in repair mode and using it in combination with the aforementioned D9D interlace filter, see here:

https://www.youtube.com/watch?v=IjVBE0GQvuo

This is the encode I call "5Sharp." QTGMC in repair-mode only. Note the two Jem'Hadar ships with the series of lines on the bottom that pivot into view towards the end of the clip. Before it goes through YouTube upload, on 5Sharp, the bottom of those ships is completely clean. No shimmer. YT is putting some of the distortion back, unfortunately.

Using what I call the "Doom 9 Deinterlacer" (posted on Page 1) in combination with QTGMC makes motion smoother but also loses a bit of clarity on lines. There's also more shimmer on the Galaxy-class windows in the upper-left-hand corner of the screen (check 0:15 - 0:17 seconds) when the D9D solution is used in combination with QTGMC.

https://www.youtube.com/watch?v=FKI9vO4FacQ

The reason to use QTGMC and D9D together is that the D9D deinterlacer alone produces errors and reversed movement in some of the frames during Sacrifice of Angels in a way that is visible during normal playback. Adding QTGMC repair resolved the problem.

I need to actually go post test scripts from downstairs, so I'll drop them in a separate post below. I don't have them duplicated on this system.

I am not "attached" to Handbrake. I am using Handbrake for two specific reasons:

1). DaVinci Resolve Studio will not ingest an MPEG-2 file in any guise *or* an MKV file of any type. Any workflow that begins with DaVinci Resolve Studio must therefore use a non-MKV file (M4V is acceptable to DRS).


2). I don't have a solution for rendering a VFR properly in AviSynth that keeps the A/V aligned when processed via StaxRip, despite repeated attempts to resolve this problem.


So right off the bat, we have two different sets of dependencies that must be resolved:

Beginning with DaVinci requires a non-MPEG-2, non-MKV source: Handbrake.

Beginning with StaxRip and MakeMKV results in a misaligned file. Using commands like "ntsc_film" or setting the file output to 23.976fps in the H.264 encoder will pull the frame rate down from the default 24.66 fps (don't ask me why StaxRip picks 24.66 fps, it just does) down to the appropriate 23.976 fps, but the audio is still improperly synchronized from minute one.

Beginning with StaxRip and an M4V file created in Handbrake will automatically fail; StaxRip cannot mux the audio back together properly.

One final thing to keep in mind: I have absolutely zero control over any encode settings whatsoever from Topaz Video Enhance AI. The application strongly prefers encodes in the 2GB - 4GB range based on my observations. Feeding it 12-24GB source files will still result in a final output of 2-4GB.

One other tidbit from before I go get code: Topaz Video Enhance AI is capable of performing single-stage ingestion if configured to do so using AVFS. I've done the entire AviSynth encode + upscale process in the application at once before. I don't actually know how this would have handled the audio, however, because I used Version 1.1.1 of the program, which did not feature audio pass-through support. The new version does, but I have not repeated this test yet.

Be advised that TVEAI quality continues to shift from version to version. I have all of the releases archived so I can pick and choose which filter implementation I want for the final product.

[JoelHruska]

Here's the QTGMC repair script I use. This works very well, as far as repairing various source errors and resolving a great deal of aliasing and flickering lines.

I have *extensively* tested QTGMC's repair functions as they apply to DS9 in general and Sacrifice of Angels in particular.

The only downside of this filter is that it does absolutely nothing to fix the credits -- in fact, the juddering it introduces has to be fixed itself through the application of further processing:

5Sharp QTMGC

QTGMC2 = QTGMC(Preset="Very Slow", SourceMatch=3, InputType=2, MatchEnhance=0.75, Sharpness=0.5, MatchPreset="Very Slow", MatchPreset2="Very Slow")
QTGMC3 = QTGMC(preset="Very Slow", inputType=3, prevGlobals="Reuse")
Repair(QTGMC2, QTGMC3, 1)

The 0.5 sharpness is where the name "5Sharp" comes from. I tested every single option (0.1 - 1.0) and settled on 0.5 for best practices. Increasing this further can help if you apply additional filters that create blur. I tested Interframe, for example, as a means of offsetting judder, as well as adding MotionBlur to the episode to offset it. Ultimately I've stuck with neither approach, but if you wanted to use them, I'd tweak the sharpness setting here to compensate.

I have tested every combination of "InputType" that exist within this formula (1,1 - 1,2 - 1,3 - 2,1 - 2,2 - 2,3 (etc, etc) and experimented with various other custom settings as well. This is the best filter set I've come up with for keeping the frame rate at 23.976fps, smoothing motion, and eliminating the occasional 3:2 pulldown and deinterlaced frames.

5Sharp + D9D

This results in ~48 fps output (60 fps if used on a VOB extracted via DVD Encrypter and then rendered in StaxRip / AviSynth as below):

Y=nnedi3(field=-2)
A=yadifmod2(mode=1,edeint=Y).selecteven()
B=yadifmod2(mode=1,edeint=Y).selectodd()
C=Tfm(field=1,mode=0,cthresh=2,mthresh=2,clip2=A,micmatching=0)
D=Tfm(field=0,mode=0,cthresh=2,mthresh=2,clip2=B,micmatching=0)
Interleave(C,D)
QTGMC2 = QTGMC(Preset="Very Slow", SourceMatch=3, InputType=2, MatchEnhance=0.75, Sharpness=0.7, MatchPreset="Very Slow", MatchPreset2="Very Slow")
QTGMC3 = QTGMC(preset="Very Slow", inputType=3, prevGlobals="Reuse")
Repair(QTGMC2, QTGMC3, 1)

The advantage of this method is that it solves the judder issues in 5Sharp. The disadvantage is that it walks back some of the AA improvements. StaxRip only includes native support for three AA methods that are classified as such (SangNom, DAA, MAA), and of the three, I have found DAA3Mod more effective. I have noticed that there are more options available on the VapourSynth side of things, but I do not know how to code for VapourSynth yet and have not tested them.

The D9D deinterlacer introduces some flicker on windows that I haven't figured out how to eliminate without using DaVinci Resolve Studio, but I'm trying to avoid doing that for my completely free tutorial pathway.

I have also tested every single "Input Type" shift that exists within the above, meaning I rendered the D9D encode path 9 different ways to see the impact of repairing the footage with each different method. I also experimented with accelerating and decimating this footage in QTGMC before using secondary repair methods to smooth it. Ultimately, there are better ways to accomplish this kind of conversion, so I abandoned the attempt. You can, amusingly, use QTGMC to interpolate a 119.88 fps frame rate out of 23.976 fps, and then use various decimation methods (Even, Even, Odd, Even, Odd, Odd) to calculate which frames to dump and which to keep. Lots of interesting results and visual patterns came out of this test series, but nothing that really moved the project forward).

I've experimented extensively with various denoise and degrain filters, attempts to fix moire (the Borg ship in Emissary is a horror show of crappy video quality), color tweaks, and such, but all of that fits into "experimentation" and isn't really part of the core work I'm doing. I've shied away from much in the way of noise removal, because TVEAI already implements its own denoise / deblocking, and I don't want to lose data before I chuck the files in for processing.

One point I am considering is whether earlier seasons require a different approach than later seasons. As weak as the overall DVD quality is, the early seasons are worse than the later by a significant margin.

[JoelHruska]

One last point: I'm aware that I'm throwing far more firepower at a project of this nature than is typically available to most people. I don't bring that up to brag. I bring it up because I've got far more freedom to run test encodes to see what things look like than most people do.

I don't care about encode times. I literally don't care if it takes 4 days to run one encode. If that's a problem, I'll just launch more encodes, some of which will take less than four days. I am aware that threading support can be dicey, so while I've tested the impact of using multi-threading in AviSynth+ (which is what StaxRip requires), I mostly just let stuff run in default threading modes, then run more encodes to compensate.

I am happy to launch 20 - 40 encodes of the same episode at once with completion times between 2 hours and 4 days to give myself enough to do while waiting for long-term tests to complete.

I also don't care at all about file sizes right now. That's something I'll trim down later, once I know what the best-achievable quality is.

[poisondeathray]

Right now, I'm wondering what the best way is to get moire out of the early show credits and out of Episode 1-1, Emissary, where the Borg cube is absolutely riddled with it. Is there a way to remove the rainbow effect with a filter, or does it have to be done by hand?


Aliasing and moire patterns can be difficult to remove without degrading the footage or oversmoothing.

One way to approach the credits is to mask /roto them out and filter them differently

Has anyone compared the intros in terms of aliasing (not the text)? Are they exactly the same in say episode1,2,3 ... ? There are ways of signal averaging that might help if there are minor differences, then you can add back the text

Rainbows can be filtered with derainbow filters (most essentially blur the chroma, or some variations)


One question I'd really like to know the answer to, if anybody does: Everyone talks about H.265 in terms of its ability to deliver high-quality results in a smaller file size. I don't really care about that aspect of it. What I'm curious about is this: Does H.265 ever produce better visual results than H.264? Are there times when one should use H.265 rather than H.264 because it results in a higher quality picture *in absolute terms, regardless of file size?*


In absolute terms, both can be lossless, so your question is not phrased very well.

If you use lossless or near lossless with h265, but not with h264, the h265 encode is going to be better in all categories except filesize

Better compression efficiency implies higher quality at a given filesize (bitrate). (But "quality" is difficult to measure or define)






My intended tutorial workflow doesn't require scene-by-scene editing, and applying QTGMC in repair mode smooths certain AA issues that otherwise crop up.


But are you blindly applying that to everything ?

It's counter productive if your goal is to upscale. It's quite destructive to details. You should only use selectively it on problem areas

Are you aiming for ideal results, or more for ease of use workflow?




One final thing to keep in mind: I have absolutely zero control over any encode settings whatsoever from Topaz Video Enhance AI. The application strongly prefers encodes in the 2GB - 4GB range based on my observations. Feeding it 12-24GB source files will still result in a final output of 2-4GB.


Export an image sequence like PNG or TIFF instead . Then compress that properly afterwards. That's the ideal lossless workflow out of of Enhance

[zapp7]

applying QTGMC in repair mode smooths certain AA issues that otherwise crop up.

Doesn't the use of QTGMC degrade the spatial resolution? My limited understanding of de-interlacing is that half the resolution is lost.

I'm not sure if it's because of YouTube's encoding, but those ships look a bit smoothed for my tastes and I find they have more of a cartoon-ish look. Too each their own, though.

I just went through Sacrifice of Angels using the override file method, and I'm happy with the results. The pulldown effect is removed by TFM in over 99% of the episode, and QTGMC takes care of the few combed frames that are left. The majority of the frames are pretty much unprocessed and left intact. A lossless input is fed to Topaz and there are no audio sync issues with the final result. Making override files is a bit annoying, but not super time consuming and once they're made, they can be shared with others.

It may just be that I'm not observant enough to notice the issues you're trying to address.

One point I am considering is whether earlier seasons require a different approach than later seasons. As weak as the overall DVD quality is, the early seasons are worse than the later by a significant margin.

I noticed this as well! I think the change may have coincided with the revamped intro they introduced in Season 4. The Topaz output looks far superior in later seasons. I wonder if a different Topaz setting (i.e. HQ vs LQ) should be applied before and after this change?

[JoelHruska]

But are you blindly applying that to everything ?

It's counter productive if your goal is to upscale. It's quite destructive to details. You should only use selectively it on problem areas

Are you aiming for ideal results, or more for ease of use workflow?

You can see the results for yourself. That's why I'm uploading the clips, is so people can see the outcomes in ways that aren't just theoretical.

(I realize that YT takes its own pound of flesh, so I may start using Vimeo, but I can't fix that problem right now): Set for 4K viewing in all cases when available.

First Fleet Attack:

DVD:

https://youtu.be/f56nFLey724

Upscaled MKV:

https://youtu.be/DzeENB9JKmE

Rubicon (My own upscaling workflow, including QTGMC applied as above):

https://youtu.be/8DwfHADU0QY

The first few seconds of this video, in comparison to the upscaled MKV, are the perfect selling point for Rubicon as compared to the other methods (in my own opinion). The approach is far smoother. There's far less shimmer.


Second Fleet Attack:

DVD:

https://youtu.be/MzJx0uuaTko

Upscaled MKV:

https://www.youtube.com/watch?v=RC_VQ_n0kA0

Rubicon:

https://youtu.be/oSOR2Uk1aCg

Conversation on Defiant:

DVD:

https://www.youtube.com/watch?v=niwY_UkcKAA

Upscaled MKV:

https://www.youtube.com/watch?v=1ePspekugbs

Rubicon (100ms audio offset in this video, since corrected):

https://www.youtube.com/watch?v=QQbX48HSA2U

These clips compare the original DVD source against an MKV file that's been fed through Topaz VEAI using the Gaia-CG preset against "Rubicon" -- a DVD source file that I've processed extensively, including temporarily converting it to a 119.88 fps file.

Do you think the look of Rubicon reflects an overall loss of detail or quality level compared to either the MKV upscale or the DVD?



Export an image sequence like PNG or TIFF instead . Then compress that properly afterwards. That's the ideal lossless workflow out of of Enhance

Theoretically possible, but it'll be murder on storage requirements. The output from Topaz VEAI is about 4.8MB per frame per PNG, and about 16MB per frame per TIFF. At 65,000-odd frames of content, that's about 320GB per episode if you use PNG, and about 1TB per episode for TIFF.

I could build a workflow around sizes that large, but I'm not planning to do it.

[poisondeathray]

You can see the results for yourself. That's why I'm uploading the clips, is so people can see the outcomes in ways that aren't just theoretical.

(I realize that YT takes its own pound of flesh, so I may start using Vimeo, but I can't fix that problem right now): Set for 4K viewing in all cases when available.



It's not very useful to compare on youtube; vimeo is slightly better but still not ideal.

I'm not disputing the usefulness reduction in shimmer on sections that require it. I'm saying you're going to lose details in other sections that do not have shimmer to begin with. It's a destructive filter - it's not some theoretical loss of details; this is how the filter works. Actual details are discarded before you upscale.

It doesn't make sense in my mind to jump through all these hoops and they dummy it down with crappy encoding quality, or to discard actual details before upscaling. It's your choice, you decide where you are willing to make compromises

[videoh]

I'm aware that I'm throwing far more firepower at a project of this nature than is typically available to most people. Wow, you're so awesome. Where is the 'bow down peons' smilie?

[JoelHruska]

Read the next sentence. The point is not braggery. The point is to arrive at a better final result by being willing to evaluate every potential outcome, partly because, as I have written publicly in numerous stories, I am a giant n00b.

I have the following hardware available to me for this project:

AMD Ryzen Threadripper 3990X
AMD Ryzen Threadripper 3970X
AMD Ryzen 9 3950X
Intel Core i9-10980XE
Intel Core i9-9980XE
Intel Core i9-9900K
Intel Core i9-9980HK

I also have: Two RTX 2080s, two RTX 2070s, three RTX 2060s, a 1080 Ti, and a GTX 1080.

I can bring 3-4 of these systems up at once. Currently, I'm using two of them -- the 3990X and the 10980XE. The 9980HK is on "hot standby" I suppose you could say. I'm willing to put more into service if it allows for more effective / efficient testing.

I'm not sitting here trying to preen. I'm trying to deploy available hardware resources to best test potential outcomes. If you're willing to engage with that, by all means, feel free. If you want to turn the facts of my job into some kind of pretended and pretentious value judgment by me, you can have that discussion with yourself. I won't be participating.

[JoelHruska]

It's not very useful to compare on youtube; vimeo is slightly better but still not ideal.

I'm not disputing the usefulness reduction in shimmer on sections that require it. I'm saying you're going to lose details in other sections that do not have shimmer to begin with. It's a destructive filter - it's not some theoretical loss of details; this is how the filter works. Actual details are discarded before you upscale.

It doesn't make sense in my mind to jump through all these hoops and they dummy it down with crappy encoding quality, or to discard actual details before upscaling. It's your choice, you decide where you are willing to make compromises

So, what you propose is something more along these lines:

MakeMKV or Handbrake directly into Topaz VEAI. Upscale.
Test everything else *post* upscale.

I hadn't done this, for the simple reason that Topaz VEAI has no idea how to handle a VFR file. Given the input from MakeMKV, it will read a file with some 80,000+ frames and encode the entire output at 29.97 fps. The output from Topaz VEAI if handed MakeMKV source will have to be pulled through another framerate conversion. This is another hidden dependency / problem.

If I encode losslessly in Handbrake and use CFR at that point, I could pull the file directly into Topaz VEAI. However, remember, I have no control over Topaz VEAI's settings at this point. Any detail it throws away is going to be lost forever.

So...

Your proposed workflow appears to be:

Handbrake Source (CFR file, to allow for proper Topaz ingestion). ~6GB initial file.
Topaz VEAI upscale. (~2GB output file, despite 4x nominal resolution upscale).
Followed by either:

DaVinci Studio Resolve (for interpolated or dummy frame rate conversion) + AviSynth (for decimation and QTGMC repair).

or

AviSynth (for QTGMC repair) followed by DaVinci Studio Resolve (for interpolated / dummy frame rate conversion)

With an optional final AviSynth run to yank the frame rate back down, if desired.

Obviously the DaVinci runs can be left out entirely if desired, but I'm fitting this to the workflow I'm actually using at the moment.

I'll get started on this today. The upscale alone will take about 10 hours, so it'll be tomorrow before I have results. I'll test both workflows and see how they compare.

[poisondeathray]

You're shooting yourself in the foot and leaving details on the table before you even upscale.

The amount of detail loss will be approx. proportional to the amount of motion in the scene. The more motion in the shot, the more details you will lose . With very low or no motion, you might not lose much.

IVTC, vs. your "5sharp". Here is an animated webp. Most browsers should be able to display it. It's 1:1 crop , non par corrected, and I brightened it up a bit

https://forum.videohelp.com/threads/395895-animated-webp-test#post2582929

or if you prefer png (hit 1 or 2 number keys) . I couldn't get animated png to embed on d9
http://www.framecompare.com/image-compare/screenshotcomparison/9JC2JNNU


Look at the blurred away skin textures,loss of wrinkles around the eye, neck textures blurred away - this guy looks 3 years younger now. The specular highlights in the hair are reduced. Costume (leather?) textures are softened .

It's not show in this frame comparison, but there are temporal artifacts in adjacent frames - the teeth are discolored from ghosting , the ear ridges are distored along a different direction

The point is - if 99% of it is 23.976p, it doesn't make any sense to dumb down 99% to fix 1% . You should apply the damaging filters selectively.






So, what you propose is something more along these lines:

MakeMKV or Handbrake directly into Topaz VEAI. Upscale.
Test everything else *post* upscale.

I hadn't done this, for the simple reason that Topaz VEAI has no idea how to handle a VFR file.


No.

Proper preprocessing is essential prior to upscaling

If 99% of it is 23.976, it doesn't make any sense to dumb down 99% to fix 1% . You should apply the filters selectively.

The way you handle VFR is external timecodes . Each program does not need to know it's VFR, or what the frame rate is, they just look at "frames"

Best practices is going to be VFR . Everything runs at the proper framerate. The only problem is mixed sections with multiple frame rates within the same frame (eg. text overlays over 23.976p sections) . Those I would mask out and treat differently. I imagine the only differences should be the guest stars per episode

I use RGB images into upscale because you can control the RGB conversion (chroma upscaling algorithm used) and you can scale it full range (and scale it back when converting back to YUV) . It makes a difference on things like space scenes. Or even indoor scenes with bright lights , or dark shadows regions. AI Upscale will use a standard range conversion if you feed it YUV - it will clip Y16-235 instead of preserving all the data 0-255.


You can choose where you want to make trade offs in the workflow, but the one thing you should not ever do is apply a damaging filter like QTGMC in progressive mode to every frame.

[videoh]

If you want to turn the facts of my job into some kind of pretended and pretentious value judgment by me, you can have that discussion with yourself. I won't be participating. That's great. I can pontificate at will. You know you sound like a condescending and entitled prima donna, right? Is that working for you in life? Bluster and bullying can take you only so far.

[poisondeathray]

Export an image sequence like PNG or TIFF instead . Then compress that properly afterwards. That's the ideal lossless workflow out of of Enhance


Here's a demo illustrating what you "leave on the table" by using mpeg4 output. Note it's using mpeg4-asp (xvid)

Maybe in future versions, they will have more control over the export settings, such as using AVC, or higher bitrates, but right now, it' s a TERRIBLE idea. You're shooting yourself in the other foot.

This is non par corrected. It's just a straight IVTC and upscale from one of the samples posted. No preprocessing. Export out of Upscale AI

mpeg4 output
https://i.postimg.cc/qByRNhSM/mpeg4.png

png output
https://i.postimg.cc/d0gs1w9y/png.png

Notice the blocky compression artifacts and poor shadow detail. Any details that you upscale in darker areas are going to become blocky artifacts. That's before you even upload to YT or whatever you're planning on doing.

It's a complete waste of time to upscale if you're going to use mpeg4 output

So those 2 things are the absolute must not do's

[SaurusX]

divx had its day, but it's long past. With Topaz you have to export to PNG if you want quality. And if you don't then what's the point of this project?

[zapp7]

I use RGB images into upscale because you can control the RGB conversion (chroma upscaling algorithm used) and you can scale it full range (and scale it back when converting back to YUV) . It makes a difference on things like space scenes. Or even indoor scenes with bright lights , or dark shadows regions. AI Upscale will use a standard range conversion if you feed it YUV - it will clip Y16-235 instead of preserving all the data 0-255.


I'm quite interested in this - how would one convert to RGB with this workflow? (and then back to YUV)

DVD Decrypter -> DGIndex -> AviSynth(TFM, TDecimate) -> Topaz

mpeg4 output
https://i.postimg.cc/qByRNhSM/mpeg4.png

png output
https://i.postimg.cc/d0gs1w9y/png.png

Notice the blocky compression artifacts and poor shadow detail. Any details that you upscale in darker areas are going to become blocky artifacts. That's before you even upload to YT or whatever you're planning on doing.

Damn, you've convinced me to switch to image output. I'll have to redo the 10 or so episodes I've already done. One question: Is .png or .tiff better? I've heard competing claims in that regard. Which one preserves more quality?

[JoelHruska]

*snip*
No.

Proper preprocessing is essential prior to upscaling

If 99% of it is 23.976, it doesn't make any sense to dumb down 99% to fix 1% . You should apply the filters selectively.

The way you handle VFR is external timecodes . Each program does not need to know it's VFR, or what the frame rate is, they just look at "frames"

Best practices is going to be VFR . Everything runs at the proper framerate. The only problem is mixed sections with multiple frame rates within the same frame (eg. text overlays over 23.976p sections) . Those I would mask out and treat differently. I imagine the only differences should be the guest stars per episode

I use RGB images into upscale because you can control the RGB conversion (chroma upscaling algorithm used) and you can scale it full range (and scale it back when converting back to YUV) . It makes a difference on things like space scenes. Or even indoor scenes with bright lights , or dark shadows regions. AI Upscale will use a standard range conversion if you feed it YUV - it will clip Y16-235 instead of preserving all the data 0-255.


You can choose where you want to make trade offs in the workflow, but the one thing you should not ever do is apply a damaging filter like QTGMC in progressive mode to every frame.

Alright. So how, then, does one generate / extract a proper timecode for this kind of operation? I attempted to do so via several methods, but never managed it successfully when using MakeMKV source.

Well, either I never successfully managed it, or I managed it but the audio was still misaligned. I genuinely forget which. I pivoted to investigate other methods of frame rate adjustment because I was having trouble with VFR ingestion.

I would be more than happy to test the impact of applying QTGMC and other repair methods on a frame by frame scripted basis, at least in a trial basis. I do not necessarily anticipate writing custom scripts for each and every episode, but I would be very happy to test the impact of this method of repair versus the more global application method I've been using.

[JoelHruska]

That's great. I can pontificate at will. You know you sound like a condescending and entitled prima donna, right? Is that working for you in life? Bluster and bullying can take you only so far.

That's your interpretation. Another interpretation is that I'm compensating for my complete lack of knowledge by running tons of encodes while painfully aware that if I knew what I was doing, I wouldn't have to. This interpretation has the benefit of being supported by evidence, including quotes from my own articles like these:

"I’m never going to be able to make these old DVDs look as good as what Paramount could do. Heck, I’m never going to improve them as much as a professional video editor could do. But Paramount has no plans to upgrade DS9 itself, and that means the only way to restore the TV show to some semblance of how it could look is with a lot of elbow grease, filter testing, and one exhausted RTX 2080. I think the work deserves to be done, even if Paramount disagrees."

https://www.extremetech.com/extreme/308505-star-trek-deep-space-9-upscale-project-update

"despite having no previous experience or education in video editing."

"Paramount could build a better version of the show than I could even hope to create — but since they aren’t going to bother, I figure I’ll keep up my own efforts."

I have referred to myself as "Barely video literate."

https://www.extremetech.com/extreme/309653-deep-space-nine-upscale-project-update-variable-frame-rate-dvds-can-burn-in-hell

I have talked about various issues which have confused and perplexed me (in the same link). I have admitted to previous mistakes made in earlier articles (in the same link).

My own project goals include statements like: "Be willing to laugh at some of the ridiculously bad quality encodes you will occasionally create, especially if it takes 1-2 days to create them."

https://www.extremetech.com/extreme/310224-deep-space-nine-upscale-project-ds9up-technical-goals-and-faq

But sure. Having repeatedly called myself a newb, the most obvious explanation for why I made that statement about available hardware is to somehow establish myself as having enormous credibility in front of a group of people I made it clear I don't expect to find me credible.

Newsflash: I don't consider owning a 3990X to be worth much in the way of credibility. The only thing the CPU is good for, absent knowing *what* code to run on it, is running lots and lots of code at once. I'm aware of that. I assumed you were, too.

Alternately -- and I'm just spitballing here -- you might conclude I emphasized my willingness to run a lot of different render tests as a way of illustrating my good faith and commitment to a project, despite the fact that I'm completely new at this. I didn't come here to impress anyone with the size of my CPU cores. I didn't come here to impress anyone at all. I came here to find better information on how to rip DVDs to create a better effective remaster of Deep Space 9, because this is the forum to come to for that kind of information.

Because I didn't want to be viewed as an imposter, I waited until I'd put in three months of work and rendered out a great deal of footage to even start having the conversation. Because I take what you guys know seriously. Because I take your expertise seriously. Because I, also, want to be taken seriously as someone who is here to learn and who cares about this content. So I emphasized what I can do and how seriously I'm taking it.

You can decide which of these reasons you find more persuasive. I'm done with the topic.

[JoelHruska]

I'm quite interested in this - how would one convert to RGB with this workflow? (and then back to YUV)

DVD Decrypter -> DGIndex -> AviSynth(TFM, TDecimate) -> Topaz



Damn, you've convinced me to switch to image output. I'll have to redo the 10 or so episodes I've already done. One question: Is .png or .tiff better? I've heard competing claims in that regard. Which one preserves more quality?

It's not just going to be a question of quality. Upscaled episodes are about 16MB per frame at 400%, from my own testing. PNGs are about 4MB. That's going to take 335GB - 1TB of storage per uncompressed episode, assuming you do the entire episode at once.

That is how you get lossless, however.

I have not compared the quality difference between 16-bit TIFF and PNG and cannot comment on which is better.

[SaurusX]

It's not just going to be a question of quality. Upscaled episodes are about 16MB per frame at 400%, from my own testing. PNGs are about 4MB. That's going to take 335GB - 1TB of storage per uncompressed episode, assuming you do the entire episode at once.

That is how you get lossless, however.

I have not compared the quality difference between 16-bit TIFF and PNG and cannot comment on which is better.

I don't think the difference between PNG and TIFF can be appreciated with human eyeballs. And the episode is only lossless until you use ffmpeg (or whatever) to encode that string on pictures into a final video. Then you're looking at 2-4GB per ep depending on the quality settings.

[poisondeathray]

I'm quite interested in this - how would one convert to RGB with this workflow? (and then back to YUV)

DVD Decrypter -> DGIndex -> AviSynth(TFM, TDecimate) -> Topaz




If you want full range, in avisynth you would use the "PC matrices" . This "maps" Y 0-255 <=> RGB 0-255 . So the contrast will look lower , washed out. But that doesn't matter, you'll fix it later. The goal is to preserve all the details, instead of clipping some data prior to upscaling.
ConvertToRGB24(matrix="PC.601")

You can also control the upsampling algorithm. By default "bicubic" is used for avisynth. Maybe you want sharper chroma scaling, or maybe less sharp. Maybe you want to use some more exotic chroma interpolation upscaling methods before the Upscale AI stage.

(This is f^&%^ slow, but can work ok on some types of content)
https://forum.doom9.org/showthread.php?t=173005

After the upscaling stage, it's better to adjust it in another application, such as resolve or any NLE. You have more control to adjust more shadow details or super bright details and to bring the contrast back.



Is .png or .tiff better? I've heard competing claims in that regard. Which one preserves more quality?

In theory both should be the same . PNG just uses lossless compression. TIFF can use lossless or lossy compression, but most variants use uncompressed lossless. Another potential issue is some applications write colr tags in PNG, this can cause some programs to display the colors slightly shifted. For example ffmpeg writes PNG with this when the input file has colorimetry tags. Upscale AI does not do this (untagged), so PNG output is fine.

[poisondeathray]

Alright. So how, then, does one generate / extract a proper timecode for this kind of operation? I attempted to do so via several methods, but never managed it successfully when using MakeMKV source.

Well, either I never successfully managed it, or I managed it but the audio was still misaligned. I genuinely forget which. I pivoted to investigate other methods of frame rate adjustment because I was having trouble with VFR ingestion.

I would be more than happy to test the impact of applying QTGMC and other repair methods on a frame by frame scripted basis, at least in a trial basis. I do not necessarily anticipate writing custom scripts for each and every episode, but I would be very happy to test the impact of this method of repair versus the more global application method I've been using.


Timecode VFR is too big of a discussion to go into for this thread - but the information is out there, examples this forum and others. There are guides around as well. 2pass TIVTC VFR is a commonly used method for avisynth. But if you 've looked at some earlier posts, some overrides might be necessary for some sections

Definitely there are some bad aliasing sections, and those need attention. But I'm suggesting you filter those separately. It's way too damaging to apply to the 99% of content for scenes with motion.

It's easy in avisynth to apply different filters to different sections (it's not really "frame by frame") - But how do you "automatically" identify those with any accuracy without human eyes? I don't know.

[zapp7]

If you want full range, in avisynth you would use the "PC matrices" . This "maps" Y 0-255 <=> RGB 0-255 . So the contrast will look lower , washed out. But that doesn't matter, you'll fix it later. The goal is to preserve all the details, instead of clipping some data prior to upscaling.
ConvertToRGB24(matrix="PC.601")

You can also control the upsampling algorithm. By default "bicubic" is used for avisynth. Maybe you want sharper chroma scaling, or maybe less sharp. Maybe you want to use some more exotic chroma interpolation upscaling methods before the Upscale AI stage.


So before feeding into Topaz, I do ConvertToRGB24(matrix="PC.601"), and after upscaling with Topaz I convert back with ConvertToYV12(matrix="PC.601"). Is that right?

I'm also not using any other upscaling algorithm other than the Topaz software.

[Chir]

Do you correct for the SAR at any point later in the process? I ask because this command appears to produce a horizontally stretched image. It's not super obvious but it's evident if you compare your output it to the original DVD footage. I used the codec because it's my understanding that SAR can't be corrected using the "copy" command. I read that CF 0 H.264 is lossless so I was hoping that would be sufficient.

I have about 10 episodes "complete", and I put that in quotes because I feel as though I am still learning the whole process and making refinements. There are undoubtedly errors in what I have. Should I share anyway? What do you think?

I wasn't aware of the SAR issue -- I'll take a peek at my results and see if I notice anything. Thanks for the heads up!

Please! Share what you have in the git hub! If github is intimidating (and it really can be!) feel free to just send me an email and I'll put them in for you. What I have out there is not yet complete, either -- and I think the best way is just to share share share. I'd like to see a "signoff process" where a couple people go through each episode and give a thumbs up to cross check.

[poisondeathray]

So before feeding into Topaz, I do ConvertToRGB24(matrix="PC.601"), and after upscaling with Topaz I convert back with ConvertToYV12(matrix="PC.601"). Is that right?

I'm also not using any other upscaling algorithm other than the Topaz software.

Yes, that essentially does the reverse operation back to YV12 in full range

But you will get generally better results if you take the time to adjust it in another program. Often the way these TV shows are graded , they are "harsh", and the shadow detail is all clustered together instead of gradual tonal separation

[JoelHruska]

Timecode VFR is too big of a discussion to go into for this thread - but the information is out there, examples this forum and others. There are guides around as well. 2pass TIVTC VFR is a commonly used method for avisynth. But if you 've looked at some earlier posts, some overrides might be necessary for some sections

Definitely there are some bad aliasing sections, and those need attention. But I'm suggesting you filter those separately. It's way too damaging to apply to the 99% of content for scenes with motion.

It's easy in avisynth to apply different filters to different sections (it's not really "frame by frame") - But how do you "automatically" identify those with any accuracy without human eyes? I don't know.


All of my work to shift to 119.88 fps has been undertaken to deal with the VFR problem, that being the strategy described as "most widely compatible" in the AviSynth Wiki.(keeping in mind that I'm writing a tutorial for people to follow, so it needs to as simple as possible).

Right now, the single greatest roadblock to refining my method in the manner you suggest is trying to figure out how to properly generate timecodes in a manner that allow me to keep the A/V synchronized and use MakeMKV in the first place. If I can't handle the VFR output in AviSynth from the start, then I have to perform a framerate conversion no matter what application I pull it into.

But the two things I'm getting out of QTGMC that I functionally care about are:

1). Repair for the interlaced and 3:2 pulldown frames scattered throughout the content.

2). Rather excellent horizontal AA performance, which is particularly helpful in some otherwise jagged scenes.

If I can duplicate those two functionalities in other filters and use a lighter / better touch to fix the errors in the source elsewhere, I'll certainly take a crack at it.

I'll see if I can get some usable timecodes.

[poisondeathray]

All of my work to shift to 119.88 fps has been undertaken to deal with the VFR problem, that being the strategy described as "most widely compatible" in the AviSynth Wiki.(keeping in mind that I'm writing a tutorial for people to follow, so it needs to as simple as possible).

Right now, the single greatest roadblock to refining my method in the manner you suggest is trying to figure out how to properly generate timecodes in a manner that allow me to keep the A/V synchronized and use MakeMKV in the first place. If I can't handle the VFR output in AviSynth from the start, then I have to perform a framerate conversion no matter what application I pull it into.


It's a bit misleading. "119.98" CFR because "23.976" is evenly divisible into it (x5) , and so are all common framerates of 29.97 (x4), 59.94(x2). The frames are "evenly" spaced apart in time, so it's smooth. I dislike it because many displays refresh at 60Hz anyways. And if you have 120Hz or similar judderless display then the point is moot anyways too. Also you encode 5x more frames - it's not insignificant. And 119.98fps UHD is not fun to play back on many systems - so not really that "compatible" in that sense. And if youtube is one of your "goals" for an audience, it's not supported either.

I'm talking about timecode VFR. Each section plays back at it's original framerate. 23.976p sections playback at 23.976 ; 29.97 at 29.97p ; 59.94 at 59.94, or whatever at whatever (some content can have different base frame rates other than those). The only problem is mixed rates in 1 frame - ie. the text and credit overlays. Personally I would take the underlying BG frame rate , but there are ways to interpolate one or the other. I dislike motion interpolation because it's prone to artifacts. If you want to do a good job it takes lots of manual work and motion tracking to guide the motion estimation, along with compositing/masks. (That's a tradeoff I'd be willing to make, I'd just take the BG framerate, and mask out the text to filter differently)

You don't need VFR "within" avisynth, or any program. You can assume any temporary framerate. It's the timecodes afterwards that you mux into the container that control the playback FPS . Each frame is unique, instead of encoded 5x the number of frames with duplicates. Unique frames also helps with temporal filters, such as QTGMC, or others such as temporal denoising. Duplicate frames often cause problems with temporal filters.

The most popular method is the 2pass TIVTC VFR, it's also mentioned in the wiki. That generates timecodes that can be used in MKV (or other containers like MP4). There are more complete instructions in the filter documentation

If there are just a few sections and you know exactly what sections have what (e.g. the intro has aliasing/flicker problems maybe needs some QTGMC in mode 2 or 3, maybe some other section etc...) , then you can just manually specify those, and the timecodes file. It will actually be faster than a 2pass TIVTC run. Have a look at the mkvmerge documentation under the "external timestamp" section. (it used to be called "timecodes", they refer to the same thing). The formatting is very easy for v1 timestamps



But the two things I'm getting out of QTGMC that I functionally care about are:

1). Repair for the interlaced and 3:2 pulldown frames scattered throughout the content.

2). Rather excellent horizontal AA performance, which is particularly helpful in some otherwise jagged scenes.

If I can duplicate those two functionalities in other filters and use a lighter / better touch to fix the errors in the source elsewhere, I'll certainly take a crack at it.

I'll see if I can get some usable timecodes.



If 99% of these DVD's is mostly clean 3:2 pulldown (that's what others are saying), then you should IVTC 99%. That's how you return the original high quality frames to start with before your upscale. Anything other than that will yield lower quality. Period. If you try QTGMC in progresive mode, anything with lots of motion will lead to moderate quality loss before you even start upscaling.

Absolutely QTGMC can play a role in that 1% problem areas, but I would not use it anywhere else - way too damaging

[JoelHruska]

I'm talking about timecode VFR. Each section plays back at it's original framerate. 23.976p sections playback at 23.976 ; 29.97 at 29.97p ; 59.94 at 59.94, or whatever at whatever (some content can have different base frame rates other than those). The only problem is mixed rates in 1 frame - ie. the text and credit overlays. Personally I would take the underlying BG frame rate , but there are ways to interpolate one or the other. I dislike motion interpolation because it's prone to artifacts. If you want to do a good job it takes lots of manual work and motion tracking to guide the motion estimation, along with compositing/masks. (That's a tradeoff I'd be willing to make, I'd just take the BG framerate, and mask out the text to filter differently)

You don't need VFR "within" avisynth, or any program. You can assume any temporary framerate. It's the timecodes afterwards that you mux into the container that control the playback FPS . Each frame is unique, instead of encoded 5x the number of frames with duplicates. Unique frames also helps with temporal filters, such as QTGMC, or others such as temporal denoising. Duplicate frames often cause problems with temporal filters.

The most popular method is the 2pass TIVTC VFR, it's also mentioned in the wiki. That generates timecodes that can be used in MKV (or other containers like MP4). There are more complete instructions in the filter documentation.

I was never able to get this method to work. The Wiki begins by stating: "For this you'll need TIVTC and avi_tc."

Only problem is, AVI_TC is a dead program. It's no longer online. It's no longer available anywhere. I did track down a version of it installed as part of a different third-party application, but was completely unable to get it to do anything useful.

Since I couldn't ever find a useful version of the application I was supposed to use, I dropped this line of approach. I was unable to determine how to actually use the methods described in the wiki. I also wasn't very pleased with the quality I was getting from Vdub.

If there are just a few sections and you know exactly what sections have what (e.g. the intro has aliasing/flicker problems maybe needs some QTGMC in mode 2 or 3, maybe some other section etc...) , then you can just manually specify those, and the timecodes file. It will actually be faster than a 2pass TIVTC run. Have a look at the mkvmerge documentation under the "external timestamp" section. (it used to be called "timecodes", they refer to the same thing). The formatting is very easy for v1 timestamps.

I'll see what I can do. I've had precious little luck with this method before.






If 99% of these DVD's is mostly clean 3:2 pulldown (that's what others are saying), then you should IVTC 99%. That's how you return the original high quality frames to start with before your upscale. Anything other than that will yield lower quality. Period. If you try QTGMC in progresive mode, anything with lots of motion will lead to moderate quality loss before you even start upscaling.

Absolutely QTGMC can play a role in that 1% problem areas, but I would not use it anywhere else - way too damaging

It's not 3:2 pulldown at all. According to DGIndex, it's about 93% film progressive and 7% "Other." The "Other" runs the gamut from single interlaced frames (usually between different clips, though there are some exceptions) to multiple instances of 3:2 pulldown that are encoded directly into the source DVD.

So, for example.

You'll get: Progressive Frame 1, 2, 3, 4, 5, 6,.... 200. Then, the sequence of frames from 201 - 2010 will be in 3:2 pulldown.
(201, 202, 203 progressive, 204/205 interlaced, 206, 207, 208 progressive, 209/2010 interlaced). Then 211 - 500 will be progressive. 501 - 600 will be a short clip of 29.97 fps, which may be interspersed between two other clips of 23.976 fps, all of which take place on the same set. From 601, it'll all be progressive again. (Numbers are strictly representative, not a literal example).

The credits are always 29.97 fps but they are not in 3:2 pulldown either. They're just really pig ugly in the DVD source.

[zapp7]

It's not 3:2 pulldown at all. According to DGIndex, it's about 93% film progressive and 7% "Other." The "Other" runs the gamut from single interlaced frames (usually between different clips, though there are some exceptions) to multiple instances of 3:2 pulldown that are encoded directly into the source DVD.


It is 3:2 pulldown in most of those film sections though. You can easily apply TIVTC to the film sections that are pulldown and it works very well. The only problem sections are where, like you said, there is some other framerate like credits on the screen. The existence of a frame here and there that goes against the pattern doesn't mean that TIVTC won't work for the majority of the episode. The approach to preserve as much quality as possible is to TIVTC and then only QTGMC where it's needed.

For the end credits we have just been treating them as video and blending the frames. I don't really care about the end credits, anyway.

[poisondeathray]

Only problem is, AVI_TC is a dead program. It's no longer online. It's no longer available anywhere. I did track down a version of it installed as part of a different third-party application, but was completely unable to get it to do anything useful.


Here is a mirror for the avi_tc_package .

https://forum.doom9.org/showthread.php?p=1445996#post1445996




It's not 3:2 pulldown at all. According to DGIndex, it's about 93% film progressive and 7% "Other." The "Other" runs the gamut from single interlaced frames (usually between different clips, though there are some exceptions) to multiple instances of 3:2 pulldown that are encoded directly into the source DVD.

So, for example.

You'll get: Progressive Frame 1, 2, 3, 4, 5, 6,.... 200. Then, the sequence of frames from 201 - 2010 will be in 3:2 pulldown.
(201, 202, 203 progressive, 204/205 interlaced, 206, 207, 208 progressive, 209/2010 interlaced). Then 211 - 500 will be progressive. 501 - 600 will be a short clip of 29.97 fps, which may be interspersed between two other clips of 23.976 fps, all of which take place on the same set. From 601, it'll all be progressive again. (Numbers are strictly representative, not a literal example).

The credits are always 29.97 fps but they are not in 3:2 pulldown either. They're just really pig ugly in the DVD source.


So it's mixed, 93% 3:2 soft pulldown, and "other" is 3:2 hard pulldown, along with 29.97p sections - but that does not really change what you do . The goal - always - is to return the original progressive frames. That's what field matching does (TFM). You have 23.976p and 29.97p sections in that example.

And I think it was mentioned there were some pure interlaced sections somewhere, those become 59.94p, and it's appropriate to use QTGMC there , in normal mode. This is more tricky to do, because you have to use TFM mode 6, and there are some timecode issues with it. IMO it's easier to edit the script and timecodes for 59.94p sections if there aren't that many

[JoelHruska]

So it's mixed, 93% 3:2 soft pulldown, and "other" is 3:2 hard pulldown, along with 29.97p sections - but that does not really change what you do . The goal - always - is to return the original progressive frames. That's what field matching does (TFM). You have 23.976p and 29.97p sections in that example.

I don't know what you mean by "soft pulldown." The overwhelming majority of the footage in later episodes like Sacrifice of Angels is 23.976 progressive.

I am looking at the MakeMKV source in MPC-HC with all deinterlacing disabled. The application is set to show progressive frames.

I am staring at sequences of hundreds of frames in length, each of them a precise distance from the next (in terms of motion), with no interlacing or 3:2 pulldown artifacts or anything of the sort.

Interspersed with this, as I've said, is the occasional clearly visible pattern of 3:2 pulldown and the odd interlaced frame or two. Beyond that, there are none. I can upload a sequence of frames in the AM if you want visual proof.

This applies to both space combat scenes and in-person shots.

[poisondeathray]

I don't know what you mean by "soft pulldown." The overwhelming majority of the footage in later episodes like Sacrifice of Angels is 23.976 progressive.



Soft pulldown is 23.976p content, but encoded progressive. Repeat field flags output a 29.97i signal in a 3:2 pattern . If you ignore the flags, then you see 23.976p . Some software players IVTC on the fly, others just ignore flags. Some can be set to honor pulldown flags

Hard pulldown is 23.976p content, but encoded interlaced. Instead of repeat field flags, actual repeated fields are encoded in a 3:2 pattern

Note both have 23.976p content. Hard pulldown is just stored differently. In both cases IVTC will return the original 23.976p frames.

[hello_hello]

I am not "attached" to Handbrake. I am using Handbrake for two specific reasons:

1). DaVinci Resolve Studio will not ingest an MPEG-2 file in any guise *or* an MKV file of any type. Any workflow that begins with DaVinci Resolve Studio must therefore use a non-MKV file (M4V is acceptable to DRS).


2). I don't have a solution for rendering a VFR properly in AviSynth that keeps the A/V aligned when processed via StaxRip, despite repeated attempts to resolve this problem.


So right off the bat, we have two different sets of dependencies that must be resolved:

Beginning with DaVinci requires a non-MPEG-2, non-MKV source: Handbrake.

Beginning with StaxRip and MakeMKV results in a misaligned file. Using commands like "ntsc_film" or setting the file output to 23.976fps in the H.264 encoder will pull the frame rate down from the default 24.66 fps (don't ask me why StaxRip picks 24.66 fps, it just does) down to the appropriate 23.976 fps, but the audio is still improperly synchronized from minute one..

I'm pretty sure the reason for the odd 24.66fps frame rate, is when you rip with MKV and open with StaxRip, it's using a method for indexing and opening the video (probably lsmash) that doesn't honour repeat flags by default. So it sees the interlaced/hard telecined sections as 29.97fps and the film sections as 23.976, but as Avisynth needs a constant frame rate, it decodes at the average frame rate. As the source is mostly 23.976fps, the average works out at 24.66fps. The interlaced parts are too slow and the film parts too fast, so the A/V sync is lost.

If you open a vob file and get a constant 29.97fps, it's because the repeat flags are being honoured so the interlaced sections are 29.97fps and the film sections are telecined to 29.97fps. That's where you should start, even though eventually you'll be reversing the soft telecine created via repeat flags on playback, as you'd do for the hard telecined parts (the telecine is encoded). If you've already ripped with MakeMKV, you can open the MKVs with TSMuxer and remux them as TS files. Using TS files as the source, I suspect StaxRip will index with DGIndex as it probably does for vob files, and the repeat flags will be honoured.

Katie's method bob de-interlaces the whole lot to 60fps, I assume to avoid problems where interlaced content has been overlaid on hard-telecined content, but you'd end up with lots of repeated frames in the film sections.

AnimeIVTC has a mode for dealing with interlaced stuff overlaid on telecined stuff. I used a sample from an earlier post and encoded with a script using AnimeIVTC for the opening credits/CGI part, and TIVTC for everything else. The output is a constant 23.976fps.

I didn't try to fix the remaining aliasing. I think it's encoded into the video anyway. I followed AnimeIVTC() with AddGrainC() as I thought it might look more natural.
The source is Stereodude's sample from here.
https://forum.doom9.org/showthread.php?p=1906994#post1906994
There's a link for the encodes at the end of this post.

DGDecode_mpeg2source("D:\VTS_02_1_sample.d2v")

Crop(8,0,-8,0)

Trim(0,734).TFM().TDecimate().MCDegrainSharp()++\
Trim(735,3000).AnimeIVTC(Mode=3, cbob=4, aa=2).AddGrainC()++\
Trim(3001,0).TFM().TDecimate().MCDegrainSharp()

Resize8(640,480)
GradFun3()

A modified version of the Katie method to remove the unnecessary use of YadifMod, fix the TFM field order, and decimate to 23.976fps. I'd also suggest trying her method after replacing the nnedi3 de-interlacing line with QTGMC to see how it compares. ie
Y = QTGMC()
That might prevent the problems you're trying to fix with QTGMC later, by de-interlacing with it in the first place, or it might not.

DGDecode_mpeg2source("D:\VTS_02_1_sample.d2v")

Crop(8,0,-8,0)

Clip = last

Y = nnedi3(field=-2)
A = Y.Selecteven()
B = Y.Selectodd()
C=Tfm(field=0,mode=0,cthresh=2,mthresh=2,clip2=A,micmatching=0)
D=Tfm(field=1,mode=0,cthresh=2,mthresh=2,clip2=B,micmatching=0)
Interleave(C,D)

TDecimate(mode=7, rate=24.0/1.001).AssumeFPS(24000,1001)

QTGMC2 = QTGMC(Preset="Very Slow", SourceMatch=3, InputType=2, MatchEnhance=0.75, Sharpness=0.7, MatchPreset="Very Slow", MatchPreset2="Very Slow")
QTGMC3 = QTGMC(preset="Very Slow", inputType=3, prevGlobals="Reuse")
Repair(QTGMC2, QTGMC3, 1)

E = last

F = Clip.TFM().TDecimate().MCDegrainSharp()

E.Trim(0,75)++\
F.Trim(76,2971)++\
E.Trim(2972, 0)

Resize8(640,480)
GradFun3()

Because Katie's method restricts the field matching it might potentially produce smoother motion at the expense of more "wobble" where there's already aliasing, although QTGMC does help with that. The AnimeIVTC method resulted in very slight jitter in a couple of places, which might be fixable by specifying the field order with AssumeTFF() or AssumeBFF() beforehand, or playing with some of it's options, or even by starting the AnimeIVTC section on a different frame, as the IVTC process works on frames in groups of five, but either way, I think outputting a constant 23.976fps from Avisynth is the way to go, even if it requires a bit more work to create the scripts.

Nothing was "interlaced" in the source as far as I could tell, aside from maybe the credits overlaid on hard telecined video (it's encoded that way), with "baked in" aliasing. And there's possibly hard telecined stuff overlaid on other hard telecined stuff, but without lining the fields up as such, making the field matching process harder. The actual film sections appear to be straight forward soft-telecine (repeat flags), except where there's credits and it's hard telecine. At least I assume... as the sample I used had credits throughout, but decoding while honouring the repeat flags and reversing the telecine with TIVTC should be all that's required for the film sections.

If the source was combinations of purely interlaced 29.97fps and film at 23.976fps, you could extract the timecodes, de-interlace the interlaced parts and use the timecodes for a VFR encode, but for the hard telecined parts if you remove the telecine you'll have 29.97fps with repeated frames and jerky motion, and if you decimate to 23.976fps, the original timecodes won't work. Unless I'm missing something....

VTS_02_1_samples.zip (https://www.sendspace.com/file/8smu6l) (75.3 MB)

By the way, I strongly suspect the correct SAR for the original DVD video is 10:11, not 8:9. I feel it in my bones. :)
Have a look here:
https://forum.doom9.org/showthread.php?p=1058927#post1058927
If you encode anamorphically, try 10:11, and when using an mpeg4 SAR, if you crop 8 pixels each side, or a total of 16 pixels from the sides, what you're left with will be exactly 4:3, so from there you can resize to any 4:3 dimensions.

[hello_hello]

Bluster and bullying can take you only so far.

You read that on neuron2's headstone, didn't you? :)

[zapp7]

By the way, I strongly suspect the correct SAR for the original DVD video is 10:11, not 8:9. I feel it in my bones. :)
Have a look here:
https://forum.doom9.org/showthread.php?p=1058927#post1058927
If you encode anamorphically, try 10:11, and when using an mpeg4 SAR, if you crop 8 pixels each side, or a total of 16 pixels from the sides, what you're left with will be exactly 4:3, so from there you can resize to any 4:3 dimensions.

Wow, this makes way more sense than the episode-specific cropping that I was doing. Many thanks!!

[JoelHruska]

I'm pretty sure the reason for the odd 24.66fps frame rate, is when you rip with MKV and open with StaxRip, it's using a method for indexing and opening the video (probably lsmash) that doesn't honour repeat flags by default. So it sees the interlaced/hard telecined sections as 29.97fps and the film sections as 23.976, but as Avisynth needs a constant frame rate, it decodes at the average frame rate. As the source is mostly 23.976fps, the average works out at 24.66fps. The interlaced parts are too slow and the film parts too fast, so the A/V sync is lost.

If you open a vob file and get a constant 29.97fps, it's because the repeat flags are being honoured so the interlaced sections are 29.97fps and the film sections are telecined to 29.97fps. That's where you should start, even though eventually you'll be reversing the soft telecine created via repeat flags on playback, as you'd do for the hard telecined parts (the telecine is encoded). If you've already ripped with MakeMKV, you can open the MKVs with TSMuxer and remux them as TS files. Using TS files as the source, I suspect StaxRip will index with DGIndex as it probably does for vob files, and the repeat flags will be honoured.

Katie's method bob de-interlaces the whole lot to 60fps, I assume to avoid problems where interlaced content has been overlaid on hard-telecined content, but you'd end up with lots of repeated frames in the film sections.

AnimeIVTC has a mode for dealing with interlaced stuff overlaid on telecined stuff. I used a sample from an earlier post and encoded with a script using AnimeIVTC for the opening credits/CGI part, and TIVTC for everything else. The output is a constant 23.976fps.

I didn't try to fix the remaining aliasing. I think it's encoded into the video anyway. I followed AnimeIVTC() with AddGrainC() as I thought it might look more natural.
The source is Stereodude's sample from here.
https://forum.doom9.org/showthread.php?p=1906994#post1906994
There's a link for the encodes at the end of this post.



A modified version of the Katie method to remove the unnecessary use of YadifMod, fix the TFM field order, and decimate to 23.976fps. I'd also suggest trying her method after replacing the nnedi3 de-interlacing line with QTGMC to see how it compares. ie
Y = QTGMC()
That might prevent the problems you're trying to fix with QTGMC later, by de-interlacing with it in the first place, or it might not.



Because Katie's method restricts the field matching it might potentially produce smoother motion at the expense of more "wobble" where there's already aliasing, although QTGMC does help with that. The AnimeIVTC method resulted in very slight jitter in a couple of places, which might be fixable by specifying the field order with AssumeTFF() or AssumeBFF() beforehand, or playing with some of it's options, or even by starting the AnimeIVTC section on a different frame, as the IVTC process works on frames in groups of five, but either way, I think outputting a constant 23.976fps from Avisynth is the way to go, even if it requires a bit more work to create the scripts.

Nothing was "interlaced" in the source as far as I could tell, aside from maybe the credits overlaid on hard telecined video (it's encoded that way), with "baked in" aliasing. And there's possibly hard telecined stuff overlaid on other hard telecined stuff, but without lining the fields up as such, making the field matching process harder. The actual film sections appear to be straight forward soft-telecine (repeat flags), except where there's credits and it's hard telecine. At least I assume... as the sample I used had credits throughout, but decoding while honouring the repeat flags and reversing the telecine with TIVTC should be all that's required for the film sections.

If the source was combinations of purely interlaced 29.97fps and film at 23.976fps, you could extract the timecodes, de-interlace the interlaced parts and use the timecodes for a VFR encode, but for the hard telecined parts if you remove the telecine you'll have 29.97fps with repeated frames and jerky motion, and if you decimate to 23.976fps, the original timecodes won't work. Unless I'm missing something....

VTS_02_1_samples.zip (https://www.sendspace.com/file/8smu6l) (75.3 MB)

By the way, I strongly suspect the correct SAR for the original DVD video is 10:11, not 8:9. I feel it in my bones. :)
Have a look here:
https://forum.doom9.org/showthread.php?p=1058927#post1058927
If you encode anamorphically, try 10:11, and when using an mpeg4 SAR, if you crop 8 pixels each side, or a total of 16 pixels from the sides, what you're left with will be exactly 4:3, so from there you can resize to any 4:3 dimensions.

Really interesting stuff here. I will launch some test encodes this afternoon to try some of these ideas.

TBH, part of the reason I continue to use QTGMC in the repair mode as I do is because every IVTC solution I've tested has created problems as well as solving them. Motion in the credits might be improved, but I'll see increased blur caused by out-of-order frames. Applying QTGMC to repair this sort of *occasional* damage seemed like a smart way to limit the impact.

I'm going to run through this later today. Also, while PoisonDeathRay is recommending the use of timecodes and scripting to only target specific frames with QTGMC (and I fully intend to also explore this), I am *also* testing the impact of upscaling before performing any of my traditional workflow.

I want to see what the following looks like:

DaVinci Resolve Studio used to change frame rate to 119.88fps
Upscale to 4x DVD resolution. From this point, apply various frame processing techniques.

I'm also doing a lossless upscale with PNG files to see what the outcome is. That'll be compared to an MP4 output from Topaz with the same base file to see comparative output once the video is reassembled.

Finally, I'll be tackling the advice you and others have given, to see what I can make of this timecode issue and bring MakeMKV source back into the running.

[hello_hello]

Wow, this makes way more sense than the episode-specific cropping that I was doing. Many thanks!!

Because there's very little black down the sides, and assuming I'm correct and the total display aspect ratio is a little wider than 4:3, you could reduce the side cropping to a total of 10 pixels and crop 2 pixels from the top and bottom. Upscaling to 720p that'd give you resizing of 976x720 (or at 1080p it'd be 1464x1080) with a display aspect ratio of roughly 1.356 instead of 1.33. At 720p it's only 16 pixels wider than 4:3, but it'd fill a bit more of a 16:9 display.

Using my script to show you the result of the calculations.

Cropping 16 pixels from the width.
CropResize(0,720, 8,0,-8,0, InSAR=10.0/11.0, Info=true)

https://i.postimg.cc/SYqBMfkS/1-333.jpg (https://postimg.cc/SYqBMfkS)

Cropping 10 pixels from the width & 4 from the height.
CropResize(0,720, 4,2,-6,-2, InSAR=10.0/11.0, Info=true)

https://i.postimg.cc/q6L9X6v8/1-356.jpg (https://postimg.cc/q6L9X6v8)

So if you cropped and resized the following way (976x720 or 1464x1080), the aspect error would only be off by one quarter of a pixel. Just a thought, but I'd probably take the "slightly wider than 4:3 option" if the sample posted earlier is typical, and assuming 10:11 is the correct SAR.

Crop(4,2,-6,-2)
SomeResizing(976, 720)

BTW, I haven't seen a script that includes it yet, but when upscaling it's probably a good idea to convert the colors from standard definition colorimetry to HD colorimetry so the upscaled version displays the same way. The easiest way to do it is with the ColorMatrix plugin. Just thought I'd mention it....

ColorMatrix(mode="Rec.601->Rec.709", clamp=0)

[hello_hello]

TBH, part of the reason I continue to use QTGMC in the repair mode as I do is because every IVTC solution I've tested has created problems as well as solving them. Motion in the credits might be improved, but I'll see increased blur caused by out-of-order frames. Applying QTGMC to repair this sort of *occasional* damage seemed like a smart way to limit the impact.

I had a couple of thoughts regarding the IVTC problems, and about to test them....

It occurred to me some of the cause of the wobble might be the de-interlaced clip, and maybe QTGMC should be creating that after TFM has field matched it, rather than de-interlacing the original clip. So it'd look something like:

DeintClip = TFM(PP=1).QTGMC().SelectEven()

TFM(Clip2=DeintClip).TDecimate()

The idea being that the de-interlaced clip is field matched by TFM but without it fixing any combing, and then it's de-interlaced by QTGMC. Hopefully that'll help reduce the wobble. It's a working theory.

I've just started playing around with making DeintClip quite bright so I can see what TFM is doing and fiddle with it's options accordingly. The white bits in the screenshot are the pixels taken from DeintClip. I'll play around and post back if anything comes of it.

https://i.postimg.cc/hfh0D7RN/Deint-Clip.jpg (https://postimg.cc/hfh0D7RN)

[zapp7]

BTW, I haven't seen a script that includes it yet, but when upscaling it's probably a good idea to convert the colors from standard definition colorimetry to HD colorimetry so the upscaled version displays the same way. The easiest way to do it is with the ColorMatrix plugin. Just thought I'd mention it....

ColorMatrix(mode="Rec.601->Rec.709", clamp=0)

I'm a total noob when it comes to all of this. What I'm doing currently, based on comments upthread, is converting to RGB24 with the PC.601 matrix, then feeding into Topaz. I then convert the Topaz output back to YV12 using the PC.601 matrix. How would the 709 fit in to that? Also, I'm upscaling to 2160p, if that makes a difference.

[hello_hello]

JoelHruska,
The QTGMC repair you ran was way too much for me. In the end I only ran a QTGMC repair on the first close-up shot of the space station. It's the one that really needed it. The rest of it is fairly wobble free now. You could try running QTGMC over it all to see if it fixes the baked in aliasing, but I'd be tempted to leave it as it's not over the top.

Three little functions to make life simpler.

# IVTC of the opening credits
function QIVTC(clip Video)
{
DeintClip = Video.TFM(Mode=6, PP=1, MI=20, Slow=2, CThresh=4).QTGMC().SelectEven()
Video.TFM(Mode=6, Clip2=DeintClip, MI=20, Slow=2, CThresh=4).TDecimate()
}

# To IVTC the film sections with a bit of denoising
function IVTC_Denoise(clip Video)
{
Video.TFM().TDecimate().MCDegrainSharp()
}

# QTGMC repair
function QTGMC_Repair(clip Video)
{
Video.QTGMC(Preset="Very Slow", InputType=1)
}

It's split into 4 sections. The first part is film, then the shot of the comet (to avoid turning it to mush), the CGI crap, then film again.
It looks better than the encodes I uploaded earlier (assuming you've seen them as it appears SendSpace is down).

Another VTS_02_1_sample.mkv (https://ufile.io/4dtvdk6e)

DGDecode_mpeg2source("D:\VTS_02_1_sample.d2v")

Crop(8,0,-8,0)

Trim(0,65).IVTC_Denoise() ++ \
Trim(66,736).TFM().TDecimate() ++ \
Trim(737,3000).QIVTC() ++ \
Trim(3001,0).IVTC_Denoise()

Trim(0,928) ++ \
Trim(929, 1258).QTGMC_Repair() ++ \
Trim(1259, 0)

Resize8(640,480)
GradFun3()

zapp7,
HD is normally converted to RGB for playback using rec.709, so if you're upscaling SD you'd normally convert from rec.601 to rec.709. It can be done without converting to RGB using the ColorMatrix plugin. Or you could convert from RGB using rec.709 when coming out of Topaz, I assume.
UHD is rec.2020, but it uses different color primaries and I don't think it's worth it. If you label the video stream by specifying rec.709 in the x264 command line for the color matrix, you'd probably be fine converting to rec.709 for UHD too. A modern player should read it and convert to RGB that way for display on a monitor/TV.

Mind you upscaling standard definition to UHD seems like over-kill to me. I rarely upscale SD to even 720p myself. I usually just clean it up if need be, re-encode, and let the player/TV do the upscaling.

[JoelHruska]

hello_hello,

*sigh*

Clearly I've got a lot of work to do before I can even attempt the scripts you've been kind enough to write. Multiple filters you call are, apparently, either invoked differently by StaxRip and the AviSynth+ installation it uses or must be downloaded and added. I've not had much luck doing this manually to-date.

There is no MCDegrainSharp. When I remove the call to that filter, StaxRip tells me "Splice - Video Frame Rate Doesn't Match." I'm not sure why. StaxRip uses AviSynth+, not AviSynth, and some of the calls are different, but I don't know which.

I continue to learn things that are not particularly helpful. Apparently, calling "ffms2" instead of "FFVideoSource" will work in StaxRip, but I'm not sure it changes anything in the other errors when I do.

*pause*

Nope. Doesn't.

At any rate, apologies. I'll have to do some more surgery on the OS, clearly, before I can test any of this.

EDIT #2: I'm getting exactly the same error on Handbrake that I am on MakeMKV. I've tried both a CFR and a VFR MKV file ingest. Probably has something to do with using StaxRip as a front-end or having AviSynth+ installed instead of AviSynth.

[JoelHruska]

PS -- All of the credits encodes you provided look truly phenomenal. I have to wait for the sun to go down before I can really proof dark-screen content on this system (Yeah, I know, goofy reason, but it's true), but they look gorgeous from what I can see.

[poisondeathray]

I'm a total noob when it comes to all of this. What I'm doing currently, based on comments upthread, is converting to RGB24 with the PC.601 matrix, then feeding into Topaz. I then convert the Topaz output back to YV12 using the PC.601 matrix. How would the 709 fit in to that? Also, I'm upscaling to 2160p, if that makes a difference.

PC.709 when going from your upscaled RGB images to YUV

(unless you were planning on using Rec2020. Many UHD productions still use 709 for legacy reasons)

[zapp7]

This MCDegrainSharp function is awesome! I applied it to the season 1 intro (which is horrible quality) and it looks way better. Is there any down side to applying this to the entire episode, aside from longer processing time?

[poisondeathray]

Apparently, calling "ffms2" instead of "FFVideoSource" will work in StaxRip, but I'm not sure it changes anything in the other errors when I do.

*pause*

Nope. Doesn't.

At any rate, apologies. I'll have to do some more surgery on the OS, clearly, before I can test any of this.

EDIT #2: I'm getting exactly the same error on Handbrake that I am on MakeMKV. I've tried both a CFR and a VFR MKV file ingest. Probably has something to do with using StaxRip as a front-end or having AviSynth+ installed instead of AviSynth.


The wrong framerate is probably from ffms2. You probably have jitter in the MKV timestamps

If you're using ffms2, FFVideoSource, you also need to set rffmode=1 to honor the repeat field flags .

But ffms2 is less reliable, less consistent than DGIndex, MPEG2Source. MPEG2Source is what everyone uses for DVD's. It's rock solid

To use DGIndex on a DVD MPEG2 in MKV, you'd have to demux it first. (DGSource will work on a MKV , but it requires a compatible Nvidia card and is not free)

[StainlessS]

There is no MCDegrainSharp. When I remove the call to that filter, StaxRip tells me "Splice - Video Frame Rate Doesn't Match."

Looks to me like you are saying that you dont have McDegrainSharp(), and when you comment it out you get wrong framerate warning.

I'm guessin' that what you have actually commented out are calls to IVTC_Denoise() which calls McDegrainSharp, if so then


# To IVTC the film sections with a bit of denoising
function IVTC_Denoise(clip Video)
{
Video.TFM().TDecimate().MCDegrainSharp()
}

If call to above commented out then no TDecimate and would indeed be mismatch in framerate. [commenting out MCDegrainSharp alone would not affect framerate]

Here is McDegrainSharp, try again without commenting out the filter.
https://forum.doom9.org/showthread.php?p=1737045#post1737045

Also, if above guesswork was correct, then maybe be a little more clear so as to avoid the guessin' bit.

EDIT:
Is there any down side to applying this to the entire episode, aside from longer processing time?
I use it on pretty much everything (although mostly with Frames=1[default=2], and quite often csharp=0.3 [default=0.6]), downside ?, me dont think so, me likee :)

EDIT: I've also just added this edit to McDegrainSharp() post,
EDIT: Perhaps McDegrainSharp() default bblur should also be raised a little for HD stuff.

[hello_hello]

Clearly I've got a lot of work to do before I can even attempt the scripts you've been kind enough to write. Multiple filters you call are, apparently, either invoked differently by StaxRip and the AviSynth+ installation it uses or must be downloaded and added. I've not had much luck doing this manually to-date.

First thing:
I discovered while writing these instructions that I messed up with the frame numbers. The CGI section should have ended on frame number 3714 (or 3175), not 3000. I'm not sure what happened there. Maybe I incorrectly used the frame number after IVTC, not before. I'll run another encode again later.

Also, if you compare the credits in the film section between my AnimeIVTC and KatieIVTC encodes, you see some of them "blink out" a little for the Katie encode whereas they're smoother in the other. Exactly the same IVTC was used for both though. I think the difference was starting the IVTC for the film section on a different frame number, which can effect the result, because the IVTC process works on groups of five frames. Theoretically, you'd keep the Trims to multiples of 5, or start a new Trim on a scene change, but I found adjusting the end/start frames up or down by a frame could change the result, especially in the CGI section (where the field order appears to change), so if there's jitter etc, that's something to try. Anyway...

MeGUI has an AVS cutter under the Tools menu. You create a script to open the source (MeGUI can do that from the File/Open menu) then save and open it with the AVS Cutter. It has a preview displaying the frame numbers, and you use it to set the start and end points for multiple instances of Trim. It looks a bit different to the way I've been doing it manually, but the result is the same.

This was the initial script:

LoadPlugin("C:\Program Files\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("D:\VTS_02_1_sample.d2v")

Crop(8,0,-8,0)

Using the AVS Cutter to add the first lot of Trims looks like this (MeGUI calls them "cuts").

__film = last
__t0 = __film.trim(0, 65)
__t1 = __film.trim(66, 735)
__t2 = __film.trim(736, 3714)
__t3 = __film.trim(3715, 6858)
__t0 ++ __t1 ++ __t2 ++ __t3

As those cuts are going to be used to apply IVTC, they'll change the frame count, so if you want to add a second lot of cuts you need to add IVTC first. You can just add basic IVTC to make it fast if you want to, if all you're concerned about is the correct frame numbers after IVTC. In fact you could probably just leave the trims as they are and follow them with a single IVTC.

TFM().TDecimate()

If you want to add additional filtering that doesn't cover the same frame ranges as the previous Trims, you'd open the script in the AVS Cutter again and add a second lot of Trims. When you're done, save them to the script and edit it to add the appropriate filtering to each (also removing the temporary IVTC). After the Trims you can add additional filtering that'll apply to the whole video. In my case I just added some resizing and dithering.

__film = last
__t0 = __film.trim(0, 65).IVTC_Denoise()
__t1 = __film.trim(66, 735).TFM().TDecimate()
__t2 = __film.trim(736, 3714).QIVTC()
__t3 = __film.trim(3715, 6858).IVTC_Denoise()
__t0 ++ __t1 ++ __t2 ++ __t3

# TFM().TDecimate() This line can now be removed

__film = last
__t0 = __film.trim(0,928)
__t1 = __film.trim(929, 1258).QTGMC_Repair()
__t2 = __film.trim(1259, 0)
__t0 ++ __t1 ++ __t2

Resize8(640,480)
GradFun3()

There is no MCDegrainSharp. When I remove the call to that filter, StaxRip tells me "Splice - Video Frame Rate Doesn't Match." I'm not sure why. StaxRip uses AviSynth+, not AviSynth, and some of the calls are different, but I don't know which.

As StainlessS said, you probably removed the IVTC with it, so the frame rates no longer match, and each spliced Trim must have the same frame rate.

Install AVisynth+ if you don't have it installed. You can put additional plugins and avsi functions in the "installed" Avisynth plugins folder. You could save the little functions from my earlier post with an avsi extension and put them in the "installed" Avisynth plugins folder too, if you wish. When a programs runs it's portable version of Avisynth, that folder is still checked, and any plugins/functions inside are automatically loaded, so you can just use them in scripts without having to load them first. And with Avisynth installed you can open scripts in other programs.
I assume StaxRip comes with it's own collection of plugins and functions which it loads in scripts as required, but using additional plugins/functions from the "installed" Avisynth plugins folder should work the way I described. I haven't used StaxRip for quite a while and I can't remember how to modify it's scripts or how easy that is.

I don't quite understand what you meant regarding the Handbrake error. Can Handbrake open Avisynth scripts these days?

Edit: Everything needs to be 64 bit or 32 bit, and I gather StaxRip is 64 bit these days? I'm using the 32 bit MeGUI, but there is a 64 bit version, and you'll probably have to install 64 bit Avisynth+ and use 64 bit plugins. You might be able to install 32 bit and 64 bit versions of Avisynth at the same time, and use 32 bit and 64 bit programs with them, each Avisynth installation with the appropriate 32 bit and 64 bit plugins. I'm not sure though. I'm still using XP. Someone else will no doubt be able to tell you.

I continue to learn things that are not particularly helpful. Apparently, calling "ffms2" instead of "FFVideoSource" will work in StaxRip, but I'm not sure it changes anything in the other errors when I do.

FFMS2 is FFVideoSource and FFAudioSource combined, but the audio is disabled by default.

The MCDeGrainSharp function can be found here:
https://forum.doom9.org/showthread.php?p=1855907#post1855907
I discovered it through StainlessS.

zapp7,
I use MCDeGrainSharp quite a bit, but only if there's light to medium noise, otherwise I'd use something else, but if you like the result, there's probably no downside.

I'll run another encode shortly with the correct Trim ranges to see what it looks like. That might fix the slight jitter I noticed somewhere towards the end of the CGI section.

[StainlessS]

HH, NOTE that McDegrainSharp updated some time ago, [updated compared to your posted link, I update that linked post, whenever it may happen].

Again McDegrainSharp() here:- https://forum.doom9.org/showthread.php?p=1737045#post1737045

[hello_hello]

HH, NOTE that McDegrainSharp updated some time ago, [updated compared to your posted link, I update that linked post, whenever it may happen].

Again McDegrainSharp() here:- https://forum.doom9.org/showthread.php?p=1737045#post1737045

Am I missing something or did you leave TrueMotion enabled for that version?

[StainlessS]

I did not touch TrueMotion,
remind me, was it suggested to turn off for HD, (cant remember, nor remember where was suggested).
I only changed default blocksize, and added Limit stuff as per hi-lites in BLUE.

Also should maybe (guessin) raise bblur default 0.6 where HD (due to the 'grittiness' of HD compared to SD). (by how much, dont know)

EDIT: Oops, I did not notice that you had changed TrueMotion in your link, I thought it was simple copy of original post.
I'll come back to the TrueMotion thing later (got to go shopping for beer and other necessities).
EDIT: Arh, that thread was where trueMotion was discussed, who knew :)

[hello_hello]

I did not touch TrueMotion,
remind me, was it suggested to turn off for HD, (cant remember, nor remember where was suggested).
I only changed default blocksize, and added Limit stuff as per hi-lites in BLUE.

Also should maybe (guessin) raise bblur default 0.6 where HD (due to the 'grittiness' of HD compared to SD). (by how much, dont know)

Remember the screenshots in the TemporalDegrain2 thread where I compared MCDegrainSharp with and without TrueMotion? They were 720p.
https://forum.doom9.org/showthread.php?p=1855869#post1855869

Or the earlier comparisons, where QTGMC was looking more clever than TemporalDegrain2 because the latter had True Motion enabled?
https://forum.doom9.org/showthread.php?p=1855055#post1855055

They were the inspiration for my McDegrainSharp mod to disable it (the version I linked to).

Edit: I missed your edit before posting so now I'm repeating what you know. :)

I'm fairly sure it's disabled for resolutions above SD in SMDegrain and I think the default is disabled for MCTD, regardless of resolution, but it might pay to check. I can't remember when QTGMC enables it, but I'm sure the default is disabled. QTGMC mightn't have an argument to change it directly as such. It might be tied to another setting or a preset. I can't remember.