Codec Fight! Animes encoding

[Sirber]

Hi

After the success of my RV9 vs XviD thread (http://forum.doom9.org/showthread.php?s=&threadid=49791), I've decided with Ramirez to do a second comparison, but this time, for animes encoding. The bitrate will be 350kbps. It will be a full clip comparison and a frame by frame comparison too.

Fighters will be:

DIVX Tahanea
Real Video 9 (EHQ)
Windows Media Video 9
XviD unstable


Source
------

Name: Ghost in the Shell - Tachokoma Special - Episode 3
File Name: T03_source.avi
FOURCC: DIV3 (SBC)
Average Video BitRate: 800kbps
Codec: MP3
Average Sound Bitrate: 128kbps
Size: 14.426.112 Bytes
Lenght: 1m43
Resolution: 712x382
FPS: 24

Output (video only)
-------------------

Real Video (Sirber):
Average BitRate: 350kbps
Codec: RealVideo 9
Special Features:
>EHQ: 80
>Max Startup Latency: 25 sec
>Keyframes Interval: 10 sec
>Input ColorSpace: YUV2
Total Encoding Time: ~8 minutes

DivX (Sirber):
Average BitRate: 350kbps
Codec: DivX Tahanea
Special Features:
>Nth Passes: 3 (1 + 2)
>Psychovisuel Enhancement: light
>Quality / Speed: Slowest
>BFrames: 1
>Optimized For: Constant Quality
>Keyframes Interval: 300 frames
Total Encoding Time: ~35 minutes

XviD (Ramirez):
Average BitRate: 350kbps
XviD unstable (24062003-1 build)(27/6/2003 13:47:38 PM)
Encoding Mode: 2 Pass.
I-frame Boost: 0%
Below I-frame Distance: 10%
I-frame Bitrate Reduction: 20%
Curve Compression: Payback with Bias, Bitrate Payback Delay: 250frames
High Bitrate Scenes: 0%, Low Bitrate Scenes: 0%
Hinted Motion Estimation: OFF
Alternative Curve System: OFF,
Motion Search Precision: 6 - Ultra
Quantization Type: H.263
FourCC Used: XVID
VHQ Mode: 4 - Wide Search
Max I-frame Interval: 300, Min I-frame Interval: 10
Lumimasking: ON
Interlacing: OFF
Greyscale: OFF
Quarterpel: OFF
Global Motion Compensation: OFF
Chroma Motion: ON Optimizer Enabled
Max B-frames: 2
B-frames Quantizer Ratio: 150%
B-frames Quantizer Offset: 100
B-frames Quantizer Treshold: 100
Packed Bitstream: OFF
DX50 B-VOP Compatibility: ON
Print debug info on each frame: OFF
Min I-frame Quantizer: 2, Max I-frame Quantizer: 10
Max Bitrate: 10000kbps, Max Overflow Improvement: 60%, Max Overflow Degradation: 60%
Total Encoding Time:10 minutes

WMV9 (Sirber):
Average BitRate: 349kbps (was 400)
Codec: WMV9 VCM
Special Features:
>Encoding Quality: 5/5 (Slowest)
Encoding Time: ~8 minutes


News:

25 June 2003:

DIVX, WMV9 and RV9 are done. I'm waiting for Ramirez and his XviD clip. Making the frame by frame comparison will take few days (I hope :D).

Stay tuned!

26 June 2003:

Warning: Please don't download them if you don't care about codec comparison. I'm bandwith limited (speed) and hosted at my work. Also, please avoid downloading files between 9h and 16h, GTM -5.

Source: T03_source.avi (http://www.webernic.com/codec_comparision/T03_source.avi)
DIVX: T03_DIVX_3pass.avi (http://www.webernic.com/codec_comparision/T03_DIVX_3pass.avi)
RV9: T03_RV9_EHQ80_2pass.rmvb (http://www.webernic.com/codec_comparision/T03_RV9_EHQ80_2pass.rmvb)
WMV9: T03_WMV9_2pass.avi (http://www.webernic.com/codec_comparision/T03_WMV9_2pass.avi)

28 June 2003:
XviD: T03_XVID_2pass.avi (http://www.webernic.com/codec_comparision/T03_XVID_2pass.avi)

30 June 2003:
All links removed.

30 June 2003 - PM:
Links updated.

[Hiro2k]

Nice Work, I hope Xvid wins!

[unmei]

:D Xvid has made huge steps for anime starting in may build

but 350kbit...damn low (but according to my test Xvid gets a lot better between 260 and 350kbit/s, at least). I'm looking forward to this comparision as a never really tested RV9, i just don't like it if i cant use avisynth/VDM to encode but i would still like to know what could be done in RV

[temporance]

Originally posted by Sirber
Source
------

Name: Ghost in the Shell - Tachokoma Special - Episode 3
File Name: T03_source.avi
FOURCC: DIV3 (SBC)
Average Video BitRate: 800kbps
....You are using a source that is already heavily compressed. IMHO, this could mess up your results as the quantized coeff levels and ME / ringing / blocking / noise artifacts will do different things to different codecs.

Having said that, I'm interested to see your results.

[kilg0r3]

No offense intended, but the source really seems to be a problematic choice.

Additionally I'd really recommend using the latest xvid build since its b-frame quality seems to have increased considerably. Please read the relevant thread before encoding. For there have been quite some changes in the threshold settings. Trellis quant, sometimes, seems tohave become a good choice for anime too.

Good Luck!

[Dark-Cracker]

hum perhaps u should host the original file perhaps some guru in such or such codec can obtain better results. and perhaps try with an most recent anime because i think if u encode ghost in the shell in rv9 at 15 fps u will have correct speed while with new anime u need at last 24 fps for traveling scene IMHO.

Bye.

[Sirber]

Originally posted by temporance
You are using a source that is already heavily compressed. IMHO, this could mess up your results as the quantized coeff levels and ME / ringing / blocking / noise artifacts will do different things to different codecs.

Having said that, I'm interested to see your results.

The source is very clean, no blocky, no noise. The source is an excellent choice IMHO because I recompress 230 Mo animes (800 - 2000kbps) to 350kbps or 450kbps, including a soundtrack. Also, it's very hard to find anime Vobs.

Originally posted by kilg0r3
No offense intended, but the source really seems to be a problematic choice.

Additionally I'd really recommend using the latest xvid build since its b-frame quality seems to have increased considerably. Please read the relevant thread before encoding. For there have been quite some changes in the threshold settings. Trellis quant, sometimes, seems tohave become a good choice for anime too.

Good Luck!
I'm not doing the XviD part, I let that to Ramirez. People don't trust me when I use XviD... :( I'll post the source, and all compression tests on my server. So you'll be able to compare by yourself too.

[temporance]

Originally posted by Sirber
The source is very clean, no blocky, no noise. The source is an excellent choice IMHO because I recompress 230 Mo animes (800 - 2000kbps) to 350kbps or 450kbps, including a soundtrack. Also, it's very hard to find anime Vobs.Even if you can't see any blocks/noise etc. in the source, it doesn't mean that there aren't some artifacts that will affect an encoder. But if you have no alternative, then, well, good luck!

One advantage of using a compressed source is that you can post a link to the source AVI, so that experts at Real, xvid, DivX, MS, etc. can fight amongst themselves!

[Sirber]

Files uploaded and link posted. See the first post.

In my opinion, here's the winner list:

Source: :D
RV9: Sharp and detailled
WMV9: Good image quality, sometimes edge blurred
DIVX: A lot of wierd things around shapes, no plain color

A more detailled comparision will fellow... when XviD will be ready. Go Ramirez Go :D

[The Edge]

DivX file not available.

The requested URL /codec_comparision/ T03_DIVX_3pass.avi was not found on this server.

*Edit*
Link fixed as I was typing.

Bren

[31 Flavas]

Originally posted by unmei
i just don't like it if i cant use avisynth/VDM to encode but i would still like to know what could be done in RV VDM = Vitruldubmod?

Why not just load the avs script in RVencoder? RVencoder (both the GUI and CLI) supports avs.

[Sirber]

I'm remaking the WMV9 clip. My first was at 400kbps, my second at 328 kbps. the VMC codec don't do the bitrate I ask :angry:

[bill_baroud]

i think if u encode ghost in the shell in rv9 at 15 fps u will have correct speed while with new anime u need at last 24 fps for traveling scene IMHO.

This sample _is_ new eh :)

it's not from the movie, but from the TV Serie which started in october 2002 :)
and with the animation's quality, you're right, it might sux a lot at 15fps with all those full 30fps CG-scenes :)

imho, the bitrate used isn't a fair one, or one i will use, but i'm really looking forward to the results :D

[Sirber]

usualy I do animes at 350kbps (with 32kbos voice) or 450kbps (with 64kbps surround). 350kbps whitout sound is enough for an anime of that kind with no sound.

All this is based on my tests and on IMHO :D

[Sigmatador]

Originally posted by Sirber
usualy I do animes at 350kbps (with 32kbos voice) or 450kbps (with 64kbps surround). 350kbps whitout sound is enough for an anime of that kind with no sound.

poor anime :scared: ...

[Sirber]

The only way to get more than 3 on a CD... :)

[Latexxx]

Originally posted by Sirber
I'm remaking the WMV9 clip. My first was at 400kbps, my second at 328 kbps. the VMC codec don't do the bitrate I ask :angry:

Always use Microshaft windows media encoder to encode video to .wmv files. It uses more advanced tecnologies than the avi-version because of the avi limitations.

[Phanton_13]

the DivX Tahanea is the badest but it is at 640x480+blackbars intested of 712*382 than the other codecs have, its posible to reencode??, I like to make the test with olders or experimental codecs to compare the improvement but I don´t have much time now(studient live). I only try and was surprised by VP3 it only has a problem in the video and it is atributable to a bug( and at max quality they have the same problem but the vp3 codec based theora alpha1 dont have this problems but its extremedly inestable for now, I ned to try compile th ealpha 2 for windos) and they look greatly for an old codec.

my configuration:
resize the video to 720*384 for compatibility with the codec
ver 3.6.1
auto key frane on
drop frane on
quick compres off
minimun alowed quality 38
video smoth <- this make the codec litle more agresive with the details boot for anime is the best option and don´t have visible efects for the black lines and contours in the anime.
minumun key franes interval 1
max key frane interval 240
key frane tresold 90
bitrate in KB/s for virtualdub=
40 for 4.36MB
39 for 4.26MB
Sorry I cant have any site to put the video.

If I have more time i try to other codes.


The source is realy poor If do you like a beter source to compare anime please go to:
http://www.irradiance.net/Animation/GroupsMPEG4/ they only have openings and endings a lot with more than 40MB

[Sirber]

IMHO, VP3 is dead. Also, all clips have the same size. I don't know why it's in 640x480 on your computer...

[midiguy]

Wasn't really the fairest test... This type of clip will always be favourable to RV9. The background is not detailed at all (or actually, has no details, and is only white), and the foreground isn't too detailed either. This scenario is perfect for RV9, but isn't a very common sceneario that most people would find themselves in. A fairer test would have been a clip from a Cowboy Bebop episode, or something like that.

Sorry about spelling/grammar errors... it's late.

[Phanton_13]

I find my probolem with divx5, yes VP3 bur I konow a few user, and they only use it to low bitrate anime. I extend my test to expermental codecs.

[net1999]

RV9 should be the winner easily at this bitrate, followed by xvid but you need lots avisynth plugins and the encoding speed will be hell slow...
Waiting for the final result:D

[Ramirez]

Aloha guys,sorry for the delay with the Xvid clip,I've simply couldn't find the necessarily time to make it sooner due to the high pressure at my work. Anyway it's done and will be available for D/L later on. In the meantime here are the settings I've used for this encoding. (Sirber will copy&paste it to the top of the tread)


XviD unstable (24062003-1 build)(27/6/2003 13:47:38 PM)
Encoding Mode: 2 Pass.
I-frame Boost: 0%
Below I-frame Distance: 10%
I-frame Bitrate Reduction: 20%
Curve Compression: Payback with Bias, Bitrate Payback Delay: 250frames
High Bitrate Scenes: 0%, Low Bitrate Scenes: 0%
Hinted Motion Estimation: OFF
Alternative Curve System: OFF,
Motion Search Precision: 6 - Ultra
Quantization Type: H.263
FourCC Used: XVID
VHQ Mode: 4 - Wide Search
Max I-frame Interval: 300, Min I-frame Interval: 10
Lumimasking: ON
Interlacing: OFF
Greyscale: OFF
Quarterpel: OFF
Global Motion Compensation: OFF
Chroma Motion: ON Optimizer Enabled
Trellis R-D Quantisation: ON
Max B-frames: 2
B-frames Quantizer Ratio: 150%
B-frames Quantizer Offset: 100
B-frames Quantizer Treshold: 100
Packed Bitstream: OFF
DX50 B-VOP Compatibility: ON
Print debug info on each frame: OFF
Min I-frame Quantizer: 2, Max I-frame Quantizer: 10
Max Bitrate: 10000kbps, Max Overflow Improvement: 60%, Max Overflow Degradation: 60%
Total Encoding Time:10 minutes


P. S.
I wouldn't choose the winner yet because we're going to make a frame by frame comparison later on (probably will take a few more days) we're planning to build this thing in Flash Mx for more comfortable (easily switchable) frames comparison.

Stay Tuned :)

[Teegedeck]

I'm curious for the XviD sample - as I experimented a bit myself and was surprised that my initial guess was quite good - my standard settings except for using H.263-quant and R-D on this one. And the result didn't nearly suck as much as I expected. :p The outcome was quite foreseeable: XviD has got ringing problems and RV9 smoothed the colours a bit too much for my liking. Both isn't good, taste decides. I, too, would probably go for RV9 if it was for this sample and if I were crazy enough to encode at 350 kbps... :)

Excuse me if reading those XviD settings makes me wonder: I-frame bitrate-reduction but no I-frame boost? The reduction is only there to level the I-frame bitrate again after applying a boost (like boost:100%, reduction:50%). It doesn't make sense that way. Reading again, I see that this setting won't take effect anyway, as a min.I-frame-distance of 10 is applied, so there'll never occur any I-frame that receives a bitrate-reduction. And besides, without an I-frame boost, it's pretty unlikely that it will look like anything else but shite. ;)

Lumi-masking??? For anime at that???? That idea never occured to me, sounds a bit *dangerous*, but I will test it...

Edit: Thanks for the idea of performing that test, quite inspiring.

[bill_baroud]

I agree with midiguy :/

i watched only the RV9 sample and discover suprisingly an extract of Tachikoma Bonus ... now, i'm not even looking forward to the results of your test... the clear winner will be RV9, no matter you tweak the other codecs. I did some test some time ago, with Chobits Opening (so, like this sample, large & flat color pannel with no detail) and RV9 performed amazingly ... Why didn't you choose the CG-Opening from GITS (where xvid would perform very well imho :p )? or any part of the episode itself (for a more fair test)?

the second encode i tried on a badly encoded Samurai Deeper Kyo (with a lot of smog and mpeg block artifact) was absolutly terrible for RV9 ... your test sound like Apple G5 benchmark for me :/

I hope i didn't offense you (and i really respect your work) but i'm very disappointed by the sample choice. At least you should do it like doom9 on 2 or 3 differents sources.

[unmei]

@31 flavas: yes i meant virtualdub mod. But it was only "short notation" for saying "all the usual tools, including players and analysers etc"....but the more post from sirber i read, the more likely i will really install all the junk real wants me to (encoder, player)..*shudder* - just to see for myself. I think i will have to reinstall windoze soon anyway on this comp, so real stuff would be away again :D

i will rather test with DVD source and to 1000-1200kbit/s, as my xvids are in this region too

[Sirber]

I didn't choose the opening of GITS because I only have it in DIVX5, and the quality isn't very good...

[Teegedeck]

The problem with this source is that there are artefacts in the original already (it's DivX3.11 after all...). Now, should that codec be declared the winner which reproduces the artifacts best? This is only a theoretical limit to the value of the outcome, there's still some differences worth comparing, of course. Just wanted to remind you.

[Sirber]

The artefacts in the sources are minor IMO. I wanted this comparison to test how codecs will behave on low-bitrate, anime content. By that I mean sharpness and color.

it's pretty unlikely that it will look like anything else but shite.How can you judge an encode whitout seeing it before? I just watched Ramirez clip, and I'm surprised. It's much nicer than what I expected. The clip will be avalible soon. IMHO, at some place XviD is better than WMV9...

[Teegedeck]

I didn't want to insult Ramirez' work, I hope it didn't come across as such! It's only that I compared my own encoding with and without I-frame boost and the difference was really, really striking. As I said, I can't wait to see that sample.

[unmei]

in my experience Lumi-Masking is a low-bitrate feature. It tends to smear the black areas which isn't good for hi-bitrate but in low-bitrate it gains a lot which overweighs the negative effects and even reduces them, as the saved bits are used to reduce similar artifacts in the important areas of the picture . but for 1000-1200kbit/s it's not that good idea to use it, rather at 350 ;)

[Teegedeck]

The XviD sample actually looks better than I had feared, except for two instances where it really looses out - lumi-masking certainly was a bad choice.

[Sirber]

Originally posted by Teegedeck
The XviD sample actually looks better than I had feared, except for two instances where it really looses out - lumi-masking certainly was a bad choice. At which scenes?

Will redo the clip whitout lumimasking. We will compare whit and whitout, for fun, and keep the best one.

[Teegedeck]

The first one starts about at frame 1337 to 1460, the second one from 2055 to 2100; noticeable smearing introduced by lumi-masking.

To compensate for that, my own encoding looks worse in terms of ringing from 750-800.

Edit: While you're at it, could you redo it with Trellis-RD, quarterpel and a 100% I-frame-boost, and of course with min-I-frame-distance=1? ;)

[Ramirez]

Trellis based R-D where used in my first encode,I've simply forgot to mention it oops..
Anyway no probs, sirber will keep two links for a while, one is for my clip (as it) and another encoded exactly as you're proposing it.

[31 Flavas]

Originally posted by unmei

but the more post from sirber i read, the more likely i will really install all the junk real wants me to (encoder, player)..*shudder* - just to see for myself. Yes, its increadibly easy to bash Real, but please read a couple of threads first when you do reformat. We already had discussion on why RealPlayer8 sucks far worse (http://forum.doom9.org/showthread.php?s=&postid=331236#post331236), then the latest RealOne Player. Do not reinstall RP8. Please, I'm begging you! :) Also do read the How to make RealOne never bother you again (http://forum.doom9.org/showthread.php?s=&threadid=48179) thread.

i will rather test with DVD source and to 1000-1200kbit/s, as my xvids are in this region too Heh, if you are going to go in to that bitrate territory, don't forget to use anamorphic encoding (http://forum.doom9.org/showthread.php?s=&threadid=40572) in RVencoder or for that matter EHQ.

[Sirber]

Or he can use both, anamorphic and EHQ :D

[Ramirez]

@Teegedeck
Done...Hmm kinda hard to tell which one is better, my clip seem to retain more details and less crap around objects while encoded using your tips seem to be a little bit more sharper,(more artefacts also ;),anyway we'll compare both and as sirber said we'll keep the best one.

/edit
Those who like to D/L also the second clip (encoded using Teegedeck's corrections) please PM me or Sirber.

[Sirber]

I can't see much differences. We'll keep Ramirez's encode and start the comparison. A website will be developped with all the stuff on it.

[unmei]

my first test was kinda useless...
i took the same HuffYUV source as for my latest Xvid and happily hit the same filesize :) but on the CRT monitor i see absolutely no difference that would matter between the two codecs - i think the source is the limiting factor (DVD but older anime) or i would have to watch them on TFT, but i haven't installed real player on that comp..

Good for Real is i was able to watch a 720x576 video on my P3 600mhz with matrox card without any stutter or delay at all - this wouldn't work with Xvid :D

[Sirber]

What is U96?

[chepe36]

i remember that once enconding an anime with lumi-masking at low bitrates i created a strange artifact. but it was a big artifact it was like huge blocks (almost all of the screen covered with them) light gray blocks almost white, of course i had to reencode the clip this thing made it almost imposible to watch the clip.

anyway the point is that i think lumi-masking is not meant for low bitrates.

[bill_baroud]

What is U96?

It's the unmei beta USF Editor

[Dark-Cracker]

usf=universal subtitle file

[buba king]

350kb/s :eek:

You actually reencode 800kb/s files to 350kb/s! :eek: Anime deservs more bw man :P

Anyway.. if you want a REAL comparison i can provide small anime VOBs.

Cowboy Bebop R2
Berserk
Scryed
Mahoromatic
One Piece R2

[Sirber]

Anime don't deserve more than 450kbps, including sound, IMHO, when you use other codecs than DIVX3 or SBC.

[buba king]

Thank god not many ppl agree with you ;)

[Sirber]

lol :)

I don't want to waste like 20 CDs for a serie that I can recompress to fit on 3, at good quality. That's why this comparison is for low-bitrate anime encoding.

[Ramirez]

Originally posted by chepe36
i remember that once enconding an anime with lumi-masking at low bitrates i created a strange artifact. but it was a big artifact it was like huge blocks (almost all of the screen covered with them) light gray blocks almost white, of course i had to reencode the clip this thing made it almost imposible to watch the clip.

Hmm... Have you downloaded the Xvid clip I provided? Would you mind kindly point me out where exactly those terrible artifacts you're referring to might be observed?.:rolleyes: IMHO considering quite horrible source Xvid performed remarkably well.
Originally posted by chepe36
anyway the point is that i think lumi-masking is not meant for low bitrates.

Yes I know that "supposedly" Lumi-masking is not meant for a low bitrate stuff, (usually I'm not using it in a high/bitrate/ Q encodes also).I've used L-M in this particular anime encode because I needed those saved bits (crucial in such a low-bitrate stuff) that L-M preserves by applying more compression to the dark areas of the frame, and IMO this approach have greatly paid-off, as I said earlier IMO the overall Q is better with L-M ON then in one encoded with L-M OFF.

(Can anyone of the Xvid experts shed some light on this issue?)

[Sirber]

Originally posted by Ramirez
horrible source

I'll get vobs soon. We'll redo the comparison then.

[Sigmatador]

Originally posted by Sirber
lol :)

I don't want to waste like 20 CDs for a serie that I can recompress to fit on 3, at good quality. That's why this comparison is for low-bitrate anime encoding.

i think u need glasses :rolleyes:

[kastro68]

Originally posted by Sigmatador
i think u need glasses :rolleyes:

hahahahahahahahaha

[Teegedeck]

We should remember that - sady, sadly - many people out there like to soften their anime into an amorphous soft & cosy something before encoding it to DivX3.11... An ultra-soft, lowly-detailed picture seems to be a desired standard for those and has become a viewing-habit. It's more of a reason to cry than to laugh.

[Teegedeck]

Sirber,

although no-one here uses such low bitrates, it still was interesting for me to fiddle around with XviD, doing something that I would normally not do.

What bitrate do you aim for now? If it's above 1000 kbps, Ramirez could try dumping trellis in favour of MPEG-quant - subjectively sharper look, especially with Qpel.

[unmei]

*double shudder*
i finished my comparision at 450kbit/s same source as for the 1500kbit/s one (720x576)
xvid looks like confetti storm and rv9 like a washing machine in action. I think Sirber really needs glasses - at such low rates, at least with full resolution both codecs produced output faar from watchable.
Now you could tell me i had no experience setting the parameters right for low bitrates - that is true, BUT i know xvid enough not to screw it up that much only by my settings and for rv9 i used the "450kbit VBR download" audience definition which - being a preset from real - should not be that far off the good values.

i guess this is my last test for such low bitrate for some time, i will return to my 1000+ kbit/s (or a /little/ lower, i have to reevalute my lower limit for xvid with 24/6 i think :)

[Sirber]

So you used the old GUI, with no EHQ? lol. You could also use XviD stable and MPEG4v2 for your comparison. :angry: Who need glasses?

[Sirber]

Comparison closed.

I won't loose my time for you anymore guys.

[edit]

my bandwith also

[Dark-Cracker]

sorry for this off-topic but i always have think this forum was here to exchange some knowledge and not to criticize other people.

i can understand that sirber want to encode it's anime at low bitrate (does this made me a very very tolerant people ?) are u here to judge it's encode ?

i can't understand answer like :

"poor anime :( ..."
"Thank god not many ppl agree with you :)"
"i think u need glasses :rolleyes:"
"hahahahahahahahaha"

but perhaps can u explain me where is the interest of such answer ?

[Lefungus]

IMO, this comparison was biased since the beginning.
Not because of low bitrates but because of the source.
Divx 3.11 at 800 Kbit/s IS low-quality.

But i'm still interested in a comparison, this time with a high-quality source and a wider range of bitrates like one at 350 and another one at 800.

[Sirber]

I was about to get a VOB of Cowboy Bebop and restart the whole thing. Those last posts (except D.C.) killed my mood and I'm not interrested anymore to do a comparision for public purposes.

[Teegedeck]

Well, it was not all for naught. Some of us have viewed the samples, tried to encode to the best possible result ourselves, and learned something.

[Sigmatador]

@Dark
"poor anime :( ..." --> i really thought that
"i think u need glasses :rolleyes:" -->i was just kidding
"hahahahahahahahaha" --> so my stupid joke make laugh someone: good news :D

@Sirber
"lol. You could also use XviD stable and MPEG4v2 for your comparison. Who need glasses? "
(repeat: i was just kidding) I didn't say that rv9 was not the winner, no doubt at this bitrate it was. but i just want to say: "with this bitrate, you can't get good encode, just acceptable one" and for a big anime fan, store anime a this bitrate it's a "sacrilège" :p ( only 50% of kidding ;) )

i thought it was a "codec fight" for the "less worst encode" and not a test for low bitrate storage. So i stop my stupid joke, but i think your question is useless: at this bitrate Rv9 will surely win! (Versus XviD) now maybe you can compare to wmv9 (i think rv9 is still better).

Sig. wait for a good h.264 implementation to join this lowbitrate fight :devil:

[kastro68]

Sorry.

I didn't mean to make anyone mad. I just thought that a little laughter would help lighten the mood.

It is well documented that those who are optimistic live significantly longer.

[TheXung]

I wasn't going to say anything but decided that I will now. The problem with this comparison is that it is biased. I will not comment on the low bitrate because everyone has their preference and I will respect that. The problem I do have with this comparison is that no where have I ever seen anime with such a white background. And what else will shine on clips with such a white background than a codec with in-loop filtering. Of course Real should win in it. And it's obvious why ramirez used lumimasking on the encode; it was to hopefully increase the quantizer around the white background. Of course, no one hardly touches the lumimasking code these days, that I doubt it actually still functions in that way anymore. Not only that, but the 2-pass algorithm in xvid has curve stabilizing logic in it to compensate for the instable behaviour that it exhibits. However in this clip, where every other frame should have been decimated, the curve stabilizing logic prevents the quant from rising steeply for the repeated frames. In summary, there are areas where Xvid could be tuned for this clip, or a more respesentative clip should have been chosen, or this clip was chosen to exploit these deficencies of the codec that don't normally show up in most clips. And what was up with the interlacing artifacts?

[midiguy]

Originally posted by Lefungus
IMO, this comparison was biased since the beginning.
Not because of low bitrates but because of the source.
Divx 3.11 at 800 Kbit/s IS low-quality.

But i'm still interested in a comparison, this time with a high-quality source and a wider range of bitrates like one at 350 and another one at 800.
Also a more common, more challenging source. RV9 has a tendency to blur out backgrounds and save a lot of bits for the foreground (which often DOES pay off). But for this type of clip that has a completely white background (a very uncommon clip too...), it isn't really a fair test. Still was fun though.

[karl_lillevold]

I am writing on this thread partly because it seems there are some visitors that have followed only this thread, and not so much the other discussions that have been going on in the New A/V Formats forum.

There has been some good feedback and encouraging words, but it is sad to see many criticizing Sirber and Ramirez' work, even though it may take the form of jokes that are not really meant to hurt. Comparisons at any bitrate with any source are great for learning. They involve a lot of work, doing all the encodes with the best settings. Even though you like to use much higher bitrates for your encodes, have respect for other opinions and preferences, and the hard work done here. Hopefully, the responses here will not scare anyone from trying other types of clips and bitrates. I think the results are very interesting and motivating, and is part of the reason for the work I started on RV9's Animation DropDupe pre-filter (http://forum.doom9.org/showthread.php?s=&threadid=56564), to see if even further improvements were possible. Thanks to Sirber and Ramirez!

It is hard to find good source material. Sirber picked a clip he likes, that is pretty clean, even though it is pre-compressed. It is a simple clip, with few objects moving, and it is easy to make comparisons. I had never experimented with RV9 on such clips before Sirber pointed me to one. Interestingly enough, RV9 without EHQ looks bad on this clip, and is just not worth trying except to see the improvement possible with and without EHQ. So forget about the old Helix Producer GUI with 450 kbps VBR audience. This is 'dead' (it is possible to use the GUI though, with a DLL replacement and a reg key to enable EHQ. see this link for RV9-EHQ info (http://forum.doom9.org/showthread.php?s=&threadid=55193))

Without talking about winners or losers, all codecs have strengths and weaknesses. Some codecs handle noise well, some have no ringing or blockiness, some excel at very high bitrates, some prefer clips with large amount of grains, some have options that can be tweaked just to your preference, some are open source, some are not. No comparison will be completely fair.

I was very impressed with the XviD result at 350 kbps. It is clear significant improvements have been made, just like RV9 has made lately with EHQ. So congratulations to everyone involved in XviD development, good work! This is very motivating.

With EHQ and DropDupe, partly motivated by Sirber's comparison, check how a 250 kbps version (http://www.lillevold.com/files/T03_RV9_EHQ_DD_2pass_250kbps.rmvb) looks pretty close to Sirber's 350 kbps version. So as you can see, for RV9, 350 kbps is almost too high a bitrate for this clip, since the improvement is already tapering off between 250 and 350 kbps. Personally I think comparisons where the bitrates are so low the codecs have to struggle a little are the most interesting. After all, codec development and improvement is partly about lowering the bitrates and improving the video quality. The clip used here should not really require a very high bitrate to look good. Other clips, yes, require a lot more.

If you do compare RV9-EHQ at much higher bitrates, and it does not fare as well as in this comparison, that would be great feedback I would use to focus on future improvements, and not be upset over the results. Please do not just rehash what you have heard. Take the time to try yourself, using the latest tools, encoders versions, and recommended settings from the main RV9 info thread (http://forum.doom9.org/showthread.php?s=&threadid=40392). For instance, at 1000 kbps or higher, native anamorphic encoding (http://forum.doom9.org/showthread.php?s=&threadid=40572) is almost a requirement for RV9.

So, now it's time for you to beat me up :eek:, instead of Sirber.

[RadicalEd]

fffffffffffffffff.
gah, I'm doing a large scale comparison as soon as I get the clips I need. I'll make sure to try a bunch of different bitrates and get up a site full of detailed results/analysese.
I love having no life.

[Sirber]

All those words made my heart heavy and my prostate weak :D

I got 2 vobs from buba king, 2 vobs of Coybow Bebop, I may restart a new comparison with a MPEG2 source, not sound, maybe at 450kbps. I'll discuss with Ramirez and get you posted.

Also, I'll reactivate old links for the 350kbps version.

[edit]

BTW, it's hard to read bashing and flaming when the brain just woked up...

[Sirber]

The source will be a 3 minutes, 10mbps HUFFYUV source from a MPEG2, ITVC by VDub. I'll upload that clip to Ramirez (1.6 Go) but I cannot distribute it. The crop + resize will be done by AVISynth.

More infos to come

[edit]

VDub ITVC isn't good enough. I'll use decomb. Huffyvu is quite bit also. I'll try the MPEG2 I-Frames and LOCO codec, both looseless, to try to get smaller filesize.

About LOCO4

LocoCodec is a lossless/lossy codec.

Installation:
Unzip the files in a temporary directory.
In windows explorer, right click on "lococodec.inf" and choose install.
You can now delete the unzipped files.

Summary:
- Lossless file size if about 70% of Huffyuv
- lossy can decrease file size another 10-20% percent
- about 1/4 the speed of huffyuv :-<
- Stores YV12 natively
- GPL: (C) 2003 Mohammad Rezaei

TODO:
- Performance.
- calcLoco can be vectorized. Part of comp_one_pel can be vectorized.
- riceEncode can not be easily vectorized.
- unlikely to be made more than 50% faster
- YV12:
- conversion to YUY2 and RGB after decompression
- interlacing
- is there a flag indicating interlacing in the incoming images?
if so, store it.
- a quick test showed that unless most of the video is highly combed,
it does not make sense to compress fields separetely.

[Sirber]

Originally posted by TheXung
And what was up with the interlacing artifacts?
Where?

[midiguy]

hey sirber, there are some special anime settings that you can use for decomb. The default ones usually (sometimes) work okay, but sometimes you can tweak them a little to get the best results for a specific clip (with usualyl little to no tweaking required). I am a little out of date with the whole anime ripping scene, but I am sure someone on this forum has awesome anime decomb settings.

[TheXung]

Originally posted by Sirber
Where?

Properly matched fields should not exhibit these stairstepped lines.
http://www.people.virginia.edu/~xn4f/image2.png

This is the result of incorrectly matched fields that have been filtered. What annoys me about this source is that it was encoded with practices that I would never do. Subtitles should be in a text based file, not make up half the complexity of the frames. The repeated frames should have been decimated. Which coincides with proper field matching. I'm aware your source was downloaded, but most of us do not recompress already heavily compressed sources.

The tricky part about doing a comparison using anime as the source is that the deinterlacing and frame decimation has to be done perfectly otherwise, it is not the core of the codec being tested but rather how it's 2-pass counterpart can cope with the abomination of a video source.


On a side note, if that dropdupe filter can tap into the variable framerate of the real media container, then it is the answer to cartoons that I have been waiting for.

[Sirber]

As you can see, my goal wasn't to do a comparison based on a perfect "with no error" source, but on reencoding a already encoded, downloaded, subbed, easy to find anime source, at 350kbps, to see how codecs will react with it. That's my goal: to see how codec react with the source.

About the picture, I can't see any interleaced stuff in those two squares, only a bad zoom. Interleace is always on moving parts, when there is motion, not on those static dead tachikomas.

[Ramirez]

@TheXung
Hi, thanks for replay, here are some PSNR test results; one is for clip encoded using lumi-masking ON, and the second OFF (the rest of the settings unchanged)

L-M ON---- PSNR: -------- 33.8384 42.9531 58.8898(dB)
--------------------------------------------------------------------------
L-M OFF--- PSNR: -------- 35.8097 43.1208 60.5941(dB)

There is obvious drop in PSNR which is exactly what I hopped for in this particular anime encode, so I guess L-M still working exactly as it's supposed to work (I might be terribly wrong though, plz leave your comments :))


@RadicalEd
LOL! :D By all means, go for it! You'll see how much of the plain nerves and time involved in creation of such comparison (I know it for a fact, already being there ;)

[Ramirez]

@Forum
Please keep your comments constructive, this is so discouraging reading some of your posts here, please remember we're mainly doing it for fun,plz don't turn it into "religious" war.

Thanks! :)

[netterpaladin]

@Sirber

great to hear you will continue your comparison! I think this thread was popluar judging by the amounts of replies and views. I think many people will at least consider real again (like me too).

Concerning the low bitrate. For storing and backupping your own DVDs, I think everyone would prefer higher bitrates BUT for the internet the lower is still the better.
When I think of these small, really bad anime (real,asf) one could download long ago..... We actually might see small and good looking ones in the future.

Daniel

[Sirber]

You can already see small and good encodes, just take a look at Karl's 211kbps clip. IMO, modern MPEG4 can't beat that even at 600kbps, for that kind of clip.

[edit]

Corrected a lot of spelling errors:rolleyes: My keyboard is tired:rolleyes:

[karl_lillevold]

here is the RV9-EHQ-DropDupe 211 kbps version (http://www.lillevold.com/files/T03_RV9_EHQ_DD_2pass_211kbps.rmvb). Link in earlier post was to 250 kbps version. Did not want to go too low at first :) If you already got the 250 kbps version, no need to get this one. They're pretty close.

[TheXung]

Originally posted by Ramirez

There is obvious drop in PSNR which is exactly what I hopped for in this particular anime encode, so I guess L-M still working exactly as it's supposed to work (I might be terribly wrong though, plz leave your comments :))

My line of thinking was that quants should have been upped for the white background as well as the black background during the credits. However, I'm still not sure if it was doing that during the scenes with the white background because ffdshow wasn't showing a fractional average quantizer when I played it back during those scenes. However I'm not sure which version I have installed (cvs or koepi's). Whatever it is, I guess I'll try it out again after my machine frees up.

[Teegedeck]

If it's Koepi's build, 'lumi-masking' refers only to psychovisual code by ReferenceDivX that acts similar to an HVS-quantizer. No adaptive quantization is performed then.

[RadicalEd]

Originally posted by Ramirez

@RadicalEd
LOL! :D By all means, go for it! You'll see how much of the plain nerves and time involved in creation of such comparison (I know it for a fact, already being there ;)

Hey I've already done a good 5 or 6 significantly large comparisons in my day :cool: but with all this cool new stuff like EHQ and the constant XviD upgrades it's about time to do a big all inclusive one, and it's summer, I'm just a kid with a part time job, I've got nothing better to do :D
It's more constructive than surfing forums all day anyway :P

[Sirber]

surfing forums and doing tests is the best way to learn.

[temporance]

Well, this thread has certainly awoken some encoding ogres!!! And we've had some good debate and exchange of opinions. I admit to downloading Sirber's source material and trying to beat the encode quality. When doing this I had an idea: How about an encoding competition?!?!?!

All we'd need for an ongoing encoding competition would be a server and some bandwidth somewhere.

This way, more people get involved and more settings get tried out, more gets learnt. If developers at xvid/divx/real get involved, then we get better codecs out of the process.

So we just need a few short, high quality, low res but sharp, clips in huffy or high-bitrate lossy compression that can be our source. Preferably clips with no copyright issues.

The someone sets the tasks: e.g. best quality at 400kbit/s, and we go for it!

Anyone like this idea?

[Sirber]

yeah, sounds great. but it will be long to review all 2 000 000 clips :(

[Sirber]

Clips are being encoded...

Targeted bitrate: 450kbps

[thejho]

Hey !
sounds like a great idea !
Go ahead, I'll be the referee :D ! :devil:

[Sirber]

RV9, WMV9 and XviD are done, but maybe XviD will be redone.

Stay tuned!