View Full Version : Codec Fight! Animes encoding
Sirber
26th June 2003, 02:54
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
26th June 2003, 03:36
Nice Work, I hope Xvid wins!
unmei
26th June 2003, 05:23
: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
26th June 2003, 08:11
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
26th June 2003, 11:06
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
26th June 2003, 11:56
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
26th June 2003, 12:44
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
26th June 2003, 13:12
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
26th June 2003, 13:18
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
26th June 2003, 13:26
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
26th June 2003, 15:11
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
26th June 2003, 23:08
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
27th June 2003, 01:48
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
27th June 2003, 02:27
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
27th June 2003, 03:18
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
27th June 2003, 12:25
The only way to get more than 3 on a CD... :)
Latexxx
27th June 2003, 14:03
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
27th June 2003, 23:42
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
28th June 2003, 04:17
IMHO, VP3 is dead. Also, all clips have the same size. I don't know why it's in 640x480 on your computer...
midiguy
28th June 2003, 07:47
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
28th June 2003, 09:55
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
28th June 2003, 10:12
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
28th June 2003, 13:06
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
28th June 2003, 13:37
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
28th June 2003, 13:52
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
28th June 2003, 14:22
@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
28th June 2003, 14:28
I didn't choose the opening of GITS because I only have it in DIVX5, and the quality isn't very good...
Teegedeck
28th June 2003, 14:31
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
28th June 2003, 14:44
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
28th June 2003, 15:01
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
28th June 2003, 15:04
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
28th June 2003, 15:21
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
28th June 2003, 15:22
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
28th June 2003, 15:31
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
28th June 2003, 16:34
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
28th June 2003, 16:42
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
28th June 2003, 17:01
Or he can use both, anamorphic and EHQ :D
Ramirez
28th June 2003, 17:26
@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
28th June 2003, 18:01
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
29th June 2003, 03:24
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
29th June 2003, 03:33
What is U96?
chepe36
29th June 2003, 06:35
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
29th June 2003, 07:23
What is U96?
It's the unmei beta USF Editor
Dark-Cracker
29th June 2003, 13:17
usf=universal subtitle file
buba king
29th June 2003, 16:32
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
29th June 2003, 16:35
Anime don't deserve more than 450kbps, including sound, IMHO, when you use other codecs than DIVX3 or SBC.
buba king
29th June 2003, 16:37
Thank god not many ppl agree with you ;)
Sirber
29th June 2003, 16:40
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
30th June 2003, 02:33
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
30th June 2003, 02:51
Originally posted by Ramirez
horrible source
I'll get vobs soon. We'll redo the comparison then.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.