Plain deinterlacing or Bob+SelectEvery: what do you prefer and why?

[Terranigma]

well i'm not going to get all technical like scharfis_brain, but i'll give you my predictions. Scharfis might be the most correct, but we'll see. :D

a = tdeint + eedi2
b = mcbob
c = tdeint
d = original
e = securebob
f = mvbob

;)

[Chainmax]

let me guess Chainmax the fastest was SecureBob ;)

Yup :).

What, faster than TDeint alone? I find that hard to believe.

Of course it wasn't, blame that slip-up on a brain fart :o.

[Didée]

I managed to guess MCBob wrongly on Chainmax' sample ... let's see if I manage again. ;)
(It's disadvantageous I didn't download the original sample, since thus I can't cheat;) )

In descending order:

D - original
B - MVBob (discrete [field->field] motionsearch [8x8-blocked] found lots of matches)
C - Tdeint (kernel)
E - TDeint+EEDI - usual EEDI misery
A - SecureBob - big EEDI misery (not static anywhere, so EEDI2 everywhere)

[...big gap...]

F - MCBob (the [field->X<-field] guesswork /w 16x16-blocks mismatched everywhere on runners' "random" motion)

:D

Technical note:
MCBob's Error correction still is rather poor. The tricky part is: in order to reduce flicker on slow motion, MCBob *has* to use a risky strategy: where MVBob uses the traditional "small error is safe, big error is an error" strategy, it is necessary to accept big local errors. With this premisse, seperating "the good from the bad" is quite difficult ...

Perhaps I'm mistaken again, and it's really B=MCBob, F=MVBob ... I'd be happily surprised if it's so, but I fear it's not ...

[Terranigma]

Hmm, you two guys might be right.

[WorBry]

Perhaps I'm mistaken again, and it's really B=MCBob, F=MVBob ... I'd be happily surprised if it's so, but I fear it's not ...

Fear not and be of good cheer for, as Scharfis rightly concludes:


a = securebob (no residual combing, eedi2 artifacts on the tree)
b = mcbob (no residual combing, fine detail remains preserved)
c = tdeint (residual combing from motion map, stairstepping)
d = original (no weirdnesses, full detail)
e = tdeint + eedi (eedi2 artifacts, same residual combing like in c)
f = mvbob (residual combing due to mocomp, throughpassed eedi2 artifacts)


Terranigma - you were not far off.

I'm assuming the ''throughpassed eedi2 artifacts'' Sharfis notes for MVBob are what I assumed to be motion artifacts noticable on closer inspection around the the runners in the foreground. 'Bodies moving on grass' seems to be a particular challenge, as I've noted with my home DV videos, and MCBob copes with this rather well. If anyone has run their own comparative tests on the source clips (;) )they will have also noticed on playback a marked reduction in the shimmering of relatively static areas (e.g. tree tops, background crowd) with MCBob compared to the other bobbers. This was also particularly evident in the Musicians and Toy-Train reference clips that I put up earlier in this thread.


Interestingly, here are the results on the (AVS) quality metric measures that I ran on the full 5 sec clips

Bobber OPSNR SSIM VQM MSU Blur
__________________________________________________
MCBob 36.95 84.55 1.14 28.22
MVBob 33.83 80.88 1.36 27.61
TDeint 34.92 79.32 1.40 27.61
TDeint-EEDI2 33.61 73.32 1.57 26.71
SecureBob 32.98 69.96 1.66 26.89



MCBob clearly stands head and shoulders above the rest in all 3 metrics. Interestingly, TDeint does better than MVBob in the OPSNR ranking and is not far behind in the other two measures.

I’ve also done some parallel tests using the MSU Quality Measurement Tool which reveals similar patterns for PSNR, SSIM and VQM. I’ll put up the graphs and samples for the metric ‘visualizations’ shortly (bogged down with work right now), which I think are quite useful in locating ‘hot spots’. The ‘blur’ measure is also quite revealing. You may or may not be surprised that the ranking in terms of least to most blurring is:

MCBob
MVBob & TDeint – virtually the same.
SecureBob & TDeint-EEDI2 – virtually the same

Edit: I've added the MSU 'Blur Measure values' (Y-YUV channel only) to the above table. The higher the value, the less blurring, as the 'visualizations' confirm. I will put up some images when I have a bit more time.

The lesser degree of blurring seen with TDeint, compared to TDeint-EEDI2 and SecureBob, would, in part, explain the higher PSNR values. But, as our experts note, this belies a notable degree of residual combing and stair-stepping. Therein lies the limitations of objective quality measures.

Still, I'm very impressed with values MCBob achieves. An OPSNR of 36.95 'aint half bad' considering that half of each frame is re-created.

[Didée]

Ooops. :o :D

If there're not much annoying artefacts, it seems I did set up error correction pretty strong for v03b...
Error correction is what I'm fiddling much with these days, and that's why I'm getting nothing but artefacts, more artefacts and even more artefacts from MCBob the last two weeks ... could be I don't have the "right picture" because of this. ;)

But something must be done, imo, because of:

also noticed ... a marked reduction in the shimmering of relatively static areas (e.g. tree tops, background crowd) with MCBob compared to the other bobbers. This was also particularly evident in the Musicians and Toy-Train reference clips that I put up earlier in this thread.
It's this very point I'm getting almost ANGRY about. "Reduced shimmering", indeed. Reversly this means there still is shimmering that can be noticed - even when there should be none: try putting a "return(naked)" at the end of mcbob! (of course then there will be interlacing artefacts everywhere) ... when checking e.g. ToyTrain and Musicians, one will note that all the critical parts (sheeps, rail ballast, piano player's shirt, etc.pp.) show close to *zero* shimmering in the raw weave.
*That* is how those spots *could* look like (and should) ...

Ergo, the current error checking is not smart enough: in the effort of avoiding artefacts, also quite some "good" parts of the compensation get "repaired", and the result shimmers again in places where the plain, not-corrected compensation is smooth as silk and free of artefacts. This I consider unsatisfactory.

[WorBry]

Flip, I sure didnt mean to rattle anyone with my obviously less-than-adequate descriptive terminology, which was meant to be complimentary and encouraging rather than irritating :(

Possibly my comment

This was also particularly evident in the Musicians and Toy-Train reference clips that I put up earlier in this thread.

may have been misconstrued. I was in fact implying that the (ill termed) 'shimmering' that was quite noticable with MVBob etc was indeed 'close to zero' with MCBob.

Think I'll leave well enough alone and duck-out...while your creation 'incubates' :) What do I know anyway.

[Didée]

Halt, full stop. My "angryness" is not about your description, not at all. It's about those dumb computers that can't see the difference between a (soccer) football and a water melon ... :)

[WorBry]

Even so, probably the last you need is someone like me putting up this sort of stuff (probably prematurely) and attempting to make insightful comments when they dont really understand the mechanics involved......but there again, that's what us 'end-users' do when we are enthused about something and cant really contribute anything more useful.....still I hope you've found the test clips helpful.

About those dumb computers....actually I've noticed greater similarity between a melon and a basketball. Maybe I should run some metrics to test that.....see, there I go again.

[Chainmax]

Don't sweat it, Didée is a great guy and if he says he's ok then he's really ok :).

[Revgen]

Don't sweat it, Didée is a great guy and if he says he's ok then he's really ok :).

In Didee We Trust!;)

[Chainmax]

In Didee We Trust!;)

LOL, good one. Continuing with that line of thought:

http://img93.imageshack.us/img93/3149/idwtyo2.png (http://imageshack.us)

;) :D

[Didée]

Thanks for compliments & the nice words ... :o

For the moment, I've settled for this fact:
There is no (direct) way to prevent the machine from kicking the melon and/or eating the football.

But the last few days, I'm following a different strategy: don't try to hold it back. Let it kick whatever it wants to, let it eat whatever it wants to.
But afterwards, it can be checked if there's juice all over the floor, and/or whether the snack has been tasty or tough to chew. ;)

Read: Back-compensation is needed. (Somewhat similar, probably, to backprojection in image resizing.) While this can't close the "hole of uncertainty" which any method will always trap in at some point, it does make the hole much smaller.
The feature has been on the plan from the start, to be added when the "simple mode" had been finished ... seems it's about that time now, in order to achieve any more improvement. Tests so far have been promising, but it still needs big time of fiddling with.

Also, the holy numbers (metrics tests) should increase quite a bit hereby. :)

... alas, speed will be about halved. :(

[WorBry]

LOL, good one. Continuing with that line of thought:


Presumably this is the reverse side :D

http://img214.imageshack.us/img214/5732/usdollar100frontscharfixp3.th.jpg (http://img214.imageshack.us/my.php?image=usdollar100frontscharfixp3.jpg)

[Chainmax]

Most definitely :).


Didée: do you think future versions could be tweaked to take advantage of tsp's multithreaded version of Avisynth?

[Didée]

As we know, the MVTools related parts can't be multithreaded.

All or most other stuff appearing before/after/in-between MaskTools-filters probably could ...

... but I don't have the hardware to test it. :)

[Terranigma]

... alas, speed will be about halved. :(

hehee. That's what I expected, but I don't mind the speed. Long as it does what it should do ;)

[Chainmax]

As we now, the MVTools related parts can't be multithreaded.
...

Time to pester Fizick then :).

[foxyshadis]

Someone buy the man a dual-core for christmas. ;)

[Fulcanelli123]

Someone buy the man a dual-core for christmas. ;)

McBob won't work on my machine. :( Or at least the scripts I imported won't (v03a & v03b).

Do I just "import" them and "McBob()"? If so, it won't do anything - not even move forward a frame. Can't be that slow can it?

I've got the dreaded stair stepping and shimmering lines on my encode, which I've never had before, and from what I've been reading McBob might solve the problem - if I can get it to work for me.

Loaded all the .dlls required, then imported the McBob script, loaded my file, AssumeBFF, then McBob.

Had to ConvertTo Y12() as it's a Huffyyuv file. Can somebody give me some idea how to use this McBob thingy (previously been using Decomb without problems).

Thanks!

[zambelli]

Has MCBob been posted to a Wiki yet?

[Didée]

Has MCBob been posted to a Wiki yet?
It's a preemie, handle with care ;)


Fulcanelli123:
Sounds correct, sure ... if all DLLs are loaded and the source is [converted to] YV12, then you can use MCBob() just like you would use any other filter.
For safety, post your calling script.

However,
it won't do anything - not even move forward a frame. Can't be that slow can it?
it could be that slow, indeed: How much RAM does your machine have? If it's only 256MB/384MB, then things may get very slow indeed. The filterchain in MCBob eats ressources for breakfast, and 512MB seems like the bare minimum to run it. With too little RAM, the system will swap out to harddisk. If that happens, usually it's the ultimate performance killer.

(If motion estimation+interpolation is done on Window's swap file (<- visualize that, hihi), then 20th order equations have to be solved, to compensate for centrifugal forces and vertigo.) :D

[foxyshadis]

The english ones are still down :( and the japanese one doesn't seem to have it yet. I'd have posted it if they were up.

Fulcanelli, do you get any error message? Anything happen besides just hanging?

(btw, in lieu of getting vista with a flash-backed hard drive, you can put your swap file on a flash drive/card if you have one handy. It's still bad, but not nearly as bad.)

[Fulcanelli123]

The english ones are still down :( and the japanese one doesn't seem to have it yet. I'd have posted it if they were up.

Fulcanelli, do you get any error message? Anything happen besides just hanging?

(btw, in lieu of getting vista with a flash-backed hard drive, you can put your swap file on a flash drive/card if you have one handy. It's still bad, but not nearly as bad.)


Nope no error message. It does eventually move but at the rate it's going it'll probably be 10 frames an hour! Totally unusable. :(

It's a huge HD source (resized to svcd) which encodes fine with other deinterlacers like decomb, and while I don't mind adding a couple of hours to the encode if I can get rid of that dreadful stepping - which strangely is only really noticeable on TV and not computer) McBob looks as it would take a week.

Not got a particularly fast comp - AMD 64, 1.8ghz, 1gig ram - but I didn't expect things to be that slow. I have to be doing something wrong.

[Didée]

:script:

[Fulcanelli123]

:script:

Sorry Didee, I missed your earlier reply.

Here is my script:

LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\mvtools\mvtools.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\masktools\mt_masktools.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\EED12\EEDI2.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\removegrain\RemoveGrainSSE2.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\removegrain\RepairSSE2.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\reduceflicker\ReduceFlickerSSE2.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\medianblur\MedianBlur.dll")
Import("C:\Program Files\AviSynth 2.5\plugins\MCBob_v03b.avs") #also tried v03a

AviSource("D:\caps\testclip.avi")
AssumeBFF()
ConvertToYV12()
McBob()
LanczosResize(480,360)
AddBorders(0,60,0,60)
ConvertToYUY2()

I've tried the non SSE files also, as I'm not sure whether my comp has that, but same result. Also tried TFF as it looks exactly the same using either so can't really tell. When I used the TS with DirectShow the encoder always said Lower Field first so I'm guessing it's that.

The file is a 1440x1088 HD PAL clip which I'm keeping at 25fps and running thru DGPulldown later. It's 49 minutes so using 23.976>pulldown would add a couple of minutes and lower the bitrate. Leaving it at 25fps seems to work out ok.

I've previously encoded 2 episodes via DirectShowShource without the stair stepping, and I only usually use Telecide(). No other filters (I prefer a bit of noise as I think it looks more natural on the TV - nobody watches SVCD on computer anymore. ) Unfortunately DirectShow kept messing with the frames - or maybe it was the H.264 codec, so had to save out to Huffyuv. That seemed to do the trick. Except when viewing on TV certain scenes were shimmery and stepping.

Strangely, white tiles and paving slabs didn't show any problems with the lines in between. It was lines on cars, and that yellow "crime scene tape", the seam on a black leather jacket etc. Barely noticeable on the comp but really distracting on the TV. Thought there was something wrong with my eyes!

Maybe it's Huffy...had a look in VDub, and stepping got introduced when I resized...tried every resizer with the same result.

The file is half progressive and half interlaced. The interlacing is really poorly done too, looks like a double exposure in one scene.

So I'm hoping MCBob might fix the worst of the stair stepping. Don't mind letting it run overnight, but any longer and I have to use the computer. Encoding always maxes my CPU out.

I thought it might be the size of the clip that was causing the prob - 78gig Huffy file, so I just clipped a couple of minutes where the worst stair stepping is and tried to filter that bit, but it still has problems seeking. I'd be lucky to get a couple of frames a minute the way it's looking. Hopefully I'm doing something wrong and fixing it will pep things up a bit.

Other than the stepping I'm really pleased with the encode and don't want to go back to capping the SD version.

[Terranigma]

try this instead
separatefields().selecteven()

[Fulcanelli123]

try this instead
separatefields().selecteven()

Nope, tried that and it still took as long. :( Also gave me 50fps.

[Terranigma]

Nope, tried that and it still took as long. :( Also gave me 50fps.

Hmm. Your source original fps is 25.00fps, am I'm correct?
If so, then are you aware that bobbers are usually double-rate deinterlacers? mcbob should be followed by either Selecteven or Selectodd. The parameters i've mentioned above were for the handling of the interlacing. Now if your source fps is 50fps, and you'd like to lower it to 25fps, then add in this line
decimate(cycle=2).

:cool:

[Fulcanelli123]

Hmm. Your source original fps is 25.00fps, am I'm correct?
If so, then are you aware that bobbers are usually double-rate deinterlacers? mcbob should be followed by either Selecteven or Selectodd. The parameters i've mentioned above were for the handling of the interlacing. Now if your source fps is 50fps, and you'd like to lower it to 25fps, then add in this line
decimate(cycle=2).

:cool:

Yeah source is 25fps, which obviously I need to keep at that for playback on a standalone. (Will be running it thru DGPulldown for NTSC playback)

I'm confused though. If it's deinterlacing by separating the fields and not weaving them back together, using decimate throws away half the fields no? So wouldn't you get the same result in the first place by just dumping one of the fields? Or am I missing something?

[Terranigma]

I'm confused though. If it's deinterlacing by separating the fields and not weaving them back together, using decimate throws away half the fields no? So wouldn't you get the same result in the first place by just dumping one of the fields? Or am I missing something?

Yes, I thought your source was 50fps 'cuz you said your output was still 50fps. ;)
Yes, You'd get the same result. Just using Tom Barry's uncomb filter (which selects the appropriate even/odd fields, thus negating the interlace) is enough.
Now if this was a dvd file, i would've mentioned
seperatefields().weave()., but we're talking about hd here, which would'nt really hurt the quality if you chosed not to weave.

The reason why your output is coming out at 50fps, is because mcbob is not being followed by anything is it, like Selecteven? Again, it's a bobber, so it's a double-rate deinterlacer. :p

[foxyshadis]

No, smart bobbers require all fields to make their decisions before you get to throw half of them away.

In your case, however, you're resizing down way below half your field size. Have you considered just replacing the deinterlacing step with separatefields().selecteven(), rather than doing it after the bobbing? I think that's what Terranigma was pointing out. That would be lightning fast, and you're chucking out so much after the bob that this really isn't worthwhile.

If you still get shimmering in that case it's your source's fault, not something a bobber can fix (although other tweaks might be able to).

Anyway, I'm pretty much going to bet that this is a perfectly normal speed, given your processor and the resolution, and since you have no setmemorymax(), it's still hitting the swap file even though you have 1g, because it's so huge. Try setmemormax(512). If your video grinds the hard drive it is wrong, heavy video processing should always mean light hard drive access.

Another way you should optimize it: Resize horizontally before bobbing, resize vertically after. But before even trying that, try just dropping the field and resizing.

[Terranigma]

No, smart bobbers require all fields to make their decisions before you get to throw half of them away.

Have you considered just replacing the deinterlacing step with separatefields().selecteven(), rather than doing it after the bobbing? I think that's what Terranigma was pointing out.

That's exactly what I meant :cool:

[Fulcanelli123]

Have you considered just replacing the deinterlacing step with separatefields().selecteven(),

Ah, I was using it after MCBob.

If I use it instead of the bob then I won't be using MCBob which is what I'd hoped would get rid of the shimmers and stair stepping, after reading this thread.

I just tried a 1 minute clip with MCBob and Procoder said it'd take 4hrs so that's obviously a no-go. Tried it with just dumping the fields and that still gave the stair stepping/shimmers. Normally I'd expect that to disappear on TV but this has gotten worse. I must have created the worlds first svcd which actually looks better on the comp!!

If you still get shimmering in that case it's your source's fault, not something a bobber can fix (although other tweaks might be able to).

It's not technically the source because when I look at the full file - which is difficult as my screen res is set to 1024x768 and the file is 1440x1088 - I can see the bits that are giving me problems and everything looks fine. When I resize though and examine it I have stair stepping in certain parts. It was very faint on the encode when viewed on the comp, but the glare and shimmer on TV was pretty startling.

Previous encodes I did using the TS with DirectShowSource and avisynth never gave me such a problem so I'm wondering if it's the Huffy encode that's thrown a spanner in the works. Aside from that, telecide works fine and I usually get a nice encode. I've got to sort this shimmer/stepping problem though.

Normally I do a backup cap in SD because the HD ones have been so hit and miss with the DirectShow filter messing up frames, but I thought I'd solved it with Huffy. The encodes usually look the same except the one using the HD source is obviously much sharper and 'cleaner'. The SD version didn't have the stepping or shimmers but it's possibly because the HD one shows more.

I think I might try encoding the problem area directly with the TS and DirectShow again. If no problem, then it's Huffy and I'll have to find a new lossless codec to act as intermediary.

Pity I can't use MCBob though, as it sounds fantastic!

Another way you should optimize it: Resize horizontally before bobbing, resize vertically after.

I'll give that a shot. Thanks.

Gawd, if I knew how difficult it would be to decode/encode these wretched AVC files, I think I mightn't have bothered!

[Fulcanelli123]

That's exactly what I meant :cool:

Heh, sorry. I'm in idiot mode tonight. These bloody HD files have pummeled my brain into exhaustion.

[vkamicht]

Hmm, I'm having some color issues and I don't know if this has been brought up yet.

I'm trying to deinterlace some video game footage (from PS2) and it works great for the most part, but I tend to notice a lot of color distortion sometimes. However it seems to actually be a form of ghosting. Here are 4 images, you can compare a bicubic resized version of the field with the deinterlaced frame. 1 and 4 look ok (though you can still see this "ghosting") but 2 and 3 are the worst offenders.

Anyone know why this is happening? Perhaps I'm missing something... the script is real simple

AviSource("RAW_TOD.avi").ComplementParity
ConvertToYv12().mcbob()

1. bob (http://img53.imageshack.us/img53/8407/bob1xk6.png) - mcbob (http://img158.imageshack.us/img158/2261/mc1vs0.png)
2. bob (http://img201.imageshack.us/img201/7653/bob2vh6.png) - mcbob (http://img82.imageshack.us/img82/5977/mc2ic0.png)
3. bob (http://img149.imageshack.us/img149/5318/bob3xl3.png) - mcbob (http://img464.imageshack.us/img464/4636/mc3kb5.png)
4. bob (http://img83.imageshack.us/img83/979/bob4wm6.png) - mcbob (http://img208.imageshack.us/img208/7421/mc4mc3.png)

I know at 60fps these might seem trivial, I can't even notice them watching it normally. Despite that it still seems like a glaring error and I can't help but think it might effect compression performance.

Thanks

[Didée]

Okay, let's see if MCBob is at fault ... try the exact same script, just with Bob() instead of MCBob():

AviSource("RAW_TOD.avi").ComplementParity
ConvertToYv12().Bob()

Try, and report how the result looks like. :)

[vkamicht]

Okay, let's see if MCBob is at fault ... try the exact same script, just with Bob() instead of MCBob():

AviSource("RAW_TOD.avi").ComplementParity
ConvertToYv12().Bob()

Try, and report how the result looks like. :)

Oh... :o

Yeah, you're right... it's not mcbob at all. Well then, that raises another question: why is converting to YV12 doing this and how can I avoid it? :P

[Didée]

Since your input is interlaced, it might be an idea to use

ConvertToYV12(interlaced=true) :)

[vkamicht]

Since your input is interlaced, it might be an idea to use

ConvertToYV12(interlaced=true) :)

Thanks a ton, good sir. Loving the script :p

[wonkey_monkey]

Any news on mcbob, Didée? Is it close to deserving it's own thread? ;)

I'm seriously considering writing a control program that will distribute scripts to multiple PCs and collate the results, just so I can make use of mcbob in a more reasonable amount of time (3-4x realtime). Or can anyone suggest which functions I might farm out to other PCs using tcpdeliver/tcpsource?

David

[Terranigma]

Any news on mcbob, Didée? Is it close to deserving it's own thread? ;)
David

Didée will not purposely release a later version unless he's fully satisfied with the output quality the deinterlacer provides, so it might be a while before we see version d, or 0.4.

===

The latest beta version of mcbob can be found Here (http://forum.doom9.org/showthread.php?t=118784&page=2).
;)

[steve77]

Hello all,

I've read these forums time and time again to get tips on deinterlacing material, but I need to upgrade my arsenal of AviSynth plugins.

I have used mostly Donald Grafts Decomb Filter Package, which works great for most uses.

I had tried his DGBob filter, but video would "shimmer" far too much for my liking.

I'm basically a deinterlaicing virgin. :rolleyes:

So anyway, if you could help me out this would be great.

Problem: I need some new deinterlacers

1- Now I've looked and it seems that MCBob is the best bobber available, judging by your comments. I have a fast PC (Core 2 Duo @ 3.2GHz) so I have enough processing power.

I've used TDeint w/ EEDI2 and was pleased with the result it had given me. I downloaded:
EEDI2 - 2006/06/07 v0.9.2
TDeint - 2006/10/16 v1.0 (Released)

from: http://www.missouri.edu/~kes25c/
and put those in my AviSynth "plugin" folder... is this all I need, or are other plugins required before writting my .avs file?

2-I clicked the link for MCBob and it seems like there is only code, and no dll to put into my AviSynth Plugin directory. Do I have to compile it or something? And is there an easy way to find all the "prerequisite" plugins easily?

Thanks VERY much for the help, I sure can use it.

Steve

P.S. Wow first post in almost 2 years. Like I said, I come and read here alot, but right now I NEED your help

[Adub]

There is no dll. It is an Avisynth script. You can save it as an avs or an avsi, for easy loading.

You search for more information.

[wonkey_monkey]

Out of curiousity, is anyone else interested in methods for distributed encoding? I've got as far as remotely initiating Avisynth encodes to Xvid - now all I need to do is write a control program. Unfortunately I'm not too hot on writing user-friendly apps, but if there's interest I'll try my best.

mcbob in realtime is within my grasp... ;)

David

[steve77]

Ok, I had already guessed that I had to save as a .avs file. I also read that I need:

# - MVTools, preferably v1.4.13 (or newer)
# - MaskTools v2.0
# - EEDI2
# - RemoveGrain/Repair package
# - ReduceFlicker (if temp-NR for ME is used)
# - MedianBlur by tsp

But:

1-Where do I download these?
2- How do I "call" the MCBob function? Do I put the text in an avs file followed by:

mpeg2source("mysource")
MCBob(paramaters)

:confused:

EDIT... I tried this:

Ok, I had already guessed that I had to save as a .avs file. I also read that I need:

mpeg2source("BWA.d2v")
mcbob()

...mcbob script cut and paste....

Is there a easy way to implement MCBOB?

And had the following error message:

Avisynth open failure:
RemoveGrain: invalid mode 20
(C:\Video...\MCBOB.avs, line 224)
(C:\Video...\MCBOB.avs, line 2

[Boulder]

You need the latest RemoveGrain dll, download it here: http://home.arcor.de/kassandro/RemoveGrain/RemoveGrain.rar

[steve77]

Ok that seems to have done it. However:

1- Is there anything I can configure with MCBob or do I just do as previously indicated, that is load the file in the first line then use MCBob() in the second

2- I'm getting 4 frames per second in the "Video Rendering Rate"... and am only getting ~50% load. I'm guessing that everything that makes up MCBob isn't multithreaded /SSE optimised? Is it really that slow?

3- I'm getting some black stuff on the top of some frames. Is there a workaround or should I just crop the top line?

[Boulder]

1. If you don't know what you're doing, just use MCBob()

2. Well, I'm much closer to 4 seconds per frame. The official Avisynth release isn't multithreaded. tsp's special build is but you can't use any multithreading options with anything that includes MVTools and MCBob is one of those.

3. Crop or use LetterBox

[Revgen]

Ok that seems to have done it. However:

1- Is there anything I can configure with MCBob or do I just do as previously indicated, that is load the file in the first line then use MCBob() in the second

2- I'm getting 4 frames per second in the "Video Rendering Rate"... and am only getting ~50% load. I'm guessing that everything that makes up MCBob isn't multithreaded /SSE optimised? Is it really that slow?

3- I'm getting some black stuff on the top of some frames. Is there a workaround or should I just crop the top line?

If your hard drive is big enough, and you have enough memory (more than 1gig) just encode the movie lossless and split the movie into two halves and encode it on your dual-core.

Make sure to go into Task Manager-->Set Affinity and make sure both avisynth encodes are encoded by 2 separate cores by assigning "cpu 0" to one and "cpu 1" to the other. Works for me with MVBOB. Cuts the encoding time by about 70%.

Then just cut the 2 halves back together and encode to Xvid or X264. The longer the movie is the more time you save. It's the only way to use Dual-Cores to encode with MVTools.

Also make sure that you have 2 separate mvtools.dll files loaded for each avisynth script. For some reason, it doesn't work well when one mvtools.dll file in a single location is use for both avisynth encodes at the same time.