What exactly is the problem Virtualdub has with Divx multipass?

[Onceler2]

and how do I get it to work?
My problem is this I bought divx now I am trying to make multipass videos from dvds using first dvd decrypter then vob2mpg then virtualdub mod with divx as the encoding codec set to multipass it goes for an hour and makes files that are around 70MBs in size and does not work

[guns1inger]

You have to do the first pass to create the stats file, then do the second pass to get a video.

Or you can used AutoGK, which automates the process and does a damn fine job.

[Onceler2]

how does AutoGK do on cropping,I have video fles that need cropping but they are uneven in the way they need cropping,what I mean is that sometimes in the video the black bars change in a way in which the croping would need to be more like 8 left instead of 4 left which is where the video starts needing the crop?

[jman98]

Using VirtualDub (any version) to encode to Divx is kind of like hunting squirrels with a bazooka. Unless you are an extremely experienced user and you are using it specifically because there is something it lets you do that you simply cannot do anywhere else, I'd use either AutoGK or Dr. Divx. Dr. Divx will let you change the cropping as you wish. I'm sure AutoGK will too.

[guns1inger]

AutoGK is pretty accurate with cropping, but if it does happen to miss, you can over-ride the settings manually using the hidden setting panel (Ctrl+F9)

[manono]

But if different parts of the video need different crop values, AutoGK won't be able to do that. The best way to handle that sort of thing is via AviSynth.

[jagabo]

Why do you need to crop? Black bars consume almost no bitrate. Unless your source is noisy, like VHS.

[Onceler2]

it was my understanding that black bars take up all the bitrate

[jagabo]

Just to put some numbers on it, I ran a little experiment. I encoded 10 minutes of a 2.35:1 DVD as Xvid with a target quantizer of 3 (note that in target quantizer mode the output video will always have exactly the same quality, the file size will vary depending on how compressible the video was) with no audio. In one video I used the full 720x480 frame untouched. In the other I cropped away 48 lines of black bars from the top, and 48 lines from the bottom. That didn't remove the black bars entirely but it was most of them them.

The full frame version (720x480) came out as 52,524,716 bytes. The cropped one (720x384) came out as 52,380,922 bytes. So removing black bars which constituted 20 percent of the frame saved less than 0.3 percent in the overall file size.

[FulciLives]

Just to put some numbers on it, I ran a little experiment. I encoded 10 minutes of a 2.35:1 DVD as Xvid with a target quantizer of 3 (note that in target quantizer mode the output video will always have exactly the same quality, the file size will vary depending on how compressible the video was) with no audio. In one video I used the full 720x480 frame untouched. In the other I cropped away 48 lines of black bars from the top, and 48 lines from the bottom. That didn't remove the black bars entirely but it was most of them them.

The full frame version (720x480) came out as 52,524,716 bytes. The cropped one (720x384) came out as 52,380,922 bytes. So removing black bars which constituted 20 percent of the frame saved less than 0.3 percent in the overall file size.

Very interesting BUT if some of the bitrate is going towards the black then isn't that less bitrate for the "real" image? Does that make sense? LOL

- John "FulciLives" Coleman

[jagabo]

The damage you'll do in cropping and resizing the frame to remove every little bit of black border (and likely misaligning the existing 8x8 DCT blocks) will be much worse than the damage from losing 0.3 percent of your bitrate.

[FulciLives]

The damage you'll do in cropping and resizing the frame to remove every little bit of black border (and likely misaligning the existing 8x8 DCT blocks) will be much worse than the damage from losing 0.3 percent of your bitrate.

My question was more academic ... I wasn't necessarily agreeing or disagreeing with you. I was genuninly curious is all.

- John "FulciLives" Coleman

[Onceler2]

it was my understanding that encoding from the image to the black bar was where all the bitrate goes,I can understand black bars using little bitrate ,but it is from the image to the black bars and back that uses it most
BTW cuting 48 bars from the scene seems like an excessive amount I was talking about a fullscreen video that needs to be cropped 8 off both sides

[FulciLives]

it was my understanding that encoding from the image to the black bar was where all the bitrate goes,I can understand black bars using little bitrate ,but it is from the image to the black bars and back that uses it most
BTW cuting 48 bars from the scene seems like an excessive amount I was talking about a fullscreen video that needs to be cropped 8 off both sides

I've heard that argument ... that the "hard" line of the image against the black will "eat up" bitrate especially if not mod 16 ... or something.

Whatever. It might be an issue with DivX or XviD where the bitrate is so low but I've never worried about it with DVD and now with H.264 encoding (I have a PS3) I see even less of a reason to worry about it.

- John "FulciLives" Coleman

[jagabo]

it was my understanding that encoding from the image to the black bar was where all the bitrate goes,I can understand black bars using little bitrate ,but it is from the image to the black bars and back that uses it most

It's true that the border between the picture and the black bar will require more bitrate if it's not on an 8 pixel boundary. This is because the non moving black bar restricts the range of motion vectors that can be used. And the sharp edge between picture and black bar requires more high frequency detail be retained. But this effect isn't big unless you have a very small frame height. I certainly wouldn't call it "most" of the bitrate. More like a few percent more in the worst cases.

BTW cuting 48 bars from the scene seems like an excessive amount I was talking about a fullscreen video that needs to be cropped 8 off both sides

If you ever watch those videos on a TV the cropped pixels mean you will miss more of the picture to overscan.

I used 48 lines for a few reason. The video I ran the test on was a 2.35 AR movie on a 16:9 DVD. So it had about 60 lines of black on the top and bottom. Cropping 48 lines removed most of the black bars. It also left the remaining picture aligned on 16 pixel boundaries so the existing macroblocks didn't end up spanning new boundaries. Doing so would have changed in the bitrate requirement for the remaining picture making it hard to determine how much of the difference was due to the black bars and how much was due to new alignment of the picture data.