How to delay a field?

[Boulder]

I've got a TV capture clip in which I can notice at scene change positions that one field is from the previous and the other field from the next frame.

How can I delay the other field so that this doesn't occur and keep the clip interlaced at the same time? I'm sure there's an easy answer but this is really not my field of expertise, I've not handled interlaced material much.

Thanks in advance.

[Guest]

Originally posted by Boulder
[B]I've got a TV capture clip in which I can notice at scene change positions that one field is from the previous and the other field from the next frame. If it is interlaced video, then there are no frame pictures, so what you say is conceptually faulty!

Probably you are deinterlacing with blending and you get a blended frame at these scene changes, and you object to that. You can try interpolating instead of blending for your deinterlacing.

How can I delay the other field so that this doesn't occur and keep the clip interlaced at the same time? You can't. To do that you would need to add or delete a field. But that would shift all subsequent fields out of place spatially.

The easiest thing to do is just delete the blended frame, or duplicate it from the preceding frame.

Finally, if you are not deinterlacing and are encoding as interlaced, it doesn't matter at all; just leave it as is.

[johnmeyer]

This is exactly the same problem that I'm trying to solve.

I have captured the exact same videotape twice. I am then going to blend these two captures together, averaging each pixel. This results in a substantial reduction in noise and has been well documented elsewhere in this forum. The problem is that my second capture has frames that are offset by one field from the previous capture. I therefore need to create new frames that consist of the second field from the previous frame and the first field from the current frame.

I can probably figure this out eventually, since I did write a script to do 18 fps pulldown, but that was three years ago, and I haven't written an AVISynth script since then.

Any help or hints would be appreciated.

[Guest]

Define "offset by one field".

Do you mean that this:

a c e g
b d f hbecomes:

. b d f h
a c e g .If so, then it is not possible, because the fields are spatially in the wrong places (unless the broadcast changed).

Or do you mean:
a c e g
b d f hbecomes:
c e g i
b d f h That is a field dominance reversal.

To help you we need to know exactly what you are talking about. Please explain it with pictures like these.

Rereading your post, I see you imply the second case above. The standard way to correct that is like this:

DoubleWeave().SelectOdd()

The fog of red wine suggests to me that you may need to modify that but the idea is clear, at least to me.

BTW, it's NOT exactly the same problem as the initial poster. Why did you say that?

[johnmeyer]

Boulder,

Here is the solution to our mutual problem:

AviSource("e:\my video\VHS'20031001 10.36.42.avi")
SeparateFields
Trim(1,0)
Weave

I think you will find that this does exactly what you want (obviously you have to put your own path/filename in the first line).

John

[waka]

Two functions I use to make johnmeyer's process a bit easier and more functional.

function deletefield(clip clip, int num, int field)
{
fe=clip.separatefields.selecteven()
fo=clip.separatefields.selectodd()
fe=(field==0) ? fe.deleteframe(num):fe
fo=(field==1) ? fo.deleteframe(num):fo
return interleave(fe,fo).weave()
}

function duplicatefield(clip clip, int num, int field)
{
fe=clip.separatefields.selecteven()
fo=clip.separatefields.selectodd()
fe=(field==0) ? fe.duplicateframe(num):fe
fo=(field==1) ? fo.duplicateframe(num):fo
return interleave(fe,fo).weave()
}

num is the frame, field=0 deletes or duplicates the even field, field=1 does the odd field. This just shifts the top or bottom field with relation to the other, which may or may not be what the original poster wanted.

[johnmeyer]

waka,

I'm always looking to make something work better. In looking at your code, it uses more lines of code and involves creating a user defined function which I assume might execute more slowly. However, you say that it is "easier and more functional." Do you mean that it should execute faster, provide more flexibility, or something else?

I'm not defending my measly three lines of code, but if you've got something that's gonna run faster, I want to know about it, and I definitely want to use it.

[waka]

I have no idea what kind of speed difference there would be. I would guess it is negligible, but I don't know.

Mainly it's useful if you want to delete the top field of frame 102568 and then later duplicate the top field of frame 102621. I find it easier to implement and keep track of using the functions. Flexibility in other words.

If you are just shifting one field at the very beginning, then your method gets the job done and might be faster. Use whichever you prefer.

[Boulder]

Originally posted by neuron2
If it is interlaced video, then there are no frame pictures, so what you say is conceptually faulty!


What is the correct term to use when talking about a clip that has been captured at the resolution of 720x576 (EDIT:shot on VHS with a handheld camera in 1996)? I'm not good at these terms so any corrections are appreciated, of course :)




Probably you are deinterlacing with blending and you get a blended frame at these scene changes, and you object to that. You can try interpolating instead of blending for your deinterlacing.



I'm encoding to MPEG-2 so I want to keep it interlaced to preserve the smooth motion. I've also got the bitrate to spend so no need for deinterlacing.



Finally, if you are not deinterlacing and are encoding as interlaced, it doesn't matter at all; just leave it as is.


Here are three screenshots of one of the problematic spots. They have not been treated in any way. The first one is the frame before the spot, the second one shows the mixed frame and the last one shows the frame after the scene change.

http://www.cc.jyu.fi/~camneely/extras_before.jpg # frame 120
http://www.cc.jyu.fi/~camneely/extras_mixed.jpg # frame 121
http://www.cc.jyu.fi/~camneely/extras_after.jpg # frame 122

Does this turn out to be OK if I encode as interlaced? I'm quite positive that it's the capture card drivers that cause this but if encoding as interlaced works without any extra corrections, I'm happy;)

@johnmeyer and waka: Thanks for the input, I'll test the scripts and see how they work. However, I'm eager to see what Don has to say about those screenshots so I won't do anything final before he's got rid of the hangover caused by his beloved red wine:D

[waka]

It would appear you have truely interlaced material, in which case its better to think of it as fields per second rather than frames, as each field is unique temporally. Shifting fields will possibly screw up the motion. If you are encoding interlaced and are playing back on a interlaced device, you don't need to do anything. Just make sure you set tff/bff properly in the encoder. Tff appears to be the case here.

Donald said all this earlier, but I didn't want to give the wrong idea.

[Boulder]

Once again thanks, my knowledge in this area is very limited.

How should I treat this material if I intend to keep it truly interlaced but filter temporally, is this correct:


avisource("path\clip.avi")
separatefields()
even=selecteven().temporalcleaner()
odd=selectodd().temporalcleaner()
interleave(even,odd)
weave()


Or should I do as someone wrote in an earlier thread:


avisource("path\clip.avi")
complementparity()
bob()
temporalcleaner()
separatefields()
selectevery(4,1,2)
weave()


The latter one is obviously slower, but is there any difference quality-wise?

[Guest]

The two are equivalent it seems. If you must apply temporal filtering to field-based video, which I think is not a good idea, the first script is one reasonable way to proceed.

Regarding the combo frame that concerns you: If you play the clip back interlaced on an interlaced display, those two fields will be displayed one after another separated in time by a field time. The only reason it appears to be a problem is because you have put them together in a combined frame on your PC!

A progressive clip has frame pictures; each frame can be a new picture. An interlaced clip has field pictures; each field can be a new picture.

The scripts given for changing dominance and thus curing the blend for that scene change will convert other clean scene changes to blended ones, so take it all with a grain of salt.

[Boulder]

Thanks, Don, I appreciate it. Always something new to learn every day :)