Divx 5 on anime

[Zarxrax]

Today I ran a test on Divx5 on the anime Read or Die, episode 3. A few weeks ago I made a nice SBC encode which is almost perfect, except for some blocks in the subtitles. Here are the settings that I used for divx5:
-b22 1250 -key 200 -log "c:\divx.log" -mv "c:\mvinfo.bin" -b -g -q -dr 6,2,2000,10,20 -sc 50 -pq 5

I set the bitrate a bit higher than I did on my SBC encode since everyone is saying that their encodes come out too small. The Divx5 encode ended up about 20mb larger than the SBC encode. Now, I really cant see any difference in the quality of either of them, whatsoever. The divx5 may look better in some parts, and the SBC better in other parts, but overall I'd say they are equal. Now this was a bit disappointing, as with claims like its supposed to be 40% better than sbc and such, I was not expecting equal quality!

Also, divx5 files dont seem to display the frames properly in Virtualdub. If I seek using the keyframe buttons, then it will show completely wrong frames. If i seek any other way, the actual frame it displays is about 2 frames behind the same frame in the SBC encode. My friend has said the same thing happens with him, and he has also tested without B-frames, and the same thing happens. If im not gunna be able to use vdub properly with divx5, and it gets similar quality to SBC, I dont think I'm gunna be changing over quite yet...

[Kyo]

What setings do u use in the past encode and what bitrate besides what codec 3.11 or 4, also do u use filters(smart smother... etc)?
Personally i love the 3.11 on anime the results are great!

Divx5 seem to work well but in especific resolution or bitrates
(testing it...)



___
Kyo

[Zarxrax]

Filters used on both were 2d cleaner and temporal cleaner.

Heres my nandub profile from the SBC encode:

VirtualDub.video.SetDepth(24,24);
VirtualDub.video.SetMode(3);
VirtualDub.video.SetFrameRate(0,1);
VirtualDub.video.SetIVTC(0,0,-1,0);
VirtualDub.video.SetRange(0,0);
VirtualDub.video.SetDivX(1200,10);
VirtualDub.video.SetQualityControl(2,15,28,0);
VirtualDub.video.SetMotionDetection(8,10,300,300);
VirtualDub.video.SetCrispness(30,0);
VirtualDub.video.SpaceKF(24);
VirtualDub.video.InternalSCD(96);
VirtualDub.video.SetMinKBPS(460);
VirtualDub.video.SetCurveFile("C:\\vidfiles\\ROD3 VOB\\rod3.stats");
VirtualDub.video.SetCurveMcFactor(20);
VirtualDub.video.SetCurveCompression(15,3);
VirtualDub.video.SetCurveFilter(270,2600);
VirtualDub.video.SetCurveCredits(0,350);
VirtualDub.video.SetLumaCorrectionAmp(1,10,30);
VirtualDub.video.SetCurveRedist(1);
// VirtualDub.video.CalcCurveCompression();
VirtualDub.video.SetCompLevelsMain(2,4);
VirtualDub.video.SetCompLevelsA(300,3,16);
VirtualDub.video.SetCompLevelsB(300,4,16);
VirtualDub.video.SetCompLevelsC(300,5,16);
VirtualDub.video.SetCompLevelsD(300,6,16);
VirtualDub.video.SetCompLevelsE(300,7,16);
VirtualDub.video.SetCompLevelK(2,4);
VirtualDub.video.SetBitsReservoir(2,35,30,70,45,0);
VirtualDub.video.SetLowBrCorrection(0,0);

[Kyo]

Nice Nandub Settings ;)

If you use 2 clean filters the video get "very clean" -> compress very well, besides if you use preprocessing in divx5(?) this could clean the picture, but also the encoding with sbc at that bitrate
should be really good for a 25min of video. And you try to compare without filters? or use a more detailed reziser(sharp bicubic)?



___
Kyo
Sorry the English :o

[Wyldchyld]

I'm currently encoding Ghost In The Shell, and i've now done a good 8-9 full length test rips, most of which w/ 3.11A +Nandud & +VDub, some w/ 4.12 +VDub, and one w/ DivX 5.0Pro +VDub. Note: all rips used the same resolution & same filtering processes. Taking the nicest overall rips w/ 3.11A & 4.12, and the one 5.0Pro rip, the respective bitrates/filesizes for them were:

- 3.11A: 1025Kbps, 622MB (Nandub)
- 4.12: 1050Kbps, 626MB (VDub, 2-Pass)
- 5.0Pro: 1250KBps, 600MB (VDub, 2-Pass w/ all 3 MPEG-4 Tools but neither new psycho-whatever, luma-something, or noise filtering).

I'll be totally honest, the DivX 5.0 rip looks noticeably nicer, that's for dead sure. The 3.11A & 4.12 rip times were roughly the same though, around 8.5-9.0 hours (~4-4.5 hours per pass, due to heavy filtering). DivX 5.0Pro was 8.0 hours on the nose, making it about 8-10% faster than the others (see PC specs below). Oh, I'm using the latest versions for Nandub (1.0 RC2)& VDub (1.4.9), as well as for all the plugins/filters used, in case you wanted to know for reference.

On the plus side, DivX 5.0Pro handled solid colours on low-motion scenes really well, surprisingly in fact; the embedded IVTC/Deinterlace tool, meh... i'll stick to Decomb or GreedyHMA or IVTC4 or TMPEG, LoL! The denoising filter, not bad at all if i wasn't going to have any post-processing, which isn't much of an option for high-quality anime rips unless you have a flawless source (I.E. scans of the original animated stills, LoL!). The psycho-whatever filter, no change there. The luma-something filter, pretty darn neat but i didn't really feel i needed it here, more testing is required. The 3 new MPEG-4 Tools? Brilliant, in my opinion, they really cut down on filesize during my tests, without compromising quality. Overall processing time? W/ heavy filtering, little difference, like i said 8-10%. Without, however, i did experience a larger decrease, maybe 15%, and i'll take any percentage off i can get!

So far, w/ only one movie and not having decided on final ripping parameters for this movie, my impressions are favorable, even if i'm still heavily experimenting w/ AVISynth scripting and hesitating as to which ripping method is best. I'm happy w/ DivX 5.0 Pro so far, but i still hope they'll keep improving it over the months/years to come!

Wyldchyld :devil:
Current project: Ghost In The Shell, Dubbed&Subbed, ~700MB, (Haven't decided on a codec yet), 608x336.

[OUTPinged_]

2wyld:

hmm, GiTS, i have encoded that one :-)

some thoughts on that and an advice which may prove usefull:

try to encode it with divx5 at 640x resolution and using most strict bucubic resize. cap drf's at 2-8 and enable b-frames and GMC.

a movie like gits will gain _really_ much from b-frames, and encoding it only at 608x is evil =)

please try to make a sample that way and check if overall picture quality got any better.

b-frames are a godsend to anime encodes, i am getting up to 30% filesize reductions on some episodes O_o

[Wyldchyld]

@OUTPinged_: Those were the exact settings i'd been using actually, :) No foolin'. I was even considering lowering the bitrate since 1250 is alot already for GITS, and using 2-6 or 2-7 DRF's. I ran several samples in 640x352, and they didn't look quite as nice as the 608x336 ones obviously, but i'll give it a try overnight :) Mind if i ask how you ripped GITS originally? And yes, b-frames (the way i understand them) rox0r for anime, i totally agree!!

Wyldchyld :devil:
Current project: Ghost In The Shell, Dubbed&Subbed, ~700MB, (Haven't decided on a codec yet), 608x336.

[OUTPinged_]

It was encoded @800x using nandub and did fit 2cd nicely with two audio tracks(yes, i'm a "quality" freak). i was asked to make dub+sub, but i couldnt fit it @640x into 1cd with decent audio and video.

800x was used because i believe that watching the movie at it's original resolution looks best, and 640x movie was taking only 1150mb @70% first/second pass (i dont like to go over that in divx3 encodes).

The movie was extremely well compressable. the bad thing is, it looses too much small details at lower resolutions and i personally wouldnt go under 640x even if i'd have to use neutral/soft bicubic.

and here is one more thing.

it looks like high drf levels in divx4/5 look better than in divx3. and you cant just be even 50% sure that if a frame has drf8, it looks bad in motion.

it is bad there isnt a way to automatically measure quality of each frame and make a easy to read statistics for it. for divx311 you could be sure that 5 or lesser drf used give good quality, 6-8 gives tolerable and higher one's give crap. so quality checking was easy. you get your drf statistics with drf analyzer, checked frames with high (5+) drfs and then could just watch a result once and encode did turn out with blocky looking scenes rarely (fixing bad places with manual drf placing).

for divx4/5/xvid content you can only tell the encode did turn out well if you'd watch the entire encode O_o

and there is no antishit to report at least PSNR of each frame with dbview.

i dropped into a xvid forum with that issue, but my ritorical skills suck (i thought just imoplementing all the features of nandub will do the trick) and these guys kicked my ass =) guess i have been just way too rude :/

[Zarxrax]

I reencoded with Divx5 now, this time setting minimum quantizer to 4 and disabled quartar-pel. This time, it looks just a bit better than the first encode. For the most part, quality is very similar to the sbc encode, except in scenes with fast motion. In the scenes with fast motion, the divx5 encode looks much worse than the sbc. Does anyone have any idea for what settings I could change to imporve the fast motion scenes, and what values i might wanna try?

[ThePanda]

Does anyone else notice halo color effects with divx5? Maybe it is my source.. I also get playback slowdown with postprocessing enabled.

[OUTPinged_]

zarxrax:

dont set min drf to 4. it has to be set to 2 to make your encode look good in lo-mo scenes.

you can set max drf to 5-8, it gives out better results than setting it to 31.

vanilla divx5 isnt suited to produce stable results on anime encodes. the codec is good but more control over bitrate/drf is required :-(

waiting for divx5log =)


panda: thats strange. i dont get any halos even w/o postprocessing. maybe reinstall the codec?

[Zarxrax]

Im sorry, I meant to say that I changed my MAX quantizer to 4.

And yeah, Divx5 does have a color problem, which you can see in these images I made here. Noteice How there is white along the edges of the subtitle in Divx5.

[Zarxrax]

Hrmmm, my attachments dont seem to be appearing.
Try these links:
ftp://zarxrax.kicks-ass.net:8882/divx3.png
ftp://zarxrax.kicks-ass.net:8882/divx5.png

[The People's Elbow]

OUTPinged_ wrote:
b-frames are a godsend to anime encodes, i am getting up to 30% filesize reductions on some episodes
- Can't agree with that completely...my testing objects are DragonBallZ Episodes and as you probably might know there is long time happening nothing in the picture, but when they start fighting...the nightmare begins. In this case, if a long fighting scene appears, the b-frames give less quality instead of more :( , B-Frames are no cure-all for video compression, at least not in the way they are used in DivX5 with it's IPBPBPB scheme. Just want to say that B-frames can do very good on animes, but also...well...may suck! Depends on the source I think, if it's more low-motion or fast-motion!

[Wyldchyld]

@Zarxzax
What Sub plugin are you using, anyway?

Wyldchyld :devil:

[Zarxrax]

Avery Lee's Subtitler filter.

[OUTPinged_]

2Elbow:

that is strange. the only drawback of b-frames is an excessive cpu load. i have tested some extreme motion scenes too but havent seen any degradation in quality.

people, dont use 2-4 drf range. it is evil. drf4 may look good as static picture but in high motion scenes your cpu will be loaded at 100% and will produce actuallly _worse_ quality picture than even drf8.