MCBob

[SPiKA]

That worked... thanks!

[Comatose]

Originally Posted by Terranigma

Maybe you're getting that error, because you need to discard half of the frames mcbob creates?

To get the original rate, use either selecteven() or selectevery(2,0) after mcbob.

Is this really safe? Are they all dupes?

[themostestultimategenius]

If your use MCBob on a progressive source then yes, you'll end up with dupes.

[Adub]

But why the hell would you use MCBob on a PROGRESSIVE clip?!!!

[Malow]

what "part" of mcbob cannot work with yuy2?

[Didée]

At the time when it was written: definetly MaskTools, not sure about MVTools and RemoveGrain/Repair. Today: none.

So, if you want MCBob to process YUY2 input, all you need to do is to add a "ConvertInterleaved2Planar()" to every clip argument that goes into any function filter of RemoveGrain, Repair, or any MaskTools filter, add "planar=true" to all RemoveGrain/Repair calls, and an immediate "ConvertPlanar2Interleaved()" afterwards all of these, in case the result is processed by a filter that is not RemoveGrain, Repair, or a MaskTools filter. And ideally, all these conversions/additions should be made conditionally, since they shouldn't be made for regular YV12 input ...

It's probably less than 100 places that need to be altered, and it shouldn't take much more than 100^100 swearings until it's really up & running.

I wish much fun when doing that.

[thetoof]

Originally Posted by Comatose

Is this really safe? Are they all dupes?

They are not dupes. By doing that, you reduce the temporal resolution by half (similar to half-framerate conversion with mvflowfps). So, the movement may look choppy

Originally Posted by Merlin7777

But why the hell would you use MCBob on a PROGRESSIVE clip?!!!

QTF... MCBob is meant for pure interlaced only, as it doesn't even knows that progressive frames could exist in the source clip.

Originally Posted by Malow

what "part" of mcbob cannot work with yuy2?

Masktools2

Originally Posted by Masktools2 documentation

The filters have a set of common parameters, that mainly concern what processing to do on each plane. They all work only in YV12 (though with Avisynth 2.6, support for all planar formats will be available).

[Terranigma]

Originally Posted by thetoof

QTF... MCBob is meant for pure interlaced only, as it doesn't even knows that progressive frames could exist in the source clip.

Not true. The results of mcbob, is most of the times, better than that of any other bobber/deinterlacer, and if you know how to use functions to either give it guidance, (such as by configuring tdeint to detect interlaced frames and then use mcbob as an external deinterlacer with selectevery(2,0)) or manually select frames for deinterlacing, then it can be used in the exact same manner as any other interlace detecting deinterlacer/bobber.

It may have been constructed for true interlaced material, but it can be used for progressive material (that has a bit of interlacing) as well. :P

[Didée]

@ thetoof: Everything correct .... almost.

Originally Posted by MaskTools V2 alpha 35 documentation

.
VI) Changelog

Alpha 34 :

added : support for interleaved2planar hack, enabling 422 support

@ Terranigma:

No. If MCBob hits progressive (or telecined) sections, then there's no benefit over filters dedicated for that respective kind of content. On such input, all internal motion compensations necessarily are wrong (because of the way of motion interpolation that is used). Most of that damage might be hidden because it's (hopefully) caught by the error correction, but probably not everything. So, there's nothing-at-all to benefit to begin with, plus a possible chance to get some unnecessary artifacts.

So, on progressive or telecined sequences, MCBob will never be better than dedicated filters. It can only be worse.
Perhaps it's somehing of the edi-postprocessing / sharpening / something else that might look nice at times nonetheless ... but to get that, you don't need to apply MCBob.

[thetoof]

I just read the whole thread and felt like adding a few things

Originally Posted by Kumo

i'm trying to deinterlace an old anime ntsc r1 (usa) dvd.dgindex reports it as interlaced

Check out the link in my signature + the other posts I made in this thread; I think it may interest you. (It explains why DGindex reports anime as "interlaced" when it's actually telecined.

Originally Posted by SPiKA

Is there a way to use mcbob just in a section of the encode? Because I'm getting "Framerate doesn't match" error when using trim...
And another question... I know that mcbob doubles the framerate, but how can I get original framerate (29.97fps) back?

If the reason you want to do this is because you have a clip with telecined and interlaced sections, I gave a suggestion on how to do handle it here.

[Comatose]

Originally Posted by thetoof

They are not dupes. By doing that, you reduce the temporal resolution by half (similar to half-framerate conversion with mvflowfps).

So uh, what would be the (in most cases) best way to reduce the framerate to something sane like 29.97 or 23.976 fps?

[thetoof]

Well, to go back to 29.97, cut your temporal resolution by half (selecteven() or selectodd()) and, to convert to 23.976, you have a few options, one being a motion compensated framerate conversion.
If you want to process an interlaced section of a telecined clip, use something like this:

raw=mpeg2source("yourd2v.d2v")

# IVTC the telecided portion of your source
a=raw.telecide().Decimate().trim(0,x) # Use your prefered IVTC method, as long as you add .trim(0,x) at the end, where x is the last frame before the credits. Be sure to check what is the number of that frame after ivtc.

#Bob the interlaced section to 60p
source=raw.mcbob() #or any other deinterlacer you want

#Get the motion vectors (these settings are... hum.. insane :p so change them if you want)
backward_vec = source.MVAnalyse(isb = true, pel=4, idx=1,search=3, overlap=6)
forward_vec = source.MVAnalyse(isb = false, pel=4, idx=1,search=3, overlap=6)

#Convert the fps of the interlaced section
b=source.MVFlowFps(backward_vec, forward_vec, num=24000, den=1001, ml=100, idx=1).trim(first frame of the credits,last frame of the credits) #Be sure to check those numbers after the framerate conversion

#and, if you have something after, ivtc it
c=raw.telecide().Decimate().trim(frame after the interlaced section,0)
a+b+c

A trick to get the correct frame # is by adding return a/b/c at the end of the script.
If you source is always interlaced (which is extremely rare for anime, if that's what you're dealing with), you can use the portion of the script from "bob" to "convert".

Anime is most likely 24 fps with bad telecining. AnimeIVTC() + documentation will soon be ready, so I'd recommend that you take a look at these. My signature will be updated when it's done, so it won't lead to the obsolete post#23.

edit: you can also use MVFlowBlur after the framerate conversion to generate a motion blur that'll make your movements look less choppy.

[Inventive Software]

I use MCBob with NNEDI posted on the first page I think by Wilbert, and I've had to change the RemoveGrain functions on line 222 of the combined comments + script, under the "EdiPost = 2" section, because the mode specified was out of range and the AVS file wouldn't load in VirtualDub. 20 was the number in the script, I changed it to 2. Would that work as intended?

[Didée]

No, that'll not do the intended operation. (20) performs a full 3x3 convolution blur, which in its negotiation gives a sharpen operation. (2) is a median-like clamping operation, clamping the center pixel to not exceed the 2nd-extremest neighbors. In the given context this will result in very weak sharpening, probably almost null.

Obviously you're using a *very* outdated version of RemoveGrain. What's the point in not updating to the "v10pre2" (July 2005) version?

[Inventive Software]

Because my searching skills are obviously lacking. Thank you Didée, I shall try again tomorrow.

[Inventive Software]

I got some (not much, but enough of an increase that makes it worthwhile on an AMD Turion64 X2) speed from using MT 0.7 properly with AviSynth 2.5.7, and a fully working MCBob, and the results are, if I may say so, rather impressive. They put into the shade the Bob() that comes with AviSynth. No shimmering to speak of. On an onboard lap at Istanbul Park taken from the F1 2005 Review DVD I had to wait around 2 hours at an average 0.69 FPS to MCBob that lap to a HuffYUV file. I now intend to try compression techniques with x264 and see what I can get.

I have one general question about encoding sports footage, specifically F1. Is it more ideal to encode it interlaced and (if using ffdshow) Kernel bob deinterlace on playback, or Bob / MCBob the source before encoding? Bobbing in general gives double the framerate, but I can't fault MCBob's amazing quality. Oh the dilemma!

[radar]

hi
im trying to use mcbob,but im getting a error "no function named mt_lut.ive read all the posts and tried the corrections sujested.
this is my script:

loadplugin("C:\Program Files\AviSynth 2.5\mcbob\mvtools.dll")
loadplugin("C:\Program Files\AviSynth 2.5\mcbob\RemoveGrain.dll")
loadplugin("C:\Program Files\AviSynth 2.5\mcbob\EEDI2.dll")
loadplugin("C:\Program Files\AviSynth 2.5\mcbob\mt_masktools-25.dll")
import("C:\Program Files\AviSynth 2.5\mcbob\MCBob_v03c.avsi")
MCBob()


please help.thanks

[radar]

i got mcbob to work,but the video is slow.the sound is fine.

my script:

loadplugin("C:\Program Files\AviSynth 2.5\mcbob\RepairSSE2.dll")
loadplugin("C:\Program Files\AviSynth 2.5\mcbob\mvtools.dll")
loadplugin("C:\Program Files\AviSynth 2.5\mcbob\RemoveGrainSSE2.dll")
loadplugin("C:\Program Files\AviSynth 2.5\mcbob\EEDI2.dll")
loadplugin("C:\Program Files\AviSynth 2.5\mcbob\mt_masktools-25.dll")
import("C:\Program Files\AviSynth 2.5\mcbob\MCBob_v03c.avsi")
MCBob()

the video is nice and not glitchy just slow

[LaTo]

Originally Posted by radar

i got mcbob to work,but the video is slow.the sound is fine.

the video is nice and not glitchy just slow

it's normal, MCbob is slow... you need re-encoding for normal playback or a new pc

[radar]

i mean after its done its encoding i play it.the video is slower than the sound but the sound is the correct spd.