need a way to automatically correct field parity

[*.mp4 guy]

My capture card has a bad tendency to drop a single field every ~1000 frames (even though my disk is fast enough and I have spare cpu cycles, it looks like its just a driver problem, but there are no alternative drivers), which causes the feiled parity to switch between tff and bff at those intervals, its easy to correct the field parity manually with something like:

s = last.separatefields
A = s.trim(0, 1396)
B = s.trim(1398, 12759).assumebff()
s2 = A+B

However correcting field order in that manner is too time consuming to be workable. It seems like it would be rather easy to detect parity switches and compensate for them automatically, so how can it be done?

[neuron2]

It seems like it would be rather easy to detect parity switches It appears very hard to me. What makes you think it is rather easy? Do you have an algorithm in mind?

Anyway, ditching a field every 1000 frames is going to mess up AV sync.

Get a decent card.

[actionman133]

It wouldn't be too hard, neuron2. I suggested this algorithm for 30p vs 30i detection in the AutoPAL/NTSC120 filter...

Consider two consecutive interlaced frames with 4 fields:

ac
bd

With this, subtract the diagonally opposite fields. Assuming TFF, Subtract (a, d) would show much greater difference than Subtract (b, c). Vice versa for BFF. I don't know how it would deal with parity changes though....

Actually... are you working in NTSC? Would changing i from drop frame timecode to non-drop frame (or vice versa) fix that problem?

[neuron2]

Well, if you think it is so easy, you should go ahead and implement it. :)

But distinguishing progressive from interlaced is not the same as detecting field order reversals.

[*.mp4 guy]

I would get another card, but this one has very good video quality, significantly better then bt***. It has a 3d adaptive comb filter and a low noise analog tuner (its a myhd mdp130) which puts the analog video quality far ahead of most of the cards I have seen. What I am really looking for is something that can detect wheather field parity is correct and switch betwean two clips based on that, ie:

s1 = avisource().assumefieldbased.assumetff.assumefps(59.94).weave
s2 = avisource().assumefieldbased.assumebff.assumefps(59.94).weave
conditionalfilter(s1, s1, s2, "ParityDetection", "=", "true")

[henryho_hk]

MyHD MDP-130?! Please let me know when and where you will dump it. ^_^ This problem seems not to have listed in the FAQs below:

http://www.digitalconnection.com/Support/cn_myhd_15.asp
http://www.avsforum.com/avs-vb/showthread.php?t=647837

Would it be a problem of the capture program?

Moreover, if a field is missing, i am afraid that your 1st script is not sufficient. I think it is necessary to apply "parity reversal" filters in those sections.

[*.mp4 guy]

The reason its not listed is that it is extremely hard to even coax it into outputting non-mangled analog video, unless you set a lot of completely unrelated settings correctly it will dumbob the video before outputting it, no matter what resolution you ask it to output, I would imagine that most people never even figure out that it can output perfectly pristine unmangled video to realise that it drops a field every ~2000 fields or so.

As to dumping it, I won't be for the time being, it is an excellent HD tuner and resale wouldn't cover what I paid for it, its just rather vexing to have such nice analog captures that have been made unwatchable by a stupid bug that will most likely never be fixed.

I can verify that the first script I posted does work, here is a snippet from a short test script I made, that I know works.
s = AVISource("J:\Captures\1229-030103.avi").assumefieldbased.assumetff.assumefps(59.94).converttoyuy2()#.weave()
A = s.trim(0, 1396)
B = s.trim(1398, 12759).assumebff()
s2 = A+B
C = s2.trim(0, 3392)
D = s2.trim(3394, 12758).assumebff()
s3 = C+D
E = s3.trim(0, 5404)
F = s3.trim(5406, 12757).assumebff()
s4 = E+F
G = s4.trim(0, 7426)
H = s4.trim(7428, 12756).assumebff()
s5 = G+H
I = s5.trim(0, 9428)
J = s5.trim(9430, 12756).assumebff()
s6 = I+J
K = s6.trim(0, 11406)
L = s6.trim(11408, 12756).assumebff()
s7 = K+L
s7.trim(0, 12412).weave().converttoyv12()

[henryho_hk]

It is kind of strange having assumefps(59.94) without separatefields().

Would you also consider converttoyv12(interlaced=true)?

And just curious, why don't you duplicate the residual fields instead of removing them? You can maintain the frame count in this way.

[*.mp4 guy]

It is kind of strange having assumefps(59.94) without separatefields().

Would you also consider converttoyv12(interlaced=true)?

And just curious, why don't you duplicate the residual fields instead of removing them? You can maintain the frame count in this way.

1 - The video is 1 field per frame, with a (wrongly) set framerate of 29.970, the real video frame rate is 59.94.

2 - I'm not having any trouble with that line as it is.

3 - Because I don't really care, it would take more work, and that script isnt a workable solution for anything but short tests where audio sync isnt an issue.

[henryho_hk]

If you don't mind the minor flicker once a while, it's possible to duplicate the fields in this way:


A = s.trim(0, 1397)
A1 = s.trim(1397, 1397)
B = s.trim(1398, 12759)
s2 = A+A1+B


And how do the ".assumebff()" calls work in your script?

[*.mp4 guy]

They are there becuase after a field has been droped the field parity switches, so having assumebff at the end switches the field parity back.

[henryho_hk]

Isn't ".assumebff()" for frame-based footage only? I thought it should be something like ".ComplimentParity()". Yet, I thought it should be applied to the whole clip. I am not sure of the effect when applying to a clip portion and then appending the clip to another one.

[AVIL]

Hi:

Perhaps Dan Donovan's filter ReMatch could help:

ReMatch uses the odd field, and constructs 3 frames: One with the current even field, one with the previous even field, and one with the next even field. Combing artifacts are counted with a threshold and the picture with the least amount of detected combs is chosen.

Find it in:

http://kawaii-shoujo.net/AntiAliased/programs.html

Good luck

[kempodragon]

This is similar to my problem. Awhile back, I posted that my card's drivers would only allow capping at 720x240, 59.94fps in avi. I did a recent capture, and after weaving the frames together, stepped through the picture and confirmed that fields are reversing throughout. It starts at BFF, then changes to TFF at some point, and then later changes back to BFF. I was thinking of weaving the original cap and saving it to a new file, and then applying your script. Your thoughts would be appreciated.

[*.mp4 guy]

That would work, but you will have a small amount of audio delay. In order for it to work correctly you have to align the "cuts" with the dropped fields before weaving.

[stickboy]

Isn't ".assumebff()" for frame-based footage only?I don't understand *.mp4 guy's script, but AssumeBFF() isn't just for frame-based clips. If you use it on a field-based clip, it affects what Weave() does.

[MOmonster]

Repair_ff (http://forum.doom9.org/showthread.php?p=857487#post857487) is created for such fieldorder problems. The function is a little bit older and today I would write a different code, but it can be helpful.

[*.mp4 guy]

Thanks for the suggestion momaster, I tried out the script, but it doesn't work on the type of field order problem I'm having =/, it is meant to fix jerky motion caused by out of order fields (right?) which isn't a problem I have, the problem I'm dealing with is where in a progressive frame the top field is below the bottom field which creates ugly combing artifacts. It was worth a try though.

[Mug Funky]

try it in conjunction with this:

function autoswap (clip c)
{
global order = c.getparity()==true? 1:0
global as_c = c
d=c.converttoyv12().horizontalreduceby2()
global swapped = c.swapfields().doubleweave().selectodd()
global cmetric = d.mt_edge("-1 -2 -1 2 4 2 -1 -2 -1 16",0,255)
global smetric = d.swapfields().mt_edge("-1 -2 -1 2 4 2 -1 -2 -1 16",0,255)

scriptclip(c,"cmetric.averageluma > smetric.averageluma? swapped : as_c")
}

it's a bit raw though - i've only used the above script once, and that was a year ago on a progressive source.

[*.mp4 guy]

Hey it works, thanks for posting it. It has a little trouble with a really tough source I've been testing on, but its much better then doing it by hand ;). Definately a nice function to have around.