The new wonder drug? or more placebo...

[Chung]

After reading inc's last post.. DivX5.. I've heard mixed feelings about it.. Some say it's great.. other's say not so much.. Wondering what the crowd out there thinks.. I'm still using DivX4, as I haven't seen a need to install yet another codec on my box since the only thing I've seen DivX5 so far is Dream-Anime's stuff.. or at least that I've noticed. Seems it's still got a ways down the road to general acceptance, though..

--Chung

[user]

I've done a few small test re-encodes with DivX5 (with only B-frames enabled, no q-pel or psycho), and while I couldn't see any significant CPU hit on playback, I didn't find any great quality gain either. I have more issues with the installer and trying to untangle the mess it makes of the divx3 and divx4 codecs.

Personally, I'll probably stick with divx3/4 for now and wait until divx5 matures a bit more.

[AlienBoy]

[earthdark]

I'd say, let's keep on using tried and true formats like Vivo.

[(inc)]

To amplify what I said elsewhere, that wasn't really an endorsement of the current iteration. For instance, though it runs fine on my main computer, I have one box that, so far, gets indigestion every time divx5 is installed.

As for the current divx5 posts, it's hard to say how much bloat there is -- some may just not want to take the time to make it small. As an example, on a 1-pass quality based encode (at slowest and the default Quantizer), with Quarter Pixel, GMC and Bidirectional Encoding all enabled (1 pass because I thought it might give a clearer idea of what the other parameters did across multiple episodes), the time required to do a run seems to about double. But tests at these settings on Melchior's FBC's went as low in size as 88M (with a divx5 resize down to 488x366), and, except for a slight muting of the colors, seem virtually indistinguishable from the original post.

But I’m still pretty ignorant on what makes an encode small or large. Previously I’ve been pretty much able to look at a show and by noting its motion, color range, light/dark ratio, etc., have at least a general idea what size range it might end up at. Other additional things are going on with divx5 – I’m finding that the re-encoded size range does not necessarily follow the same curve as the original encode – even though episode X might be much larger then episode Y as divx3, it might end up considerably smaller then Y when both are re-encoded to divx5. Probably the Global Motion Compensation and the B-frames in action, but I guess I need to read up on it some more – I’m feeling ignorant. And I’ve barely played with the 2-pass at all.

(inc)

[oblio]

[(inc)]

Heh, I knew that ob -- I wasn't signaling out your encodes -- sorry if I didn't make that clear. They just happened to be the ones I was mentioning 'cause I had just done a lot of them. ;-) The source material or its size really doesn't matter -- I was just looking more for something that looked good already, and yours do, and _still_ looked good after being munched down to the 100-120M range -- the range I would dearly love to be able to post decent encodes in. Doing this kind of thing with some of the mpegs being posted is actually harder to judge, because they tend to look rather mediocre to bad already. I find it easier to subjectively check how I'm doing, the better the source material -- I hate judging degrees of *badness*. ( It's a complement... ;-) )

(inc)

[user]

[AlienBoy]

Thanks for the heads up. I'll be giving that a try tonight. Doesn't look like there should be any problems.