XviD 1.1 vs RealVideo 10

[Musafir_86]

Hi,

-Does XviD encodes quality can still be improved in the near future? I heard that this MPEG-4 ASP codec is reaching it limits, is that right? If not, (I'm begging) can the XviD developers push it further so XviD can match RealVideo 10 in terms of quality (not speed) in low-bitrate area, especially for animes/toons. Everyone know RV10 is clearly better than XviD in this arena.

-I know that RV10 'principle' is "to avoid compression artifacts at any bitrate", but it somehow had 'inspired' from XviD in certain parts (such as STAT file for 1st pass, curve compression model, rate control, etc.) since XviD is GPLed (so they can peek at the source code). So, can't XviD 'counter-attack' it by much more quality improvement in it outputs (encodes)? I don't mind if this will make encoding slower (RV10 is currently 30-50% slower than XviD!).

-I hope related peoples will give attention to this matter. In fact, I'm challenging you! :sly: Go, go, go!!! :D

Regards,
-Musafir_86.

[Koepi]

Please read the last Doom9 codec comparison and i.e. the codec comparison of magazines with proper reputation (i.e. the c't 10/05 had a proper comparison).

You'll see that your observation, "that everyone knows", is not the whole truth.

Or is this an open trolling trial?

[Sirber]

You'll see that your observation, "that everyone knows", is not the whole truth.
He's talking about anime content and low bitrate. RV10 uses filtering (inloop) to blur blocks like H264 do, that's why it's effective at low bitrate. XviD (MPEG4) doesn't filter.

I made a comparison in the past if you are interrested:
http://www.detritus.qc.ca/forum/viewtopic.php?t=95

XviD clip is not too bad using post filtering and is better than VP6 if I remember correctly. Whitout filtering, it's a square party :)

RV10 uses ideas from xvid for the curve comoression (RC) and not the source, so it doesn't apply to GPL licence.

[Sharktooth]

Xvid and RV10 are 2 completely different codecs.
If i have to choose what codec to use for very low bitrates i would choose RV10 (or if a third choice is possible a h.264 codec like nero recode or x264).
But if you aim at quality backups Xvid is still the best of the 2 (IMHO).
However reading some comparisons would help...

[Sirber]

@Sharktooth

I use XviD for HQ movie rip in DVD rez in anamorphic mode, AC3 sound and MKV container.

I use RV10 for anime content (~500kbps) and 1 CD movie rip.

I'm starting to use x264 on anime content (350-500kbps).

[ChronoCross]

@Sharktooth

I use XviD for HQ movie rip in DVD rez in anamorphic mode, AC3 sound and MKV container.

I use RV10 for anime content (~500kbps) and 1 CD movie rip.

I'm starting to use x264 on anime content (350-500kbps).

I don't see why you are encoding them at so low a bitrate. I mean 300-500 would be suitable if you were streaming it but for some reason I don't see the companies giving anyone a license to stream anime over the web. encoding at such a low bitrate is simply for tests and if you pump up the bitrate and do a proper DVD backup of an anime source it absolutely destroy's RV10.

Xvid: Proper Backups
RV10: Streaming

[Sirber]

I use low bitrate to store a maximum of episodes per DVD (CD before). 80-100MB is better than 170-235MB. I've been encoding anime for years now and I have excellent quality using RV10 and x264.

[edit]
encoding at such a low bitrate is simply for tests and if you pump up the bitrate and do a proper DVD backup of an anime source it absolutely destroy's RV10.
It destroys my goal of small filesize. :)

[Musafir_86]

-Haa... that should be what I mean. Maybe I should change from 'low bitrate' to 'very low bitrate'? I'm planning to squeeze as much as possible into one disc without sacrifying any (noticeable) quality.

-From my recent test, converting/reencoding from DivX3 AVI to RV10 (using RealProducer Basic 10 & RealAnime 3 RC2.1 - 'Extreme' search) it would take above 2 hours for ~24 minutes of (anime) video clip. XviD only took 1 hour and half to complete (max setting I can think of). Target bitrate is 350kbps.

-But, my eyes tell me that RV10 encodes IS original?! I mean that there is no grain/blocky/ringing effect at all (or at least not noticeable to me).

-Anybody have further comment(s)? Thanks.

Musafir_86.

[Sirber]

Hi

You are in my field of encoding :D. 350kbps for 640x480, 24 FPS? You should try x264 too, gives pretty good results.

Have a look here:

http://www.detritus.qc.ca/forum/viewtopic.php?t=110

Click on the icons (left if here) to send me IM messages.

[Musafir_86]

@Sirber,

-Thanks for the info :p ; but doesn't x264 is still in early beta stage? Will there aren't any future problem (e.g. in decoding), & currently I think XviD still superior (overall - less buggy, etc.). Also, I started using XviD when it enters the post-1.0 stage/official (non beta) release. Before that I used DivX5.1.1.

-Note that I only used software - not codecs, that is in pre-1.0 beta stage. But if they enter post-1.0 beta (e.g. XviD 1.1 beta-2), I surely will use it (this is rather a personal opinion).

-BTW, I use RealAnime 3 RC2.1 at the default settings; only set target bitrate to 350kbps & EHQ Search to 'Extreme'. Still, I see RV10 is better than XviD in this test(~24 min of anime, 640x480). Can't XviD developer team do something about this? I'm waiting for some improvement 1.1 beta-3...

Good luck! :D

-Musafir_86.

[Sirber]

x264 is pretty good at current stage, and should be decoded with no problem later since it's standart complient.

Do you use divx and xvid at 350kbps? :confused:

[Musafir_86]

-Yep ;) ; I just want to pack as much as possible onto one disc! Thanks to post-processing (ffdshow is the best/better than XviD decoder post-proc.), it managed to 'hide' some grainy/ringing/blocky artifacts.

-Again, hey, but how RV10 can do that without post-proc.? (still dont' understand why XviD can't) :confused:

Musafir_86.

[Sirber]

RV10 uses another kind of processing.

Have a look here (http://forum.doom9.org/showthread.php?s=&postid=366301&highlight=in+loop+filtering+rv9#post366301)

Thanks google! (no offence, I just used it, thefreedictionary found nothing :() :D

[Musafir_86]

-So, can't XviD do the same (or even better) in the near-future release :rolleyes: ? I'm still hoping (some kind of fanatic/obsession).

::Tomorrow Never Dies:: :cool:

-Musafir_86.

[Sirber]

nope, not MPEG4 complient. Sorry. H264 can do it.

[Musafir_86]

-Okay, if that isn't MPEG-4 (ASP) compliant, why don't XviD find another/whatever way to achieve the target; or provide option(s) that isn't MPEG-4 ASP compliant to anyone who dare to use them (even broking compatibility). I still sure that XviD can still greatly improved; or should we started to move to Theora/Snow/Dirac??? :stupid:

-As we know, there're a lot of algorithms/techniques/whatever laying around the Net, some even patent-free. (just my thinking, though).

-BTW, do you any DETAILED suggestion to fine-tuning/pushing XviD (1.1 beta-2) to it max (time isn't a factor) at 350kbps to match RV10?

Musafir_86.

[Teegedeck]

B e c a u s e there is no need for it. Why should any open-source developer today hack XviD to imitate the behaviour of MPEG-4 AVC when he could just work on x264 which is a real MPEG-4 AVC codec?

XviD's strength certainly is not low-bitrate encodings like you do them but rather transparent or near-transparent encodes (H.263 quantizer~=3). If XviD isn't the right thing for your purposes, use x264. Just as open-source and just as free as XviD.

[Musafir_86]

-Okay, now I understood & can accept this; thanks.

::Start Using x264 Anytime Soon::

Musafir_86.

[Sirber]

B e c a u s e there is no need for it. Why should any open-source developer today hack XviD to imitate the behaviour of MPEG-4 AVC when he could just work on x264 which is a real MPEG-4 AVC codec?

XviD's strength certainly is not low-bitrate encodings like you do them but rather transparent or near-transparent encodes (H.263 quantizer~=3). If XviD isn't the right thing for your purposes, use x264. Just as open-source and just as free as XviD.
:goodpost:

Very good explanation! :D

[Sharktooth]

yeah, Teegedeck is becoming my personal idol even if his answers are still to long :D

[karl_lillevold]

If XviD isn't the right thing for your purposes, use x264. Just as open-source and just as free as XviD.
I really should stay out of this discussion, but I have to add something to this statement. Yes, both of these are open-source, but they are not really free. Both MPEG-4 and H.264 require distributors to pay license fees to a number of parties, MPEG-LA, Via Licensing, one large company who recently decided it wants a huge share, and is not a member of any of the patent pools, but is now contacting distributors of MPEG-4 and H.264, asking for more than either patent pool.

At the moment, both are available for free for enthusiast users via various binary distributors. Note how the developers never make binaries available themselves. Hopefully, this happy state of affairs will continue, since the license owners and patent pools would have a really hard time shutting down this binary distribution, but legally, in most countries, they could.

Open source is not always equal to free.

[Teegedeck]

You're right there. How about 'they're GPL'd' (hm, haven't checked x264's license actually)? Just doesn't sound as catchy, does it?

[karl_lillevold]

Yes, but that sounds complicated. What you first wrote "How about 'the sources are open and free'".. :) (that's what the e-mail notification said) is probably also true, but the patent and IP landscape is terribly complicated, and accurate statements hard to make :S

[Musafir_86]

-Yay, but isn't there a poll on www.xvid.org titled "What do you expect from XviD 2.0?" :) . I voted for "MPEG-4 AVC profile (h.264) support" - also many times too :D

-Hah, what do you want to say now? ;)


Musafir_86.

[Musafir_86]

-Oopss, I'm referring to post #17 by Teegedeck in my previous post (#24).

Musafir_86.

[Teegedeck]

Of course you're not the first one to bug XviD-developers with the request to include AVC into XviD and the answer has invariably been: "AVC has next to nothing in common with XviD - we would have to start from scratch!" So AVC-support in XviD 2.0 actually translates, "stop developing XviD, start development of a completely new codec and call it 'XviD 2.0'."

All that would remain would be the name.

I have a suggestion: If all you want is the nametag 'XviD' on an AVC codec download x264.exe and rename it 'xvid.exe'. Voila! :)

[Sirber]

I have a suggestion: If all you want is the nametag 'XviD' on an AVC codec download x264.exe and rename it 'xvid.exe'. Voila! :)Would that be xvid complient? ;)

[Backflip]

After reading through the thread I get the idea that x264 should be used for those low bit rates while XviD is better for higher bit rates (1000 Kbps and up?). Is this fair to say? Or is x264 meant to surpass XviD in all quality instances, including the high bit rate?

[unskinnyboy]

-Yay, but isn't there a poll on www.xvid.org titled "What do you expect from XviD 2.0?" :) . I voted for "MPEG-4 AVC profile (h.264) support" - also many times too :D
AVC in ASP?? I cannot for the life of me figure out how this is possible!..waitafrigginminute, 49.44 % have voted for that.!! :/

'Lossless compression' or 'Multi-pass encoding' is more practicable IMO.

[Mug Funky]

Or is x264 meant to surpass XviD in all quality instances, including the high bit rate?

i think so. the disadvantage being decoder complexity - you don't need a megaputer to decode xvid - just a moderately competent computer (my old p3 733 for example) running mplayer can decode full D1 PAL in realtime and only use 30% CPU. AVC at that size is jerky as hell and 100% CPU on the same system.

however, i don't think xvid has reached saturation just yet - think that mpeg-1 is still competitive on a limited number of sources (progressive, 4:3 or square-pix movies mainly). you can always squeeze a little more out of a well designed codec.

[Teegedeck]

Just as a general impression of mine, with XviD @ quant=3 (H.263) and better (high bitrate CQMs) XviD outshines AVC for me still. So, no advantage of AVC for transparent encodes as of now. Maybe that'll change with time, as AVC custom matrices are maturing.