Correcting Field Order and Swapping in interlaced sources
I was asked by friend Boulder in previous topic about this and thought it needed a different heading. These are a couple of things I do that may be of interest to some people, obvious to others. Whilst this refers particularly to captures it can apply to any true interlaced clip. Purpose is to generate an Avisynth script to correct field order spacially and temporally with Vdub's help. Without fixing this first it can ruin what you do from that point on.
a. Correct field orientation spacially: I check this on any capture. I generally capture in Vdub using 352x576 in Preview mode to get both fields. Opening file in Vdub I briefly apply the Field Swap filter to make sure output video is indeed worse at several points along the stream. If it is better, then I use FieldSwap() in Avisynth script to correct. It is obviously essential that lines 1,3,5… etc in the captured frames (ie. Top Field) correspond to 1,3,5..of the source. Capture cards can get this wrong sometimes. Usually it is OK but well worth checking. b. Correct and determine field orientation temporally (field order): I use if using a Deinterlacer that needs to know field order (TomsMoComp) or if maintaining interlacing in SVCD encoding where encoder also needs to know. I think it is a good thing to clean up regardless. This is where things can go horribly wrong since the capture card can indiscriminantly drop fields and pairing in frames gets out of whack. Lets say Source frames have bottom field ahead of top (bff) in time but the captured frames, due to a phase shift, now have frames where the top field is ahead of the bottom (tff). If there is no Top Field First Flag (TFF) set in the captured file (generally not) then Avisynth assumes BFF and gets it wrong. ie it serves fields which are behind, in time, the one following. If a TFF or BFF flag is actually set in the captured file and it is wrong, same problem. If you get a combination of these then you are in the pooh (in a Tolkein way of course 8) ). I tend to trust my eyes on fixing this rather than programs. OK some steps on a real example: 1. Cap.avi is an actual test capture. Firstly I used this: z="c:\cap.avi" AviSource(z) AssumeFrameBased() SeparateFields() In Vdub you see the fields individually being served BFF irrespective of what the order they actually should be or what Cap.avi file flags might say. Moving slider slowly forward you will either see a smooth transition or a forward and back motion (guess what it should be :D ). The latter is where the frames contain the top field ahead of time. In my actual example Cap.avi, using above script the first half of clip was jerky and the second was smooth. I'm not joking, this was an actual capture!! I noted the transition point was at field 400 (ie. Frame 200 in clip z). 2. Here is the script which fixed the first half and gave me a final clip which was actually BFF all the way through and served that way. Use SeparateFields() at the end to double check in Vdub the flow of final clip. z="c:\cap.avi" AviSource(z) AssumeFrameBased() a = Trim(0, 200). \ComplementParity(). \SeparateFields(). \Trim(1,0). \Weave b = Trim(201, 0) a + b #SeparateFields() #Use to double check Note that Trim(1,0) deletes one field and Weave() restores correct phasing in frames. Now you can tell your deinterlacer (or Tmpgenc if SVCD encoding) what the field order is with confidence. A reminder: What the field order actually is, what the file flags say and what Avisynth assumes can be 3 different things. Trust your eyes. Feedback welcome Ozjeff99 |
Thanks, I'll have to do some tests on my captures later this week. My caps have always worked out fine as BFF so it's going to be interesting to see how the tests show them to be IRL :D
|
Hi Boulder. I see you have a bit of experience in filtering captures. What works best for you. Any scripts welcome.
Cheers Ozjeff99 |
This is something I've been using on my Star Trek TOS captures, shot on film and converted from NTSC to PAL, captured at 720x576:
Code:
LoadPlugin("c:\avs25\cnr2.dll") I use AVS2.5 but you can do the same things with AVS2.0x as well. Funny thing though, I captured the clip using the Morgan Multimedia MJPEG codec, a beta version which is supposed to capture correctly in YV12, and there are no combing artifacts 8O If I capture in YUY2, they sure are there.. |
Thanks Boulder. I'll definitely give yours a try. I'm not sure about Telcide for PAL as I understand that it should not be used on truly interlaced video. I can see that it could match up wrong fields to minimise combing and actually mess up an interlaced stream. This is what you want for a phase-shifted or telecined progressive stream however. I guess it always comes back to checking the source in Vdub first before doing anything to check what you have. I'll check this out further. Is bb the founder of Convolution3d?? If so he obviously knows what he is talking about.
Not sure what is going on with your YV2 capture? Could be only capturing one field. Thanks again |
Quote:
Quote:
http://www.cc.jyu.fi/~camneely/yuy2.jpg http://www.cc.jyu.fi/~camneely/yv12.jpg sh0dan did test the codec as he's the one who reported a field doubling bug to the people at Morgan Multimedia and he said that it does work fine. If you want to test it, look for it at the Morgan Multimedia website forum, there's a thread regarding the matter. |
Hi Boulder
Thought my memory was right on this one (convolution3d): Quote:
You obviously need to know that the codec is not spacially smoothing an interlaced source. Is the Codec lossless? I always use Huffy to ensure that the video does not contain any compression artifacts prior to processing and encoding. Disk space is cheap these days. ozjeff99 |
Ah, I should have remembered..I didn't even remember that bb suggested the other matrix in Con3d. My brain has to be punished - again :lol:
I played some more with the codec yesterday and now I got combs in the video. I just tried disabling interleaving (interleaving is supposed to capture both fields), did a test capture, enabled interleave and tried again. If interleaving is disabled, the other field is just discarded and the other duplicated to get two fields. Somehow disabling and then enabling interleaving got the codec working correctly. I think it could be that some settings were not being set correctly (beta version) and this fixed the problem. Anyway, here's a snapshot from the HuffYUV capture, done at the same time as the others: http://www.cc.jyu.fi/~camneely/huffyuv.jpg Here's my ST:TOS cap before I got things fixed: http://www.cc.jyu.fi/~camneely/trek.jpg When I check the field order of that clip, there's no jerky motion in TFF or BFF! MJPEG is a lossy compression method, basically the codec encodes the source into JPEG pics. However, my quality settings are very high so it's nearly lossless. At least you can't tell the difference between a HuffYUV capture and a HQ MJPEG one. If I had digital source, things would probably be different. |
@ boulder,
Don't you just HATE it when they plaster those logos on our clip ?? We suffer this nonsense way over here in usa too - - sucks big time!! Quesiton.. What "codec" does vdub reports when you open your YV12 captures in it ?? I have been doing some confusing research on YV12 captures, and.. I've ben messing w/ YV12 captures under vdub and avi_io but when I try to open them, I get an error about an I420 missing codec or something, which confuses me. But, I have what I believe one of the ATI codecs that I think opens it sort of incorrectly and reports an YUV 4:2:0 (I420) codec under vdub 1.3c, but any other vdub version won't open any of these YV12 captures. So, this is puzzeling me a bit. If you (or anyone else) knows this phenomina, any help would be appreciated.. thanks. -vhelp |
Quote:
Quote:
Quote:
|
Site design, images and content © 2002-2024 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2024 Jelsoft Enterprises Ltd.