filters for wobbly (older-persons) VHS home video

[frednerk]

My mother-in-law's friend's husband passed away, and she asked could we "put her VHS home video onto DVD" as it the husband was in it. It seems of usual VHS quality, albeit with severe constant hand-wobble all the way through (she is an older person). I use the following (newbies roughie template) AVS and get 4fps according to HC17 (1&1/2 hr tape !)

Since it's about 4fps, I am only doing light Convolution3d instead of better things, although I'd like more. A bit of testing shows... - it's about [+1 or +2] fps without the DePan stablilization - Pixie reduces it to about 2fps - I can run 2 parallel HC17 encodes of this (one with stabilization, one without) and get just about the same fps for each, as above !

a) any suggestions as to why it appears to "run so slow", and yet I seem to get nearly 2-for-1 with separate encodes (I suppose I could use TRIM on the AVI and halve the elapsed time with 2 encodes, but that doesn't help me as to why, in case something's wrong)
b) suggestions welcomed for a filter chains to clean up this more nicely (speed aside) ? Sample: http://rapidshare.de/files/14974455/RR-3secs-huffy.avi.html (3s 25Mb huffy extract, no audio).


# this one's for VHS captured interlaced gear
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\DGDecode.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins-dcw\ReverseFieldDominance.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins-dcw\TDint.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins-dcw\DePan.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins-dcw\Cnr2.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins-dcw\dctfilter.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins-dcw\fft3dfilter.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins-dcw\degrainmedian.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins-dcw\Convolution3d.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins-dcw\despot.dll")
#LoadPlugin("C:\Program Files\AviSynth 2.5\plugins-dcw\blockbuster.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins-dcw\WarpSharp.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins-dcw\MaskTools.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins-dcw\mt_masktools.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins-dcw\RemoveGrainSSE2.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins2.0\LoadPluginEx.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins2.0\DustV5.dll")
Import("C:\Program Files\AviSynth 2.5\LimitedSharpenFaster.avsi")
Import("C:\Program Files\AviSynth 2.5\dcwresize.avsi")
Import("C:\Program Files\AviSynth 2.5\DeHalo_alpha.avsi")
Import("C:\Program Files\AviSynth 2.5\Deblock_QED_MT2.avs")
#Import("C:\Program Files\AviSynth 2.5\YLevels.avsi") # from http://forum.doom9.org/showthread.php?p=525465#post525465
FRAMERATE=25
WIDTH=704
HEIGHT=576
AviSource("D:\capt\RR2005\RR2005-capt.avi", audio=false)
Trim(0,154989)
#L = LAST.ConvertToYV12(interlaced=TRUE)
#Crop(left, top, -right, -bottom, true)
Crop(16, 8, -0, -16, true)
AssumeTFF()
ConvertToYUY2(interlaced=TRUE)
SeparateFields()
mdata2 = DePanEstimate(range=1, fftw=true)
#DePanStabilize(data=mdata2,prev=3,next=3,rotmax=5,cutoff=2.0,dxmax=120,dymax=120) # process greater than 2Hz shakes
#DePanStabilize(data=mdata2,prev=2,next=2,rotmax=5,cutoff=1.0,dxmax=120,dymax=120) # process greater than 1Hz shakes shakes
DePanStabilize(data=mdata2,prev=0,next=0,rotmax=5,cutoff=1.0,dxmax=120,dymax=120) # process greater than 1Hz shakes shakes
even = SelectEven()
odd = SelectOdd()
#even=even.Cnr2()
#odd=odd.Cnr2()
even=even.Convolution3D(0, 3, 4, 3, 4, 2.8, 0)
odd=odd.Convolution3D(0, 3, 4, 3, 4, 2.8, 0)
#even=even.Convolution3D(0, 6, 10, 6, 8, 2.8, 0)
#odd=odd.Convolution3D(0, 6, 10, 6, 8, 2.8, 0)
#even=even.Convolution3D(0, 32, 128, 16, 64, 10, 0)
#odd=odd.Convolution3D(0, 32, 128, 16, 64, 10, 0)
#even=even.Convolution3D(0, 32, 128, 32, 128, 10, 0)
#odd=odd.Convolution3D(0, 32, 128, 32, 128, 10, 0)
Interleave(even,odd)
Weave()
AssumeTFF()
ConvertToYV12(interlaced=true)
# -------------------------------------------------------------------------------------
#DeSpot(median=false, interlaced=TRUE, seg=2, show=0) # SAFE
#DeSpot(median=false, interlaced=TRUE, seg=0, show=0) # seg=0 means STRONG
#DeSpot(p1=35, p2=14, mthres=25, interlaced=TRUE) # UP the limits before it's considered noise
#DeSpot(interlaced=TRUE)
#FFT3DFilter(sigma=3, sharpen=1.0, degrid=1.0, interlaced=TRUE)
#DeGrainMedian(limitY=5,limitUV=7,mode=0, interlaced=TRUE)
#DeGrainMedian(limitY=2,limitUV=3,mode=1, interlaced=TRUE)
# -------------------------------------------------------------------------------------
#ConvertToYUY2(interlaced=TRUE)
#SeparateFields()
#Pixiedust(output="YUY2")
#Pixiedust(limit=5,output="YUY2")
#Pixiedust(limit=7,output="YUY2")
#Weave()
#AssumeTFF()
# -------------------------------------------------------------------------------------
SeparateFields()
even = SelectEven()
odd = SelectOdd()
even=even.DeHalo_alpha(rx=5,ry=5)
odd=odd.DeHalo_alpha(rx=5,ry=5)
Interleave(even,odd)
#LimitedSharpenFaster(smode=4,strength=115,overshoot=3,radius=5,wide=true) # ,wide=true
#LimitedSharpenFaster(smode=4,strength=115)
LimitedSharpenFaster(smode=4)
Weave()
AssumeTFF()
# AddBorders(clip clip, int left, int top, int right, int bottom [, int color])
Addborders(16,8,0,16)
#Converttoyv12(INTERLACED=TRUE)
#SeparateFields()
#even = SelectEven()
#odd = SelectOdd()
#even=even.Deblock_QED_MT2()
#odd=odd.Deblock_QED_MT2()
#Interleave(even,odd)
#Weave()
#AssumeTFF()
# -------------------------------------------------------------------------------------
#P = LAST
#Crop(left, top, -right, -bottom, true)
#Lleft = L.crop(0,0,-352,-0,true).subtitle("unfiltered",y=30)
#Pright = P.crop(352,0,-0,-0,true).subtitle("filtered",y=30)
#S = stackhorizontal(Lleft,Pright)
#S = L.subtitle("unfiltered",x=40,y=40) ++ P.subtitle("filtered",x=40,y=40)
#return S

[Chainmax]

It's somewhat hard to read such a messy script. For clarity's sake, remove all the lines you commented out. I'll check out the sample and get back to you.

[frednerk]

Thanks Chainmax !

LoadPlugin("C:\Program Files\AviSynth 2.5\plugins-dcw\DePan.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins-dcw\dctfilter.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins-dcw\Convolution3d.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins-dcw\WarpSharp.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins-dcw\MaskTools.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins-dcw\mt_masktools.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins-dcw\RemoveGrainSSE2.dll")
Import("C:\Program Files\AviSynth 2.5\LimitedSharpenFaster.avsi")
Import("C:\Program Files\AviSynth 2.5\DeHalo_alpha.avsi")

AviSource("D:\capt\RR2005\RR2005-capt.avi", audio=false)
Trim(0,154989)
Crop(16, 8, -0, -16, true)
AssumeTFF()
ConvertToYUY2(interlaced=TRUE)

SeparateFields()
mdata2 = DePanEstimate(range=1, fftw=true)
DePanStabilize(data=mdata2,prev=0,next=0,rotmax=5,cutoff=1.0,dxmax=120,dymax=120) # process greater than 1Hz shakes shakes
even = SelectEven()
odd = SelectOdd()
even=even.Convolution3D(0, 3, 4, 3, 4, 2.8, 0)
odd=odd.Convolution3D(0, 3, 4, 3, 4, 2.8, 0)
Interleave(even,odd)
Weave()
AssumeTFF()

ConvertToYV12(interlaced=true)
SeparateFields()
even = SelectEven()
odd = SelectOdd()
even=even.DeHalo_alpha(rx=5,ry=5)
odd=odd.DeHalo_alpha(rx=5,ry=5)
Interleave(even,odd)
LimitedSharpenFaster(smode=4)
Weave()
AssumeTFF()
Addborders(16,8,0,16)

[Chainmax]

This one is quite messed up, it has very strong haloing. Using DePan in the following fashion:

i = last
mdata = DePanEstimate(i)
DePanStabilize(i,mirror=15,data=mdata)

after deinterlacing or bobbing might help. You should probably use ReYV12() and Reinterpolate420() on it as well, do a search for them.

[FredThompson]

What?!?!

First, do NOT deinterlace. Stabilizing with software is highly dependent on temporal analysis. Deinterlacing DESTROYS that information, period. This is a video source. It should stay interlaced.

This filter chain has far too much complexity.

What are the source and capture hardware and method? (It looks like PAL VHS -> PAL DV.) With that information, you can determine the proper sequence of processing steps.

Long story short, The "best" thing you can do with a VHS source is to use a good S-VHS deck with digital filtering and stabilization. The information stored on the tape is different than that which comes out the video connections. Once the signals have left the VCR, there's only so much you can do.

[Boulder]

I think this thread might be quite useful: http://forum.doom9.org/showthread.php?t=83234

schafis_brain's posts are, as always, full of valuable information.

[berrinam]

First, do NOT deinterlace. Stabilizing with software is highly dependent on temporal analysis. Deinterlacing DESTROYS that information, period.Bobbing doesn't. It keeps the full framerate AND resolution -- the best of both worlds. There is no information lost at all in that.

[FredThompson]

Interlaced source is 2 independent streams of images. Bobbing makes it look a little nicer during playback on a progressive display but it still screws up the temporal aspect by adding persistence to one field while the other is instantaneous.

It sure looks like scharfis_brain considers this less destructive because it gives more data for the correction during stabilization. Hmm..not sure that makes sense. Upsampling to reduce rounding errors makes sense but the temporal smear ...

(Gotta be careful on this stuff. Boulder caught a similar blunder in one of my scripts recently.)

Is that a blackberry or raspberry?

[frednerk]

What are the source and capture hardware and method? (It looks like PAL VHS -> PAL DV.) ...
a good S-VHS deck with digital filtering and stabilization.
Ta. Source was an old-lady-supplied PAL VHS cassette of unknown copy/transfer/generation, captured from an ordinary Sony VCR into a Winfast TV2000Expert capture card via composite. Cassette thought to be from either (A) a very old video camera direct to cassette, or (B) an analogue video camera into a PAL VCR via composite.

Guess I'm hoping for the most reasonable thing I can do with what she has and I have... This is where AviSynth and the people in these forums shine, making the most of what you've got !

[Wilbert]

but it still screws up the temporal aspect by adding persistence to one field while the other is instantaneous.
Excuse my english :) What do you mean by persistence and instantaneous here?

[FredThompson]

Yeah, finding the "proper" words for this isn't so easy. I'll try...

Each PAL interlaced field represents a still image taken instantaneously at a unique time, 1/50 sec before or after the adjacent fields in the stream, right? Hold that thought.

Here's how DG explains DGBob, "This filter splits each field of the source into its own frame and then adaptively creates the missing lines either by interpolating the current field or by using the previous field's data. The filter attempts with some success to mitigate the flutter that bobbing produces. Note that this process of converting fields to frames will double the frame rate of the input clip."

In this case, the bobbing process uses temporaly old information to pad each field with assumed data. Field X is an instantaneous representation of the camera view at a distinct time to which an equivalent amount of outdated information (camera position, subject position and camera view) is stuffed.

Think of how rotary motion is converted to linear motion in a mechanical device. There's a point at which the linear motion stops, instantaneously, but the rotary motion continues. It's the same principle. Linear motion is represented by the distinct instantaneous images of the video stream and rotary motion is represented by the shaking camera position.

Or, put another way: http://image.allmusic.com/00/amg/cov200/drf800/f802/f80256rrz9b.jpg

[Wilbert]

"This filter splits each field of the source into its own frame and then adaptively creates the missing lines either by interpolating the current field or by using the previous field's data. (...)"
Looking at the source code, i think that the decision to interpolate the current field or use the previous field depends on the amount of combing. In case of much combing, the current field is interpolated, otherwise the previous field is used. I'm sure neuron2 will correct it, if it's wrong. So, i fail to see how it screws up the temporal aspect.

[Chainmax]

Without entering into technical details I know nothing about, I recall mvbob being said as to conserve the most detail out of all bobbers. That would mean that bobbing causes in a loss of detail. Therefore, wouldn't it be better to just separate the fields, filter each field and then wave it all back?

[berrinam]

How can a bobber introduce a loss of detail? The original fields are left untouched, so you can always get back to the original. Saying that mvbob 'conserves' the most detail is just a slight misunderstanding. It would be better to say that it 'creates' the most detail.

[FredThompson]

@Wilbert, you forgot the camcorder is moving in 3D under dynamic force vectors and so is the subject, neither of which is regulated by the field capture rate of the camcorder.

Interpolation is like fitting a curve, it's an assumption. All we've got in this video stream is a set of planes derived from 2 points moving dynamically in 3 dimensions. The motion vectors are in constant flux.

Bobbing, no matter how sophisticated, creates frames with 50% assumed data. If you bob before doing motion analysis, the analysis will be screwed up because the 50% assumed data smooths and obscures the motion, sort of like trying to fit a curve to a set of averaged values, not raw values.

scharfis_brain's suggestion to do the first pass of DeShaker as B&W is very good advice, regardless of the source.

@blackraspberry, it's not that a bobber modifies the original data. You are correct, the original field is untouched. The corruption comes from additional processing based on the assumed "filler" data.

[FredThompson]

This whole discussion might fall apart because any processing involves changing the data.

[Boulder]

*creak*

Did I hear a can of worms opening?

This is very interesting, I've also wondered whether a stupid bob would be enough if you don't do any resizing but just denoise. I hope someone could really explain it in simple terms (if there are such things in this case).

[FredThompson]

Get some pure video (not NTSC converted to PAL) of high-motion WWE wrestling with lots of flash photography and see what happens if you try to interpolate. The stuff that "works" with relatively stable scenes is all screwed up by motion and impulse. A jiggled camcorder is similar. If I'm doing a manual pan, I put the camcorder in a short sling. It helps to remove some of the jiggle.

[frednerk]

You should probably use ReYV12() and Reinterpolate420() on it as well, do a search for them.
Thanks, I didn't spot Reinterpolate420 in a sticky. Searched... is Wilbert's Reinterpolate420 at
http://www.geocities.com/wilbertdijkhof/ReInterpolate420_v2.zip in thread http://forum.doom9.org/showthread.php?p=549121#post549121 the latest one ? Wasn't sure about scharfis_brain's script as it used tomsmocomp which i gather may be dated (given tcritical's TDEINT has been updated a lot recently)...

[scharfis_brain]

@fred:
Bobbing, no matter how sophisticated, creates frames with 50% assumed data. If you bob before doing motion analysis, the analysis will be screwed up because the 50% assumed data smooths and obscures the motion, sort of like trying to fit a curve to a set of averaged values, not raw values.

That is nonsense.
A deshaker in interlaced mode has some options:
1) separating the fields,
do a motion search,
apply a fixed vertical shift to every other vector field to compensate the up and down shaking of the separated fields video stream
2) do a vertical field shift after separating the video:
even fields 1/4 scanline up
odd fields 1/4 scanline down.
this compensates vertical shaking but DOES NOT compensate flicker due to a high amount of vertical detail
3) do a bob() on the video an search for vectors.
it is the same like 2) just that the vertical size is doubled.
you'll have the same amount of line flicker like in 1) or 2)
4) search on the fields separately. But I dunno whether that is accurate or not...

my approach in deshaking is for quality reasons in the 2nd pass, cause deshaker (as well as all other deshakers I know of) are lacking a proper field scaling algorithm.

I commonly use a plain bob() for analysis. The 50% of interpolated data doesn't really matter, cause the block size is high enough to get passed though, also the shaking is MORE present than the interlace flicker.

For the second pass, I use mvbob() or at least securedeint(), cause both offer stright connected diagonal lines in the deinterlaced output, so the later applieder scaler won't mess up the new field structure and thus leaves image clarity intact.

with deshaker in its nativ interlace mode I always got weird stairstepping and blurryness due to the (simple) field scaling applied.
With my method you are feeding progressive high quality upscaled images into deshaker. So after reinterlacing the scaled image just looks like it never had been scaled by the deshaker.

[FredThompson]

You don't understand what I was saying and combined two issues. Read it again.

Each field of interlaced camcorder video represents a unique instantaneous point in time as "seen" through one of 2 interwoven views. You can't take an object from one instant in time and project it into another instant in time without distortion. Interpolation, no matter how it is done, is a guess. It is not true data.

Limitations of whatever tools are used don't change the linear nature of time nor the motion of objects.

[foxyshadis]

You can't reduce the size by two and then upsample with all the detail, but there are algorithms to get you 90% of the way there (not talking lanczos here). Similarly, a good enough bob can be, if not indistiguishable, at least good looking except in certain cases (your example, along with some other sports and very jittery video, and making mvbob even slower with a deshaker or global lumanence compensator could help there). That doesn't invalidate it for cases where it works, because there's so much information available to make that guess fairly accurately. It's just dependant on human intervention deciding whether it is called for.

[scharfis_brain]

You don't understand what I was saying and combined two issues. Read it again.
I still don't get what you want to say.

1st, let us clarify, how - in your optinion - a deshaker should / does search for motion:
a) on the video with separated fields
or
b) on each, the even and the odd fields separately (like stacking the fields vertically and then measuring the motion)

btw.: just for showing to you how accurate motion analysis on bobbed stream can be: mvbob's first and only motion estimation is done on an adaptive bob-deinterlaced clip. Even with blocksizes down to 4x4 pixels (meaning 4x2 pixel 'original" data per block) I get a very good estimation an thus a pretty decent compensation result.
I experimented without interpolating the fields, but the results weren't convincing enough. The compensated images always were off by a varying amount. So it was useless, because I needed a 1/2 pixel precise compensation between the (interpolated) top <->bottom fields.

So now tell me, why should bob-deinterlacing harm a motion analysis of a deshaker filter which only needs the global amount of motion, if even the results for an object based approach are very good.
A deshaker just grabs the motion of the largest object (the highest count of vectors with same lenght and direction) and then calculates a global shift value out of that. Since it has a LOT of vectors, it has a lot of overhead data to compensate (average) a potential impact on precision introduced by bobbing like you say.

[FredThompson]

How many times do you want me to restate the same comments?

The conditions have to be defined before a methodology can be created. I'm talking about how the conditions affect the potential accuracy of the methodology and you're talking about the methodology as if there are no limitations from the starting conditions.

The camera and subjects are almost always in constant motion.

Interpolated data is not real data.

Interlaced fields don't record the same points in space or time.

Video is recorded at a constant frequency. Environmental motion is not synchronized to that frequency.

SD (or lower) resolution video is a relatively small number of data points for motion analysis.

It doesn't matter what tools or techniques are used. Those conditions still apply.

--

To your last question, how many axes of motion do you think are happening? There are at least 5 for the camera and living subject. That's a minimum of 10 types of motion.

--

In answer to your first question, each field needs to be treated as an independent image because the motion can change but the data points don't represent the same positons of the subjects. You know that as well as I do.

Interpolation screws everything up when there is a rapid motion. That motion may be a moving subject or a moving camera. The further the camera is from the subject, the more pronounced the change in the actual data. The same thing happens with deinterlacing.

[scharfis_brain]

To your last question, how many axes of motion do you think are happening? There are at least 5 for the camera and living subject. That's a minimum of 10 types of motion.
I don't get your point. Why do I need to crack my brain about possible types of motion, when we are discussing how to analyse motion on interlaced video?

In answer to your first question, each field needs to be treated as an independent image because the motion can change but the data points don't represent the same positons of the subjects. You know that as well as I do.I know that. But we have several sampling problems with interlaced video: the ones you mention and ALSO the vertical subsampling, meaning that each field alone violates nyquist and thus shows heavy aliasing.
THis aliasing also irritates motion estimation (vectors are getting sticky to diagonal edges). With some sort of ELA / EDI one can avoid that. (that is my practical experience)

Interpolation screws everything up when there is a rapid motion.I cannot agree with that.
If the interpolation is purely spatial it won't mess up movements more that static areas. Even contrary: movements are handled better, because movements introduce motionblur which itself reduces aliasing in the fields, so the type (and error) of interpolation more and more becomes unimportant.
It is more that static areas are handled in a wrong way (flicker)

Please show me a pratical example, where bob-deinterlacing destroys or at least impacts motion estimation in a bad way.
I'd be glad if you could provide such sample video.

I can assure to you that I thought about these issues a lot of time (how to estimate motion and process the compensation results). I always ended up bob-deinterlacing the video (with a long temporal mask to avoid temporal smear like you called it and an ELA/EDI based tecnique to reduce aliasing) due to quality and handling issues.

[FredThompson]

Take some time off from this discussion then come back and read what I've typed. You're still missing what I'm saying. There's no point in restating things again or answering questions if you're going to compalin about the answers.

I don't think I made any comment which was derogatory about your methods. If that's your opinion, I apologize you received my words that way.

All I've been saying is interpolation creates assumed data. All assumed data has a caveat about its accuracy. High motion, sporadic motion or non-linear motion decreases the reliability of that assumed data.

In that regards, it's like any other noise or corruption removal, the dirtier the starting signal, the less desired data can be recovered.

It's also like working with a curve function or a derivative. Those are calculated approximations of the actual (missing) data. Sometimes they're useful, sometimes they're misleading.

Regarding sample video, I've got quite a bit of camcorder NTSC DV which was converted to 422 MPEG2 with machinery as the subject. There's a lot of rotary motion in the subject matter and sometimes the camera platform was unstable (metal walkways, that sort of thing.) I'm not sure how much of it would break the way you want for me to provide a practical example for my statements. The camcorder is NTSC and most of the machinery is in Europe. The challenge in that situation (or a PAL camcorder in a North American factory) is the different frequencies of the electric lights and the frame rate. AC lights pulse so this difference leads to pulsing in the video. I've been thinking about getting a high-output flashlight to help but that's more bulk to carry.

Worms all over the place...

[scharfis_brain]

Okay, let's stop discussing this. Everyone builds a (or more) method that works best for the own processings.

Anyways you may try some kind of deflicker filter on your footage. I had a very similar thing: 54Hz Super8 recorded with a 50Hz PAL cam and it worked like a charm :)

[FredThompson]

I've been doing a lot of work with multiple anthropomorphic robots in the same operating space lately. That's where the 3D stuff thoughts come from. There's a classical mechanics illustration about point of view that compares looking at a spinning merry-go-round vs. looking from that same spinning merry-go-round which applies to this. It's also quite revealing that the DynaPel MotionPerfect same videos are such small resolution. That conveniently hides the distortions you mention.

PM me a snail mail address for you and I'll send you some camcorder shots of various mechanical devices that defy deinterlacing/stabilizing. Maybe your eyes and experience would come up with something that has elluded me. (Same goes for rainbow removal. 411 and 420 video of moving metal roller conveyor...ugh.)

Getting back to the OP, what script would you use for bob-deinterlacing of his source? How would you adjust the 420 source before running it through DeShaker?

I've tried the various deflicker filters. Most seem to be for video made of projected film. They don't work well with mixed light sources. I've got some where the foreground subject is illuminated by a skylight and the background is 50 Hz. It makes a real mess when seen in 60 Hz NTSC.

@Wilbert, you still around? Can you help the OP regarding ReYV12() and Reinterpolate420()?

[Chainmax]

Thanks, I didn't spot Reinterpolate420 in a sticky. Searched... is Wilbert's Reinterpolate420 at
http://www.geocities.com/wilbertdijkhof/ReInterpolate420_v2.zip in thread http://forum.doom9.org/showthread.php?p=549121#post549121 the latest one ? Wasn't sure about scharfis_brain's script as it used tomsmocomp which i gather may be dated (given tcritical's TDEINT has been updated a lot recently)...

I was referring to scharfis_brain's script, but I only looked for the thread title. Maybe he can update it to use TDeint and MaskTools2.