Codec Fight! Animes encoding

[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!