View Full Version : Undot and Deen on interlaced source
djan
21st July 2005, 07:45
Hi,
I dont know if it has already been asked but I would like to know if Undot and Deen can be used on interlaced source ? If not, how can I use them without to deinterlace ?
Thx.
mg262
21st July 2005, 10:45
Any filter that can be used on progressive source can be used on an interlaced source by doing this:
separatefields
filter
weave
-- the separatefields turns the picture into what is nearly a progressive stream attwice the rate and half the height.It's not quite right because every other frame in that stream will be shifted down by half a scanline. @Scharfis_brain has posted a script using a bob -- I think LeakKernelBob -- recently (and probably on many occasions) that can get around this. Search will find it.
That said, it may be that either undot or deen or both detect interlaced source and deal with it an intelligent manner. If they do it should be mentioned in their documentation...and if you want to make extra sure, this is something that search (for 'undot interlaced', etc.) should turn up again.
edit: make sure you have the video correctly flagged as top or bottom field first (using assumetff/assumebff) before using separatefields.
Video Dude
21st July 2005, 13:33
Both Deen and Undot require progressive sources.
Read this post:
http://forum.doom9.org/showpost.php?p=529776&postcount=2
stickboy gives a good explanation on how to use the three main kinds of smoothers: temporal, spatial, and temporal-spatial.
Like mg262 suggested, another approach is to bob the interlace video and then reinterlace, read this thread for the posts by scharfis_brain:
http://forum.doom9.org/showthread.php?t=97585
djan
21st July 2005, 19:23
Thx for your advises. After reading the posts, I arranged all the datas for my use and would like to know if the following script is correct :
LeakKernelBob(order=0, threshold=7)
ConvertToYv12()
Undot().Deen()
ConvertToYUY2()
assumebff().SeparateFields().selectevery(4,0,3).Weave()
Are ConvertToYv12() and then ConvertToYUY2() needed ? If yes, why ?
mg262
21st July 2005, 20:23
from the documentation:
UnDot()
... Requires either YUY2 or YV12 input.
Deen for avisynth 2.5 - beta 2 - by MarcFD
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
deen is a set of assembly-optimised denoisers.
requires a ISSE capable cpu and YV12 colorspace.
So I would use the sequence
Undot()
ConvertToYv12()
Deen()
ConvertToYUY2()
I think the second conversion might not be necessary if you were intending to encode in an *interlaced* YV12 format. (If it's progressive then Weave + assumption of progressivity in YV12 will average the chroma across 4 vertical lines. I think. Someone will correct me if it is wrong!)
Video Dude
22nd July 2005, 03:47
ConvertToYV12()
This is required only if your input video is YUY2 or RGB. Deen requires YV12 colorspace.
ConvertToYUY2()
This will convert back to YUY2 colorspace. Some encoders only work in YUY2, such as CCE.
Use Undot after the YV12 conversion. Undot only filters luma in YUY2. But both luma and chroma are filtered using YV12.
Your script is good:
LeakKernelBob(order=0, threshold=7)
ConvertToYv12()
Undot().Deen()
ConvertToYUY2()
assumebff().SeparateFields().selectevery(4,0,3).Weave()
djan
22nd July 2005, 05:02
ConvertToYV12()
This is required only if your input video is YUY2 or RGB. Deen requires YV12 colorspace. Is it bad if I use ConvertToYV12() when the source is already YV12 ? If I ask it, it's because I don't really know the source type. For info, I use DVD-RB, maybe you know the source type generated after the prepare phase ?
Thx anyway.
mg262
22nd July 2005, 08:45
Is it bad if I use ConvertToYV12() when the source is already YV12 ? No. but it's easy to find out the colour space...
run this script:
#source video
info()
djan
22nd July 2005, 12:41
No. but it's easy to find out the colour space...
run this script:
#source video
info()
Ok, thx.
Another question, why is using LeakKernelBob and then reinterlace better than just separateFields, Filters and then Weave ? Are we not losing quality with deinterlacing and then reinterlacing ? Maybe I'm wrong with what I tell.
mg262
22nd July 2005, 13:16
This is easier to see than to explain... run the script:
#source
separatefields
and step through it frame by frame in VirtualDub. You should see that the picture jitters up and down very slightly... because the odd fields (after separation) are half a line lower than the original even fields. Bobbing is a way to get around this.
bobcat56458
26th July 2005, 00:57
I’ve been using an Avisynth script when frameserving my DV camcorder video that was shot indoors to reduce the grain in the video. I’ve been using Undot, & Convolution3D as filters using the script as follows to frameserve from VideoStudio (using Debugmode) to Avisynth, then loading that script into TMPGEnc to encode it as a two pass VBR MPEG2.
My original script:
LoadPlugin("E:\Program Files\AviSynth 2.5\plugins\UnDot.dll")
LoadPlugin("E:\ProgramFiles\AviSynth2.5\plugins\Convolution3D.dll)
Avisource("H:\Video Tests 2\Julie project\debugmode.avi")
SeparateFields()
UnDot()
odd=SelectOdd.Convolution3D(0, 12, 20, 12, 16, 6, 0)
evn=SelectEven.Convolution3D(0, 12, 20, 12, 16, 6, 0)
Interleave(evn,odd)
Weave()
converttorgb24()
This script has given me good results. I leave out Reinterpolate411 because I’m using the Cedocida DV codec that claims it takes care of the function the Reinterpolate411 plugin does. Now I’m reading in this thread about the video showing jitter using this script. So I thought I would give the LeakKernelBob method a try. I did not have this plugin installed with my Avisynth plugins so I downloaded it and placed the “LeakKernelDeint.dll” file in with my Avisynth plugins. There were a lot of other files in the LeakKernelDeint downloaded file so I placed that folder in the Avisynth plugins folder also. Usually a Avisynth plugin just consists of a “***.dll” file so I’m not sure I’ve installed this plugin correctly, or is it even a plugin? Anyway, I did an encode using the method above, using the LeakKernelBob script below, and it opened the script correctly in TMPGEnc and encoded the DV file into a MPEG2 file. This took considerably longer then the script I usually use, 26 minutes for one minute of video, compared to 18 minutes using my original script. I then tried the test mg262 suggested for seeing the jitter in VirtualDub using both my original method MPEG2, and the MPEG2 created using the LeakKernelBob method. When playing the new MPEG2 video file it looks the same as one done using my original script. Both of the MPEG2’s showed the same amount of jitter when I frameserved them to VirtualDub using the “separatefields” script, and advanced a frame at a time. Is there something wrong with my LeakKernelBob script that I do not see an improvement of the jitter problem?
Avisynth script with LeakKernelBob included:
LoadPlugin("E:\Program Files\AviSynth 2.5\plugins\UnDot.dll")
LoadPlugin("E:\Program Files\AviSynth 2.5\plugins\Convolution3D.dll")
AVISource("H:\Video Tests 2\Julie project\debugmode.avi")
LeakKernelBob(order=0, threshold=7)
UnDot()
Convolution3D(0, 12, 20, 12, 16, 6, 0)
assumebff()
SeparateFields().selectevery(4,0,3).Weave()
converttorgb24()
Video Dude
26th July 2005, 01:43
I think you misunderstood what mg262 posted.
Every clip will "jitter" if you separate the fields.
Take the original clip and use only SeparateFields(). Open in VirtualDub and frame step.
Now remove SeparateFields and replace it with LeakKernelBob. Open in VirtualDub and frame step.
Notice the difference.
Edit: Corrected spelling
bobcat56458
26th July 2005, 03:27
OK Video Dude I can now see what LeakKernelBob does, but I’m the kind of guy that likes to be able to test and see the results of adding a filter in the Avisynth script by making a comparison test of the original, to new filter added. The results of just viewing the two videos really shows no difference. I’d like to know it is worthwhile adding 8 minutes for each minute of video I encode. I’m encoding my MPEG2 video to author a DVD to be watched on TV, so it needs to be interlaced as the source video is. Does LeakKernelBob as the name suggests Bob the video making it Deinterlaced?
bobcat56458
26th July 2005, 16:22
Just to answer my own question that I asked in my original post on this thread. The reason there were other files in the LeakKernelDeint.dll download was because they were source code files (da!). I also did a search on the different methods of bobbing a video and now have a better understanding of how this script works. What seems odd to me is that I do not see this up and down jitter happening when playing a DVD on a TV that has been encoded to MPEG2 using the original method of “SeparateFields()”, not involving the use of LeakKernelBob in the Avisynth script. Is this akin to the way the eyes\brain perceives 30 pictures per second as a fluid representation of an actual visual event? For now I think I’ll stay with my original script because of the less additional encoding time involved, and the inability to actually see a real world payoff in using the LeakKernalBob method.
mg262
26th July 2005, 16:38
TVs play content differently. If you are trying to encode for TV playback, you should not be deinterlacing. (The guides on the main site explain this in more detail.)
If you post the complete script, we might be able to say why the jittering doesn't happen...
Leak
26th July 2005, 18:15
Just to answer my own question that I asked in my original post on this thread. The reason there were other files in the LeakKernelDeint.dll download was because they were source code files (da!).
Yeah, sorry about that clutter - I blame the GPL (http://www.gnu.org/licenses/gpl.html) though...
;)
(And please - no lengthy discussion that it's enough to make the source available on request instead of supplying it with the binaries... :D)
np: F.S. Blumm - Nie (Zweite Meer)
bobcat56458
26th July 2005, 22:17
Mg262, I did post the complete original script that I use for frameserving DV interlaced video in my first post in this thread, here it is again though:
LoadPlugin("E:\Program Files\AviSynth 2.5\plugins\UnDot.dll")
LoadPlugin("E:\ProgramFiles\AviSynth2.5\plugins\Convolution3D.dll)
Avisource("H:\Video Tests 2\Julie project\debugmode.avi")
SeparateFields()
UnDot()
odd=SelectOdd.Convolution3D(0, 12, 20, 12, 16, 6, 0)
evn=SelectEven.Convolution3D(0, 12, 20, 12, 16, 6, 0)
Interleave(evn,odd)
Weave()
converttorgb24()
As for the deinterlacing of TV video, I’m well aware of this. My concerns were in using LeakKernelBob in an Avisynth script as a way to allow you to use a filter like Undot that requires progressive video, and if it actually benefited doing so in the quality of the final output video. My tests seem to show that for me at least it’s not worth the extra processing time.
mg262
26th July 2005, 22:24
Mg262, I did post the complete original scriptSorry...
Weave is the exact opposite of SeparateFields... ie it puts the fields back together again. That's why you don't see any jittering.
(I hope we're not talking at cross purposes.)
bobcat56458
26th July 2005, 23:34
mg262, This is getting kind of funny :p, I realize what the Weave command does. I guess what I'm having a hard time seeing is what we are trying to correct using the LeakKernelBob method described throught this thread if there is no difference after using it. Are we trying to fix something that is not broke? :rolleyes: If there is no jittering after using my original script whats the point of using the LeakKernelBob method? I do see it as a viable alternative method but it takes more processing time to give what me thinks is an identical outcome.
Video Dude
27th July 2005, 01:29
I see now where you are confused bobcat56458.
The jitter will not be shown in the final output because you put the fields back together with Weave.
The jitter is present when the filters are working. Spatial filters can handle this but not spatio-temporal filters. As a side effect, the filters can mess up the video. This is why the Bob method is used, to prevent this.
bobcat56458
27th July 2005, 02:34
Video Dude, Thank You for clearing up my questions. I can now see the reasoning behind the LeakKernelBob method, although I do not actually see the beneficial results yet in my test encodes. So often it is suggested to add this or that filter without a good explanation of what it is doing and how. You have finally supplied the theory behind the method. I will test it further and see if it meets my DV filtering needs. Thanks also to mg262 for trying to solve my questions, even though I believe he was having trouble getting to the point of my concerns. I like to hone my video\audio skills every day, and Doom9's forum with its knowledgeable members is the place to do it.
djan
27th July 2005, 04:57
Isn't bob altering the quality as I heard everywhere that it's better to not deinterlace ? So maybe the separate fields technic is better than deinterlacing and reinterlacing then.
mg262
27th July 2005, 06:29
@bobcat56458,
now I see where you're coming from... when I told @djan about stepping through to look for jitter, I was referring specifically to this:
#source
separatefields
and I meant it as a way of understanding interlacing rather than anything else. It's very possible that using filters between separatefields/weave would also cause jitter, but that wouldn't be my first guess (and that's not what I said above)... you might find that denoisers work slightly worse or particularly that there is slight vertical blurring. It would depend (as ever) on the clip and what filters you are using. But if you can't see any difference, don't worry about it.
@djan,
bob-deinterlacing (which is not the same as normal de interlacing) doubles the number of fields; it both retains the original fields and interpolates new ones... and yes, those new ones are of slightly lower quality. But when you apply this:
assumebff()
SeparateFields().selectevery(4,0,3).Weave()
the number of fields is halved again and precisely the original fields are kept. I.e. all the interpolated fields are thrown away. So they were just there to help the filters that were run between Bob and SeparateFields().selectevery(4,0,3).Weave() ... and the fact that they were off slightly reduced quality is in that context a lot less important in that context (and is certainly a worthwhile trade-off in return for not been shifted by half a scanline).
djan
27th July 2005, 19:09
@djan,
bob-deinterlacing (which is not the same as normal de interlacing) doubles the number of fields; it both retains the original fields and interpolates new ones... and yes, those new ones are of slightly lower quality. But when you apply this:
assumebff()
SeparateFields().selectevery(4,0,3).Weave()
the number of fields is halved again and precisely the original fields are kept. I.e. all the interpolated fields are thrown away. So they were just there to help the filters that were run between Bob and SeparateFields().selectevery(4,0,3).Weave() ... and the fact that they were off slightly reduced quality is in that context a lot less important in that context (and is certainly a worthwhile trade-off in return for not been shifted by half a scanline). Wow, your explanation was very clear. Now I understand it. Thx !
bREAkDoWN
12th January 2006, 21:12
@djan,
bob-deinterlacing (which is not the same as normal de interlacing) doubles the number of fields; it both retains the original fields and interpolates new ones... and yes, those new ones are of slightly lower quality. But when you apply this:
assumebff()
SeparateFields().selectevery(4,0,3).Weave()
the number of fields is halved again and precisely the original fields are kept. I.e. all the interpolated fields are thrown away. So they were just there to help the filters that were run between Bob and SeparateFields().selectevery(4,0,3).Weave() ... and the fact that they were off slightly reduced quality is in that context a lot less important in that context (and is certainly a worthwhile trade-off in return for not been shifted by half a scanline).
Hi!
Doing some searching through the forum i've come into this thread, but there is one thing that i can't verify. If i make a simple script that just bobs and reintarlaces an interlaced clip, without any kind of filtering, i won't obtain the original clip, but a more blurred one. I'm checking this by switching through two instances of virtualdub, one with the original clip and another with the test script.
I'm using the internal bob() command (with no parameters) of the latest avisynth version.
Am i missing something?
Thanks in advance.
ByE!
foxyshadis
12th January 2006, 22:37
Given that a bob requires interpolation it will always be slightly different (except for scanline doubling), and bob() is the fastest and dirtiest of the bobbers anyway. Much more accurate are mvbob, tdeint, or leakkernelbob but even they won't be entirely reversible.
Boulder
13th January 2006, 08:55
Using Bob(0,x) should be lossless (x is usually 0.5 or 0.6).
Centurione
13th January 2006, 10:35
Just to ask, when dealing with interlaced contents, and applying filters in spatio-temporal domain, I normally use, instead of separatefields(), the combination ViewFields(), UnViewfields(), that simply stacks vertically the two fields (so avoiding the bobbing problem), and then it combine the fields again.
I can just imagine some problem between the bottom and upper part of the two fields, but for that normally I just add a tiny black border (normally in the overscan area of the TV).
Do you see any other drawback in this approach ?
Regards, Centurione
Boulder
13th January 2006, 11:31
From what I've seen, the strength of denoisers need to be lower. As bobbing resizes the field to full height, the smoothing effect is not as strong as when you have half-height fields.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.