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

Didée

14th October 2006, 03:42

Basically, quality-wise both methods are the same. The result depends on the used deinterlacing routine only. A same-framerate deinterlacer will ask you for a "field=top/or/bottom" parameter, defining which of both fields will be thrown away & interpolated: Same framerate = one field doomed.
A bobber does the same, but after each frame inserts another frame that is based on the previously thrown-away field: Framerate doubled by not dooming one field.

Or, perhaps like this:

Same-framerate-deinterlacing:
> source.Deinterlace(field=[top or bottom])

Double-framerate-deinterlacing (Bobbing):
> source.DoubleWeave().Deinterlace(field=[alternating])

So, obviously, decisive for the result is only the deinterlacing algo. And that's where MVbob is bringing an additional choice over TDeint, LeakKernel-XX, and Co. : all these are "only" motion-adaptive, i.e. in moving areas, they have to give up & can only do interpolation guesswork. MVBob currently is the only one taking the chance to search around for really-present image information that can be transported into those missing scanlines.

I'd say that, in theory, MVBob.SelectEither() should deliver superior image quality compared to the other methods, simply because the technique used for deinterlacing is more advanced.
Note that this doesnt say that the technique is already maxed-out ... MVBob does have its own problems just as well, so it's not necessarily "the best" of the available choices. The current implementation of the more advanced technique still has a few issues left over ... something should be done in that area. ;)

Chainmax

14th October 2006, 04:38

Thanks for the explananation, Didée :).

Seed

14th October 2006, 08:37

MVBob and its variants are bobbers: they deinterlace to double the original framerate. What I'm asking about is same-framerate deinterlacers.

Didee has explained nicely. What I mean is mvbob.selecteither method.

While on this interlaced material processing department, I am often affected by "highest-quality-itis syndrome", and uses
mvBob, temporal or spatial-temporal denoising filters, SeparateFields, SelectEvery(4, 0, 3), Weave method for intermediate deinterlacing of interlaced footage. That is when I leave my PC running overnight :D

Didée

21st October 2006, 02:46

I'm only interested in the best quality short of interlaced encoding. I guess that still means TDeint+EEDI2 then,
Check this (http://rapidshare.com/files/80071/CompareBobs.rar.html).

Trixter

21st October 2006, 03:57

MVBob and its variants are bobbers: they deinterlace to double the original framerate. What I'm asking about is same-framerate deinterlacers.

The problem with same-rate deinterlacers is that you will be throwing away half the motion no matter how you process it. For material shot on video, it's unacceptable -- the end result always looks "computery" (terrible phrase, I know). 60Hz interlaced material that has been same-frame deinterlaced, no matter the process, now has judder during horizontal pans and generally looks cheap, IMO.

My first full-field capture device was an IOMega Buz (remember those?) from 1998 which was essentially a very high quality Zoran MJPEG capture device coupled with some truly sh*tty software drivers. The input was awesome but the drivers didn't pay attention to field order and some captures were BFF and others were TFF. To fix the problem, I attempted deinterlacing every single clip (both field duplication and field blending) but you could clearly see, on the Buz's video output hooked up to a television, that it destroyed the smooth motion I had just captured. I couldn't live with that, so I invested in a Pinnacle device (with the same chipset, heh) that had proper drivers that worked.

So all this rambling has a point: What footage do you have where same-frame deinterlacing is the "best" option?

Trixter

21st October 2006, 04:00

I am often affected by "highest-quality-itis syndrome", and uses
mvBob, temporal or spatial-temporal denoising filters, SeparateFields, SelectEvery(4, 0, 3), Weave method for intermediate deinterlacing of interlaced footage. That is when I leave my PC running overnight :D

Overnight? I just finished up a PAL->NTSC transcode for 3 hours of footage -- it took two 3GHz machines 5 solid days (that's 240 CPU hours) to complete! But my transcodes look MUCH better than the Sony DSC-1024 we've got here, so nobody is complaining :D

Seed

21st October 2006, 11:14

Overnight? I just finished up a PAL->NTSC transcode for 3 hours of footage -- it took two 3GHz machines 5 solid days (that's 240 CPU hours) to complete! But my transcodes look MUCH better than the Sony DSC-1024 we've got here, so nobody is complaining :D

Mine is a 3Ghz (overclocked) machine too, but my clips are edited in 5-10 minutes sequences and compiled into a 10-20 chapters DVD.

BTW, I was also an ex-user of IOMega Buz :scared: . Yea, good hardware, bad driver and ugly support! Luckily 1n 1998 my required final output was VCD, and TMpegEnc did a nice job of deinterlacing and encoding. I later switched to a Philips SAA 7134 chipset capture card and never looked back. Indeed it is still my capture card via S-video input.

Seed

21st October 2006, 11:36

Note that this doesnt say that the technique is already maxed-out ... The current implementation of the more advanced technique still has a few issues left over ... something should be done in that area. ;)

Your SoonToComeBob() looks pretty promising. Though as you said no technique can claim to have "maxed out" in this smart-bobbing area, I eagerly await it. I hope "soon" means within a few weeks ;)

check

21st October 2006, 12:07

I assume this new bobber will be as slow as paint peeling? It just wouldn't feel right otherwise :D

Seed

21st October 2006, 15:52

The topic title keeps changing. i'm sorry to say that the current tilte "Plain deinterlacing or Bob+SelectEvery: what do you prefer and why" is not quite appropriate. TDeint (with or without EEDI2) is a very sophisticated deinterlacer and will do a much better job of deinterlacing than a dumb/not-so-smart bobber +SelectEvery

CruNcher

21st October 2006, 17:29

For me personaly i allways use Securebob it's a good Speed/Quality tradeof for me.
but the best Speed/Quality @ the moment wich sadly yet can't be used (at least no one wrote a custom allocator for it yet) is Nvidias Per Pixel Adaptive Motion Deinterlacer inside their Mpeg-2 Decoder (PureVideo) it has no problems to convert 1080i into double framerate progressive Video in Realtime (on the GPU) pretty exciting to see that in front of your eyes, quality isn't as good as tdeint tough :)

Tdeint with GPU support that would be the revolution :D

Didée

21st October 2006, 18:13

IMO, SecureDeint is too anxious with its motion masking. Avoiding motion artefacts is good and all, but if it comes at the cost of many "in fact static" areas still keeping bobobobobbing, then it's not a good tradeoff.

Motion masking of the upcoming upproach is fully adaptive to local complexity, like my unheared proposal in the TDeint thread. Works like a charm, nonetheless.:) Wrapping it out ala SecureDeint won't be a problem.

WorBry

22nd October 2006, 14:37

Hi Didee,

In testing your ‘SoonToComeBob’, I thought you might be interested (as I would) in seeing how it fares with this clip, which I think is as good a ‘deinterlace stress test’ as any.

http://rapidshare.com/files/229055/Test_576i25_TFF_YV12_3sec.avi

It’s sample from one of the reference D1 576i25 sequences (src6_ref__625) at

ftp://ftp.crc.ca/crc/vqeg/TestSequences/Reference/

I converted the original 8 bit YUV4:2:2 (UYVY or YUY2) sequence (Top Field First) toYV12 (FFDShow-HuffYuv) via RawSource and ConvertToYV12(interlaced=true) and used a 3 second sample as the source for testing:

MVBob (latest public version 14.9.06)
SecureBob
TDeint-EEDI2
SmoothDeinterlace

I intentionally sampled the clip to include a scene change. After deinterlacing I resized to 720x544 (Lancozos3).

As expected, MVBob and SecureBob are rather more effective in avoiding residual interlacing artifacts, most noticeable with the white road line and around the captions in the areas of fast background motion. Here are grabs of frame 102:

http://rapidshare.com/files/230193/Frame_102_MVBob_14.9.06.jpg

http://rapidshare.com/files/230258/Frame_102_Secure_Bob.jpg

http://rapidshare.com/files/230342/Frame_102_TDeint_EEDI2.jpg

http://rapidshare.com/files/230416/Frame_102_Smooth_Deint.jpg

However, on stepping through the frames, it will be seen that MVBob and SecureBob are rather more susceptible to modulation (swelling) in the height of the captions with some bobbing of the strip margin. Of course, this is barely noticeable on normal playback, but is it what you are referring to by ‘bobbing of static areas’?

Didée

22nd October 2006, 18:37

Good (awfully;)) test clip indeed. Reveals there is work left to do.

Why did you vertically resize for the comparison? That's less than ideal, in order to check for the raw deinterlace performance.

Your result with MVBob I cannot reproduce at all. With the latest version, just "MVBob()" gives me this:

http://img345.imageshack.us/img345/2469/frame102mvbobya6.th.png (http://img345.imageshack.us/my.php?image=frame102mvbobya6.png)

And that's pretty much the performace I'm getting always of it. Only rescue is to reduce "correctth" so much that the whole thing becomes almost a no-op.
You surely didn't mix up something? Could you please state the exact settings used?

WorBry

22nd October 2006, 20:20

Didee,

Yeah, you are right, in my haste I duplicated the frame grab from the SecureDeint encode, instead of MVBob. Here’s the ‘correct’ MVBob frame 102 (at 720x544).

http://rapidshare.com/files/268836/Frame_102_MVBob_14.9.06.jpg

These are the scripts I used – nothing fancy, with both MVBob and SecureBob at default.

AVISource("C:\... Test 576i25 TFF YV12 3sec.avi")
AssumeTFF()
MVBob() or SecureBob()
LanczosResize(720,544)

AVISource("C:\... Test 576i25 TFF YV12 3sec.avi")
AssumeTFF()
interp = separatefields().eedi2(field=2)
tdeint(mode=1,order=1,edeint=interp)
LanczosResize(720,544)

AVISource("C:\... Test 576i25 TFF YV12 3sec.avi")
AssumeTFF()
SmoothDeinterlace(tff=true, doublerate=true)
LanczosResize(720,544)

The MVBob (and SecureBob) version used is this one (14th Sept 2006):

http://home.arcor.de/scharfis_brain/mvbob/mvbob.rar

I resized to 720x544 because that’s the resolution I normally use for MPEG-4 encodes for PC playback, but I receive your point about it being more difficult to accurately assess deinterlacing performance. Here are the grabs again without resizing:

http://rapidshare.com/files/269028/Frame_102_MVBob_14.9.06_720x576.jpg

http://rapidshare.com/files/269095/Frame_102_Secure_Bob_720x576.jpg

http://rapidshare.com/files/269170/Frame_102_TDeint_EEDI2_720x576.jpg

http://rapidshare.com/files/269138/Frame_102_SmoothDeinterlace_720x576.jpg

Didée

23rd October 2006, 14:47

WorBry -
You also messed up the TDeint+EEDI2 deinterlacing: you've to use "eedi2(field=-2)" to let eedi2 automatically adapt to the actual fieldorder, or field=3 to manually set it up for TFF. field=2 is just plain wrong, here.
Used correctly, result looks like this (http://img108.imageshack.us/my.php?image=frame102tdeinteedi2correctts0.jpg).

Moreover, those obvious motion artefacts should be possible to catch by using the AP feature of TDeint. Didn't try that, though.

Anyhow, if you zoom in & look close, do you still hold up with the finding about which deinterlacers avoid residual combing? I see lots of it, everywhere ...

For the new toy, this clip surely forces to make some modifications. That half-transparent static overlay is a stinker. :)

But results are already getting better. And when compairing to this (http://img120.imageshack.us/my.php?image=sarahsecuretp1.jpg) or this (http://img140.imageshack.us/my.php?image=sarahmvbobzq3.jpg) or this (http://img78.imageshack.us/my.php?image=sarahtdeinteedilf5.jpg), I feel quite comfortable with getting this (http://img78.imageshack.us/my.php?image=sarahnewcg4.jpg) instead. Feels a bit like quadrature of the circle. :)

A test version is here (http://home.arcor.de/dhanselmann/_stuff/MCBob_v03a.avs) - usage at own risk only. Keeps changing.

foxyshadis

23rd October 2006, 19:02

Pookie

23rd October 2006, 19:48

I spot four separate eedi2 calls (although three are pp-only), and chunks of mvbob. I would expect no less, but see if you can throw a fifth in - these new dual cores might be able to get over a half an fps right now, and you wouldn't want to ruin your reputation. ;)

LimitedSharpen and SeeSaw are peppy - fast enough for real time processing during playback. :D

WorBry

23rd October 2006, 20:01

You also messed up the TDeint+EEDI2 deinterlacing: you've to use "eedi2(field=-2)" to let eedi2 automatically adapt to the actual fieldorder, or field=3 to manually set it up for TFF. field=2 is just plain wrong, here.

Yep, that was plain stupid of me. In my initial tests I reversed the field order to BFF (with ReverseFieldDominance) but with some weird results. On reverting back to TFF I overlooked to change the EEDI2(field) from 2 to 3.

Anyhow, if you zoom in & look close, do you still hold up with the finding about which deinterlacers avoid residual combing? I see lots of it, everywhere ...

True, but I wasnt suggesting it was absolute, just "rather more effective". Perhaps I should have chosen my words more carefully - ''reducing'' rather than ''avoiding" residual deinterlacing artifacts

A test version is here (http://home.arcor.de/dhanselmann/_stuff/MCBob_v03a.avs) - usage at own risk only. Keeps changing.

Cool, thanks:)

Didée

24th October 2006, 13:14

I spot four separate eedi2 calls (although three are pp-only), and chunks of mvbob. I would expect no less, but see if you can throw a fifth in - these new dual cores might be able to get over a half an fps right now, and you wouldn't want to ruin your reputation. ;)

Funny. :D

There are not any chunks of mvbob used. Except for usage of EEDIbob, MCBob was created from bare scratch. The multiframe max'ing of the motion mask is similar, sure ... there are not too much different ways to put a thread through a needle's eye. MCBob uses different yarn, however. ;)

EEDI usage isn't as insane as it might look at first glance. Normally, EEDI is used either only once (EdiPre=1,EdiPost=0, or EdiPre=0,EdiPost=1), or maximally twice (EdiPre=1,EdiPost=1). Post=2 is just experimenting, anyway.
Mind you, it's not "sports" for me to make scripts as slow as possible. I just do what I think that has to be done; and if the result runs at mfps, then it does for a reason. See, the actual MVBob crawls at ~2fps for me ... and that's with MVBob, no offense, being a script doing mostly bare basics ... and looking at the result closely, I see not enough justification for the extensive processing time. Using a fast deinterlacer, out come shimmering and artefacts. Investing much time into MVBob, out come - - shimmering and artefacts ...

So, in order to do better than what we currently have, most probably things will get slower than what we currently have. Simple logic.

Speed is low due to, of course, the overall amount of operations done. In particular:

- Same-parity search requires MVFlow pixel interpolation instead of MVCompensate block compensation. Flow is slower.
(But it has to be done necessarily. Inter-parity ME/MC as in MVBob, by principle can't do much against the main "bobbing" issue: for static parts you don't need MC, and in motion parts ME will just follow the present bobbing. Blurring before searching hardly helps on that matter. Same-parity search surely rises a bunch of other problems, but basically there's no way around using it.)

- The "nothing-new" thingy forces one more set of frame's subpixel interpolation to be stored (ressources), and one more set of motion interpolations to performed (speed). From the idea, it's surely a right thing to do. How much the actual benefit is, has to be seen. It should be mostly benefitial with EdiPre=0, and much less with EdiPre=1, so it should be switchable instead of hardcoded.

Then, there are a bunch of small functions that imo nicely qualify to be coded as (more speedy) plugins:

- Vinverse() is quite handy to kill out residual combing, with visual loss close to zero.

- MinBlur() makes a "best of both worlds" combination of a (more or less) gaussian filter with median filtering. Result reminds a little of a bilateral filter.

- At lines 125~135, there is a scripted variant of MaskTools' in/expand, which also could fit well into MaskTools. The original filters "only" in/expand absolute pixel values. Here, I'm doing the corresponding operation on "difference" maps, i.e. what gets in/expanded is the pixel "magnitude", instead of the absolute value. Or in other words, a "signed" version of in/expand, where "zero" is 128.

- the "STT" thingy already is relatively fast ... originally, I implemented the idea in the way I had "seen" it, with two subsequent 7-tap-with-holes convolutions on the bobbed frames. Then I realized that practically the same could be done with just a blurry bob. Aaah, speed. ;)

foxyshadis

24th October 2006, 18:18

I tease, but it looks quite interesting. Honestly, I couldn't see any difference at all in the clip you posted, but on one of my own I did. And the speed difference isn't that much!

Anyway, Vinverse is something I've needed a few times and usually had to rewrite as a custom function each time; this one looks a little nicer than my attempts. That alone is awesome.

WorBry

24th October 2006, 21:28

Hi Didee,

Tested MCBob v3.0 (at default settings) with the ‘stinker’ clip - I’m seeing holes and residual comb artifacts in and around the smoke in the area of the car body and wheels (above the semi-transparent strip).

http://img409.imageshack.us/img409/5229/frame111mcbob720x576ma2.jpg

http://img249.imageshack.us/img249/1403/frame111mvbob720x576vc7.jpg

http://img249.imageshack.us/img249/8190/frame111securebob720x576dq1.jpg

http://img265.imageshack.us/img265/5769/frame111tdeinteedi2720x576fq0.jpg

Certainly, as you suggested, the AP parameter in TDeint is quite effective at removing these residuals. Here's the result with

interp = separatefields().eedi2(field=3)
tdeint(mode=1,order=1,edeint=interp, AP=5, APType=0 )

http://img401.imageshack.us/img401/2051/frame111tdeinteedi2ap5720x576up5.jpg

Is there a similar tweak in MCBob?

Didée

25th October 2006, 09:23

@ Worbry

Indeed, I forgot something. Look below: ;)

http://img176.imageshack.us/img176/2972/correctionco3.th.png (http://img176.imageshack.us/my.php?image=correctionco3.png)

Honestly, I couldn't see any difference at all in the clip you posted, but on one of my own I did.
Jeeze, really not? Load in Vdub, and step through the frames. In the clip bobbed by TDeint+EEDI2, practically all detail is flickering or bobbing up/down. The row of lights in the foreground not only flickers, but in the righthand part also shows the uglyness of EEDI2 errors. MCBob for the most parts is as calm as a lossless bob filter can only do.

Didée

26th October 2006, 00:29

I've put up a slight revision of the script: MCBob v0.3b (http://home.arcor.de/dhanselmann/_stuff/MCBob_v03b.avs). Still sloppy, but it handles this motoracing clip without (too) obvious errors, while keeping the benefits intact which the whole thing is targetting at.
Also, the included Vinverse() function was updated: there was a small, but not trivial error in it.

For those with tired eyes like foxyshadis :p , I've uploaded some short samples that should make the difference more obvious:

1) static comparison (http://rapidshare.com/files/662851/BobComparison_static.rar.html) - a scene showing the effekt of the motion masking procedure

2) motion comparison (http://rapidshare.com/files/665834/BobComparison_motion.rar.html) - a scene showing the effect of same-parity search vs. inter-parity search or no search at all
(lightspots & line structures (green ones!) in the background, top edge of sara's dress on the top, ...)

3) artefacts (http://rapidshare.com/files/659527/BobComparison_artefacts.rar.html) - a very short sequence with (or without) introduction of artefacts.

The sources are of mediocre quality from the start, consequently the overall look is not exactly impressing. But when compairing them one against each other, it should get pretty obvious where the differences are. :)

For the moment, that should've been the most part. I'll promise to make up a new thread, once I've settled down on the remaining nitpicks. (Could be Don is already drumming with his fingers, because of thread hijacking ;) )

Fizick

26th October 2006, 18:47

may be moderator can split the thread?

Chainmax

27th October 2006, 03:06

...
I'd say that, in theory, MVBob.SelectEither() should deliver superior image quality compared to the other methods, simply because the technique used for deinterlacing is more advanced.
Note that this doesnt say that the technique is already maxed-out ... MVBob does have its own problems just as well, so it's not necessarily "the best" of the available choices. The current implementation of the more advanced technique still has a few issues left over ... something should be done in that area. ;)

Ok then, would you prefer MCBob.SelectEither() or MCBob.TDecimate(mode=7,rate=initialfps)?

scharfis_brain

27th October 2006, 20:40

what is the sense of doing decimation to the half framesrate on pure moving video without dupes?

Chainmax

28th October 2006, 02:56

I assume it will give better results than simply throwing away all the even or odd frames.

Didée

28th October 2006, 05:54

foxyshadis

28th October 2006, 06:14

If you're looking for some kind of motion fluidity boost, you can use mvfps, or mvflowblur.

halsboss

28th October 2006, 06:33

Er, I can't reliably locate latest mvfps perhttp://forum.doom9.org/showthread.php?p=893298#post893298

WorBry

28th October 2006, 07:16

Or you could try this, a modification of Scharfis_Brain's mvfpsscd (mvfps with improved scene detection) using MG262(Clouded)'s 'MotionProtectedFPS' script instead of MVConvertFPS.

http://forum.doom9.org/showthread.php?p=761045#post761045

Gives nice fluidity of motion without too much blurring of slower moving detail. The original mvfps (or mvfpsscd) function is less prone to structural distortions (see the images I put up in that thread) but is much slower.

Chainmax

29th October 2006, 00:11

Wrong assumption. When you use a decimator to halve the framerate, the decimator will do nothing else but throw away half of the frames. Only difference to SelectX() is, if the decimator tries to be "smart", there's a slight chance to get jerkyness in some places. :)

I see, thanks for the explanation. Does it make a difference wether the video is TFF or BFF when selecting between using SelectEven() or SelectOdd()?

zambelli

29th October 2006, 02:45

Does it make a difference wether the video is TFF or BFF when selecting between using SelectEven() or SelectOdd()?
You should always use SelectEven(), regardless of whether you AssumeTFF() or AssumeBFF(). The point of AssumeXFF() is precisely to determine which field comes first. The first field will end up being frame #0 after bobbing, which is why you want to use SelectEven().

Chainmax

30th October 2006, 05:24

zambelli

30th October 2006, 06:22

I didn't say I was going to use AssumexFF() anywhere on the script. I'd just Bob then select either the even frames or the odd ones. What I meant was if the video being TFF or BFF had an impact on deciding which ones to select.
But you have to select field order when bobbing. That's what determines which fields (top or bottom) end up as even or odd frames.

WorBry

30th October 2006, 07:25

zambelli

30th October 2006, 10:22

If I am not mistaken, smart bobbers like MVBob, and now MCBob, automatically detect the field order of the interlaced source and deinterlace appropriately (i.e. Order 1 for TFF and Order 2 for BFF). However, as an added precaution, and partly out of habit, I do usually include XFF before bobbing, having first determined the field order of the source. Of course, if you get it wrong then its going to screw up the bob resulting in a jumpy output. As far as I can see, that is the only impact of XFF on the outcome. Since the output is progressive, surely it shouldnt matter whether you SelectEven or SelectOdd?
No, most deinterlacers/bobbers I've encountered rely on Avisynth field order (which is typically set via AssumexFF if not inherited from source) or require you to pass the field order as a parameter to the plugin/function.
SelectEven() selects the frames constructed from the dominant field. SelectOdd() will pick the frames constructed from the opposite field.

krieger2005

30th October 2006, 12:20

MVBob and others need the AssumexFF-command before they were called. But i think you @zambelli are not right, when you say, that with SelectEven one select the "constructed" frames.
The Thing is, that both Even and Odd frames were constructed. But for both were build different fields to get deinterlaced. For Example: On an BFF-Video is the Even frame than one, which is build from the Buttom-Field. The Upper Field will be reconstructed by the bobber. The Odd frame is build by the Upper-Field, where the Buttom-Field is reconstructed.

WorBry

30th October 2006, 13:58

Please note correction to typo error in my last post. BFF should be Order=0, not Order=2.
If I am not mistaken, smart bobbers like MVBob, and now MCBob, automatically detect the field order of the interlaced source and deinterlace appropriately (i.e. Order 1 for TFF and Order 0 for BFF)

No, most deinterlacers/bobbers I've encountered rely on Avisynth field order

Isn’t that precisely what this call in MVBob does?

#determine clip Fieldorder
order=(c.getparity==true)? 1:0
yv12 = isyv12(c)

SelectEven() selects the frames constructed from the dominant field. SelectOdd() will pick the frames constructed from the opposite field.

I thought there was no ‘field dominance’ in a bob with double-rate output and that the field order simply determines the ‘leading’ field in the sequence i.e.

For TFF source:

Frame 1 – Original TF unchanged, BF interpolated
Frame 2 – Original BF unchanged, TF interpolated
Frame 3 - Original TF unchanged, BF interpolated
etc

For BFF source:

Frame 1 – Original BF unchanged, TF interpolated
Frame 2 – Original TF unchanged, BF interpolated
Frame 3 - Original BF unchanged, TF interpolated
etc

Which is essentially what Krieger2005 is saying

krieger2005

30th October 2006, 14:19

Well isn’t that precisely what this call in MVBob does?

#determine clip Fieldorder
order=(c.getparity==true)? 1:0
yv12 = isyv12(c)

This use just the Parity of Avisynth (which is set not always correct). The Parity of Avisynth can be changed with the AssumexFF-command. And if the parity is set wrong the bobber will do the work not correct. So, in general i would say (and many other) just call the AssumexFF command before the call of any such "smart"-bobber and you will get correct outputs.

zambelli

30th October 2006, 14:33

I thought there was no ‘field dominance’ in a bob with double-rate output and that the field order simply determines the ‘leading’ field in the sequence i.e.
I didn't say there was a field dominance in the bobbed sequence. The field order applies only to the interlaced video. What I meant was that the even frames in a bobbed sequence will always correspond to the "dominant" fields in the interlaced source.

For TFF source:
Frame 1 – Original TF unchanged, BF interpolated
Frame 2 – Original BF unchanged, TF interpolated
Frame 3 - Original TF unchanged, BF interpolated
etc

For BFF source:

Frame 1 – Original BF unchanged, TF interpolated
Frame 2 – Original TF unchanged, BF interpolated
Frame 3 - Original BF unchanged, TF interpolated
etc
Which is essentially what Krieger2005 is saying
Which is essentially what I was saying. :) If you use SelectEven(), you'll get frames based on your dominant fields. So if your source was BFF, using SelectEven() after bobbing will give you frames based on the bottom fields of the source video. SelectOdd() would not necessarily be wrong because it'd simply return frames based on top fields instead. In the end it doesn't really matter, so one might as well stick with SelectEven() for consistency. The important part is getting field order right before bobbing. :)

Chainmax

30th October 2006, 15:28

I understand now, thanks :).

Chainmax

30th October 2006, 21:25

I get a "can't load ReduceFlicker" error when trying to use MCBob even though I have the dll. If I comment out the ReduceFlicker loading line, the script loads fine. Does MCBob need ReduceFlicker on a default call?

scharfis_brain

31st October 2006, 01:56

if there aren't complaints by AVS there is no need for it.

Didée

31st October 2006, 09:30

Does MCBob need ReduceFlicker on a default call?
No. For v0.3, I've changed defaults to not use any denoising for motion search. Unless MEtempNR is explicitetly set to non-zero, ReduceFlicker is not even constructed in AVS' internal filterchain:
# If requested, do flicker reduction before searching motion vectors
# -------------------------------------------------------------------
(MEspatNR==0.0) ? bobbed : bobbed.Merge(bobbed.minblur(2,uv=3),MEspatNR)
(MEtempNR==0.0) ? last : last.Merge(reduceflicker(2),MEtempNR)
srch=last

Edit:
Chainmax, you're most probably using one of the "newer" versions of ReduceFlicker.dll, for which you also must have AvsRecursion.dll in e.g. /system32.
Explanation here (http://www.avstimer.de.tf/), solution here (http://www.avsrecursion.de.tf/). ;)

Livesms

31st October 2006, 14:25

For v0.3
Could you give all libraries you use with MCBob filter.
I've collected all listed in header except ReduceFlicker but I'm getting error for mt_lut finction in line 73 of MCBob_v03b.avs

Could you upload all needed libraries in one archive.

Didée

31st October 2006, 14:37

Can you upload all needed libraries in one archive.
"Can" (or 'could')? yes. Will? No.

It is stated that masktools v2 is needed, which you'll find here (http://manao4.free.fr/), of which "masktools-v2.0a30" is the latest.

Livesms

31st October 2006, 14:42

#TDeint with EDI
edeintted = last.AssumeTFF().SeparateFields().SelectEven().EEDI2(field=-1)
TDeint(order=1,full=false,edeint=edeintted)

http://dump.ru/files/5/5831594287/1_t.jpg (http://dump.ru/files/1/1996000287/1.jpg)
#MvBob
MvBob().SelectOdd()

http://dump.ru/files/1/114439272/2_t.jpg (http://dump.ru/files/1/197812912/3.jpg) - washed out (blured) track and grass
#MCBob()
MCBob().SelectOdd()

http://dump.ru/files/8/806140967/3_t.jpg (http://dump.ru/files/2/2548607216/2.jpg) - ribbed white track line and other details (bolid)
#MCBob()
AssumeTFF()
MCBob().SelectOdd()

http://dump.ru/files/4/47749181/4_t_1.jpg (http://dump.ru/files/9/998266362/4.jpg)

WorBry

31st October 2006, 18:08

This use just the Parity of Avisynth (which is set not always correct)

Out of interest, in what sort of situations is AVISynth Parity known or prone to set/report field order incorrectly?

Terranigma

31st October 2006, 18:10

WOW! I'm simply blown away by mcbob. I've been waiting for a deinterlacer like this forever, it totally pwns :) ;)
It seems to function like that software the fbi uses to enhance photos

Thanks Didee.

Livesms

31st October 2006, 18:14

WOW! I'm simply blown away by mcbob. I've been waiting for a deinterlacer like this forever, it totally pwns :) :cool:
It seems to function like that software the fbi uses to enhance photos

And I can not see total adv. of McBob in all parts.

Look at three pictures above, especialy into last, produces by McBob - can you see white track line is not line indeed :) and details in bolid is waved.

MvBob is better from that point of view, but MvBob blur (wash out) puctire and track looks not like track - like gray plastic sufrace :)

Terranigma

31st October 2006, 18:27

Well we all no that no deinterlacers are perfect. What I most like about mcbob, is that it doesn't castrate edges like most of the other ones. :P

Chainmax

31st October 2006, 18:38

#MCBob()
MCBob().SelectOdd()

http://dump.ru/files/8/806140967/3_t.jpg (http://dump.ru/files/2/2548607216/2.jpg) - ribbed white track line and other details (bolid)

Read zambelli's post at the top of this page. Try manually setting field order before MCBob and use SelectEven() and see if it makes the output better.

Livesms

31st October 2006, 19:07

Read zambelli's post at the top of this page. Try manually setting field order before MCBob and use SelectEven() and see if it makes the output better.

Thank you.
AssumeTFF() helps and makes picture even better then MvBob (till now rated as best by me).

Terranigma

31st October 2006, 19:39

Thank you.
AssumeTFF() helps and makes picture even better then MvBob (till now rated as best by me).

I'd agree :)

Chainmax

1st November 2006, 02:02

Thank you.
AssumeTFF() helps and makes picture even better then MvBob (till now rated as best by me).

Don't thank me, thank zambelli. He had the idea, after all :).

zambelli

1st November 2006, 10:39

Out of interest, in what sort of situations is AVISynth Parity known or prone to set/report field order incorrectly?
Because if you're reading from AVISource or DirectShowSource, there is no metadata in thouse sources that would indicate the field order (or whether the video is interlaced, for that matter). Default is simply BFF. The only source plugin that I'm aware of that might pass on such metadata to Avisynth is Donald Graft's DGMPGDec for MPEG.

Edit: Actually, DirectShow supports interlaced metadata via the VideoInfoHeader2 interface. I'm not sure if Avisynth is able to take advantage of that though. My guess is: not.

WorBry

1st November 2006, 13:07

Thanks. I've also read around the subject and (think I) understand it bit better now. AssumeTFF and AssumeBFF effectively serve as implicit (or is it explicit) 'verbs' within the AVISynth GetParity command (sounds good anyway :)). In other words, whilst the smart bobbers (MVBob, SecureBob, MCBob) do not require that the source field order is specified in the function settings, they still need to be 'told' what the field order is.

WorBry

1st November 2006, 20:25

I’ve put up a few more short 'test' clips (576i25) sampled from the reference YUV D1 sequences available at

ftp://ftp.crc.ca/crc/vqeg/TestSequences/Reference/

http://rapidshare.com/files/1580597/Test_src3_Musicians_576i25_TFF_YV12_3sec.avi

http://rapidshare.com/files/1581346/Test_src8_Scrolling_Text_576i25_TFF_YV12_3sec.avi

http://rapidshare.com/files/1581954/Test_src9_Rugby_576i25_TFF_YV12_3sec.avi

http://rapidshare.com/files/1582737/Test_src10_Toy_Train_576i25_TFF_YV12_3sec.avi

Like the motor-racing clip they are all TFF and in YV12 (FFDShow-HuffYuv)

I’ve done some comparative tests myself but will let people draw their own conclusions.

Suffice it to say, with MCBob, note the marked reduction in ‘shimmering’ (pattern on shirt of the piano player in the Musicians clip and the Sheep on the wall of the Toy Train clip) to which MVBob, SecureBob and TDeint-EEDI2 are more susceptible. Of course, these aberrations are best observed at 50p and are much less noticeable (if at all) when the outputs are cut down to 25p with SelectEven.

You might also judge the integrity of the numbers and stripes on the shirts of the Rugby Players (e.g. between frames 90 - 110 at 50p). The Scrolling Text clip is a good hunting ground for holes and edge artifacts.

Have fun.

Of course, dont forget to include AssumeTFF before the bobber :D

Edit: Didee - one other thing I might mention is that the last frame of the MCBobbed sequences always seems to mess-up i.e. much residual combing and artifacts

Terka

2nd November 2006, 10:45

what about the speed comparsion (in %) between mcbob, MVBob, SecureBob and TDeint-EEDI2 ?

WorBry

2nd November 2006, 18:37

Having to use the wife's PC (P4 3GHz, 504MB RAM, XP SP2) right now (when she's not looking :sly: ). Using a composite of the above four test clips plus the Racing Car clip (i.e. total 15 sec clip); for a straight deinterlace to 50p HuffYuv-YV12 (i.e. no denoising or resizing), I'm getting:

Bobber Encode Time File Size
(min:sec) (MB)
_________________________________________________

MCBob 0.3b 10:17 206

MVBob (14.09.06) 7:56 219

MVBob (April 06?) 5.15 216

SecureBob (14.09.06) 3:02 205

TDeint-EEDI2 3:07 211

TDeint 0:43 211

scharfis_brain

2nd November 2006, 18:42

yeah, mvbob leaves most residual combing in comparison to Mac Bob ;) that leaves (nearly) none.

zambelli

3rd November 2006, 01:46

Could you add plain TDeint too? I'm nog a big fan of the EEDI2 method. Its picture is too soft which defeats the point of using TDeint in the first place, IMO.

WorBry

3rd November 2006, 15:30

Sure, but I'm away from home for the next day or two.

Terka

3rd November 2006, 18:29

i cant make it working :devil: . please, could someone add a avs file + dlls needed?

Terranigma

3rd November 2006, 18:52

WorBry, what parameters do you usually use with Mcbob, or do you just leave it as Mcbob()?

Edit:
Offtopic.. Sort of: Am I the only one who despises chroma more so that actual interlaced stripes?

Edit 2:
Didée, could you perhaps add in some way it'd be possible to use mcbob as an override file, or tell me how: (Please don't suggest tdeint's Clip2 or edeint parameters, 'cuz It still uses it's own thresholds. It's not adaptive like mcbob)? Thanks.

WorBry

4th November 2006, 06:08

Terka - All of the dll's required are indicated in the MCBob script.

# - 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

If you wish, you can copy all of the required dll's into the same folder (created in your AVISynth Plugins folder) as the MCBob script (saved as AVS file) and load them from the MCBob script e.g.

LoadPlugin("mvtools.dll")
LoadPlugin("mt_masktools.dll")
LoadPlugin("EEDI2.dll")
LoadPlugin("RemoveGrainSSE2.dll") *
LoadPlugin("RepairSSE2.dll") *
LoadPlugin("ReduceFlickerSSE2.dll") *
LoadPlugin("MedianBlur.dll")

*As per the SSE capability of your PC.

Works for me.

Terranigma - just MCBob()

Didée

4th November 2006, 07:15

Edit:
Offtopic.. Sort of: Am I the only one who despises chroma more so that actual interlaced stripes?
Can't answer, because I don't understand the question.
Does this aim at "using a cheaper/faster method to deinterlace chroma planes" ?

Edit 2:
Didée, could you perhaps add in some way it'd be possible to use mcbob as an override file, or tell me how: (Please don't suggest tdeint's Clip2 or edeint parameters, 'cuz It still uses it's own thresholds. It's not adaptive like mcbob)? Thanks.
Highly unclear. What d'you wanna do? Something is your "basic" deinterlacer, and it seems you want to override its decisions with something else. Where in that chain do you see MCBob? Start, middle, end?
(E.g., the statement "using Undot() as an override file", this would mean ... what?:confused:)

Sorry, but I don't get you in all points. Try using more words to describe what are the problems, and/or what you want to do or achieve.

Terka

4th November 2006, 14:44

cant load dll
LoadPlugin(PluginPath + "ReduceFlickersse2.dll")
neither
LoadPlugin(PluginPath + "ReduceFlicker.dll")

Didée

4th November 2006, 15:04

cant load dll
LoadPlugin(PluginPath + "ReduceFlickersse2.dll")
neither
LoadPlugin(PluginPath + "ReduceFlicker.dll")
Follow the links in this post (http://forum.doom9.org/showthread.php?p=894458#post894458). You're probably missing AvsRecursion.dll.
On top of that, simply forget about ReduceFlicker and MEtempNR. In the way it's currently done, it's hardly of any use, anyway ...

WorBry

4th November 2006, 15:17

Have a look at the installation notes in the ReduceFlicker readme:

All three versions of the plugin are dynamically linked and require msvcr71.dll (for Microsoft specific stuff) and AvsRecursion.dll (for recursion within Avisynth). If none of the above dlls works, probably one of these two libraries is missing. They should usually be installed in C:\windows\system32

The readme gives a link for the AvsRecursion.dll.

Edit - I see Didee beat me to it.

Terka

4th November 2006, 15:41

it was not the old AvsRecursion.dll, but old mvtools. thanks 4 help!

Terka

4th November 2006, 16:54

tried the speed, but doesnot correspond to WorBry
mvbob 1:34
mcbob 6:03

316frames DV->Huff celeron 2.5 1GB RAM
---------------------
SetMemoryMax(400)
PluginPath = "C:\Program Files\AviSynth\plugins\"
Import("C:\Program Files\AviSynth\plugins\mcbob.avs")

LoadPlugin(PluginPath + "mvtools.dll")
LoadPlugin(PluginPath + "RepairSSE3.dll")
LoadPlugin(PluginPath + "masktools.dll")
LoadPlugin(PluginPath + "eedi2.dll")
LoadPlugin(PluginPath + "RemoveGrainsse3.dll")
LoadPlugin(PluginPath + "MedianBlur.dll")
avisource("D:\4DV.avi")
MCBob() #.SelectOdd()

WorBry

4th November 2006, 17:43

Could you add plain TDeint too? I'm nog a big fan of the EEDI2 method. Its picture is too soft which defeats the point of using TDeint in the first place, IMO.

Added to results above

tried the speed, but doesnot correspond to WorBry
mvbob 1:34
mcbob 6:03

What version of MVBob are you using?

The latest public release version (14.09.06)

http://rapidshare.com/files/1978232/mvbob.avs

is somewhat slower than previous versions, such as this one (from April I think):

http://rapidshare.com/files/1978442/mvbob.avs

Again I’ve included the latter in the encoding speed/file size comparison above

Terranigma

4th November 2006, 18:03

Can't answer, because I don't understand

Highly unclear. What d'you wanna do? Something is your "basic" deinterlacer, and it seems you want to override its decisions with something else. Where in that chain do you see MCBob? Start, middle, end?

Didée, Look Here (http://forum.doom9.org/showthread.php?t=117869) :D

WorBry

4th November 2006, 18:49

I can imagine other uses for such a function, but why would you want to apply a deinterlacer to selected frames? Where does this AdaptOvr parameter reside?

Terranigma

4th November 2006, 20:12

1. I can imagine other uses for such a function, but why would you want to apply a deinterlacer to selected frames?
2. Where does this AdaptOvr parameter reside?

1. To avoid having a deinterlacer processing progressive frames. Usually on clean ntsc sources, bad frames usually pops up around scene changes, and I'd only like to have those frames processed, not the entire clip. :)

2. There isn't one yet, I'm requesting it. :D

foxyshadis

4th November 2006, 20:19

So you want a comb detector and remover. Well, look at the Vinverse fuction. (Seems to work better than Tdeint(full=false) in the minimal testing I've done, less to tweak too.)

Terranigma

4th November 2006, 20:32

So you want a comb detector and remover. Well, look at the Vinverse fuction. (Seems to work better than Tdeint(full=false) in the minimal testing I've done, less to tweak too.)
Never tried vinverse, I'll try it sometime later today, thanks :)
The way I wanted the adaptovr to function, was not actually able to detect comb; Just a simple, easier, more flexible tool then applyrange. But you do bring up an interesting addition that could be added to the adaptovr option (to detect combing). I'm thinking "adaptovr" could be used for other uses as well besides deinterlacing :)

WorBry

4th November 2006, 21:02

1. To avoid having a deinterlacer processing progressive frames. Usually on clean ntsc sources, bad frames usually pops up around scene changes, and I'd only like to have those frames processed, not the entire clip. :)

Fair enough - since this thread is/was somewhat focussed on deinterlacing interlaced video, I'd assumed that's what you were referring to. With that I'll gracefully butt out :D

Terka

6th November 2006, 15:44

the latest mvbob, but the mc bob is 4times! slower

Terranigma

6th November 2006, 18:22

the latest mvbob, but the mc bob is 4times! slower

slow = quality.

I'd prefer that mcbob was slow as possible :sly:

Chainmax

6th November 2006, 19:17

That's an odd choice, I'd rather have it turn as good a result as possible regardless of speed :p. Speed and quality are not necessarily exclusive after all.

Terranigma

6th November 2006, 19:22

That's an odd choice, I'd rather have it turn as good a result as possible regardless of speed :p.
That's what I was getting at, but For that, it'd usually take longer; like when compressing videos and choosing a higher motion search method :P

Chainmax

7th November 2006, 01:16

Of course, you're right. Hence, the mocking smiley I used in the reply :).

Terka

7th November 2006, 09:50

but WorBry had similar speed for mcbob and mvbob:
Bobber Encode Time File Size
(min:sec) (MB)
_________________________________________________

MCBob 0.3b 10:17 206

MVBob (14.09.06) 7:56 219

MVBob (April 06?) 5.15 216

SecureBob (14.09.06) 3:02 205

TDeint-EEDI2 3:07 211

TDeint 0:43 211
my test: mcbob 4times slower! then mvbob - strange

WorBry

7th November 2006, 11:18

Terka,

I've rechecked my tests, with the same results. I'll do some further tests with DV and other interlaced material...when I have a bit of time. Out of interest, what encoding times do you get with SecureBob, TDeint-EEDI2 and TDeint, using your 316 frame DV clip?

Edit: Here are the results with a 30 sec 'home' DV (Pal, Type 2) clip, again deinterlaced to 50p HuffYuv-YV12 (FFDShow) with no denoising or resizing. The DV decoder was Cedocida with 'forced' YV12 output and 'MPEG-2 interlaced' YV12 sampling.

Bobber Encode Time File Size
(min:sec) (MB)
_________________________________________________

MCBob 0.3b 19:86 379

MVBob (14.09.06) 15:26 400

MVBob (April 06?) 10:11 393

SecureBob (14.09.06) 5:50 377

TDeint-EEDI2 5:58 382

TDeint 1:17 378

The results, in terms of relative encoding speed and file size, are pretty similar to those that I posted for the TFF 576i25 YV12 clip earlier in this thread.

Chainmax

7th November 2006, 22:15

Do you notice image quality differences between SecureBob and TDeint+EEDI2? If so, can you describe them?

scharfis_brain

7th November 2006, 23:47

TDeint + EEDI2 leaves motion artifacts with complicated footage. securebob tries to avoid them byusing a far longer temporal window.
However this is exchanged by bobbing everything that 'could' be possibly a moving area. (unless securebob's static detection isn't that bad at all)

Chainmax

8th November 2006, 00:11

Could this alleged extra bobbing result in a smoother image?

scharfis_brain

8th November 2006, 00:29

huh? dunno what you mean...
motion is only affected, when there are weaving artifacts in one of both.

so try and see yourself.

zambelli

8th November 2006, 01:21

Edit: Here are the results with a 30 sec 'home' DV (Pal, Type 2) clip, again deinterlaced to 50p HuffYuv-YV12 (FFDShow) with no denoising or resizing. The DV decoder was Cedocida with 'forced' YV12 output and 'MPEG-2 interlaced' YV12 sampling.
Any kind of performance data should probably also include your processor model and speed, and the instruction sets it supports. ;)

Chainmax

8th November 2006, 05:52

huh? dunno what you mean...
motion is only affected, when there are weaving artifacts in one of both.

so try and see yourself.

I already had and SecureBob looked better (with less jagged edges) than TDeint+EEDI2 on the family tape restoration I'm doing.
I got the impression that it looked a bit smoother though, and since you said that SecureBob bobs everything that 'could' be possibly a moving area I was wondering if that could lead to smoothing or if I'm just imagining things

scharfis_brain

8th November 2006, 06:06

with your weird converted family VHS it is no wonder. TDeint locks one the telecined fields of this special case, so it tries to enhances resolution by weaving, where none was before.

So THAT is a source dependant special case.
It has nothing to do with our topic here (deinterlacing real interlacing -> non converted camcorder footage)

Backwoods

8th November 2006, 08:49

Bobber Encode Time File Size
(min:sec) (MB)
_________________________________________________

MCBob 0.3b 19:86 379

MVBob (14.09.06) 15:26 400

MVBob (April 06?) 10:11 393

SecureBob (14.09.06) 5:50 377

TDeint-EEDI2 5:58 382

TDeint 1:17 378

The results, in terms of relative encoding speed and file size, are pretty similar to those that I posted for the TFF 576i25 YV12 clip earlier in this thread.

How about quality results? Do you feel they were similar or some excelled compared to others?

CruNcher

8th November 2006, 16:33

We would need to conduct a objective test at least to find out under standard viewing conditions but i doub't the participants would see a big (or any difference at all) at least between SecureBob and MCBob.

scharfis_brain

8th November 2006, 16:58

the benefits of motion compensated deinterlacing will become much more visible on Biiiiig Screens or when doing some slow motion stuff.

Anyways Didée's mcbob is much better in calming down bobbing than any other deinterlacer I've seen.
(maybe except of doubleweave().blur(0,1) LOL )

Terranigma

8th November 2006, 17:50

Anyways Didée's mcbob is much better in calming down bobbing than any other deinterlacer I've seen.
(maybe except of doubleweave().blur(0,1) LOL )
Didée, would it be possible to script an even slower, better, more accurate version of mcbob (I don't mind if it takes up to 5 mins to process a frame, lol.) ?

scharfis_brain

8th November 2006, 17:52

what kind of inaccuracies are you referring to?

Terranigma

8th November 2006, 17:57

what kind of inaccuracies are you referring to?

Honestly none. I was just wonderin' if mcbob could be better :D

scharfis_brain

8th November 2006, 18:30

It is a deinterlacer, not an image enhancer (whatever the latter could mean ;) ).

WorBry

8th November 2006, 21:40

Any kind of performance data should probably also include your processor model and speed, and the instruction sets it supports. ;)

Well I did state previously that the CPU was a P4 3GHz

Having to use the wife's PC (P4 3GHz, 504MB RAM, XP SP2) right now (when she's not looking :sly: )

In full:

Pentium(R) 4 630 3.00 GHz
MMX, SSE, SSE2, SSE3, EM64T
Core Speed: 2992.6 MHz
Multiplier: x15.0
Bus Speed: 199.5 MHz
Rated FSB: 798.0 MHz

How about quality results? Do you feel they were similar or some excelled compared to others?

Surely people would want to judge for themselves - as they say ‘up-north’ “It’s better felt than telt”. That’s why I put up the reference clips.

I’ve put up a few more short 'test' clips (576i25) sampled from the reference YUV D1 sequences available at

ftp://ftp.crc.ca/crc/vqeg/TestSequences/Reference/

http://rapidshare.com/files/1580597/Test_src3_Musicians_576i25_TFF_YV12_3sec.avi

http://rapidshare.com/files/1581346/Test_src8_Scrolling_Text_576i25_TFF_YV12_3sec.avi

http://rapidshare.com/files/1581954/Test_src9_Rugby_576i25_TFF_YV12_3sec.avi

http://rapidshare.com/files/1582737/Test_src10_Toy_Train_576i25_TFF_YV12_3sec.avi

Like the motor-racing clip they are all TFF and in YV12 (FFDShow-HuffYuv)

I’ve done some comparative tests myself but will let people draw their own conclusions.

Suffice it to say, with MCBob, note the marked reduction in ‘shimmering’ (pattern on shirt of the piano player in the Musicians clip and the Sheep on the wall of the Toy Train clip) to which MVBob, SecureBob and TDeint-EEDI2 are more susceptible. Of course, these aberrations are best observed at 50p and are much less noticeable (if at all) when the outputs are cut down to 25p with SelectEven.

You might also judge the integrity of the numbers and stripes on the shirts of the Rugby Players (e.g. between frames 90 - 110 at 50p). The Scrolling Text clip is a good hunting ground for holes and edge artifacts.

Have fun.

Of course, dont forget to include AssumeTFF before the bobber :D

Edit: Didee - one other thing I might mention is that the last frame of the MCBobbed sequences always seems to mess-up i.e. much residual combing and artifacts

The question also begs the question of what is perceived as ‘quality’ in this context. In subjective terms, surely the ultimate objective is “treatment of interlaced video in a manner that achieves a convincing simulation of 50p progressive footage that is free from motion flicker, discernible residual combing, motion artifacts and structural deformations and which retains as much (original) detail and definition as possible”.

This leaves me wondering whether a valid objective measure might be to take some high quality 50p footage, interlace it and then compare the ‘bobbed’ output with the original source using relevant metrics. I do actually have some samples of broadcast quality HD (1920x1080) 50p footage in YUY2. Any recommendations on how I might ‘correctly’ convert the footage into an interlaced format that would serve as a valid source for such tests (i.e. that avoids misalignments and chroma aberrations)? I’m thinking of first down sizing the 50p footage to 1280x720 (to make it more manageable). Should I keep it in YUY2 or convert to YV12 and then at what point i.e. before or after interlacing? What would be the most appropriate metrics to measure – PSNR (average, overall), SSIM, VQM?

Didée

8th November 2006, 21:49

Oh, sure it can get both better and slower. Issues there are enough.
Current version catches most, but not all artefacts from motion compensation, and is not fully as calm as it could be (mo'comp error correction catches also some of the "good" parts ... check the scrolling_text (http://forum.doom9.org/showthread.php?p=895006#post895006) sample to see a complete failure in that respect). And in noisy areas, it turns the noise into a bob()-typical broad noise, where a kind-of noise reduction (by dithering through a minimum of residual combing, à la MVBob) would be possible.
And sometimes there are these big jaggies, in cases where motion compensation happened to be effectively off by one pixel vertically ... difficult to detect at all, because when differenced from a dumb-bob, the difference looks just like a "good" case ...

MCBob currently is lying in the incubator. Let's wait how it will crawl along when the breeding has finished. ;)

scharfis_brain

8th November 2006, 22:32

Terranigma

8th November 2006, 23:01

Thanks Didée for answering my question. :)

Didée

8th November 2006, 23:08

An easy trick for YUY2 wouldn't be a big deal. At the end, in the STT replace mt_makediff with appropriate Overlay("difference"), and similar for the afterfollowing mt_merge. Working it would - to decide if that is *exact* too, is something for what a "scharfes brain" is needed. :D
Doing *all* of that processing stuff with double lanes for YUY2, is so far down in the priority list that I can't even see it. :p

Blue_MiSfit

9th November 2006, 02:14

Just a quick question... I'm assuming that this (like mvtools) doesn't work with MT... Is that correct?

Thanks
~Misfit

Pookie

9th November 2006, 03:28

No MT with MV :D

vkamicht

9th November 2006, 05:16

Just want to throw in my two cents.

I've been trying many many different deinterlace methods to work with PS2 footage, and nothing has really impressed me. My biggest problem with them is detecting static areas, I usually notice artifacts no matter what method I use (unless its some kind of blur or blend, or straight up bob with nothing else)

Mcbob however does an amazing job, and I've switched to it permanently. I have no problem encoding stuff overnight, so time is not an issue for me. Since I'm not too proficient with changing settings, I must say that default out-of-the-box this is the best script I've used.

Terranigma

9th November 2006, 16:40

I must say that default out-of-the-box this is the best script I've used.
Aye Aye :sly:

WorBry

9th November 2006, 22:25

WorBry: you could upload the whole 1080p50 YUY2 file to www.rapidshare.de

if it is far too large to upload, you may use these scripts to emulate a 567p50 and a 576i50 transfer from it:

50p xxxsource("1080p50.xxx")
bicubicresize(704,576)
converttoyv12()

50ixxxsource("1080p50.xxx")
converttoyuy2()
bicubicresize(704,576)
assumetff()
separatefields().selectevery(4,0,3).weave()
convertoyv12(interlaced=true)

save with lossless YV12 HuffYUV from ffdshow or with lagarith or even with RAW YV12 and RAR file compression afterwards

unlike to my common processing, I suggest YV12 here, because it currently is the only color mode supported by Mac Bob ;)

Actually the 1080p50 source I have in mind to use is one of the references sequences available at vqeg.its.bldrdoc.gov, specifically:

ftp://vqeg.its.bldrdoc.gov/HDTV/SVT_MultiFormat/1080p50_CgrLevels_SINC_FILTER_SVTdec05_/1_CrowdRun_1080p50_CgrLevels_SINC_FILTER_SVTdec05_/

The original frames are in SGI (16-Bit RGB). As you might imagine, at over 11.8MB per frame, the 10 sec (500 frames) sequence took some time to download. There is a command line tool for converting SGI to YUV

http://www.ldv.ei.tum.de/media/files/homes/oelbaum/forschung/mpeg/sgi2yuv.zip

Unfortunately, I have no idea how to use it, so instead I used XnView to convert the images to 16-Bit YUV (UYVY) and loaded them into AVISynth with ImageSequence (from RawSequence plugin). Unfortunately both the source YUV frames (1.93GB file) and YUY2 (HuffYuv) encode (1.49GB) are too large to upload. So I’ve prepared 704x576p50 and 704x576i25 YV12 (FFDShow) clips (first 5 secs) in the manner you described above. As luck would have it the internet connection on the network I’m using keeps cutting, but I’ll try and upload them when I can.

I’ll also post the results of the objective (metric) ‘bobber’ comparisons when I’m done, but I have some priority work assignments right now.

Actually, there is also a 1080i25 version available on the same ftp site, of which I also downloaded the first 2 secs and converted to HuffYuv (and thence YV12). However, when I tried to deinterlace with MVBob, it promptly crashed VDub. On that note, what would be a ‘correct’ method for downsizing a 1920x1080i25 YUY2 source (TFF) to 704x576i25 YV12 ?

anton_foy

9th November 2006, 22:30

Would it be possible to make a filter that compares the luma levels of interlace leftovers like this: Different luma combing (http://www.xtreem.nu/jonas/Comb01.png)
Just the horizontal lines and make it recognize them the way it recognises combing then brighten (or darken) every other line going from up to down making an estimate value.

This would get a much cleaner image yet undamaged(if it can work this way properly).
Just a thought that struck me because all my footage get these leftovers from any deinterlacer/bobber.

Im sure there is another way but as I said its just a thought that struck me.:p

Terranigma

10th November 2006, 00:23

On that note, what would be a ‘correct’ method for downsizing a 1920x1080i25 YUY2 source (TFF) to 704x576i25 YV12 ?
a resizer + addborders.

Should'nt be too hard to figure it out from there. ;)

WorBry

10th November 2006, 07:52

a resizer + addborders.

Should'nt be too hard to figure it out from there. ;)

No, not too hard at all :) but if it means adding borders then the interlaced clip can not serve as a valid source for comparing bobbers against the 704x576p50 clip I prepared. Actually I did manage to deinterlace the 1080i25 clip with Tdeint (without VDub crashing) and found significant misalignment with the equivalent segment of the 1080p50 clip; possibly a by-product of the interlacing method (likely hardware based) used to convert the 2160p50 'master' (also available on the ftp site) to 1080i25.

All things considered then, I'll stick with the approach of using the 704x576i25 clip that was derived from the original 1080p50 source.

Here are the links for the clips:

704x576p50:

http://rapidshare.com/files/2739537/CrowdRun_704x576p50_FFDShow-YV12_5sec.avi

704x576i25:

http://rapidshare.com/files/2736711/CrowdRun_704x576i25_FFDShow-YV12_5sec.avi

Revgen

10th November 2006, 09:21

@Didee

I decided to take a look at MCBob and I'm pretty impressed with the way it handled fast motion scenes. However, it can't seem to do as well as MVBob in slower motion scenes like instant replay.

Here's some pics to show what I mean:

http://img219.imageshack.us/img219/7647/mvbobinstantreplaydp7.th.jpg (http://img219.imageshack.us/my.php?image=mvbobinstantreplaydp7.jpg)
Slow Motion: MVBOB doesn't show as many artifacts around the rim or along the bottom edge of the backboard.

http://img219.imageshack.us/img219/540/mcbobinstantreplaynz6.th.jpg (http://img219.imageshack.us/my.php?image=mcbobinstantreplaynz6.jpg)
Slow Motion: MCBOB shows more artifacts on the rim and backboard

http://img219.imageshack.us/img219/5858/mvbobfastmotionwj7.th.jpg (http://img219.imageshack.us/my.php?image=mvbobfastmotionwj7.jpg)
Fast Motion: MVBOB seems to struggle in faster scenes. The court lines are bouncing all over the place.

http://img219.imageshack.us/img219/7272/mcbobfastmotionbz7.th.jpg (http://img219.imageshack.us/my.php?image=mcbobfastmotionbz7.jpg)
Fast Motion: The court lines are now more straight with MCBOB.

Hopefully whatever allows MVBOB to work well with instant replay footage can be implemented into MCBOB without affecting MCBOB's ability to handle the faster scenes as well as it does.

If not, then it's okay. I know you're pretty busy anyway.;)

BTW, if you're interested I can post the lossless clips of these 2 sequences if you want to look at it.

Alain2

10th November 2006, 11:23

On that note, what would be a ‘correct’ method for downsizing a 1920x1080i25 YUY2 source (TFF) to 704x576i25 YV12 ?
Sharfis_brain will correct me if this is wrong, but i think it should be:
xxxsource("1080i25.xxx")
converttoyuy2()
separatefields()
bicubicresize(352,576)
weave()
convertoyv12(interlaced=true)
You don't really need to add borders, unless you want to keep the aspect ratios correct but it's not necessary for test purposes. Anyway this script above will give you a anamorphique video, no need for borders if you decode with a 16/9 DAR

WorBry

10th November 2006, 20:32

Thanks Alain2. I'm not at home right now, but your script would make sense i.e. reducing the field height to 704/2 = 352.

Didée

10th November 2006, 22:22

@ anton_foy
Would it be possible to make a filter that compares the luma levels of interlace leftovers like this:
...
Im sure there is another way but as I said its just a thought that struck me.:p
It's another way, yes, but Vinverse() in effect does pretty much what you want. The old one (script function) is included in MCBob. For the 4 times faster plugin, read here (http://forum.doom9.org/showthread.php?p=896352#post896352). ;)

@ WorBry & Alain2 & Terranigma

No. You should NOT resize interlaced content like this. With bigger resize ratios, it will give noticeable field misalignment.
The correct way to resize interlaced content was explained by IanB >here (http://forum.doom9.org/showthread.php?p=594339#post594339)<.
Alternatively, you could resize with
InterlacedSource .AnyBob() .Resize() .SelectEvery(4,0,3) .Weave()

The pure fieldbased method is technically correct, but will sacrifice quality in static areas.
The bob method will retain more detail in static areas, given that a smart bobber is used that reckognizes static areas.

@ Revgen:
That's most probably a showcase for the general problem of the same-parity motion search + 50%-in-time interpolation method that is used. I know the problem, but it's hard to avoid. Ideally, it would require a very complicated mixed motionsearch mode from MVTools, and I don't even see how that should work.

A sample would be nice, though. Those few slomo scenes I have are rather blurry with little detail, a more sharp scene would be handy.

Alain2

11th November 2006, 00:45

@ WorBry & Alain2 & Terranigma

No. You should NOT resize interlaced content like this. With bigger resize ratios, it will give noticeable field misalignment.
The correct way to resize interlaced content was explained by IanB >here (http://forum.doom9.org/showthread.php?p=594339#post594339)<.

Indeed now that I think of it, the script I gave is wrong, sorry :(

Revgen

11th November 2006, 02:33

@ Revgen:
That's most probably a showcase for the general problem of the same-parity motion search + 50%-in-time interpolation method that is used. I know the problem, but it's hard to avoid. Ideally, it would require a very complicated mixed motionsearch mode from MVTools, and I don't even see how that should work.

A sample would be nice, though. Those few slomo scenes I have are rather blurry with little detail, a more sharp scene would be handy.

Here's the slow-motion sample. It's a 350MB YUY2 cap using the Lagarith codec.

http://www.yousendit.com/transfer.php?action=download&ufid=41DC470919B2E1F3

Chainmax

11th November 2006, 23:01

...

Bobber Encode Time File Size
(min:sec) (MB)
_________________________________________________

MCBob 0.3b 19:86 379

MVBob (14.09.06) 15:26 400

MVBob (April 06?) 10:11 393

SecureBob (14.09.06) 5:50 377

TDeint-EEDI2 5:58 382

TDeint 1:17 378

...

I didn't realize until now, but it really surprises me to see that SecureBob is actually slightly faster than TDeint+EEDI2.

WorBry

12th November 2006, 06:14

I didn't realize until now, but it really surprises me to see that SecureBob is actually slightly faster than TDeint+EEDI2.

In the two instances that I have accurately recorded respective encoding times, it would appear so....on my PC at least.

scharfis_brain

12th November 2006, 13:17

Revgen

12th November 2006, 17:35

@Revgen:

1) your clip isn't lagarith YUY2. It is YV12 with faulty converted interlaced chroma.

2) your clip can be restoreed to progressive using a fieldmatcher a la tfm() or telecide().
It is useless to use a deinterlacer here.

It is always a good idea to determine what kind of source you REALLY have! deinterlacers like
smoothdeinterlace(), tomsmocomp(), securebob(), mvbob() and mcbob() are only made for pure (nonconverted!) interlaced footage,
where ever field has its own temporal state.

even blended standards conversions like (60i <-> 50i) cannot be handeld properly by motion compensation based deinterlacers.

So make sure to know which kind of source you want to revert to progressive and choose the appropriate deinterlacer/fieldmatcher.

1) I recorded the clip from Dscaler using Lagarith, and selected YUY2. I assumed that it worked. Dscaler itself also operates in YUY2 colorspace. I don't know why it wouldn't work correctly. I just assumed that it did.

2) I can assure you that the clip is a true 30i clip. The normal non-slowmo parts of the game are fluid and smooth when deinterlaced with MVBob or MCBob.

It's just that this is a slow-motion sample that had been slowed down by the TV Channel to dramaticize the content. Apparently, what you're saying is that MVBob and MCBob have trouble when this occurs? Okay then I understand you.

scharfis_brain

12th November 2006, 23:22

1) I recorded the clip from Dscaler using Lagarith, and selected YUY2. I assumed that it worked. Dscaler itself also operates in YUY2 colorspace. I don't know why it wouldn't work correctly. I just assumed that it did.Lagartith doesn't seem to support YUY2 (it only supports YV12)so it is clear that interlaced chroma becomes destroyed.

2) I can assure you that the clip is a true 30i clip. The normal non-slowmo parts of the game are fluid and smooth when deinterlaced with MVBob or MCBob.
No, it is not! it has LOTS of duplicated fields in it. So it is not true 60i.

It's just that this is a slow-motion sample that had been slowed down by the TV Channel to dramaticize the content.
There are many different ways to produce slow motion.
This one has been made by slowing down 720p60 (or 1080i60) footage by DOUBLING frames. afterwards it has been converted to 480i60. So it effectively has been telecined (like FILM) with a weird framerate ratio.

Chainmax

13th November 2006, 01:48

Since I am currently creating a DVD for someone, I decided to make a little test of my own. The following screenshots correspond to the source and to filterchains that only differ in the bobbing method. The idea is that you rate them in ascending order of detail. Once a few replies are given, I'll, disclose which is which.

http://img183.imageshack.us/img183/9390/1qx1.png (http://imageshack.us)

http://img299.imageshack.us/img299/8505/2wn6.png (http://imageshack.us)

http://img183.imageshack.us/img183/1893/3uf6.png (http://imageshack.us)

http://img182.imageshack.us/img182/9215/4tz1.png (http://imageshack.us)

http://img182.imageshack.us/img182/1382/5fs0.png (http://imageshack.us)

http://img299.imageshack.us/img299/453/6ar2.png (http://imageshack.us)

Didée

13th November 2006, 02:50

Ah, very insightful. Reminds me a little of "which of these two pictures did use RemoveGrain(1)", when both were postfiltered by a hulken denoiser.

My ranking in terms of "detail" is:

1st place: shared between 1,2,3,4,5,6
2nd to 6th place don't apply.

For me, 1,2,4,5,6 mostly differ in those random differences of almost-aliasing, caused by the postprocessing filterchain. There are a few spots where freaks might get into lengthy discussions about this-or-that pixel ... have fun, I'd consider it rather irrelevant.
In #5, upper border of lower lip smells like MCBob's "2x2" aliasing problem, but not sure.

Perhaps it's different when viewed in motion ... but from only that still, compared to #3 all others pretty much look like the same fiasko. The differences are noise. So just choose the fastest of those bobbers.

#3 is the most pleasing picture to me, btw. :D

Chainmax

13th November 2006, 14:30

Bear in mind that the video was reinterlaced, bobbing was used to apply filtering. Therefore, the aliasing in the picture might just be normal interlacing as that was an extremely low motion scene.

Trixter

14th November 2006, 05:34

Lagartith doesn't seem to support YUY2 (it only supports YV12)so it is clear that interlaced chroma becomes destroyed.

From the website (and my own experience): "Lagarith is able to operate in several colorspaces - RGB24, RGB32, RGBA, YUY2, and YV12."

bananacreamandpeca

14th November 2006, 20:29

If I use this in Aviysynth for a pal 25 dvd source:

SeparateFields
SelectOdd
BilinearResize(384,288)

First 2 lines makes the vertical resolution look squashed.
Then the resizing of the horizontal res. will make it a
good picture again.
But if I do this. selecting odd-lines from the vertical
with no aliasing ( i guess),
could this make round-edges in vertical resolution look strange?

I mean, you do lose information that was stored in the even lines I just threw away?
Am I correct?

Backwoods

15th November 2006, 00:39

#3 is the most pleasing picture to me, btw. :D

I agree, even though it is the softest. The text on the man's shirt in the background is too distorted in the other photos.

CruNcher

17th November 2006, 04:34

yeah i agree with Didée and Backwoods the 3rd looks the most natural the background isn't oversharped and the small dof preserved.
Backwoods but ehh what man ? :D

Chainmax

17th November 2006, 04:43

Ok, here's the general filterchain:

MPEG2Source("X:\wherever\myd2v.d2v",info=3)

ColorMatrix(hints=true,interlaced=true)

Bobbing

FFT3DFilter(sigma=3,plane=3,bw=32,bh=32,bt=3,ow=16,oh=16)

DeBlock_QED()

Crop(0,0,704,478,align=true)
Lanczos4Resize(656,448)

dull=last
sharp=dull.LimitedSharpenFaster(SMode=4,Strength=200)
Soothe(sharp,dull,25)

AddGrain(2,0,0)

AddBorders(32,16,32,16)

Levels(20,1,255,16,235)

ConvertToYUY2()

And the bobbing used in each picture:
Interp = SeparateFields().EEDI2(field=1)
TDeint(mode=1,order=1,type=3,full=false,MI=48,tryweave=true,slow=2,edeint=Interp)
AssumeTFF()
MCBob()
None (source)
AssumeTFF()
MVBob()
AssumeTFF()
TDeint(mode=1,order=1,type=3,full=false,MI=48,tryweave=true,slow=2)
AssumeTFF()
SecureBob()

MLS

17th November 2006, 11:10

of course, if you want a guarantee of no artefacts (except aliasing), then bob.selecteven is probably the way to go

Is there a way to deinterlace and completely avoid aliasing? It is far too distracting for me, and tdeint, leak, selecteven, bob.selecteven, etc all seem to suffer from it.

/MLS

CruNcher

17th November 2006, 11:34

let me guess Chainmax the fastest was SecureBob ;)

davidhorman

17th November 2006, 12:57

MCBob looks fantastic - I'm curious to know, is there one particular part of the script that is slow, or is just that it has to do so many things?

It makes wish there was a distributed version... I have about 30 3GHz machines idling all day ;)

David

Chainmax

17th November 2006, 13:37

let me guess Chainmax the fastest was SecureBob ;)

Yup :).

...
It makes wish there was a distributed version... I have about 30 3GHz machines idling all day ;)

David

How do you say "I hate you" in english? ;)

WorBry

17th November 2006, 18:21

let me guess Chainmax the fastest was SecureBob ;)

Yup :)

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

WorBry

19th November 2006, 19:49

OK here’s my contribution to the party fun – ‘Name That Bobber’

Earlier in this thread I posted two test YV12 clips derived from the same 1080p50 source; one resized to 704x576p50 and the other resized and interlaced to 704x576i25

Here are the links for the clips:

704x576p50:

http://rapidshare.com/files/2739537/CrowdRun_704x576p50_FFDShow-YV12_5sec.avi

704x576i25:

http://rapidshare.com/files/2736711/CrowdRun_704x576i25_FFDShow-YV12_5sec.avi

For the purpose of this little subjective quiz, I deinterlaced the 576i25 clip to 50p with 5 different ‘bobbers’ and took equivalent frame shots from each output, as well as the reference 576p50 clip. The ‘bobbers’ tested (all at default settings) were:

MCBob
MVBob
SecureBob
TDeint-EEDI2
TDeint

I also ran parallel series, one with no resizing (i.e. 704x576) and the other resized (Lanczos) to 704x400. Other than this, no filters were included in the scripts (except AssumeTFF before the bobber).

I’ve put up the results in two sets of six frame shots labelled A- F:

704x576

http://rapidshare.com/files/4017406/Bobber_Subjective_Comparison_704x576.jpg

704x400

http://rapidshare.com/files/4017750/Bobber_Subjective_Comparison_704x400.jpg

So, the quiz is, in your expert opinions:

1. How do you rank the six images (A-F) in each set in terms of subjective quality?
2. What subtle differences lead you to this conclusion?
3. Which image do you think you think corresponds to which of the 5 bobbers and the reference 50p source?

Note: the labelling mix in the two sets is exactly the same; I’m not that crafty

When there are a few replies (of the non-four-letter kind) I’ll post the results, together with those of the objective (metric) quality tests that I ran at the same time.

So, with your zoom controls or magnifying glasses at the ready …..’name that bobber’....or for the dyslexics, 'maime that robber' :D

Revgen

19th November 2006, 20:46

^You'll only find a game like this in a D9 forum.;)

WorBry

19th November 2006, 21:22

Thats why I look nowhere else ;)

scharfis_brain

19th November 2006, 22:33

My guess for the first image (full sized PAL)

ranking (from best to worst):
definitive ( d -> b -> f ) -> uncertain ( a -> c -> e )
(uncertein, cause of different types of artifacts that are equal weighted to me)

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)

I'll judge the downsized image later.

Terranigma

19th November 2006, 23:01

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

20th November 2006, 06:24

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

20th November 2006, 13:22

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

20th November 2006, 17:03

Hmm, you two guys might be right.

WorBry

20th November 2006, 21:22

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

21st November 2006, 13:46

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

21st November 2006, 14:39

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

21st November 2006, 15:00

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

21st November 2006, 15:32

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

21st November 2006, 17:14

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

Revgen

22nd November 2006, 01:42

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

22nd November 2006, 05:14

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

22nd November 2006, 13:25

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

22nd November 2006, 14:22

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

22nd November 2006, 14:51

Most definitely :).

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

Didée

22nd November 2006, 15:10

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

22nd November 2006, 16:10

... 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

22nd November 2006, 19:45

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

Time to pester Fizick then :).

foxyshadis

22nd November 2006, 20:28

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

Fulcanelli123

30th November 2006, 00:39

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

30th November 2006, 00:43

Has MCBob been posted to a Wiki yet?

Didée

30th November 2006, 02:06

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

30th November 2006, 02:07

Fulcanelli123

30th November 2006, 02:56

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

30th November 2006, 03:13

:script:

Fulcanelli123

30th November 2006, 19:20

: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

30th November 2006, 19:39

try this instead
separatefields().selecteven()

Fulcanelli123

30th November 2006, 19:58

try this instead
separatefields().selecteven()

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

Terranigma

30th November 2006, 20:41

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

30th November 2006, 21:40

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

30th November 2006, 21:46

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

30th November 2006, 21:51

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

30th November 2006, 22:19

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

30th November 2006, 22:45

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

30th November 2006, 22:48

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

4th December 2006, 00:53

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

4th December 2006, 02:25

vkamicht

4th December 2006, 02:29

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

4th December 2006, 02:34

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

ConvertToYV12(interlaced=true) :)

vkamicht

4th December 2006, 02:37

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

ConvertToYV12(interlaced=true) :)

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

davidhorman

21st December 2006, 13:37

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

21st December 2006, 17:34

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

21st December 2006, 19:47

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

21st December 2006, 20:22

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.

davidhorman

22nd December 2006, 16:24

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

22nd December 2006, 16:26

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

22nd December 2006, 23:13

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

steve77

23rd December 2006, 16:37

Boulder

23rd December 2006, 17:21

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

24th December 2006, 04:29

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.

steve77

24th December 2006, 05:17

Well if most people are getting around/less than 4fps, that's fine. Just wanted to make sure I wasn't the only one.

Thanks for all of your assistance.... this was really helpful.

I don't have 1GB+ of ram. I have 2x512MB running @ DDR2-916. (Overclocked my Core 2 Duo E6300 to 3.2Ghz.)

I'll try some other bobbers and see if the quality gain is proportionate to the time spent. I might not be one of those people where quality is worth it at any expense.

Regards,

Steve77

davidhorman

24th December 2006, 12:33

Well if most people are getting around/less than 4fps, that's fine.

Count yourself lucky! - I'm getting 0.7fps (3.0GHz, 1Gb RAM). That'll all change when I get networked avisynthing working - no other sysadmins interested? ;)

David

Livesms

24th December 2006, 12:49

Count yourself lucky! - I'm getting 0.7fps (3.0GHz, 1Gb RAM). That'll all change when I get networked avisynthing working - no other sysadmins interested? ;)

David

networked avisynthing
What is that????

davidhorman

24th December 2006, 13:16

Livesms

24th December 2006, 13:20

I'm working on a program that will break an AviSynth script up into sections and farm it out to multiple machines (which must have AviSynth, plugins and codecs installed). I've proved the concept - now I just need to write the control program.

David

Hm - rather nice Idea :)
But about encoding - or you plan to work with uncompressed material? Or parts will be for several frames to process them parallel and combine to one part every second and compress with encoders (MPEG4 or other) in realtime

davidhorman

24th December 2006, 13:42

halsboss

25th December 2006, 12:55

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

Looking for a link to MedianBlur please ...

krieger2005

25th December 2006, 19:12

:search:
http://forum.doom9.org/search.php?searchid=1429307

or:
http://www.google.de/search?q=medianblur+avisynth&btnG=Google-Suche&meta=

steve77

25th December 2006, 23:06

Hello all,

Thanks for your help with MCBob.... now I'm looking for MVBob. I've scoured the forums and simply cannot find the script for it. Could sombody point me in the right direction?
Regards,

Steve

P.S. I'm currently processing some material that has frames that are partially interlaced (PAL source)... I used a smart-bobber (TDeint) and it did an ok job of it. Is there a better way of going about these?

Blue_MiSfit

25th December 2006, 23:15

I'm not quite sure what you mean...

Each machine will compress (or not, as you choose) it's own segment. Then they can be brought together in another AVS script. To save disk space I will probably use Xvid at 10mbps - with a script as slow as mcbob, the extra time spent encoding won't matter.

Perhaps this thread http://forum.doom9.org/showthread.php?t=119436 would be a better place to continue the discussion :)

David

David,

If you are planning on doing something like this, I would strongly suggest that you not use a lossy codec like Xvid, but instead a lossless codec like huffyuv - or something newer like lagarith / ffv1 / msu lossless. This will make a big difference if the user is going to encode the result of your program to Xvid or x264. MPEG-4 is very lossy and is not suitable as an intermediate codec.

~MiSfit

foxyshadis

26th December 2006, 02:16

I find Xvid with the EHR matrix, at q2 (or q2/3 with b-frames), makes an excellent replacement for ffv1 at about the same speed, nearly a third the size. The main problem is that ffdshow ignores packed bitstream, so non-linear editing with it is painful; don't use b-frames if you try it.

You can spot artifacts by flipping between the original and the encode at 200%, but I doubt they'd be enough to affect a final encode.

halsboss

26th December 2006, 03:43

Thanks anyway, however

http://forum.doom9.org/search.php?searchid=1429307
gave me "Sorry - no matches. Please try some different terms". Tried "medianblur download" but not much success either. TSP's web site http://www.tsp.person.dk doesn't seem to exist now. http://forum.doom9.org/showthread.php?p=902041&highlight=medianblur+download#post902041 and other links seem to point to avysynth.org

http://www.google.de/search?q=medianblur+avisynth&btnG=Google-Suche&meta=
gave me not much either (most links sent me back to avisynth.org which was down...

Any suggestions ?

bananacreamandpeca

26th December 2006, 07:43

I let Megui analyze the material and just use those settings.
It deinterlaced my DV-cam material (wich looked very hard to do,
partial interlacing etc.)
And it picked the right settings.

Didée

26th December 2006, 16:49

You can get the most recent v0.84 of MedianBlur from here:

http://www.64k.it/andres/dettaglio.php?sez=avisynth
(medianblur_25_dll_20050119.zip)

It's also included in the latest package of scharfis_brain's MVBob.

buzzqw

26th December 2006, 17:34

@Didée

64k.it/andres is my site
i hope i haven't broke any licenseses... :o i use it as a repository/mirror

(i will glady give account/password to avisynth/filter developers to upload/update filters)

BHH

krieger2005

26th December 2006, 18:22

Thanks anyway, however
gave me "Sorry - no matches. Please try some different terms". The search was timed out. I tried "medianblur" in "avisynth usage" and "search only on titles". Result: 1, the right one.

gave me not much either (most links sent me back to avisynth.org which was down... The search-link to google give at the 5-th position this link: http://forum.doom9.org/showthread.php?p=577287
Look at the first post of that thread.

halsboss

26th December 2006, 22:48

Well blow me down, thanks krieger2005. For some reason that 1st post blew up on be when I tried to download it previously; now it works when I tried it again just then. Sorry about that. Also many thanks to Didee and bizzqw for the repository.
Cheerio.

MacAddict

27th December 2006, 15:42

I let Megui analyze the material and just use those settings.
It deinterlaced my DV-cam material (wich looked very hard to do,
partial interlacing etc.)
And it picked the right settings.

I actually do the same thing on most of my material and it works very well. Got a new Panasonic DV Cam recently and I'll be curious how it performs with that source :-)

steve77

28th December 2006, 00:49

Hello all,

I posted a day or 2 ago about finding the MVBob() script. I looked all through these forums as well as googled many combinations of mvbob.avs, mvbob() etc.

Could sombody just post the contents of the script for me please? I have some hybrid material and TDeint leaves some residual combing. MCBob did the job, but took 11h for a 30 minute clip.

Any help would be GREATLY appreciated.

Regards,

Steve

Didée

28th December 2006, 01:14

steve77

28th December 2006, 14:36

2 Days? Bad searching! It took 20 seconds to find
http://home.arcor.de/scharfis_brain/mvbob/mvbob.rar
- even in this very thread. :)

Amount of residual combing after MVBob is similar to TDeint, TDeint perhaps even less. To securely avoid residual combing with either one, reduce thresholds. Zero should be perfectly secure. :)

Wow... my face is red. I swear I've been looking long and hard for these things, but there isn't really a convenient location where they're all hidden away. Neuron2 has a brief database of filters, and within the AVISynth doccumentation there are references to some plugins...

Basically, thanks. And for what it's worth, from a purely subjective point of view, MCBob is excellent, if a little slow :)

Well, back to testing!

Chainmax

31st December 2006, 19:18

I just noticed that in WorBry's "name that bobber" game, TDeint was used in sharp kernel mode. What would be the differences between that and ELA on different kinds of source?

zambelli

5th January 2007, 10:31

Has anyone noticed a strange shimmer (flicker) in MCBob output?

I compared it to the output of TDeint and generated a side by side comparison clip:

http://www.citizeninsomniac.com/video/mcbob_tdeint_x264.avi (8.5 MB)

I'm using MCBob v0.3c and the latest version of all the needed binaries. These are my scripts:

MCBob:
LoadPlugin("FFT3DFilter.dll")
Import("MCBob.avs")

AVISource("Foo_PAL_DV.avi")
FFT3DFilter(plane=4, interlaced=true)
AssumeBFF().MCBob().SelectEven()

TDeint:
LoadPlugin("TDeint.dll")
LoadPlugin("FFT3DFilter.dll")

AVISource("Foo_PAL_DV.avi")
FFT3DFilter(plane=4, interlaced=true)
AssumeBFF().TDeint()

Any idea what could be causing that weird flickering effect in MCBob?

Didée

5th January 2007, 18:22

That's an example of a "worst case" scenario. MCBob aims at producing as little residual combing as possible. Note that in those areas where MCBob flickers, TDeint is full of residual combing. (Do a 400% zoom, you'll see immediately.)

Fact is that the current MCBob is too strict (better said: not selective enough) about "allowing" residual combing.
Residual combing definetly should be avoided if it's caused by motion. But in those areas where residual combing is caused by noise, it is even favourable.

Par ex., a funny case can be seen in the "scrolling text" sample (from here (http://forum.doom9.org/showthread.php?p=895006#post895006) - download expired, someone tell if it should be uploaded once more) ... At the end of that sample, look at the background. Simple deinterlacing with moderate motion thresholds produces a static background that is fully combed. With low enough thresholds or a comb-aware bobber like MCBob, the background is free of combing and wobbles up-down-up-down.

The funny thing is: Not knowing the progressive version, I with my human brain am in trouble to decide wich of both results is correct: is it "static but combed", or "wobbling but smooth"?

How should the machine decide, if the human can't ?

zambelli

5th January 2007, 20:26

That's an example of a "worst case" scenario. MCBob aims at producing as little residual combing as possible. Note that in those areas where MCBob flickers, TDeint is full of residual combing. (Do a 400% zoom, you'll see immediately.)
Unfortunately, the clip I uploaded was not a single isolated case. Pretty much the entire 20-minute video that I tried to use MCBob with exhibited this behavior. The flickering was so strong that at first I thought it was some weird 50Hz/60Hz mismatch (shooting American lights with a PAL camera), but then I noticed the effect was completely absent in the TDeint version.

Which of the MCBob parameters can I tweak to try to reduce this effect?

chipzoller

5th January 2007, 21:12

I started a test encode using MCBob v0.3c with a simple script from a NTSC 29.97 interlaced satellite capture using:
avisource()
Import()
Trim(459,24339) ++ Trim(30213,46361) ++ Trim(53130,68112) ++ Trim(73090,84137) ++ Trim(90159,97474) ++ Trim(104101,108133)
converttoyv12(interlaced=true)
AssumeTFF()
mcbob().SelectEven()
crop( 8, 0, -16, -10)
lanczosresize(640,480)

Already hard-hitting enough with the resize, but to make matters worse I tried (just for fun) what type of speed I'd get compressing to x264 using Sharktooth's MeGUI CE-Mainprofile ( --pass 2 --bitrate 1000 --ref 3 --mixed-refs --bframes 3 --b-pyramid --b-rdo --bime --weightb --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,p4x4 --vbv-maxrate 25000 --threads auto --thread-input --progress --no-psnr --no-ssim) and the first pass alone I was getting 0.2fps on my P4 2.4GHz :eek:
The source was trimmed ~45min. First pass ETC~4 days....
Yeah, with that length of time and cost of electricity being expended by running my workstation for 2 weeks it would have been cheaper and quicker to drive to Amazon.com's headquarters and buy the DVD, then drive back :)

Still, encoding time aside, it looks like the best bobber I've tried.

Didée

5th January 2007, 22:11

Unfortunately, the clip I uploaded was not a single isolated case. Pretty much the entire 20-minute video that I tried to use MCBob with exhibited this behavior. The flickering was so strong that at first I thought it was some weird 50Hz/60Hz mismatch (shooting American lights with a PAL camera), but then I noticed the effect was completely absent in the TDeint version.

Which of the MCBob parameters can I tweak to try to reduce this effect?

Insert this into the function:
# Lastly, set correct parity for the bobbed clip
# ----------------------------------------------
naked
(order==0) ? AssumeTFF() : AssumeBFF()
This should eliminate most of any flicker. "naked" is just the original fields weaved with the raw motion compensation.
In return, you'll get back 100% of all artefacts caused by failed motion compensation. :)

Apart from that, there's not much that could be done within the current framework of MCBob. Any tweaks raising the error margin will also produce more visual errors.

Then, it's quite possible that this visually obvious problem rises from 50Hz/60Hz interference. As said, TDeint is more calm here because it just weaves, despite producing a combed output.
However I can't fully judge from already processed footage. A raw source sample of those problematic parts (e.g. the one from which you made the comparison) would be useful.

@ chipzoller

Overall performance might get better with creating an intermediate lossless compression, and encode to AVC from that one. MCBob alone should give ~1fps on your machine. After that, you can create AVC with the usual 120fps encoding performance. :D

Seriously: It is done what has to be done ... and it even is not enough yet.
If our currently available tools & hardware need so much time to make all of the needed calculations, and can't manage to calculate faster - - not my fault. :)

davidhorman

6th January 2007, 00:02

Didée, do you think there would be anything to gain from someone (and I'm not volunteering!) rewriting parts of MCBob "natively"? Like specialised versions of the plugins it uses that could be better optimised? Obviously this would make it less customisable...

In the meantime, my distributed AVISynth project is coming along nicely - I expect to have MCBob running at a mind-numbing 10fps soon :)

David

chipzoller

6th January 2007, 06:01

Didée, your inbox seems to be full.

zambelli

6th January 2007, 10:29

Then, it's quite possible that this visually obvious problem rises from 50Hz/60Hz interference. As said, TDeint is more calm here because it just weaves, despite producing a combed output.
You know, I think you may be right (or I was originally right, I guess :) ). I did a simple Bob() on the source and the flickering was still very noticeable. Plus, it only seems to appear in areas under direct fluourescent lights. What mislead me was that none of it appeared in TDeint's output - and since that was my reference deinterlace output, I just assumed it was correct.

Lesson for the future: do not shoot American fluorescent lights with PAL cameras. :(

foxyshadis

6th January 2007, 17:24

If you do happen to have flicker like that, TDeint and SmoothDeinterlace are probably the best choices. An alternative might be following MCBob with Soothe() where calm is one of the smoother bobbers. Didée may come in and say that makes no sense though. =p

Fizick

6th January 2007, 23:10

for every flicker there is at least one deflicker...
:)

kxproject

10th January 2007, 00:34

I have got an error that there is no function named mt_makediff. what should i do? I mean with mcbob script

foxyshadis

10th January 2007, 00:53

Right at the top of the script:

# Prerequisites:
#
# - 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

zambelli

10th January 2007, 01:25

Even though the main Wiki site is down, this Japanese (?) mirror seems to have all the right links:
http://www.avisynth.info/?MCBob

kxproject

10th January 2007, 11:22

I found out that mcbob requires the very last masktools dll which can be found and does not work for me with previous versions. Core 2 duo 6400 gave 1 fps.

foxyshadis

10th January 2007, 12:37

Masktools 1 and 2 aren't really different versions. It'd be more appropriate to call them entirely different plugins, with a few similar functions. You really need to keep both around.

steve77

10th January 2007, 14:59

I found out that mcbob requires the very last masktools dll which can be found and does not work for me with previous versions. Core 2 duo 6400 gave 1 fps.

Yeah, my PC does about 2FPS. (E6300 @ 3.25GHz)... but it's worth it!

kxproject

10th January 2007, 17:36

@foxyshades
I meant that not all 2.x versions worked for me. Only the last one. All other gave errors about mt_lut... functions

Chainmax

12th January 2007, 20:25

kxproject

13th January 2007, 17:21

I overclocked core 2 duo to 3,25 and got 4.5 fps. It's a wonder.

kxproject

13th January 2007, 20:53

mcbob deinterlaces gorgeously, better than internal vegas deinterlacer. I have just compared.

R3Z

14th January 2007, 04:30

As good as McBob is (and its freaking awesome) i can only justify using it on very problematic sources. SecureBob seems to be excellent for most cases.

Didée

17th January 2007, 13:00

I have another question related to the OP: would bob+selecteven still have a theoreticaladvantage over plain deinterlacing when postprocessing fieldmatching? For example, the usual recommended line to IVTC TFF material is:

AssumeTFF()
Interp = SeparateFields().SelectEven().EEDI2(field=1)
Deinted=TDeint(order=1,field=1,edeint=Interp)
TFM(order=1, extra options, Clip2=Deinted)
TDecimate(mode=1)

Would you rather use something like:

AssumeTFF()
Deinted=SecureBob().SelectEven()
TFM(order=1, extra options, Clip2=Deinted)
TDecimate(mode=1)

Probably not. My guess is that using EEDI2 for fallback in TFM is just fine.

The cases where TFM can't find a match should always be located in spots where the source actually shows motion. And if so, then

- SecureDeint won't help, because in motion scenes it will just give you back plain EEDI2, anyway

- MCBob won't help at all, because:

the missing field is missing in a progressive frame. That means that the "temporal location" of the missing field is the same as the present base field. But those MVTools-Bobbers try to reconstruct fields that are temporally in between the existing fields.
MCBob is not good at all in that scenario (because of using MVinterpolate).

- MVBob eventually might catch alittle more in the given case ... but my guess (from the guts) is that there won't be much noticeable difference, compared to just using EEDI2 directly. Considering that field interpolation should only happen sparsely during IVTC, and considering that EEDI2 alone is much faster than MVBob, I'd say that anything beyond TFM(clip2=[eedi2]) is just overkill.

But ... note that I almost never have to deal with IVTC, so the above is just theorizing. And the most likely thing to disprove a good theory is ... practice. ;)