I know MCBob is slow, but THIS slow?

[nikolai]

I have an HD clip I captured as a transport stream. It's a little less than 7 minutes long. I've never used MCBob before but I have read many threads here that discuss it. I'm resizing the clip from 1080i down to 704x480 anamorphic using an AviSynth script like this:

LoadPlugin("C:\Video\DGIndex\DGDecode.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\RemoveGrainSSE3.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\RepairSSE3.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\nnedi.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\mvtools.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\mt_masktools-26.dll")
import("C:\Program Files\AviSynth 2.5\plugins\MCBob_v03c.avsi")
MPEG2Source("E:\ed\ed.d2v")
AssumeTFF()
MCBob()
SeparateFields()
SelectEvery(4,0,3)
Weave()

I'm using HCEnc 0.23 to encode MPEG2 output.

Now, I know MCBob is slow, but I'm seeing a time estimate of 30 hours for Pass 1 of HCEnc. Since I'm doing 2-pass encoding, that's going to be around 60 hours for a 7 minute clip on a Core2 Duo 2.4 GHz machine with 2G RAM. I'm pretty sure I obtained the latest versions of the plugins listed.

Does that sound right? I routinely downsize 45-minute shows that come across the cable as 23.976 progressive with 3:2 pulldown in about 5 hours. There's no bobbing or weaving going on there so I may be comparing apples and oranges. It still seems way too slow, but like I said, I never used MCBob before so maybe it's normal.

[R3Z]

I have an HD clip I captured as a transport stream. It's a little less than 7 minutes long. I've never used MCBob before but I have read many threads here that discuss it. I'm resizing the clip from 1080i down to 704x480 anamorphic using an AviSynth script like this:

LoadPlugin("C:\Video\DGIndex\DGDecode.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\RemoveGrainSSE3.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\RepairSSE3.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\nnedi.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\mvtools.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\mt_masktools-26.dll")
import("C:\Program Files\AviSynth 2.5\plugins\MCBob_v03c.avsi")
MPEG2Source("E:\ed\ed.d2v")
AssumeTFF()
MCBob()
SeparateFields()
SelectEvery(4,0,3)
Weave()

I'm using HCEnc 0.23 to encode MPEG2 output.

Now, I know MCBob is slow, but I'm seeing a time estimate of 30 hours for Pass 1 of HCEnc. Since I'm doing 2-pass encoding, that's going to be around 60 hours for a 7 minute clip on a Core2 Duo 2.4 GHz machine with 2G RAM. I'm pretty sure I obtained the latest versions of the plugins listed.

Does that sound right? I routinely downsize 45-minute shows that come across the cable as 23.976 progressive with 3:2 pulldown in about 5 hours. There's no bobbing or weaving going on there so I may be comparing apples and oranges. It still seems way too slow, but like I said, I never used MCBob before so maybe it's normal.

I dont know why you are using McBob in this instance when your returning an interlaced clip ?

[Blue_MiSfit]

You're wasting your time with MCBob when encoding 480i from 1080i :)

P.S. Where's your resize line? ;)

Use a faster bobber like YADIF.

~MiSfit

[um3k]

In fact, in many cases you can get away with nothing more than a dumb bob.

[nikolai]

I dont know why you are using McBob in this instance when your returning an interlaced clip ?

Because I want to resize the video.


You're wasting your time with MCBob when encoding 480i from 1080i :)

P.S. Where's your resize line? ;)

Use a faster bobber like YADIF.


Too much cut & paste. It should have been like this:

LoadPlugin("E:\Local Files\Video\DGIndex\DGDecode.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\RemoveGrainSSE3.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\RepairSSE3.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\nnedi.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\mvtools.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\mt_masktools-26.dll")
import("C:\Program Files\AviSynth 2.5\plugins\MCBob_v03c.avsi")
MPEG2Source("G:\shea\ed\ed2_drez.d2v")
AssumeTFF()
MCBob()
LanczosResize(704,480) <--- Doh!
SeparateFields()
SelectEvery(4,0,3)
Weave()

A dumb mistake on my part. It now estimates 7 hours for the first pass. The entire program is an hour so that would be almost a week of processing. Wasting time, indeed. I guess MCBob is only good as an academic exercise that demonstrates what can be done, and for comparing the results of other methods. Nobody can seriously be using it for any real-world work.

As for Yadif... I tried that first and the result looked like crap. There's a 4 or 5 second shot where a plane is taking off in the background. The raw video looks good but after Yadif and resizing the tail of the plane looks really bad as it moves from left to right. I'll extract that and post it someplace as soon as I get a chance. Thanks for the assist.

Happy New Year to everyone!

[Adub]

No, I have used MCBob plenty of times on real world stuff. Just not on HD. HD is what slows down the damn thing so much. Although, you could theoretically speed up MCBob by modding it to support the new MVTools2. Still, there is no telling exactly how much faster it will be.

[nikolai]

Good point, I expect it would be quicker on SD video. I also saw a suggestion that for HD video, a resize to (704,1080) beforethe MCBob might help with the processing time.

[NerdWithNoLife]

You're wasting your time with MCBob when encoding 480i from 1080i :)
Right on, with that kind of downrezzing there's not much difference between MVTools and a dumb bob - as in Bob(). It's like doing a rotoscope on a huge image with hundreds of anchor points, then scaling down to an avatar sized thumbnail.

[nikolai]

This is my first foray into downsizing pure interlaced 1080i clips. I've had very good results with captures from Universal HD, but they are mostly from progressive 23.976 film sources. The current file I'm working on is a pure 29.97 video stream from a live sporting event. I want to experiment with different de-interlacing techniques. My first output from using yadif didn't look very good, and that's when I decided to try MCBob, just to get an idea of what "the best" de-interlacing looked like. If there are other filters that can produce acceptable results I will be using them in the future. I have several 500 GB disks full of this stuff I need to convert.

My New Year's resolution is to finish all the video conversion projects I procrastinated with all year.

[NerdWithNoLife]

Several? It does add up, doesn't it... I archive to a 1TB drive, by the time that fills up, I'll probably get a 10TB drive, by the time that fills up I'll get a 100TB drive. Who know what I'll have when I'm 90?

[R3Z]

Because I want to resize the video.



Using McBob in this case is alot like carrying water to the beach using a teaspoon!

My advice is to settle for a dumb bob that retains original fields ( i think bob(0,0.5) does) and then resize and reinterlace. Much quicker and the question of quality is really a null. McBob downsized and re-interlaced doesnt look any better than a dumb bob with the same treatment. I just tested this out and i actually prefer the output of the dumb bob.

[nikolai]

Several? It does add up, doesn't it... I archive to a 1TB drive, by the time that fills up, I'll probably get a 10TB drive, by the time that fills up I'll get a 100TB drive. Who know what I'll have when I'm 90?
I like your username. I think I'm in the same boat farting around with this stuff on New Year's Eve. Oh well, I did my share of NYE partying back in the day.

Back to the subject at hand... I found this post by Scharfi's Brain regarding downsizing 1080i video and I get good results with this script:

LoadPlugin("C:\Video\DGIndex\DGDecode.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\TDeint.dll")
MPEG2Source("E:\ed\ed.d2v")
LanczosResize(704,1080)
TDeint(mode=1)
LanczosResize(704,480)
SeparateFields()
SelectEvery(4,0,3)
Weave()

which is a variation of Scharfi's example. It's extremely fast compared to MCBob and the results look good to me. I have some more experimenting to do. That first resize on an interlaced frame doesn't seem right, although the height doesn't change so the alternating lines from the 2 fields should be OK to feed into TDeint.

[Leak]

That first resize on an interlaced frame doesn't seem right, although the height doesn't change so the alternating lines from the 2 fields should be OK to feed into TDeint.
All resizers in AviSynth are two-pass (i.e. one horizontal and one vertical pass), so if the height stays the same vertical resizing is simply skipped.

Sure, resizing horizontally first might give the deinterlacer less data to work with as far as interpolating lines is concerned, but if you're going from HD to SD the impact should be rather negligible - the speed increase by having to deinterlace less than half the amount of pixels, on the other hand, isn't... :)

np: Tocotronic - Superpitcher/Wassermann Single Mix (Pure Vernunft Darf Niemals Siegen / Remixe)

[2Bdecided]

My first output from using yadif didn't look very good...then there was an error in your script. The difference between Yadif and mcbob after you've resized and re-interlaced will be virtually invisible.

There were several threads about this topic late last year. bob, resize, re-interlace is more than good enough. IanB's interlaced resize is also fine - softer, but less aliasing.

http://forum.doom9.org/showthread.php?t=139102
...or to save you reading it all...
http://forum.doom9.org/showthread.php?p=1161524#post1161524
...or the slightly sharper...
http://forum.doom9.org/showthread.php?p=1209347#post1209347


and, for the insane, dramatically increased horizontal sharpness is here...
http://forum.doom9.org/showthread.php?t=142682
...at the expense of insanely slow processing (far slower than mcbob).

Cheers,
David.

P.S. I think something about HD>SD should be sticky-ed in this forum.

[Gavino]

There were several threads about this topic late last year. bob, resize, re-interlace is more than good enough. IanB's interlaced resize is also fine - softer, but less aliasing.

http://forum.doom9.org/showthread.php?t=139102
...or to save you reading it all...
http://forum.doom9.org/showthread.php?p=1161524#post1161524

or, with theoretically correct chroma placement:
http://forum.doom9.org/showthread.php?p=1172760#post1172760 and later

[2Bdecided]

or, with theoretically correct chroma placement:
http://forum.doom9.org/showthread.php?p=1172760#post1172760 and laterWhile I originally bowed before both you and IanB for working through this, I then forgot about it when I read...given the trouble I had building a test pattern to actually see the error, I do not believe it is worthwhile.

As you might have spotted, I use...
bob()
spline36resize(704,576)
limitedsharpenfaster().Blur(0.0,1.0).Sharpen(0.0,0.5)

assumetff()
separatefields().SelectEvery(4,0,3).Weave()IMO (!) it's slightly sharper, slightly less ringy, and looks lovely on a real interlaced display. I think it could be even better, but given that the output has to be MPEG-2 encoded for DVD, that's more of a bottleneck (again, IMO). I'm still playing with it when I get time.

Cheers,
David.

[nikolai]

P.S. I think something about HD>SD should be sticky-ed in this forum.
I was thinking about writing a guide. Time is always short, however, and now I have another issue. In the second transport stream file I have (from the same event) there are brief segments where they spliced in some 3:2 pulldown material during the live broadcast. These are apparently film clips from 20 or 30 years ago, which make the whole stream a hybrid. DGIndex flagged the exact locations of these clips by detecting field order transitions there, and running D2V Parse on the d2v file clearly shows the segments of 3:2 pulldown video in the exact locations where these transitions occur.

Time for some more research. I'm thinking some combination of TDeint and TDecimate with overrides, but I have to spend a few hours reading up.

[[7]Raven]

Gentlemen, I have another MCbob performance question. I tried to encode interlaced m2v video (from DVD, PAL interlaced source) to progressive one using x264 with MCbob applied. What I get is very slow, while my CPU usage is only 25-40%. I doubt that this works like it should.
Here's a screenshot:
http://pic.ipicture.ru/uploads/090125/20312/thumbs/5c6bY7OmEV.png (http://ipicture.ru/Gallery/Viewfull/12191289.html)

Of course I know that MCbob is slow, but I was sure that my CPU will be 100% loaded and now I have half of processor time wasting.

[um3k]

If I had to guess, I would say that MCBob is using only one core, and the slow rate of frame delivery limits the encoder.

[[7]Raven]

If I had to guess, I would say that MCBob is using only one core, and the slow rate of frame delivery limits the encoder.
But then one core used should be 100% loaded, shouldnt it?

[um3k]

Raven;1241967']But then one core used should be 100% loaded, shouldnt it?

Yeah, I thought of that a few minutes after I posted, but didn't feel like going back and changing it. I guess the problem must be something else.

[thetoof]

1 - What is your CPU usage when doing a rendering pass (or running a preview in vdub)?
2 - If you do rendering pass-file-x264 encode, what is your CPU usage/speed?

[ajp_anton]

Raven;1241967']But then one core used should be 100% loaded, shouldnt it?There's no reason to put everything on one core. Windows simply gives the next "task" to another core.

[[7]Raven]

1 - What is your CPU usage when doing a rendering pass (or running a preview in vdub)?
2 - If you do rendering pass-file-x264 encode, what is your CPU usage/speed?
Same with MCBob/NNEDI and it gives me only 75-80% CPU load on common encode (with yadif deinterlace). Looks like my encoder works this way since some time. A couple of weeks ago it worked fine (full CPU usage), it seems like some MeGUI update caused this issue.
Does anyone have this issue? I will try to reinstall MeGUI as well as all components.

[mavinashbabu]

On my system xvid_encraw.exe always uses 25% of CPU though running on all 4 cores, hence i trim the video into 3 parts and join them using VDub. where as x264.exe uses 75% of CPU with MCBob in my .avs file.

i would not have bothered if not using MCBob, but for few DVD's i have to use MCBob though.

did not understand what could be "tweaked" push it to 75% or above while doing xvid encodes.