View Full Version : Mod5, Mod16 = ?, and bobbing.
jellysandwich
25th September 2005, 05:49
Can someone briefly explain them please?
Edit: Also, what exactly is bobbing? I've read the description at avisynth.org, but I still don't understand it clearly.
I've noticed that that TDeint(1,1) works well for taking care of flapping mouths, but I don't think I'm using it right. Currently, my script is:
mpeg2source("D:\WitchHunterRobin\2\2.d2v")
AssumeTFF()
Telecide(guide=0,post=2,vthresh=35,dthresh=0,show=true)
Decimate()
tdeint(1,1)
selecteven()
... crop and resize
Wrong?
Edit 2: Shoot, this is supposed to be in the avisynth forum. Can I get a move please?
js
mg262
25th September 2005, 15:19
mod5 means exactly divisible by 5 -- so 25, 720, etc but not 704. Similarly for 16. (But where have you seen Mod5?)
Normal de-interlacing converts every pair of fields into a frame; Bob-de-interlacing converts every field into a frame. (So you double the frame rate.)
Wilbert
25th September 2005, 15:32
More precise:
a mod b = 'the smallest positive remainder of a' after subtracting as many times b as possible. Thus 15 mod 4 = 3 since 15-3*4 = 3, 15 mod 5 = 0 since 15-3*5 = 0, etc ...
mg262
25th September 2005, 15:40
a mod b = 'the smallest positive remainder of a' after subtracting as many times b as possible. Thus 15 mod 4 = 3 since 15-3*4 = 3, 15 mod 5 = 0 since 15-3*5 = 0, etc ...I haven't seen this (mathematical/programming) usage crop up on these forums... but if we mean the mathematical usage, add:
Equation (mod b) means that the equation holds when all the terms in it are considered as remainders after division by b. So
3*3 = 1 (mod 4)
Really, what is going on is that the objects we are considering are no longer numbers but "numbers mod b". This also means that you only use operations which are valid on "numbers mod b", such as *,+,- but not /.
Wilbert
25th September 2005, 16:08
This also means that you only use operations which are valid on "numbers mod b", such as *,+,- but not /.
Not quite. The integers mod p, or Z_p, form a field, which means stuff like division and inverse are also defined. You need that p is prime for this to work though.
Suppose we work mod7 (ie in Z_7). We would like to have the inverse of 3. The inverse of 3 is 5 since 3*5=1 (mod 7). So 1/3 = 5 (in Z_7).
Likewise 5/3 = 4 in Z_7, since 5*1/3 = 5*5 (mod 7) = 4 (mod 7). Etc ...
mg262
25th September 2005, 16:16
I know... but I was trying not to go too far into this, just to give a rough idea. Talking about / properly really needs some note about uniqueness of inverses (either from general theory or first principles), which is more than I wanted to get into. I should have phrased it in a less misleading way though. NB Similarly I omitted the fact that you usually use ≡ instead of =.
We could keep going indefinitely -- ideals, etc. But this is probably far enough ;). (Although I still want to know where mod5 cropped up in video work...)
Guest
25th September 2005, 17:28
Although I still want to know where mod5 cropped up in video work... The YATTA guys have something they call the MOD5 rule. It derives from the fact that you do Decimate(5) after field matching for IVTC.
jellysandwich
25th September 2005, 17:41
Ah, so that's what MOD is. Simple enough, thanks for the explanations.
Yep, MOD5 came from the YATTA thread...
But what about the script in my first post? Is that a correct way of using bob?
js
stickboy
25th September 2005, 20:17
More precise:
a mod b = 'the smallest positive remainder of a' after subtracting as many times b as possible. Thus 15 mod 4 = 3 since 15-3*4 = 3, 15 mod 5 = 0 since 15-3*5 = 0, etc ..."Remainder" is typically positive. The "modulus" (especially in programming languages) can be negative since integer division usually truncates towards zero instead of towards negative infinity.
mg262
25th September 2005, 21:09
@neuron2 -- thank you.
@stickboy -- on a similar note, I've just found that shifting by 9 bits and dividing by 512 give slightly different results...
@jellysandwich -- I'm not ignoring you, I'm just not in NTSC-land so IVTC isn't something I know much about. Do you intend to Bob rather than applying a normal de-interlacer?
jellysandwich
25th September 2005, 23:21
@jellysandwich -- I'm not ignoring you, I'm just not in NTSC-land so IVTC isn't something I know much about. Do you intend to Bob rather than applying a normal de-interlacer?
I'm not quite sure. I still don't understand bobbing well enough.
All I know is that I'd like to IVTC to 24 fps, and bob via TDeint to get rid of some flapping mouth problems. Or perhaps I can't do both?
js
mg262
25th September 2005, 23:40
You're more likely to get concrete, appropriate help on this if you post a clip...
jellysandwich
26th September 2005, 01:37
Ah, just got home.
http://s92800548.onlinehome.us/js/whr.avi
(15mb)
Will that Xvid Q=1 one work? Or do you need it uncompressed?
js
foxyshadis
26th September 2005, 02:26
Not quite. The integers mod p, or Z_p, form a field, which means stuff like division and inverse are also defined. You need that p is prime for this to work though.
Suppose we work mod7 (ie in Z_7). We would like to have the inverse of 3. The inverse of 3 is 5 since 3*5=1 (mod 7). So 1/3 = 5 (in Z_7).
Likewise 5/3 = 4 in Z_7, since 5*1/3 = 5*5 (mod 7) = 4 (mod 7). Etc ...
What, no set theory? =D You guys are hilarious.
jelly, also, exactly what you're trying to achieve would help; ie, a clean decombing, comparing bob vs, say, mo-comp, and how you'd get the best results on your source? Or just what numbers to plug into tdeint?
Guest
26th September 2005, 04:43
The clip appears to be all screwed up. I did both AssumeTFF().SeparateFields() and AssumeBFF().SeparateFields() and then served into VirtualDub. Stepping through the part where the guy walks from right to left, it's jerky both ways, implying the field-order is all screwed up and is not constant.
You can get good results with this:
avisource("whr.avi")
AssumeTFF()
telecide(back=2)
decimate()
But you're much better off finding out why your clip is so screwed up. What is the history of this clip?
jellysandwich
26th September 2005, 18:39
The clip appears to be all screwed up. I did both AssumeTFF().SeparateFields() and AssumeBFF().SeparateFields() and then served into VirtualDub. Stepping through the part where the guy walks from right to left, it's jerky both ways, implying the field-order is all screwed up and is not constant.
You can get OK results with this:
avisource("whr.avi")
AssumeTFF()
telecide(back=2)
decimate()
But you're much better off finding out why your clip is so screwed up. What is the history of this clip?
That clip was unprocessed. I think the whole series is jerky (or not smooth) like that by nature. It is, afterall, more of a drama than an action series.
I'm actually pretty happy with my IVTC. I'm just worried that by adding in "TDeint(1,1).SelectEven()" to help with the flapping mouth problems, I might add in some nasty unwanted video artifacts like extra jaggy lines.
mpeg2source("D:\WitchHunterRobin\2\2.d2v")
AssumeTFF()
Telecide(guide=0,post=2,vthresh=35,dthresh=0,show=false)
Decimate()
TDeint(1,1,type=2).SelectEven()
crop(4,0,712,480)
LanczosResize(640,480)
My test encodes should be done tonight, and hopefully they'll turn out well.
js
foxyshadis
27th September 2005, 01:02
Weird how some areas are severely combed and others aren't at all. Hopefully some of the other discs are cleaner.
I'm just worried that by adding in "TDeint(1,1).SelectEven()" to help with the flapping mouth problems, I might add in some nasty unwanted video artifacts like extra jaggy lines.
I didn't see any extra jaggy lines, just the ones that were already in there. Of course, you have the full source, so your best bet is to just test test test. (side-by-side helps a lot here, I have a function you might like if you aren't satisfied after your encodes: )
function SXS (clip "_c1", clip "_c2", int "_scale") {
_scale = default(_scale,1)
_w1 = select(_scale,0,Width(_c1)/4,Width(_c1)/2)
_w2 = width(_c1) / 2
return Stackhorizontal(_c1.crop(_w1,0,_w2,0),_c2.crop(_w1,0,_w2,0))
}
(The last parameter just selects left, mid, or right, for 0, 1, or 2.)
jellysandwich
27th September 2005, 02:57
Thanks for the script, it made my comparing a little easier.
I've only found a few extra jaggies in a few scenes, so I'm pretty happy. I might have to do some manual editing, but that's fine with. Thanks for the help guys.
js
Guest
27th September 2005, 03:59
jelly, you're not understanding my observations. I'm not going to force them down your throat, but you'd be well advised to try to understand what I'm telling you. There is no flapping mouth problem and no need to do deinterlacing at all if you get the field matching right.
A man walking from right to left should not jump backwards. That's not the action, that's just screwed up. The back option is designed for dealing with that kind of pathology. Did you try my script and see that there are no flapping mouths?
If you're still interested in getting to the root cause, you could post a source VOB fragment that contains the same scene as the AVI you posted. If you're not interested, well, you can lead a horse to water...
jellysandwich
27th September 2005, 04:30
jelly, you're not understanding my observations. I'm not going to force them down your throat, but you'd be well advised to try to understand what I'm telling you. There is no flapping mouth problem and no need to do deinterlacing at all if you get the field matching right.
A man walking from right to left should not jump backwards. That's not the action, that's just screwed up.
If you're still interested in doing it right, you should post a source VOB fragment that contains the same scene as the AVI you posted. If you're not interested, well, you can lead a horse to water...
Oh dear god, that really is screwed up. My mistake, I've never done video editing at this level, so excuse my noobness.
Ok then, since I try to be a perfectionist, let's do this right.
http://s61.yousendit.com/d.aspx?id=1TMM9MWUFWJGK33EUAHFS9TBIN
(1 min 23 sec, 73 mb)
Is that enough, or do you need a bigger fragment?
js
Guest
27th September 2005, 04:50
Downloading now. That should be enough.
mg262
27th September 2005, 05:03
I am quite ludicrously glad that I don't have to deal with reverse pulldown. People seem to put more work into dealing with that than any other single issue (cf YATTA). The funny thing is how often I'm told that "PAL is a rubbish standard" ;).
Guest
27th September 2005, 05:26
@mg262
Please watch out for rule 11: "no use" posts. Thank you.
@jellysandwich
I used DGMPGDec 1.4.4 and Decomb 5.2.2. I made a D2V project file using Honor Pulldown Flags. Then I served the video using this script:
loadplugin("dgdecode.dll")
MPEG2Source("E:\tmp\jelly\whr_frag.d2v")
assumetff()
telecide()
decimate()
The result appeared flawless to me when I play the AVS script in VirtualDub, BSPlayer, etc.
I suppose XviD messed up that AVI you posted, as well as your encodes.
jellysandwich
27th September 2005, 13:24
Hmm, interesting. I guess I shouldn't use Xvid for such purposes anymore...
More testing to do, weeee.
js
mg262
27th September 2005, 13:41
@jellysandwich,
Which purposes do you mean? For posting clips for other people to analyse, you should always stick to the source format if at all possible. For encoding, Xvid is IMO an excellent codec but you should probably inverse telecine the source before feeding it in. If you keep getting messed up results with that codec, post your script and settings and I'm sure someone will help you.
@neuron2 -- sorry.
jellysandwich
28th September 2005, 01:54
Yea, for analyzing. VOB fragments seem to work better.
js
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.