any opinions on divx 5?

[saVe]

okay, now that the brand new codec is out, what do you think about it? i think it's time for some serious comparison!

when divxnetworks can achieve such "nice" quality by using b-frames, then i can't even imagine what xvid will look like with b-frame support!

@rui, sierrafoxtrot: maybe you'll finally get your 1cd rip of "the replacements"? ;) ;)

edit: the guys from divxnetworks also got some nice ideas like an extra log file for motion vectors, which makes the second pass almost twice as fast as the first one. would this be possible for xvid too?

[gldblade]

>the guys from divxnetworks also got some nice ideas like an extra log file for motion vectors

I think there was an idea like that at the XviD forum, but I think it was dismissed.

Hey, they stole our idea! (j/k) :D

[sierrafoxtrot]

heheh, already halfway through 1st pass. but quarter pel, b-frame calculation is so godawful *slow*. it hurts to watch ;)

[saVe]

don't worry, if you checked "use mv file" 2nd pass will be almost twice the speed ;)

BTW, i heard something that b-frames aren't mpeg4 compliant, and now the divxnetworks people claim they have an mpeg4 file format superior to avi:confused: are they allowed to use that term when their codec doesn't fit mpeg4 requirements?

[Koepi]

B_frames are VERY mpeg4 compliant.
They just don't belong to the CORE profile, but to the SIMPLE profile.

(I'm not too familiar with MPEG4 specs/profiles, but something like this is the case.)

XviD is going to support B-frames as well - and gruel just made the suggestion to create a "mv hint file" during first pass (will be huge though) last night...

Well, so far,

Regards,
Koepi

[Nic]

I must admit my first impression was: "Well, that will take me about 20secs to hack" :D

Then I wondered if they'd fixed the MPEG quant bug in the decoder??
Anyone tested that yet?

-Nic

[sierrafoxtrot]

@koepi

yah. that mvinfo.bin file just keeps growing and growing, almost 7x the size of the codec's log file. wonder how this will all turn out. tell you one thing though, still grateful for curve compression and custom quantizer (still got to mess with that). irregardless of how divx5 turns out, there'll always be a place in my heart for XviD. let's face it, it's open source, and the developers are keen for feedback, and so far, it's been quite a ride :D

ps: just wondering what this new-fangled MP4 file format is all about. can it handle vbr mp3 or ogg? (sorry for the off-topic discussion but i figure it will always benefit XviD if we learn from what other so-called competitor codecs have done/are doing) LoL

[Baalthazaar]

I haven't really gotten to do any extensive testing, but I have done two short tests.

For my sources I used two videos that I captured from Final Fantasy X - a portion of the ending movie and the first movie in the game. Both were encoded at 640x416 resolution using the same .avs file. I used Divx5 Pro version (ad supported) with all of the new features turned on and Koepi's latest build as of yesterday (March 3). With Xvid I mostly set things to standard with I-frame lock set 1-6, modulated quantization, 25% keyframe gain, curve compression set to 25-high and 10-low, and luminance masking enabled on the second pass (whew, that was a lot to write - damn Xvid and it's abundant options). Each codec was set to about 125K/sec.

I can't make any absolute comments on encoding speed because I was doing things in the background at the time (watching a DVD) and just set Vdub on 'idle,' but I didn't notice any great differences. Divx5 might be slightly faster.

The ending movie was a toss up, it looked really good in each codec at a bitrate of about 125K/sec. Divx5 looked as though the brightness was set incorrectly. It was too 'bright' in the way that .asf files used to be compared to .mpeg sources - places that should have been dark black looked more greyish. Divx5 also had some 'smearing' at the scene's edge during pans. I haven't tested it without GMC, so it might be a problem with their pre-set motion compensation routines for pans. Other than that, everything to be said was much more clear in the second video.

The second movie that I did was the intro movie which contains a lot of really difficult content. Fast pans, frequent scene changes, fast zooming, dust and fine debris, etc.

Divx5 - The quality of the encode was quite good for the content, much improved from the version I had previously benched with Divx4. Divx5 retains a LOT of detail from the source, it seems. This scene has a fully animated stadium with many independently moving, screaming spectators for instance. Divx5 really outperformed Xvid at reproducing the chaos of the stands. However, this detail is often surrounded by edge artifacts when it comes to objects in the foreground. Also, the colors seemed a little washed out to my eyes. At first I thought the post-processing was perhaps disabled, but then I couldn't open up the decoder through the player I was using (bsplayer). So I don't know if it was being post-processed or not. One problem I did encounter was when I tried to play the movie in WMP7 (Windows 2000) and alt+entered to full screen I got extremely jerky playback. The problem was not present in the bsplayer. [edit] I just opened the movie in the Divx Player 2.0 alpha and sure enough could access the post-processing which was up about 2/3 of the way. I put it up the whole way and watched again, but saw no dramatic quality improvements, edge artifacts were still present, so I will let the above statements stand.

Xvid - Also a great quality encode, but in different ways than Divx5. Xvid certainly did drop some detail compared to Divx5. Detailed closeups of the character's face seemed smoothed out. High action scenes, however, looked slightly better in the Xvid encode than in the Divx5, particularly the parts that showed buildings crumbling and lots of debris. I watched the Xvid encoded version once with no post processing where it was inferior to the Divx5 build except in certain action scenes. Then I watched it with Nic's Postprocessing filters and found that the quality actually seemed better than the opposing codec. Overall, Xvid had more defined edges and retained the source's colors more accurately. Also, areas of high contrast looked sharper with Xvid. My one complaint is that in several scenes moving objects left artifacts in their wake in the Xvid encode that did not in the Divx5 version (Or at least were not visible for more than an instant - Divx5 seemed to update the scene to remove these errors more quickly than Xvid)

So here's my final verdict: Both codecs showed some artifacts. This is to be expected because of the bitrate I used and the difficulty of the clip. However, I was surprised to see that each codec seemed to lend itself to different kinds of artifacts. Divx5 had noisy edges, while Xvid seemed to leave trails behind moving objects over static backgrounds. I should note that the problem was most obvious when objects were moving over dark backgrounds, though, so the problem could have been magnified by my using luminance masking where these dark macroblocks would not be given priority by the codec. I'm going to re-encode when I'm done writing this without masking enabled to see if that helps. For my money, I'd really rather put up with trails very infrequently in the Xvid codec than the awful edge artifacts that showed up so often in my Divx5 encode.

Without post processing, Xvid is not able to compete with the Divx5 encode, but with Nic's files it really shines and outperforms the quality that I achieved with Divx5.

sorry for the long post, but that's my first impression:) Personally, I think I'll stick with Xvid. You guys don't ask me to buy anything (although I would if you did, hehe).

[saVe]

nic, don't waste your time on hacking divx, it's probably not worth it ;) those 20 secs would be better used for the xvid dsf!

@koepi: thanks, i got something mixed up here i guess... so xvid will be fully mpeg4 compliant with b-frames supported! that's some great news after we've seen what b-frames are capable of doing!

[Actron]

- First...Im very sorry, to ask this, but can someone please explain once again with one short sentence, what a b-frame exactly is ?

- Second....Im not pretty sure about it, but could it be, that DivX 4.xx and now 5.xx is more and more tending to be something like an replacement for the avaible streaming media formats ??

The strong pre and post processors and b-frames could make one think so...Especially if you keep in mind, that DVD Quality is hard to reach with any DivX Version so far, simply because it blurs so much...With Xvid its very easy to reach indeed...


just two thoughts :)

Greetings

actron

[Actron]

ah, and by the way....i will stick with xvid, because i dont like that "great" visual quality is achived by just putting higher minimum post-processing and because i can allready reach real dvd quality of a 2h film on a single cd using xvid !

guys, you are just great ! (and you would be even greater by adding one or more of the requested features :D )

act

[Koepi]

I'll try a simple explanation:

Intraframes = Keyframes

Interframes = P(redicted)-Frames = Deltaframes

B-Frames = Bidirectional Predicted Frames, I don't know of a "every day word" for it yet ;)

So until now we had:

IPPPPPIPPPPPP avis

with B-frames we'll have

IBBPBBPBBPBBIBBPBBPBBP

(looks confusing, heh :) )

A B-frame is using motion vectors to the I/P-frame before it and to the I/P-frame behind it, resulting in a smaller frame - the P-frames get predicted over a bigger distance and thus get bigger, but the B-frames can overcompensate for this.

For a more precise explanation just look into the "XviD Q&A" that sticks at the top of the XviD forum ;)

Regards,
Koepi

[saVe]

-h wrote an excellent post on this topic.

get it here: http://forum.doom9.org/showthread.php?s=&threadid=17105

[Koepi]

That post is cited in the Q&A, save :)

Regards,
Koepi

[Logos]

@Baalthazaar:

As you've seen, the postprocessing of Divx5 is enabled by default. I may have misread your post, but could you give us a quick comparison of a non-postprocessed playback ?

[saVe]

@koepi: you're so right, but if someone doesn't like bold letters....:D

@logos: as far as i can judge from the short clip i encoded divx5 is still the same blurry image with far less details than xvid.
the thing is when i sit back a bit and watch my clips from a distance of about 1-2 meters i don't mention small blocks like they appear in xvid, but i do mention the lack of detail that is still very common among divx5. so in every case xvid is a lot better i think.

if just quality wasn't that much personal taste, things would be a lot easier!

[Koepi]

At first, I'd like to thank you guys for testing DivX5 for us and give some feedback.
I still refuse to install ad-ware on my compi and thus can't test the real impact features (I'll install DivX5 [free edition without ads] just to check wheather the green/pink bug with mpeg quantizers is gone... but I don't think so yet.)

Thanks for the thumbs up for XviD :)

Best regards,
Koepi

[MaTTeR]

Just as stated before all the hype...I'm sticking with Xvid. After everyone does the first round of testing I suspect they will come to the same conclusion as well.

Clearly Xvid retains better detail/sharpness and is slightly faster using todays build. Not to mention filesize prediction is totally MIA in Divx 5!

[Logos]

@Koepi: I'd rise four thumbs if I had them :D

With the actual software and hardware technology we have, I think that we've already pushed the limits very far. The competition begins to be very tight, and AFAIK, for the final user the choice between XviD, SBC and DivX 4/5 is often a question of taste in the overall result. Their decision is rarely based on the "Open" state of the product :(.
So what ? Even if DVN made a significant step forward (more tests will tell us how far ;)), they've got a consequent, and permanent, programming staff... How many guys are actively working on XviD, mainly on their spare time ? When XviD will have B-frames and MC, what could DVN imagine to do better ? The actual technology has limits, they'll probably have to wait a little till we all have Quad-Athlon XP 4500+ in our boxes ;)

BTW: what's the actual status of B-frame support in XviD ?

Speaking about enhancements... Could someone do something to have deringing on an Athlon 800 in XviD's DS filter ? :cool:

Keep up the good work guys !

[-h]

From preliminary testing (Isibaar arrived at the same conclusion):

DivX5 uses the same motion estimation engine as DivX4 - if you encode a clip with constant quantizers in DivX4 and DivX5, not using B-frames or any of the new features, you'll find that the resulting files are close to identical. Thus, XviD's ME is still working better.

Here are some file sizes I found:

x = xvid, d = divx5, db = divx5 + b-frames, dq = divx5 + quarterpel, dg = divx5 + gmc

file size (KB):
quant x d db dq dg
2 5556 5632 4263 5683 5535
3 3633 3686 2715 3706 3606
4 2222 2646 1972 2605 2578
5 1714 1992 1523 1978 1931

From this you can see, by far the biggest improvements come with B-frame implementation. The good news is, B-frames in XviD will provide an even bigger improvement than they did in DivX5, thanks to XviD's better motion estimation engine (thanks gruel!). But no, there is no deadline being worked to :)

For the time being, DivX5 with B-frames gives you the same quality in a smaller file than XviD, though DivX5's poor ME performance starts to wipe out this advantage at higher quantizers. Also unfortunate, is DivX5's "2-pass" mode, which really does fail to take advantage of the core improvements.

Fun testing ahead.

-h

[gldblade]

The good news is, B-frames in XviD will provide an even bigger improvement than they did in DivX5, thanks to XviD's better motion estimation engine (thanks gruel!). But no, there is no deadline being worked to :)

Keep it coming! :devil: :)

[Baalthazaar]

since Logos asked for them here they are: Divx5 looks better with no post processing enabled, but not THAT much better. Edge artifacts are visible in each, but Xvid also leaves more artifact trails and generally has less detail.

To clarify my final decision on the videos, I think that if you want a SHARP picture then you'll probably prefer Divx5. However, as many people found when the 'Mpeg vs H.263' question came up, sharper isn't always what is preferred. If you're doing 2CD rips then I'd imagine that either way you go will wind up looking great. If you're doing 1 CD rips, where the codec's shortcomings are apparent, then you'll have to make a choice between smoother, less detailed images (Xvid) and sharper images with Divx5 that contain some annoying edge artifacts. Also I would stress that Xvid is much more tweekable than Divx5, so if you're a glutton for quality you could probably do much better than I did. I did one further encode since then that seems to continue the trend (10 minute long clip containing both low/high motion), but I think it looks that Divx5 improves slightly more with the increase in low motion scenes than does Xvid, so given a 2 hour movie with a lot of low motion Divx5 could clearly win out. I'll have to encode something tonight with Divx5 to see.....maybe I'll dig out BladeRunner, that'll give me an excuse to watch it again.:)

My main gripe, though, is that the colors still just don't look quite right to me for Divx5. I don't know what it is...they're just slightly wrong . I'll have to try some older video drivers tomorrow to see if the problem's on my end...

[MaTTeR]

Originally posted by Baalthazaar
My main gripe, though, is that the colors still just don't look quite right to me for Divx5. I don't know what it is...they're just slightly wrong .

Funny you should mention that actually. I did a blind comparison test of a 20 minute clip from Pitch Black for my girlfriend. I ask her to pick out the sample that looked most pleasing. Her first response was...why are the colors way off? She of course was viewing the Divx 5 clip:) It seems to me the colors in Divx 5 are not as clean compared to Xvid, the look muddy or smeared together.

[Baalthazaar]

I had previously complained about the 'smearing' effect that I noticed in Divx5 when screen pans took place and thought that perhaps it was due to the new GMC in the codec. Anyway, I was interested in finding out if that was to blame, so I re-encoded without it and what did I find? Not what I expected....with all the same settings, the video now looked like utter CRAP. Artifacts all over everything, blurriness, lack of detail, it looked worse than I would have expected of Divx4.12. So maybe somebody else would like to run a comparison of GMC vs non GMC? I'm off to read a book for the rest of the night but I'd like to hear some other people's opinions on the subject :)

As for the 'which is sharper question' which has been a bit ambiguous on this thread, I'd like to retract my statement that Divx5 is 'sharper'. My terminology was bad. Rather, I see more fine details in the Divx5 encodes (such as human hair, buttons on shirts, wrinkles in clothing, ripples in water) but, as I've said, they're surrounded by artifacts. Xvid WITH post processing looks truer to the source, however, even missing some of these fine details.

Sorry to beat a dead horse, but I barely ever post and I hate sounding stupid because of poor word choice :)

[rui]

To Baalthazaar:

When i arrived at work this morning and read your posts, a must say that we came to almost the same conclusion. Your first post is a much better test report than my owne ;)

I agree with all your findings, until you said that divx5 is sharper. but in this last post you toke back that conclusion.

IMHO, divx5 is better than divx4. BUT...

Divx5 still is blurier.

I believe if one wants details on close ups xvid is your answer. I made last night a quick test using, again, The Replacements trailer. And Xvid is more sharper (this even using H.263), than divx5. And divx5 still has those artifacts around sharp edges.
The only thing that i believe divx5 is better than xvid is, like Baalthazaar pointed very well, is that, in xvid, in some scenes several moving objects left a trail of artifacts. I think that this is the single great bug that xvid still has.
Other than that, i believe xvid is better. Especially because if one wants divx5 to compete with xvid one has to use B-frames. Which make the encoding a lot slow.
So, by the time xvid has b-frames, i think that there will be not doubt about who is the best codec... ;)

By the way, i thought that for we to use b-frames we would need a new Vdub like software. I remember reading that over xvid.org (?)

[Acaila]

By the way, i thought that for we to use b-frames we would need a new Vdub like software. I remember reading that over xvid.org (?)

That was my main question about DivX5 as well. I remember reading that no codec today can encode B-frames because it has to be handled by the program doing the encoding.
However DivX5 encodes perfectly well, and the filesize reduction when enabeling the B-frames option surely supports that B-frame encoding is indeed taking place.

Can someone clarify this please?

[Actron]

Hmm....Looks as if i have to add one more comparsion encode here...

will encode a full dvd in both, xvid and divx5 tonight. post my opinion on it tomorrow.

[-h]

AVI "shouldn't" be able to handle B-frames.

There is a VfW function whereby you can order the player to feed the codec frames ahead of time - this would solve the problem (it just means there'll be a couple empty frames at the start of the file). It is being looked into, certainly shouldn't be long.

Edit: Those interested (?) can look up the ICM_GETBUFFERSWANTED VfW message.

-h

[sierrafoxtrot]

just did an overnighter for a 1CD rip of the replacements (same old same old ... ) with divx5 to compare with my Xvid rip. here's the encoding settings,

using divx5pro
464x288 bilinear resize
default quants, key frames and motion detection and rate control,
bitrate 763
2-pass with quarter pel, motion comp, and B-frames using motion vector calcs in 1st-pass.
no psy adjustments and light pre-processing.

expected size 615Mb
returned 607Mb (still undersized)

quality comparisons ... well, to be honest, the divx5 encode of the movie was more pleasing to the eye than Xvid's, and here's why ... the image was slightly grainy, and therefore *appeared* to have a bit more detail, but there were artifacts surrounding sharp edges. these artifacts can't even be called de-ringing artifacts, because they extend some way away from the edge, but still, the quality is superb.
even in the beginning of the movie where there was this underwater scene, it had Divx4's oversmoothed look, but not as extreme as Divx4.

in xvid, that scene was just atrocious, macroblocks and a complete lack of detail, and from what i could tell, there was no significant loss of quality sacrificed from the other sections of the movie.

i guess it's always been true that certain movies lend themselves to certain codecs, because of each codec's characteristic strengths and weaknessess, but i would really like to see what xvid is capable of once B-frames are implemented.

conclusion: the test was as fair as could be, one codec vs another, but bearing in mind that xvid hasn't got b-frames (yet), and that they are supposed to free up ~25% more bitrate, i guess we'll have to wait and see.

@actron
happy encoding, let us know how it went.

@rui
have you tried 1CD rip of the replacements with divx5? it'd be good to have another pair of eyes other than mine to make a comparison. ;)

[-h]

2-pass with quarter pel, motion comp, and B-frames using motion vector calcs in 1st-pass.

You really shouldn't use quarter pel motion estimation - it slows down encoding (and decoding) significantly, and actually makes the resulting files bigger in about 50% of cases. Just wanted to save you some time :)

and light pre-processing.

Tsk tsk, that's cheating ;) All the pre-processing does is apply a smoothing filter.

returned 607Mb (still undersized)

Yep, there'll be more where that came from..

conclusion: the test was as fair as could be, one codec vs another, but bearing in mind that xvid hasn't got b-frames (yet), and that they are supposed to free up ~25% more bitrate, i guess we'll have to wait and see.

It is indeed a fair test, seeing as you can currently get far better quality from DivX than you can from XviD.

DivX5 has "hobbled" its B-frames for some reason - usually you'd place 2 together (same as TMPGEnc and bbmpeg do), but they've chosen to only put 1 in - this would raise the bitrate by a sizable margin (just look at how much putting in a *single* B-frame achieved). I don't know whether this was a move to reduce encoder complexity or what, but I sure hope they're capable of decoding XviD streams with arbitrary numbers of B-frames..

-h

[sierrafoxtrot]

@-h

thanks for the heads up, still taking things onboard ... i thought quarter pel was just another way of detecting differences between frames with higher ... resolution (not sure if it's the right word, but what i mean is that it discriminates on smaller scales)? shouldn't that just slow down encoding and not decoding?

and yeah :p the pre-processing was a cheap shot because i was a little paranoid, seeing how badly xvid fared with the replacements, even with medium noise settings.

how can you find out if a frame is I P or B? i'd like to take a look-see at the encoder when it's going full tilt, but they don't have debug ouput :(

and are significant bitrate savings only made if there's more than one B-frame in sequence? sorry for the blatant ignorance on display here ... :o but thanks for the enlighten!

[-h]

thanks for the heads up, still taking things onboard ... i thought quarter pel was just another way of detecting differences between frames with higher ... resolution (not sure if it's the right word, but what i mean is that it discriminates on smaller scales)? shouldn't that just slow down encoding and not decoding?

If you think about searching for matching blocks between frames, how often would an object move by *exactly* 1 pixel? More likely, it'll move some "fraction" of a pixel - maybe 1.5 pixels, or maybe 3.75 or even some other horrible number. By using "half-pel" and "quarter-pel" interpolation, you can simulate sub-pixel movements like those described above, and in theory get a closer match.

Unfortunately, the additional overhead of quarter-pel matching (instead of just doing half-pel interpolation, we have to do *another* interpolation above that to reach quarter-pel, and even then, quarter-pel has an extra filter that has to be executed on the image!), as well as the extra bits it takes to desribe these precise movements, means you slow down both encoding and decoding (as both these steps have to go through the extra interpolation), and risk creating a larger compressed frame (thanks to the extra bits being spent on motion vectors). It's a dangerous option to use anyway. suxen_drol, one of the XviD core developers, found that quarter-pel searches made the official ISO mpeg4 codecs perform worse as well.

how can you find out if a frame is I P or B? i'd like to take a look-see at the encoder when it's going full tilt, but they don't have debug ouput :(

You can try to look at the frame size readout while VDub is encoding - I-frames are red, P-frames are tall blue lines, and B-frames are every second blue line (should dip dramatically). It's easier to see once it's finished encoding, or just create a really really slow filter chain, and encode that :)

and are significant bitrate savings only made if there's more than one B-frame in sequence? sorry for the blatant ignorance on display here ... :o but thanks for the enlighten!

Just having one B-frame in the sequence, as DivX5 does (IPBPBPBPBPBPBPBPBPBPBPBPBPBP etc.) has brought about significant increases in compression - perhaps even the 30% they claim. There is a tradeoff, as the more B-frames you put in at once (i.e. IPBBPBBPBBPBBPBBP etc.), the larger the P-frames get (this is part of the design), and the less benefit you'll get from the B-frames. Most (all) MPEG1/MPEG2 encoders have standardised around having 2 B-frames for every P-frame, and I am surprised that DivX5 didn't allow this option.

As a (flawed) example, fire up TMPGEnc, and mess around with the GOP settings in Constant Quality mode - try encoding with all I-frames, all I and P-frames, P-frames with a single B-frame in between, 2 B-frames in between, 3, 4, etc., and compare the final file sizes.

-h

[rui]

To sierrafoxtrot: I am planning on doing The Replacements 1 cd with divx5 tonight.
I will post results later.
But i have just read doom9's post about comparing codecs, and i still am not sure if i will do it using constant quality or not.

[everwicked]

DivX 5 vs XviD wars 2002.

As we download XviD binaries every day let's give some time to DivX 5. You can't judge a codec in one day. Less than one actually.

Just my 0.02 euros

[OUTPinged_]

-h:

could it be that divx5 encodes as regular divx stream at half fps and then builds missing frames as b-frames?

i thought about that because the compression gain from b-frames look _very_ similar to results of halving fps. ie, some torture clips that i tested which gave little filesize decrease at 12fps, were affected less by b-frames too. you can check that yourself.

[dragoman]

could it be that divx5 encodes as regular divx stream at half fps and then builds missing frames as b-frames?

I don't think so.

I've looked around the web and from what I've read, b-frames are kind of a unique animal.

Think about the way it was before. You have your keyframe, and then delta frames build off that keyframe with any motion that occurs, leaving the parts that stay still alone. Kind of over-simplified I know, but that's basically it.

B-frames are kinda same idea, but they do it differently. In-between each regular frame, the b-frame is contructed by taking half the motion bits from the frame before it, and half from in front of it. Kind of a hybrid frame, so to speak. (Bi-directional, both forward and back, right?)

So this means that less bits are used to construct a new frame that differs from the keyframe, right?

I know I don't have this locked down yet, anyone know better than me, or am I totally off base?

Thanks for any answers, I'm curious about this.

dragoman

[triffid]

hmm........

reading the reviews of divx5, i am seeing that it is similar to divx4 in quality. As almost purely an anime encoder, this doesnt sit well with me. Has anybody tried it out with anime? IMO divx4 did a terrible job with anime, mostly due to the lack of hard edges...hmm, i can consistently crank out 97% DVD quality (estimated) encodes at 160-220mb per 22min ep, depending on the compressability, with good old 3.11 SBC...is divx5 gona significantly improve this? I plan to benchmark it myself, do a direct head to head episode with SBC vs divx5...sigh. I really hate the user-friendly protect-you-from-how-complicated-the-codec-is setting config from divx 4 and GKnot...oh well. Anyway, im rambling. If any of you have tried this new codec with anime, please tell about your experience, especially on the edge sharpness.

thanks
-tired rambling triffid

[Vanos_b]

B-frames have a great impact on compression. 19% smaller files with it and seems that quality is the same.

[The People's Elbow]

@triffid: Do you really think that DivX3.11 aka SBC performes better than DivX4.12...I had the exactly opposite conclusion, because 3.11 has big probs with drawing big one coloured surfaces especially if they're in blue or red! I'm encoding much anime videos (every episode of dbz, some movies, everything i can get!) and I'm very happy with the DivX4 results...hopefully DivX5 is even a bit better with B-frames. Did you ever try to encode an anime with a bitrate of about 400KBit in SBC? me not and i can't recommend it, because the lower the bitrate the more DivX4 (also DivX5 I guess!) outperformes the good ol' SBC. The only way SBC-Anime encodes evetually look better can be achieved under some circumstances, if a very high bitrate is used for example.

PS: Quarter Pel sucks @ animes after i tested it with bitrates 400 & 900...produces much noise and lowers the all-around picture quality

PPS: We're talking about 2-Pass encodes...of course ;)

[rui]

Originally posted by everwicked
DivX 5 vs XviD wars 2002.

As we download XviD binaries every day let's give some time to DivX 5. You can't judge a codec in one day. Less than one actually.

Just my 0.02 euros

Fair enough ;)

My The Replacements divx5 encode didn't go well, but it was MY fault, not divx5! I had an old avs file with a screwed resolution, and the first pass was going to last me 5 hours!
But again, it was my fault!

I am a long time xvid supporter, but I want to make fair comparisons between the two codecs.

[jrmillerUT]

@People's Elbow

I have to go with triffid on this one. Divx 4.12 never had the clarity along sharp lines just as he said that SBC has. And 4.12 is not invulnerable to the same problem of large uniformly colored areas (i find red the worst especially the ship in Outlaw Star) It's just that i think Triffid and I expect more out of rip. I don't distribute my rips and i view them much as i would a DVD. As long as the res. is above 512 I expect the output to be near DVD quality. A few blocks now and then is acceptable but I found that Divx 4 smoothed the source too much... I prefer using my own filters when needed and then letting SBC or XVID do the work. I did an encode of Titan AE with Divx5 and noticed that straight lines where the characters are composited to the CG backgrounds look horribly jaggy... moreso than in SBC XVID or 4... I just don't know if Divx5 is worth it. I'm feeling that the support of our friends koepi and nic would be more worth the effort than subsidizing a divxn who thought they could make a buck off of an idea was originally a hacked version (with improvements... just not substantial enoguh in my eyes) I think they made a step forwards and backwards at the same time. I WANT CONTROL OVER THE CODEC's!!!! and i know i'm not the only one. I keep looking for something better than SBC and the only thing looking promising is XVID. I like the idea of the mv file in D5 and B frames seem to be great. But the picture is not what it could be...


Sorry for my rant... I have 3 midterms this week and i'm kinda stressed out..

Flames are welcome. I believe that by hearing someone elses brutally honest opinion it helps me understand the other side of the argument

James

[The People's Elbow]

@jrmillerUT: Maybe I have to decrease the radius of my statement ;) ...I have much more experiences about DivX4.12@Anime-Content when it comes to low bitrate usage, I did not AS MUCH testings in bitrates 800+ ...probably we are judging from a different point of view. @400KBit/s u won't get an "acceptable" result with SBC on any anime I guess (even at resolutions of 384x288, but 24/25fps plz...no frame reduction!). DivX4.12 is able to produce an "acceptable" image, but the key word as the one in the "'s. I'm not talking about DVD-Quality in this "dark" areas of video encoding ;) , it's a way to get the right relation between size and picture quality. (If u want to store 291 episodes of DragonBallZ on your HD then u get the point, eh? ;) )
...that's it for now, but I'm not finished off ;)

PS: ATM XviD rulz! My testings at low bitrate & anime-content make it very clear...I fear that DivX5 performes even worse than DivX4.12 at this point - and my opinion about the "MPEG 4 Tools" in this case of encoding: QPel sucks - produces noise and artifacts, same does gmc, bidirectional...hmmm, not sure!

[jrmillerUT]

@elbow... not trying to bash or anything... i've gotten alot of my studying for chem done so i feel a little better :) Anyways... i just reencoded my test clip of titan ae minus the quarter pixel option on divx5. The results of the quality is enormous. at 640x272 at i think 756kb it looks incredible... I'm now much more impressed with Divx5... i'll have a bunch of time this spring break to mess with it and maybe i'll compile a little comparison of SBC vs XVID vs Div5 with high and low bitrates... alot of the straight line aritifacts are reduced when i unchecked the quater pixel option as well as i jumped from 14fps to 24fps on the first pass and got to 27fps on the 2nd

[triffid]

hmm might have to give divx5 a bit of credit then. BTW i do res at 512x384, min BR at 350 and max BR at 1100+, which along with the filters I run gives me excellent quality (maximize to full screen and I cant tell the diff between this and 640x480 on my 19 inch mon). The fades to black (which often cause problems) are black, not grey and artifacted. In fact, I hardly ever get artifacts at all. Plus the combo of low min BR and high max BR tends to work really well on anime, which often has scenes with little or no movement. My policy is to let the encode have the bits it needs, and dont let it have bits it doesn't. Granted, this means that in the same series, one ep will be 140mb and the next will be 200mb, but the quality isnt compromised. But if divx5 does this so well, I might have to give it a shot, especially if it's faster than SBC, as the filter combo I run puts my encode speed at 6-7fps on my T-bird 1333mhz.

thanks for the response! If anyone else has input, please do!
gimme a PM on dalnet if u wana see a sample of what I can do with SBC.

-a less tired triffid, after a nap

[triffid]

Started encode test with divx5

The test is on Serial Experiments Lain episode 13. I picked Lain because it has a lot of scenes with little or no motion as well as scenes with a lot of static, which tend to be kinda touchy. I use an AVS file for the input video, running the decomb filter and then cropping in AVS. In Virtualdub i run precise bilinear resize to 512x384, the 2d cleaner filter (optimized) at default settings and warp sharp at 10. I plan to use these exact settings in 3.11 SBC.

Starting the encode i saw that there is no min/max bitrate, just one bitrate setting. This is a big hit against Divx 5, as I prefer to have a bit more control over the bitrate. The first pass is running at near the same speed as Nandub SBC first pass runs. For the quantisizer i uses 2x-8x, kf interval at 99999, scene change at 100% (no keyframes except at scene changes), and enabled GMC and Bidirectional Encoding. Encode speed with those filters jumps between 5-7 fps, I estimate average at around 6.2. This is not really noticably faster than SBC, but then it does do more in that time (b-frames, GMC). Bitrate was set at 1150, which is what I plan to set as max bitrate in SBC...but i think this may be a mistake as it may work on ABR instead of a min/max type config.

Anyway, I will get back to you on filesize/second pass encode time in a few hours, when it is done.

-busy triffid

[jrmillerUT]

The bitrate tab in Divx5 functions as an abr type setting such as bitrate in SBC i.e. not functioning as high/low/pass. Well even though I was impressed with the Titan ae i just realized that i have lost my divx3 and divx4 ds filters for playback... This is ticking me off even more at divxnetworks due to the fact that now my old divx encodes now have those stupid postprocessing artifacts even when the postproc is set to 0. This really annoys the crap outta me whcih goes to show how rushed and how unethical this setup is. I think until divxn gets their act together and gets rid of ad/spyways (which by the way was taking up 20megs or ram in taskmanager before i uninstalled it) and gives us more control... i'm gonna stick to SBC and keep testing out the latest builds of XviD. These inconveniences are not worth my time and effort of learning all the nuances of a new codec, which I think, D5 is going to be the best for low motion movies while sbc and xvid still handle highmotion much better. Even with a crispness setting of 25% SBC looks at least 3x as good as D5 with its automatic motion comp.

Sorry bout the ranting...
James

[grovsnus]

Why don't you look at the positive sides instead of immediately turn this into a "my encoder is better than yours"-competition that nobody will win, anyway?

As I see it, DivX5 Pro is a major step forwards. I've made two encodes with it so far, a single pass at 1000kbps with all features enabled, mq=2/MQ=6 and Light psychovisual enhancements, and a 2-pass at 1300kbps at the same settings part from MQ=5 / same movie.

The results are impressive; the single-pass is way better than any single-pass I've ever seen from an MPEG-4 encoder. I think it rivals an average-quality DivX4 two-pass rip.

The 2-pass rip is even better. Sharper, more stable movements overall. Frankly, I think this rip is one of the best rips I've made, and I've done about 150 rips in DivX 4.xx so far (aiming for quality - usually 2- or 3CD-rips).

Talking to friends, however, I hear critizism that DivX5 is too blurry, that it smears the colours too much - especially on background objects. I must be somewhat blind, because I cannot see that. I advise you to look for yourself.

Anyway, what strikes me as the major improvement is the complete elimination of the infamous "blockiness" that both DivX 3 and 4 suffers from. I cannot detect any blockiness at all, not even in the single-pass encode. That, in my eyes, is a major win!

I also feel that the picture is sharper than DivX4, and overall have much less artifacts. I don't really understand how people can claim that DivX5 have a lot of edge artifacts and so forth.. Perhaps at lower bitrates, but I see none.

Looking ahead, I'm eagerly anticipating the implementation of B-frames in XviD, which altogether seems like a very competent encoder.

I believe as time passes, we will learn new and exciting ways of tuning both DivX5 and XviD, and new support tools a'la GordianKnot and perhaps an improved VirtualDub with support for B-frames will appear, making both DivX3 and DivX4 quite obsolete. In fact, I consider them quite obsolete already now: both DivX5 and XviD are much better than both.

So, don't worry, be happy! Play around with the new settings, explore and tweak! And please, stop aiming for those horrible 1CD-rips.. Move to 2 CDs and use the original AC3 sound.. It really is worth it. Seeing as CDs cost about 20-30 cents apiece, I don't really see the meaning of using only 1 CD...

[Hanty]

I think a lot of people used to SBC are approaching this in the wrong way. Looking for settings that exist in nandub and refusing to acknowledge the diferent/new ones.

[Acaila]

And please, stop aiming for those horrible 1CD-rips.. Move to 2 CDs and use the original AC3 sound.. It really is worth it. Seeing as CDs cost about 20-30 cents apiece, I don't really see the meaning of using only 1 CD...

It's not so much the cost of CD's, but more the irritation of having to swap CD's half-way through the movie...


Any codec can make excellent quality 2-CD rips, but the ability to perform great with limited bitrate is what seperates a great codec from a bad one. For the moment DivX5 seems to do a pretty good job (through the use of B-frames mostly), but we'll have to wait and see if that assumption holds.

Comparisons between the various codecs are all great (and necessary in my opinion), but quality is in the eye of the beholder. Please refrain from turning this into a "my encoder is better than yours"-competition as grovsnus so elloquently pointed out, and try to keep the bashing and flaming to a minimum.

[grovsnus]

It's not so much the cost of CD's, but more the irritation of having to swap CD's half-way through the movie...
Yeah, but that depends on if you're splitting the file or not.. I don't ;) Just ACE them down if you need to put on CDs. DVD-R will be commonplace within a year, and then we'll all be sitting here cursing all those split movies, trust me! (I already am)

I don't really agree that any encoder can make a good 2CD-rip though. I've got loads of really bad 2CD-rips...