DivX5 DSF *more* broken for Xvid?

[Foo]

Well post-processing for Xvid is coming right on time. It appears that the DivX5 DSF has a new problem with Xvid playback. Now there is a large pink (not like the old "pink" problem in Xvid)smear at times with the h263 quant. Resolution might play a factor. I haven't had any problems with Xvid + DivX FourCC (h263quant) as long as I stay with at least an 8x multiplier, until updating to DivX5. Res for this is 712x304, hope the attachment works :). Using Xvid FourCC instead clears up the problem. Just a heads up for everyone.

cheers,

foo

[Foo]

Hmm...actually the problem persists even with DivX4. Strange that it doesn't pop up with all resolutions (even when 8x is used). It seems the horizontal can't be lower than 16x, but the vertical can.

Horizontal 16x, Vertical 8x

640x360=okay //1.78:1 source
640x344=okay //1.85:1 source
608x328=okay //1.85:1 source
576x248=okay //2.35:1 source

This source with a Horizontal 8x

712x304=BAD ;0) //but fine with Xvid DSF

Horizontal 16x, Vertical 8x

704x296=okay


foo

[avih]

use resolutions of x16 when encoding with xvid. it's a known issue for long time now.

[Foo]

Originally posted by avih
use resolutions of x16 when encoding with xvid. it's a known issue for long time now.

Resolution issues are a known problem (with DivX FourCC), but exact details aren't. As I pointed out in my post, you don't need to use 16x for the vertical :). And if you are using the Xvid DSF then 8x multiples for both work fine. IIRC -h said anything below 8x was a bad idea ATM until the padding is fixed.

foo

[Acaila]

Better yet, use resolutions of 32, but that has to be proven yet.

Check the thread about cropping in general discussion.

[Logos]

Havn't tried XviD material with DivX 5 DSF yet, but I've just watched a movie encoded with DivX 3 slow motion (decoded by DivX 5)... :scared: I've never seen anything so ugly !

[Foo]

Originally posted by Acaila
Better yet, use resolutions of 32, but that has to be proven yet.

Check the thread about cropping in general discussion.

I think that's going the wrong direction ;) . 32 is cool as long as you don't care about the aspect ratio (or work in ranges you don't want to), or don't mind loosing 20 pixels in the crop :rolleyes: . But like you said, it still hasn't been shown to be a mod issue or an alignment one, or either for that matter ;0).

foo

[Acaila]

I've done some testing myself on that subject, and I can say from experience that cropping with 32 H-Mod has a huge effect on final filesize. From what I've seen it doesn't matter a lot how much you crop as long as it's divisible by 32. Even on a 1000 frame clip H-Mod 32 saves 3 MB over H-Mod 16 and 5MB over H-Mod 8 with equal width. That is with 100% quality mode XviD.

But I'm gonna do some more testing on that and post the result in the appropriate thread after I've finished it.

[-h]

I've done some testing myself on that subject, and I can say from experience that cropping with 32 H-Mod has a huge effect on final filesize. From what I've seen it doesn't matter a lot how much you crop as long as it's divisible by 32. Even on a 1000 frame clip H-Mod 32 saves 3 MB over H-Mod 16 and 5MB over H-Mod 8 with equal width. That is with 100% quality mode XviD.

This has me interested.

The way XviD works internally, we could *force* the frame to be internally expanded to a "H-mod" of 32 and padded out with black pixels, then cropped upon decoding. Encoders / players wouldn't notice the difference.

From the sounds of things however (you're actually creating more macroblocks for the encoder to worry about, as MPEG4 ONLY cares about widths/heights of 16), this is a motion estimation issue that could be addressed without such a padding hack.

-h

[Acaila]

@-h:

If you're still interested, I've posted my results here (http://rilanparty.com/vbb/showthread.php?s=&postid=95787#post95787).