Aloha!

[krtek]

Originally posted by arno
Does anybody have any recommendation what settings to use for encoding credits. I haven't got the slightest idea what weight-factor is reasonable or what my old XviD api-3 codec's default quanitizer for credits is.
I tried to use fixed quantizer to 16 and cartoon mode enabled and it looks acceptable (titles was static- not moving)(some another option enabled too,grayscale, b-frames to 5. etc.)
for credits (i mean clasik credits white on black) is cartooon mode ideal. You must try it.

[Sigmatador]

nobody cares about the 0.2db loss with xvid decoder :confused:

anyway here's a test with the b-vop sensitivity (decoded with divx511)

NOBVOP: 45.5255 47.8518 57.4761
Sen+00 : 45.5070 47.9361 57.5104
Sen-10 : 45.5070 47.9561 57.5104
Sen-15 : 45.4220 47.9566 57.5104
Sen-20 : 45.6184 47.9207 57.4417

i don't understand how the min PSNR can loss db while the average increase (some weird IPB decision maybe ?? )

[powerslave]

Originally posted by Cyfer
Firstly I'd like to thank Koepi and all xvid team for this wonderful codec!!!!
I'm having a little problem with this new build. I can't perform a compressibility test using Gknot.I mean when I perform a compressibilty test, no numbers appear at the bottom of the Gknot page.I tried all the other previous builds but they all work fine. what am I doing wrong here? has anyone had this problem too??

According to lenox in the g-knot forum, since configuration for old xvid is different then for the 1.0 beta, he cant put compatability into g-knot for both. He did mention that he guessed that when 1.0 becomes official, he will change g-knot to support it. Until then, either use old xvid with gknot, or use the beta without it.

[sapient]

Can someone explain in detail and suggest the recommended values for the new overflow settings of the second pass? Since previous versions of xvid did not have these options, I am a bit vague about their usefullness. I am talking about the "max overflow improvement" and "degradation" and the "overflow control strength". Could you give some examples when changing the default values would be beneficial?

[cweb]

Originally posted by cweb
My encodes are simply a black screen when virtualdubmod encodes to a Matroska file. When it encodes to avi it's ok... The speed was around 90fps, hope I saw that correctly as it seems much faster to me than dev api 3 - amazing.

Will now try muxing from avi using some other tool to see what happens...

Thanks to Koepi and everyone else involved...

Merging with mkvmerge works, so it's a problem with Virtualdubmod...
I'll use mkvmerge for the time being until vdubmod gets updated...

[mf]

Originally posted by iago
And believe me it is sometimes very possible not to get the codec to be saturated with a bitrate of even 2000kbps... :D
I encoded a psychidelic anime opening at a stunning saturation of 12000kbit/s, with a recent api4 build.

[iago]

I encoded a psychidelic anime opening at a stunning saturation of 12000kbit/s, with a recent api4 build.

He he!
That's exactly what I'm trying to explain for a long long time! ;)

Btw, mf, perhaps you should consider updating your recommended settings under your signature to avoid any possible confusion, particularly for the new users. I guess they (especially the ones for b-frames) are based on latest dev-api-3 build by Koepi and no longer apply to the beloved Aloha build, do they? :p

regards,
iago

[Hoschi]

Hi,

I did some DVB-encodes (full movies) with b-frames @default and qpel - they look awful in scenes with large areas of one color, like wallpapers, sky etc., and smoke is even worse. Without qpel aloha works perfectly, a really good job ! The reason are little distortions in the original mpeg2-file, so this is not a bug, but proves qpel ist actually working :-)

But the target filesize does not work. With qpel it seems as if ogm overhead has been calculated (about 1-3 MB smaller than expected), without qpel I get avi overhead (5-15 MB smaller files). Is this a feature of future version or a bug ? When I calculate the overhead for movie lenght with gknot and add it to target filessize I get a file suitable for my ogg-streams. Tried this with 3 movies.

[mf]

Originally posted by iago
He he!
That's exactly what I'm trying to explain for a long long time! ;)

Btw, mf, perhaps you should consider updating your recommended settings under your signature to avoid any possible confusion, particularly for the new users. I guess they (especially the ones for b-frames) are based on latest dev-api-3 build by Koepi and no longer apply to the beloved Aloha build, do they? :p

regards,
iago
Good idea. It's updating time :D.

[wannabe]

I did some DVB-encodes (full movies) with b-frames @default and qpel - they look awful in scenes with large areas of one color, like wallpapers, sky etc.

Yes i can confirm this also, and yes it more bad if the source wasnt perfect already. The default settings for B-frames 2/1.50/1.00 together with Quarterpel creates some exaggerated "vibrating" effect. I made some tests with previous build(24062003) for comparison. Here are the detailed results:

Aloha build:
-Quarterpel + B-frames at 2/1.50/1.00
filesize= 9,936,896
Vibrating effect: Yes, on flat areas it looks very bad.

-Quarterpel + B-frames at 2/1.50/0.75
filesize= 10,696,704
Vibrating effect: A little

24062003 build:
-Quarterpel + Bframes at 2/150/100
filesize= 10,252,288
Vibrating effect: A little

-Quarterpel + Bframes at 2/150/75
filesize= 11,442,176
Vibrating effect: No.

Conclusion: Aloha compresses B-frames more than previous build. If you want to get rid of it use Quantizer offset 0.75, it has about the same look as 24062003 build at 100.

Try it with Quantizer offset of 0.75, and see if that helps, it helped for me.

[wannabe]

Okey i think i have found something, that i mentioned before but now i have proof against, GMC.

I made two 2 Pass encodes of a movie with the same settings, the only difference was the the usage of GMC. I analyzed them with DRF Analyzer, got an avarage DRF of 3.496 for the GMC one, and 3.517 for the one without GMC.

The Max DRF of the GMC one was 25, the one without, was 7. Altough there werent too many frames above 7 in the GMC one as well, so even if this is a problem its kind of minor. If i understood well GMC's usage, its good for creating S-frames, thats more compressible, but i see these few ultra high quantizer frames as a side effect not unavoidable. If there is an interest i can post the full DRF Analyzer reports.

- Note: This phenomenon only reproducable with LONG (90 minutes) encodes, not few minutes ones.

[Chainmax]

syskin: what you told me about Trellis applies to b-frames as well?

How exactly can you tell if you're saturating the codec? Sorry if I'm being annoying, I'm only starting to actually explore XviD's options...:o

[Manao]

@Chainmax : You're saturating the codec ( at a specified setting ) if your second pass size is almost the same than the first one. To desaturate, either change the quant matrix ( H263 to MPEG, or even Andreas's one ), or don't use b-frames, or treillis ( EDIT : in case your already using MPEG quant ), or anything that trade quality for size ( but which are great in unsaturate cases )

@sysKin : thanks, I'll wait ( not long I guess, you seem to work harder than ever )

@wannabe : did you find the frame at quant 27 and does it look horrible ?

[wannabe]

Manao: well is there any program that would tell me where can i find a specifig quant frame ?

[loni_blues]

Hi,
I am having a problem - may be a silly one - but I am afraid I cannot find how to modify the brightness of the encoding with the Aloha Xvid decoder. Where are the settings?
Thanks,
loni_blues

[P0l1m0rph1c]

Originally posted by wannabe
Manao: well is there any program that would tell me where can i find a specifig quant frame ?
Open the stats file and search for quant 27, then you will have that frame.

[Manao]

wannabe : no ( well, I can't think of one ), but you can do a psnr test on all the frames, and search for the lowest one ( or the lowest ones ), you should get all the high quant frames

P0l1m0rph1c : no, in the first pass statfile, there are only quant 2 ( and 2,3,4 for b-frames, and higher for credit )

[wannabe]

Ohh it would have been good, but too bad i already deleted the stats file for the previous encode... :/// but i guess a quant 25 frame can not look good. Anyways here is an excerpt from the DRF reports:

For the GMC(3.496 avarage, 25 Maximum ) one:
DRF=1&2: 4274 3.1%
DRF=3: 67182 49.0%
DRF=4: 59302 43.2%
DRF=5: 6458 4.7%
DRF=6: 13 0.0%
DRF=7: 2 0.0%
DRF=8: 3 0.0%
DRF=9: 0 0.0%
DRF>9: 5 0.0%

For the non-GMC(3.517 avarage, 7 Maximum) one:
DRF=1&2: 3854 2.8%
DRF=3: 66046 48.1%
DRF=4: 59970 43.7%
DRF=5: 7354 5.4%
DRF=6: 13 0.0%
DRF=7: 3 0.0%
DRF=8: 0 0.0%
DRF=9: 0 0.0%
DRF>9: 0 0.0%


- as you see GMC has some very subtle effect on the Quant distribution.

[Prettz]

When I start an encoding session (from VDM Job Control), the new Xvid status window will start drawing the quantizer chart ALL OVER THE PLACE. I'm talking all over itself, all over the VDM status window, all over the desktop, all over the task bar, and it was seemingly doing it all over everything at once as I tried to figure out what was going on.

Syskin mentioned something about Aloha not working correctly with the VDM Job Control (I only just now saw that part). Is my problem part of what he was talking about?

edit: On a side note, encoding of both passes is very nearly 100% faster on my computer (1.7GHz Williamette P4) than dev-api-3 with the exact same settings.

[ChronoReverse]

Originally posted by mf
I encoded a psychidelic anime opening at a stunning saturation of 12000kbit/s, with a recent api4 build.

Heh, a while back, I did something similar with a japanese game opening using dev-api-4 as well. It wouldn't saturate until some ridiculously high bitrate like that reached too. But it ended looking decent even when small though =)

[Manao]

I've got a strange problem, while trying to make a SSIM test . Here is my script :source = MPEG2Source("R:\beauty.d2v").crop(16,16,-16,-16).trim(2,131209).lanczosresize(1024,560)
result = AVISource("R:\beautyv1.0.avi",audio = false).trim(3,0).lanczosresize(1024,560)
result2 = AVISource("R:\beauty-base.avi",audio = false).trim(3,0).lanczosresize(1024,560)

bla = SSIM(source,result,"bv1.0.csv","bv1.0.txt",lumimask=true)
bla2 = SSIM(source,result2,"bvdev3.csv","bvdev3.txt",lumimask=true)

return stackvertical(bla,bla2).selectrangeevery(1000,10)The first clip was made with dev-api-3, the second with dev-api-4. I can't keep the synchronization between the first and the second ( or between the second and the source ). It's because of the SelectEveryRange, but I didn't have this problem 2 months ago with dev-api-3 only. A lot of things changed on my system ( Windows XP reinstalled, Avisynth 2.52 -> 2.53... ), but I'd bet it's XviD's fault ( decoding wise ).

[HarryM]

I have one question.
Do you plan for future versions of XviD codec any internal preprocessing (filtering, resizing, deinterlacing), like to DivX???
For a direct capturing from TV (or another sources) to XviD is this very gooooood function.

The form maybe based on direct connecting to avisynth library (avisynth.dll), e.g.:cool:

[Manao]

HarryM : it's not the role of the codec, it's imho the role of avisynth. Something like TVSource() inside avisynth would allow you preprocess your video while recording. Moreover, in this case, you could use avisynth processing for any codec. And, btw, dscaler already allows a lot of preprocessing.

[communist]

If I remember correctly the XviD team decided not to implement any kind of preprocessing into XviD.

[RadicalEd]

Originally posted by communist
If I remember correctly the XviD team decided not to implement any kind of preprocessing into XviD.


Chroma optimizer is a preprocessor of sorts, but it doesn't create any visual effect.

[outlyer]

Originally posted by Chainmax
How exactly can you tell if you're saturating the codec?In adition to what Manao explained, you can also know you're saturating looking at the new encoding status window (if you can use it): if you get a similar distribution to the first pass (with the default settings it should be mostly quant 2 for I/P frames and quant 4 for b-frames IIRC).
BTW If you discard the first pass file instead of comparing file sizes compare average bitrates (again it's shown in XviD's status window).

[BoNz1]

Originally posted by Manao
treillis, or anything that trade quality for size ( but which are great in unsaturate cases )

Ok, I'm am not sure where this came from but trellis always increases quality and it should _always_ be used; yes even when you have saturated the codec see sysKin's post. I'm not even sure if trellis will reduce filesize by that much anyway, in fact I doubt it does a whole lot such as b-frames do. But the increase in quality is quite a bit in my opinion. As for b-frames it is my opinion that unless it is a very extreme case the best thing to do is use a weaker setting ie 1, 1.5, 0. BTW wannabe, DRF analyzer is really very useless IMO, just because there is a frame that is quant 25 doesn't mean it is bad, if it looks bad well then thats another story. In the couple times I've used GMC, I have never seen any problems with it except for the fact that it is quite slow.

Originally posted by outlyer
In adition to what Manao explained, you can also know you're saturating looking at the new encoding status window

Better yet, use Koepi's stats reader, since that window has been known to output bogus data. If your first pass size is close to your second pass size you will saturate the codec in the second pass.

[Prettz]

Originally posted by RadicalEd
Chroma optimizer is a preprocessor of sorts, but it doesn't create any visual effect.
For animation at least, the effect is quite obvious when comparing frame-by-frame with an encode that doesn't use it (i.e. the picture is distinctly different, even without looking closely at any details).

Cartoon Mode could also be considered something like a preprocessor, although technically it isn't one.

[Manao]

It came from a selective memory :rolleyes: Originally posted by sysKin
As a result, trellis quant when used with h263 is bringing some details back rather than throwing away more, so it increases filesize and quality at quant 2.
When used with mpeg quant type, it rather throws more details away than brings back (again, on average) - so it reduces filesize and psnr at fixed quant 2. I read that, and I totally forgot the first part, just to remember the second one. So my mistake ( I'll edit the previous post to make it accurate ).

Edit :

Originally posted by BoNz1
just because there is a frame that is quant 25 doesn't mean it is bad, if it looks bad well then thats another story. That's true. But I would bet that even if it does look good, a frame at quant 25 has one of the lowest PSNR. And if not, it also resolves the question of wannabe : the codec made a good choice when it used a quantizer 25 for this frame, so there is no bug.

[outlyer]

Originally posted by BoNz1
(...) since that window has been known to output bogus data.It has given me pretty accurate results so far :p

[wannabe]

Well my origal question wasnt that if that quant 25 frame looks bad or not, it was if its normal that GMC has an effect on the quantizer distritubtion or not.

Maybe its a part of GMC's job, to find frames that can be encoded at quant 25 and wont look that bad in order to save those bits for other parts of the video. I just want to know if its a bug or is it its job.


Btw i made a test with Chroma optimizer, with the same settings that i used for the one that did not have GMC, but this new one didnt have Chrome optimizer either. Here are the results:

For the non-Chrome optimizer (DRF 3.516 avarage, 6 maximum) one:
DRF=1&2: 3836 2.8%
DRF=3: 66139 48.2%
DRF=4: 59937 43.7%
DRF=5: 7314 5.3%
DRF=6: 15 0.0%
DRF=7: 0 0.0%
DRF=8: 0 0.0%
DRF=9: 0 0.0%
DRF>9: 0 0.0%

For the non-GMC(3.517 avarage, 7 Maximum) one:
DRF=1&2: 3854 2.8%
DRF=3: 66046 48.1%
DRF=4: 59970 43.7%
DRF=5: 7354 5.4%
DRF=6: 13 0.0%
DRF=7: 3 0.0%
DRF=8: 0 0.0%
DRF=9: 0 0.0%
DRF>9: 0 0.0%

So Chrome optimizer is one other feature that increases Max DRF unneccesary. Btw if i understood well, Chroma optimizer should prevent red-blocking with a cost of slight drop of quality. Thats what XviD FAQ says. What i dont understand from my test is that it seems to create frames with Quant 7 thats a larger quantizer, rather than use a lower quantizer on more frames. (For example have 20 DRF=6 frames would be better than 13 DRF=6 + 3 DRF=7)

About its effect: to tell you the truth i looked closely on scenes that had "red-blocking" and could not spot any difference between the original and the crhoma optimized one. So it would be very nice if a dev would explain the good side of this feature because i dont see it, it decreases mathematical quality, but i dont see any visual improvements either. Maybe it does something else that compensates its negative effect but i dont know where should i look to see it, i searched the XviD forums all trough but could not locate any detailed information.

[homersapien]

Well...Aloha worked for one 2-pass encoding. However, now it crashes right at the end of every 2nd pass. Error message points to xvid.dll.

Latest Avisynth 2.5
VDubMod 1.4.13

Strange...anyone else getting something similar to this :confused:

[Manao]

homersapien : Originally posted by sysKin
Known problems: Virtualdub crashes if you use job control. I'll contact VDM developers in a hope that they'll do stuff I should do myself - find the error *in XviD*So if you're using the job queue, it may explain the problem you've got ( and, btw, the latest version of VDM is 1.5.10.1 ).

wannabe : why do you think that 20 quants 6 is better than 13 quants 6 and 3 quants 7 ( and so 4 more quants 5 ). If the average quantizer was meaning something ( and it doesn't - it is correlated to average PSNR, nothing more ), the second case would be better. If not, you can't base yourself on DRF to judge XviD decisions - and that's the second point which is the right one.

[LigH]

Just a little cosmetic flaw: Since all the unofficial betas, an "s" is missing in "Global motion compen>s<ation".

[homersapien]

Originally posted by Manao
homersapien : So if you're using the job queue, it may explain the problem you've got ( and, btw, the latest version of VDM is 1.5.10.1 ).


Thanks manao...I guess I was pretty blind by the time I got 10 pages into this thread :D I'm sticking with 1.4.x until they put "save wav" back into the 'file' menu :devil:

[Manao]

Until they put "save wav" back into the 'file' menu Do you know that the fonction is still present ? It's in 'Streams -> Streams list', you select the ausio stream you want, and then 'save wav'

[cipher]

Just a little cosmetic flaw: Since all the unofficial betas, an "s" is missing in "Global motion compen>s<ation".

That is a nasty little bug that hides well.:D
Great bug hunting LigH!:D

[wannabe]

Well this VDub crashing problem is never occured to me. i have
Vdub 1.5.1. And i always used Job control in the last 60 hours. Sometimes i had 9 jobs after each other and never got a crash. I got an AMD Athlon XP 2100+ if thats any help ?


That quantizer distribution thing is a matter of taste thats right. I like better if the quality is closer to constant, because if there are some frames with extremely high quantizer you will spot them right away, and you will remember them and thats psychologically bad, ll leave a bad taste in your mouth. Thats why some ppl like to restrict the quantizers to lower values, and thats why Divx3.11 needed help cuz it created fair amount of high quantizer frames even with low avarage DRF.

But its still not my point, if its GMC's and Chrome optimizer's goal to create a few very high quantizer frames or thats just a side effect (no matter if thats a good side effect or not).


and that's the second point which is the right one.

You mean the red-blocking thing that chroma optimizer should solve ?

[Manao]

wannabe : I wasn't clear. What I meant by this sentence was : You can't use (only) DRF analysis to judge XviD decisions ( imho, of course :D ), you have also to use PSNR, SSIM, and most importantly, your eyes.

For the VDub thing, I got one crash once, but that's all ( Athlon XP, VdubMod 1.5.4.1 and 1.5.10.1 ) It may be a random crash.

[RadicalEd]

Originally posted by Prettz
For animation at least, the effect is quite obvious when comparing frame-by-frame with an encode that doesn't use it (i.e. the picture is distinctly different, even without looking closely at any details).

Well either chroma optimizer is broken in my version, or something's wrong with yours, cause I'm not getting so much as a mathematical difference between frames with & without, much less a visual one.

Though I'm not sure why it would cause a visual difference, as far as I understand all it does is average out the chroma in areas where the luma is pure black or pure white.

[Zep]

Cool Feature Xvid is missing and needs IMHO.

Give Xvid a checkbox option so that if checked then on the
firstpass it saves a yv12 lossless encode. (you could use VBLE
or write your own)

Now on the second pass instead of reading in from original
file or avisynth via frame serving, you read in and encode
from the lossless yv12 file made on the first pass.

Why do this? Well in my case i cap HDTV at 1920 x 1080i
and it is slow to filter. Real slow! and having to filter
it each pass is crazy when it was done on first pass just
fine and dandy :)

this way you save a TON of time because you only filter
once and since you get the first pass stats also this beats
doing a 1 pass encode on my own using lossless VBLE then a two
pass on that file (which is what i do now to save the mega
hours wasted on the 2nd pass re filter. i also get to re encode
it and try new settings in xvid without having to filter it again
in avisynth and waste more mega hours)


the only downside, more disk space is needed but anyone doing caps
should have plenty :D


Thanks


Zep

[Prettz]

Originally posted by Zep
Cool Feature Xvid is missing and needs IMHO.

Give Xvid a checkbox option so that if checked then on the
firstpass it saves a yv12 lossless encode. (you could use VBLE
or write your own)

Now on the second pass instead of reading in from original
file or avisynth via frame serving, you read in and encode
from the lossless yv12 file made on the first pass.

Why do this? Well in my case i cap HDTV at 1920 x 1080i
and it is slow to filter. Real slow! and having to filter
it each pass is crazy when it was done on first pass just
fine and dandy :)

this way you save a TON of time because you only filter
once and since you get the first pass stats also this beats
doing a 1 pass encode on my own using lossless VBLE then a two
pass on that file (which is what i do now to save the mega
hours wasted on the 2nd pass re filter. i also get to re encode
it and try new settings in xvid without having to filter it again
in avisynth and waste more mega hours)


the only downside, more disk space is needed but anyone doing caps
should have plenty :D


Thanks


Zep
I'm sure that filtering takes absolutely nothing at all compared to the amount of time it takes to encode Xvid at that resolution. I don't even want to imagine how large a VBLE video at HDTV resolution would be, either. (BTW, how large would it be?)

Why not just save the .avs to VBLE in the first place and use it for both passes???

[Manao]

Zep : it's not the job of the codec. You wouldn't gain any time integrating this feature inside XviD, and you would lose the ability to choose which lossless codec you want to use.

edit : Prettz : gain of time depends of the filtering, but relatively speaking, if you encode losslessly at 15 fps ( without prefiltering ), it's easy to make a simple avs script slower than 15 fps ( without doing any compression, just use mipsmooth for example :rolleyes: ). In that case, a temp file encoded with a lossless code makes you gain some time.

[AgeOfPanic]

I'm trying this codec too when I'm writing this. The first pass has just finished. I enabled almost anything in the codec, because I read that everything works and I would like to see the result. I was expecting a little speed encrease, but my first pass only took 42 minutes or so. The video rendering rate was about 66 fps(!). The second pass seems normal with about 8 fps. Has anybody else seen this phenomenom?

[iago]

The video rendering rate was about 66 fps(!) [...] Has anybody else seen this phenomenom?If only I could! :D

[Manao]

AgeOfPanic : something went wrong with your first pass, but I can't say why ( I would say that in your first pass, you delete the zone that begins at frame 0 and which weights 1.0, because in that case, XviD tends to have a random behavior - but it's only a guess )

[AgeOfPanic]

I'm pretty sure I didn't delete that zone and I could see that the program checked all frames. I will see what comes out and try again.
Edit: BTW for a couple of seconds I thought this was normal and an example of the speed gain that people talked about :) .

[LigH]

@ cipher: Somehow I feel that someone likes making jokes on me...

So okay, now a few more technical details!

Good news: sysKin's "secret" version "xvid1.0beta1.1" fixed the "crash on interlaced encoding" bug! Interlaced encoding works fine in 1-pass modes with any matrix, even custom ones, using this DLL.

Bad news: 2-pass encoding only works with both H.263 and B frames; it doesn't work with MPEG or Custom matrix, or without B frames.

I still wonder how this can happen, isn't bitrate calculation almost independent of matrix or frames?!... :rolleyes: - Wish you good luck in fixing!

[Manao]

Bad news: 2-pass encoding only works with both H.263 and B frames; it doesn't work with MPEG or Custom matrix, or without B frames.For which build ? beta 1 or beta 1.1. Because I've got no problem at all with custom matrices and b-frames and beta 1.0.

[Leak]

Originally posted by Manao
For which build ? beta 1 or beta 1.1. Because I've got no problem at all with custom matrices and b-frames and beta 1.0.

Gotta second this - I've been using the original beta 1 with MPEG and B-frames and 2-pass without problems.

np: Underworld - Two Months Off (Underworld 1992-2002)