It was actually the second, I forgot about having run the first somehow. I tried it with the MergeChroma(MCTemporalDenoise(settings=very high)) line, instead of creating the MCTD-only script.

Figured I'd give the MCTD-only script a shot, see if it was any quicker, and it was in a sense: it immediately jumped out to a five-day estimate.

Something about MCTD isn't getting on with my computer. Everything else is just slow, MCTD completely kills it.

I still have no idea which scripts you're running. If you refer to the split-up scripts in post #111 and post #127, you'll note that those scripts were optimized for the Studio.avi shot. The scripts for the game videos have a great many differences, especially concerning specific saturation issues that caused severe flicker and distortion. Scripts have to be optimized for unique problems in different segments of your videos. If you're applying all of the same Studio.avi script variations to all of your game videos, I can't help but feel that you're wasting your time.

Well, the exact content of the script isn't hugely important given how badly the MCTD-only script ran. But no, it's not the studio script.

Had some time, so I tried out the RAM thing you mentioned. Shut down, and just to establish a baseline booted up, and opened my StudioMCTD script:
The clip is 1:36 long. Opened straight in VDub, then File->Run video analysis pass. It completed in 29:04.

Shut down, which happened a lot quicker than it usually does. Removed the top two RAM sticks. Booted up, and repeated the process. 30:22.

Shut down again, removed the bottom two RAM sticks and placed the top two RAM sticks back in the top two slots. Booted up, repeated the process, 29:39.

Shut down, replaced the bottom two RAM sticks, booted up, ran it one more time just for the hell of it: 28:32.

2 seconds difference between longest and shortest runs isn't exactly a quantum leap. But at least you've eliminated bad RAM as a possibility. Obviously your Vista PC can run well on 8GB RAM, while my newer Win7 PC has 4GB and gives me no problems even with HD processing. The two supporting filters that run in MCTD to calm flicker are FFTD3flter and TTempSmooth. They can also be used as standalone filters and both have so many options it boggles the mind. I've been looking into MCTD's "very high" settings to see what can be eliminated from its other support filters and try to use those two monsters alone.

Was your PC a custom build or off the shelf? Motherboards differ wildly. I used an ASRock board in my XP PC with the i5 Intel, that board got to the point where it took 7 minutes to boot and turned my E drive into a boat anchor. Glad I purchased a 2-year extension warranty on that board, replaced with a Gigabyte designed for business data processing. Its no speed demon but it's done everything I asked.

I also played with some of your clips moving U and V channels into the Y channel (SwapUV is the function) and tried a ton of other tricks, but MCTD at Very High is the only thing that would calm that distortion. I've seen similar problems in many forum posts and had one tape of my own where Macrovision side effects made a complete hassle out of the first 30 minutes of the movie. So the tapes are one of those repair projects that presents one problem after another. So far, running MCTD in the manner you're using it is the only thing I've seen that cures the problem, along with curbing saturation of certain colors. It would appear that previous processing before you got your hands on these tapes has created some very tough problems that you had nothing to do with. It's not the first time I've seen this.

If you know the motherboard model # it might yield more info or some clues. The i7 CPU you mentioned isn't really that slow, only a 20% or so benchmark lower than my Ivy Bridge overall, so it shouldn't be a major slowdown. Something somewhere is haywire.

It's less wearing on one's patience to work with small video batches and decide beforehand which parts of several sources you want to use and which ones you don't want. I used to work with 5- to 7-minute increments most of the time. The 3-hour college football game tape I mentioned (3 hours) was on two tapes with enough physical damage to make a saint of me by the time it was finished. It took 4 weeks and 2 captures of each tape. Those tapes never played the same way twice.
:smack:

All that remains of the original captures (they belong to a nephew) are two before-and-after samples. Parts of these were posted elsewhere years ago. The project involved trying out 3 VCRs and two pass-thru units, not to mention all the dropped and dupe frames and other disasters caused by damage. The "fixed" example is only the first attempt and wasn't a total fix, there are still some problems solved later. There were other sections that look much worse. These were processed on my old AMD dual core 2.2GHz built 8 years ago with a cheapo Biostar motherboard. still working.

A_Samlpe2_bad.mpg
B_SAmple2_fix.mpg

Where did you get two seconds?

Eliminating causes is less satisfying than finding them.

I don't really follow this, but on the subject of filters when I load VDub I get "Autoloaded 107 filter(s) (1 failed). Check the log for details." in the status bar. According to the log (is there a way to access the log without encoding video?) "Error loading plugin "FFMpeg" from module FFInputDriver.vdplugin: Plugin requires a newer input API version (v4 > v2)."

It was custom, I think? Went in, told them what I used my computer for, they gave me a list of components and their prices. Motherboard is an intel DX58SO. I've since replaced the RAM and the graphics card, the former to upgrade and the latter because the original died. I can't locate the components list, unfortunately, but I do still have the motherboard map.

Could you expand on this?

Well, I've got the 1:36 studio content and the 1:36 intro and credits done. I figure it's probably quicker to figure out some settings for the hard camera and each of the baseline cameras, and just run each of those on the full thing, then combine in Premiere and create an extra file for anything that's still an obvious problem. It's never on one shot for more than a few seconds at a time; I'd spend more time creating a Trim() command than I'd save by not encoding the unnecessary footage, particularly since the latter can go on while I do other things.

When's the best time to use BadFrames() if I were so inclined? The documentation mentions goddamned nothing about progressive/interlaced/colorspace/etc. There's one frame of massive vertical jitter in the Studio clip that StabMod() simply will not get rid of, although I stumbled across it while Googling for a way to achieve that for a completely different clip due to one frame being almost completely black.

From your post:
You had a run time of 30:22 at most, the fastest was 28:32. Not much difference.

No, but it's part of the troubleshooting process.

You can move the U and/or V channels into the Y channel and do all kinds of in there without working on luma, then move U and/orV back again. But it offered no clues or solutions, so it's nothing to worry with. http://avisynth.nl/index.php/Swap

I don't get that message nor is there anything in any logs about autoloading filters. But I did get a similar error a few years back when I fetched an ancient PC out of storage and opened VirtualDub. Solved by uninstalling VirtualDub with auxsetup.exe and just starting VirtualDub.exe all over again. An uninistall just removes registry entries -- everything else stays as-is. Or you can get the version of the plugin mentioned. What version of VirtualDub are you running (We hope it's not 10.x.)?

You can use it with progressive or interlaced. The replaced frame will be blurred, unless you repeat a frame in which case you'll get stutter. You might also hear an audio blip on replaced frames. If interlaced, the blur will be worse. Usually one would interpolate a new frame using Avisynth's ReplaceFramesMC in progressive or SeparateFields mode, but in high action scenes it can generate distortion. Maybe a sample of the bad segment would tell us more.

A review of your motherboard is here: http://www.guru3d.com/articles-pages...-review,1.html

Some comparison benchmarks for some Intel CPU's for graphics and video processing are here: https://cpubenchmark.net/cpu.php?cpu...2.67GHz&id=834

More general comparison benchmarks vs newer or other Intel's and AMDs. My processor found in the lists here is an Intel i5 3570. http://www.cpu-world.com/benchmarks/...re_i7-920.html. The i5 is a bit faster, but there shouldn't be that huge difference between the two for video work (see bottom of the linked page).

That's two minutes, not two seconds. Which still isn't much.


I'm familiar with Swap, it came up in the context of seeing what the chroma sharpening did. I'm not familiar with it in the context of using it to fix things though.

Whether it helps in this particular situation or not, it might be helpful later. I'm here to learn how to restore video, I'm not here just to get this one video restored.

I'm not sure if it got messed up when I loaded the lordsmurf pack in or something. I have FFInputDriver.vdplugin in Plugins32, not Plugins. Not sure what, if any, difference that makes. I'm running VDub 1.9.11.

So it's better to do it with progressive footage? Would there be a difference between doing it after QTGMC and doing it after SeparateFields? Why would it touch the audio?

I'm not familiar with ReplaceFramesMC, and the Wiki turns up no results.

Not really sure what I'm supposed to glean from this. Hardware isn't really my area. Read the intro page of that review and understood almost none of the words in it. Not really sure what the comparisons mean, either. I mean, it doesn't seem like it's a great CPU, but you're saying it should still be doing better than what it is?

Yes, that's right. I typed "seconds" instead of minutes. Ooops.

I have the same FFInputDriver in my plugins32 folder along with several others from the FCCHandler site. But I removed the VDub filter pack because I already had many of them, would never use the rest, and got tired of scrolling down an endless list of unused vdf's to choose individual filters. Many oldies in filter pack compilations will crash VDUb or simply not work.

Yes.

Are you saying you looked up BadFrames but didn't try it to check the results? It can sometimes affect audio the same way the RemapFrames filter does, but often it can't be noticed.

I used Google and found several links for the original ReplaceFramesMC, including:
http://forum.videohelp.com/threads/3...=1#post2215047
http://forum.videohelp.com/threads/3...=1#post2172735

And also found the later version, runs a little slower but sometimes looks better (I use it as "ReplaceFramesMC2"):
http://forum.videohelp.com/threads/3...=1#post2224484
http://forum.doom9.org/showpost.php?...51&postcount=6
http://forum.doom9.org/showpost.php?...29&postcount=6

Both versions require MVTools 2, which you already have.

You can work with individual chroma channels U and V in YUV by moving one or both to the Y channel and working on chroma only. For example, I've seen anime where the U channel in one frame was the V channel in adjacent frames resulting in color ghosting. You could swap U and V to test or fix it: http://forum.doom9.org/showpost.php?...09&postcount=7

There are other uses, for example dot crawl is often in the UV channels but not in Y. You can sometimes fix it by resizing only the chroma channels: http://forum.videohelp.com/threads/3...=1#post2359187. I once used it to stop chroma flicker in UV only by applying a slow multi-frame temporal smoother or very aggressive FFT3Dfilter. Unfortunately your videos also have luma flicker involved, so this in itself won't work to completely stop the flicker effects and the strength of strong FTT3D is as slow as MCTemporalDenoise and dfttest in QTGMC, maybe even slower. I once saw Swap() used to correct a video where the U and V channels had been swapped in playback, resulting in really weird colors.

The motherboard review at AnanTech showed that your motherboard was one of the fastest performers of its day and is still competitive (go to the last summary page first when browsing motherboard and CPU reviews). You don't have to understand every piece of lingo, just get the general idea. The CPU comparisons show that your Intel chip isn't very far behind many newer Intels. The gist of it all is that your system isn't performing up to spec.

Well, I have much less experience with this than you do, less of an idea what to look for, and an absurdly slow computer. I dropped it in immediately after QTGMC and it looked okay.

Of course, the issue with this is frame numbers, which don't match up between the interlaced and deinterlaced versions.


I just paste the scripts into appropriately-named AVSI files in the plugins folder, yes?

Same question as above regarding the best place to use this. ReplaceFrames worked much better (I actually had four consecutive bad frames, but figured I could live with just getting rid of the worst, since i didn't know about RFMC).


Well, we sort of figured that. Any idea why? I'm still constantly getting that VirtualDub crash with ColorTools as well. Never happens with any other filter.

[quote=koberulz;46316]As you know, deinterlace, IVTC, SeparateFields, etc., change image numbers. Stop the script by using "return last" where you want to make a break and check the results so far. Of course if you're working with a big 2-hour chunk at one time, you're making it tough to work on isolated segments.

Yes. Or change the file ending to .avsi.

Use Replaceframes or BadFrames wherever you need them. One wouldn't know which to recommend without seeing some actual bad frames.

RAM seems OK, but you'd need a tech to look that system over. Vista is slower than other OS's, and some VDub filters won't work with systems after XP, but you have a hardware bottleneck somewhere that seems slower than normal.

Well I'm not using any VDub filters. MCTD seems to really kill it for some reason. That and ColorTools, which seems to die whenever I stop using it.

I'm disinclined to take my computer in anywhere; last time I did that they kept it for four days, gave it back insisting it was all fine, and charged me an absurd amount of money.

I've also had a laptop take a full month for a warranty replacement and an amplifier take four months for a warranty repair (that became a replacement due to the delay and still took an extra three weeks).

I cant' be without my PC for that long. I'd struggle to go a day, TBH.

Is it possible to pull out a few frames, operate on them, and put them back where they were (without creating new intermediate files)? Like, if I've got a second or so of video that I want to run RemoveSpots on or something like that.

You have to make a new working file. You can always discard the older one. But my workflow differs from yours. I store captures on external USB drives (I sometimes make more than one capture), From the masters I pull off small segments at a time, work with each and save the results, then pull off another segment that might require different processing, and so forth. In the end I join the work files together for a final encode. Each segment usually requires different techniques, color work, or other corrections. This method prevents having to make huge intermediate work files over and over.

I adopted these methods from other forums where I saw how advanced users organize their restoration projects.

Well, when dealing with two hours from one camera, with no cuts or anything...there aren't really any clear points at which to do that. Even with the one we've spent most of this thread on, the number of different sections surely vastly outnumbers the different restoration requirements. Dealing with thousands of segments of five seconds or less, all requiring either identical or nearly-identical treatment, is just a waste of time.

If you're saying you have three cameras, each with a different problem, and three 2-hour tapes, then you have 6 hours of video. That doesn't count half time, intro, and such. You mentioned two exceptional scenes, one where you have bad frames, another that needs RemoveSpots. You'll encounter more of these as you move along. Why not one sequence that takes you up to a bad point, then a separate routine for the bad spot, then the rest of the video. Why not break that into three or four parts and join them later? You won't need to keep the earlier version.

The prospect of watching a total of 6 hours of separate tapes for one game wouldn't turn me on as a viewer unless I was a game fanatic. I'm assuming that you have a composite of edited shots from all three cameras. If you have just one tape that is shots from all three cameras in intervals of a few seconds each, with a different problem from each camera on a shot-by-shot basis, you have what is known as a nightmare. I've had such videos and, yes, it took forever. On the other hand you could take your currently processed 2 hours, cut it into a few major segments with some short ones that require special processing, then join them later in an editor for encoding. At least you wouldn't have to remake the same 2 hours over and over.

I don't really understand what you're saying here, but what I have is what aired on TV. I don't have the full game from each camera. So, one two-hour tape (actually 1:43:13, to be exact).

You've seen each individual camera in my AVI samples, and an MP4 of how it all fits together.

The bad frames and remove spots were actually working together in the bit I referenced. It starts out with something fixable by RemoveSpots, with a couple of frames that need ReplaceFramesMC, then a bit more RemoveSpots as it returns to normal. But that's just what I know of at the moment, I'm still going through it.

In that case yes, creating a separate file just for that bad patch makes sense. But it made more sense to split that out and re-combine it within AviSynth if that were possible. Which it isn't, so tiny one-second file it is.

Should the Trim for the second file start at the end frame from the previous file, or the next frame? For example, if the first file is Trim(0,2952), should the second file be Trim(2952,2977) or Trim(2953,2977)? I'm guessing the second? The two frames mentioned in the brackets are included, yes?

I ran a video analysis pass on this script using my Studio sample:
It looked like it took about four and a half minutes, but I wasn't paying attention so I missed when it finished. Ran it again to get a better idea, and it finished in 52 seconds. Is there some sort of caching or something that could cause that, or is this just random variation in my computer's ability to be bothered doing as I ask?

One can't make changes in a video file without saving the revisions as a new copy of the old file. By working with a single long, unbroken copy of a long video, it's impossible to change any part of it without re-saving the results as a new copy of the entire video. Every time you make such a change, you'll need a new copy of the whole thing.

The Trim() function includes exactly the frame numbers in the parentheses, and no other frames. Hopefully your frames 2953 to 2977 include the entire camera shot so that the re-joined frames won't look so obvious? 75 frames of PAL video is 3 seconds, not one second. Remember that once this short segment is separated from the main body, its own frame numbers restart at 0 again, so its new frame numbers will be 0 to 74. ReplaceFrames will use new frame numbers, not the old ones.

Using the above numbers as examples, you would have three segments of video with which to contend:
(1) frames 0 to 2952
(2) frames 2953 to 2977, to receive added filtering.
(3) frames 2978 to the end of the video.

To do that in a single Avisynth script:

The double plus sign "++" is a synonym for the AlignedSplice() function (file:///D:/AviSynth%202.5/Docs/English/index.htm). If all this video is interlaced, the vid2" routine requires code to deinterlace and re=interlace the Vid2 segment. So that's another complication involved in using this method.

Its my understanding that usually if Avisynth has loaded up everything for the first run of a script, it remains loaded for running the same script again. Other than that, I don't have an answer for a PC that can't be tested and inspected in detail.

The statement "AssumeTFF().QTGMC()" runs QTGMC at its slow default settings, the same as typing "QTGMC(preset="slow")".

But I could load in the results of my restorations, then run the Trim, ReplaceFrames/RemoveSpots on the areas needed, and recompile into one AVI file, right?


The really dark/really bright game I posted samples of earlier is one continuous camera shot for each half, I think. It might cut if there's a timeout or something, but that's it. The frame numbers were just pulled out of the air as examples.

Yeah, I just ran it again fresh and it took 5:23.

Could you run it on your machine and see how long it takes, and list your specs? Trying to gather data so I can ask around.

I'd never run a script with two CPU and memory intensive plugins like QTGMC at it's "slow" default and MCTD in the same script. I made three runs with the same script from your previous post:

1st run: 2min 19 sec.
2nd Run: 2 min 21 sec
3rd Run: 2min 19 sec.

I then made two scripts with the heavy-duty plugins in separate scripts. The first script produced a file named "Time_Test1.avi". The second script ran the "Time_Test1.avi" file to make "Time_Test2.avi".

script 1:script 2:run time, script1: 4 to 5 seconds
run time, script2: 3 to 5 seconds
Total Time: 7 to 10 seconds

I repeated that a few times and got the same figures. Amazing what eliminating some memory and drive space swapping can do. Adding MergeChroma() added 5 seconds to script #2.