Ciao! (XviD-1.0-Beta2-05122003)

[Koepi]

Aloha!

Finally, beta 2 is out - Codename Ciao.

Changelog:

XviD-1.0-Beta2-05122003:
- Fixed bitstream headers to be mpeg4-compliant again.
- Quant matrices are finally threadsafe.
- Interlaced encoding is fixed.
- VFW frontend fixes and misuses of core.
- Final tweaks to frame decision and motion estimation.
- Fixed overflow degeneration (Q31 problem with i-min-distance >1).
- Fixed CBR mode - the first frames weren't capped as wanted.

Please report further bugs (from this build) here, I closed the old thread as it was getting too huge.

Best regards
Koepi

[tiki4]

Thanks, testing...

tiki4

[raz0r]

did first test, seems to be a lot faster.
always had ~5fps, now ~10.
encoded a very dark scene at ~1mbit, MSP-6 VHQ-4 H.263 trellis quant chroma motion adaptive quant (lumi masking) no GMC/QPEL/BVOP. source was pal progressive dvd (matrix reloaded), destination 640*272. quality is very good, but thats no wonder at 1mbit.

nice build, especially because of its speed. but still doesnt play on standalone :(

[P0l1m0rph1c]

Great work guys!

I'm testing as I speak...some results in a few hours.

Keep up with the great work!

:)

[Manao]

Thanks a lot ! Right on time between my first and second pass :)

[P0l1m0rph1c]

Originally posted by Manao
Thanks a lot ! Right on time between my first and second pass :)

That's not very recomendable. You should finish your movie with beta1 and then move on to beta2. If i'm wrong, plz someone correct me.

[Manao]

Well I don't think it will have a big influence on the result. And having an mpeg4-compliant header is (imho) more important than missing the wanted size by a few KB.

[zettai]

Originally posted by Manao
Well I don't think it will have a big influence on the result. And having an mpeg4-compliant header is (imho) more important than missing the wanted size by a few KB.

This release of the codec has had "tweaks to frame decision and motion estimation" and you dont think it will matter??

[Prettz]

I have a question about GMC. Is there any way at all for GMC plus VHQ4 and MPEG quant to result in lowered quality? Or does it now either not help but not affect quality or save some bits but still not affect quality adversely?

What I'm getting at is if you don't mind the loss of speed in encoding and decoding, is there any reason NOT to always enable GMC just for the heck of it?

[Manao]

zettai : I won't be sure until a developper answers that particular point, but AFAIK frame decision are made during the second pass ( and in the first when choosing between p & b & s frames ). Motion estimation is important in both passes, but since the previous ME was already very good, I don't think the ME in the beta 2 would be completely different. It may lead to a little imprecision in the final size, but I don't think it'll be sensitive.

[HarryM]

Old good 'blooming' delay b-frame message ('WARNING: NOTHING TO OUTPUT, BFRAME DECODER LAG') at decoding (xvid.ax) is resolved/removed?

[cipher]

Great work, guys!

But since it hasn't been fixed in beta2, I'm gonna state this again :)-----LigH has found that, what should be "Global Motion Compen>>s<<ation" is now shown as "Global Motion Compenation", where an "s" is missing :)

[Koepi]

Frame type decision is done in first pass, so you should redo the first pass - though since it is written in the first pass statsfile the encoder will oblige to that :)

About GMC, well, it's very slow and doesn't help too much. To be really useful it has to be tweaked a bit more. Bt sure, you can enable it if you don't mind the additional cpu power and memory necessary.

As the GUI will maybe change later we didn't give too much importance to a missing letter ;)

Regards
Koepi

[cipher]

About GMC, well, it's very slow and doesn't help too much. To be really useful it has to be tweaked a bit more. Bt sure, you can enable it if you don't mind the additional cpu power and memory necessary.

is GMC now using 3 warping points or 4?
Thx.

[Koepi]

I never heard of 4 warppoint GMC. This is "still" 3 warppoint GMC.

Ah, and about that decoder lag message: it'll stay in there as long as we don't do special DirectShow-coding for the decoder :-/ Using ffdshow (libavcodec) for decoding solves the issue.

Regards
Koepi

[mfluder]

Originally posted by mfluder
I noticed this during the testing of my dev-api-4 compiles but I wanted to wait for the official betas. When decoding dev-api-3 streams (Koepi's latest) and the height is not multiple of 16 (it's multiple of 8, 640x360) there is a bleeding at the bottom of the clip. I don't have any webspace so I can't post a screenshot but you can spot it easily. There is no problem when the clip is encoded with dev-api-4.
Sorry guys for bringing this up again but is it possible to add some kind of workaround for this problem? For example, add a condition in decoder so when bitstream version of dev-api-3 builds is detected then apply this workaround. I know it's possible to decode this kind of files correctly as ffdshow doesn't have any problem with them.

Thanks for all your work,
mfluder

[Manao]

Ok, I'll do another first pass ( btw, I can keep both stats files if you want ). It'll only be the tenth time I made a first pass for this movie ( that's mainly why I was so reluctant :rolleyes: )

[mf]

Still I find these betas slightly early. Wasn't it supposed to be so that 1.0 had core and vfw separate, and a proper GUI (ok well we know the story about the GUI..) ?

[Koepi]

ok mf, you're right. I take back the betas and remove them from my site ;)

(Or what do you expect as answer to such a [unconstructive] post?)

Regards
Koepi

[AgeOfPanic]

Ik know now that I can't use Gordian Knot to control the proces, but can I still use it to setup my Avisynth-script?

[KpeX]

Originally posted by AgeOfPanic
Ik know now that I can't use Gordian Knot to control the proces, but can I still use it to setup my Avisynth-script?

Yes. AVS scripts are independent of the codec used.


Koepi & XviD team: thanks for a quick second beta.

[mf]

Originally posted by Koepi
ok mf, you're right. I take back the betas and remove them from my site ;)

(Or what do you expect as answer to such a [unconstructive] post?)

Regards
Koepi
Ok, it's hindsight. But it's not hard to admit faults later, is it? :D The nice thing is you don't have to do anything about it because it's already happened, you can only say "Oh that's Jim Fix isn't it? Oh what a f*cking tragedy." :p.

Edit: oh and next beta, do name it "Ahoy", I specially came to #xvid to ask that. :D

[Arhu]

Originally posted by sysKinOriginally posted by cipher
and in "zone", we could also force a range of frames to use keyframes(I frames) only;No, this means that a zone starts with a forced keyframe. You have to use it if you're starting a greyscale zone, but it was originally designed for chapters - it's good when a chapter starts with a keyframe, you have faster/more accurate seeking.
This would be nice, but it's not what I experience. If I set the keyframe modifier on the start frame of a zone and run the job, only I-frames are produced. Furthermore, if the first zone starts not at frame 0 but at a later frame, the same problem occurs starting at frame 0.
If I remove the "K" from zones, everything works fine.

By the way, could perhaps MAX_ZONES be increased? I'm doing TTT which has 68 chapters, and 64 zones are not quite enough...

Anyway, thanks for all your efforts, xvid team!

[P0l1m0rph1c]

Originally posted by AgeOfPanic
Ik know now that I can't use Gordian Knot to control the proces, but can I still use it to setup my Avisynth-script?
The answer is yes.

[Enrico Ng]

I think the "s" is missing in GMC "compenation"?

[Koepi]

Enrico:
Please read page one of this thread and find the report of the missing "s" and an answer to that.

Regards
Koepi

[Enrico Ng]

Originally posted by Koepi
Enrico:
Please read page one of this thread and find the report of the missing "s" and an answer to that.

Regards
Koepi


Oh, sorry, I thought I had finally made my first conribution :(

[Wilbert]

I guess I'm doing something stupid, but I can't get the specified target size. Source is an AVS script where a mpeg2 stream is loaded with dvd2avi.

I used the following options (2pass):

HDTV profile
trellis
VHQ4
I: 2-4
P: 2-4
target bitrate: 4000 kbps

But the resulting bitrate is always about 7000 kbps. This happens also if I choose "unrestriced + h.263 + settings above" for both passes.

If the encoding is finished I got the following error message (dunno whether it is related though):

[Manao]

What is the final quant dstribution ? Since your quants are capped at 4, if your quant distribution is composed only by quants 4, then you'll have to rise that capping value to 5 or 6 ( or you can even try not to cap ). If not, I don't know what you did wrong.

[Wilbert]

What is the final quant dstribution ? Since your quants are capped at 4, if your quant distribution is composed only by quants 4, then you'll have to rise that capping value to 5 or 6 ( or you can even try not to cap ).
Yes, you were correct :) Stupid that I didn't realise that.

[Leak]

Funny enough, the about dialog says "libxvidcore version 1.0.-127" - I've never seen a program with such a negative version number... ;)

(I guess the fix for this is right next to the other speling bug on Koepi's to-do list... :p)

np: Plaid - Marry (Spokes)

[Hoschi]

Originally posted by HarryM
Old good 'blooming' delay b-frame message ('WARNING: NOTHING TO OUTPUT, BFRAME DECODER LAG') at decoding (xvid.ax) is resolved/removed?

nope, it' still there. But this is no real problem...

As I have a large number of files encoded with xvid - I noticed that some files do not decode properly. Keyframes are OK, but all other frames are scrambled.

Is 1.0 incompatible to older releases or are these problems caused by errors of earlier releases ?

24062003 decodes properly...
I do not use ffdshow, playback using divx5 improves the image, but still some errors. What did I miss ?

[torsius]

@ Hoschi

what you missed is that the included xvid decoder is sketchy at best, not only with decoding it's matching build, but even more so with streams made from previous builds, that's why ffdshow is recommended for decoding

[Koepi]

Leak:

The version number is intentional. Before beta1 it was xvid 1.-127.0 ... it's just meant to show the progress. I agree though we should have raisen the number to 1.0.-126.

Hoschi:
Unfortunately we don't have something useful as ffdshow -automatic bitstream & workaround detection- in our xvid decoder (yet). There are plans to add something like that, but they don't seem to be high on the "urgent to do" list.

Regards
Koepi

[LigH]

Great thing!

- Interlaced encoding works fine.
- 2-pass encoding works with MPEG matrix, with or without B frames.

Now that's what I call a "beta". http://forum.gleitz.de/images/smilies/thumb.gif
__

(@ mf: Did you explain your "recommended settings" somewhere?)

[Zep]

Mf said -Why would this have to be something in XviD? Use VDub's job control and set it to first encode the VBLE, then encode the XviD first and second pass from the VBLE.


read my post that is what i said i do already and WHY I want this feature
to get rid of three passes which takes longer than 2 passes.
Oh and lets not forget you have to wait for the VBLE then set it up later
when done. You can't go to bed just yet you have to let the VBLE finish
then set it up. of course I'm sure someone could write some scripts or
something to automate this so we do not have to be around. My time
(which adds to the total time to to encode) and hassle is a huge factor
in this as well :)

.You'll find that it takes just as much time as filtering, VBLE and first xvid pass at the same time. Plus, if something goes wrong during filtering to VBLE, you'll still have something useful, which is not the case with XviD.


2 passes are always faster than 3. i have tested it myself on 1920 x 1080i .ts streams

the speed gain comes from only reading that 10 gig file in ONCE since
you are doing 2 things to the data when it is already in memory
when you have the chance.

There is a TON of time wasted having to read that 10 gig file in TWICE
(once for each pass your way)

You ALREADY have the data in memory so you should do as much as you
can to it while it is already THERE and doing the VBLE and Xvid first pass on those
pixels at the same time while you have that data is exactly what I'm talking
about. You will be surprised just how long it takes to read in a 10 gig file and
the VD/VDM overhead on all that data etc... This is where the savings come from

Your way = Filter and write once , read twice
My way = Filter and write once, read once

in all my tests on 44 minute streams at 1920 x 1080i I get about a 20%
time savings. (and this is not including my time and hassle factor)

[Sofus]

There is a small problem in the decoder, witch the new Beta2 build. Overlay (gamma, contrast, brightnes) is no longer accessible in the ATi Catalyst control panel. It was working in one of gamer´s builds from the 4th

Sofus

[mf]

Originally posted by Zep
2 passes are always faster than 3. i have tested it myself on 1920 x 1080i .ts streams

the speed gain comes from only reading that 10 gig file in ONCE since
you are doing 2 things to the data when it is already in memory
when you have the chance.

There is a TON of time wasted having to read that 10 gig file in TWICE
(once for each pass your way)

You ALREADY have the data in memory so you should do as much as you
can to it while it is already THERE and doing the VBLE and Xvid first pass on those
pixels at the same time while you have that data is exactly what I'm talking
about. You will be surprised just how long it takes to read in a 10 gig file and
the VD/VDM overhead on all that data etc... This is where the savings come from

Your way = Filter and write once , read twice
My way = Filter and write once, read once

in all my tests on 44 minute streams at 1920 x 1080i I get about a 20%
time savings. (and this is not including my time and hassle factor)
I don't know about you, but whenever I filter my PC has to throw huge frames around in memory and then dragging them through CPU processing at max speed, and doing anything beside that (encoding xvid first pass) is going to cost me more memory, bandwidth, and CPU cycles. Plus I will get a fragmented hard drive because I'm writing two things at around the same time, which will cause slow disk access on my second pass. My biggest concern here is bandwidth and CPU. Windows timesharing is not effective at having your CPU do two different things at the same time in an elegant(fast) way. By pushing your hardware that far you'll probably only create new bottlenecks to slow your processing down on.

[jarthel]

The options used are:

2 pass encoding with 273mb as target size
h.234
lumamasking on
gmc on
b-frames on (3/1.5/1) with closed GOV
motion search precision - ultra-high
VHQ wide-search
cartoon mode
default quantization with trellis on

Encoded using latest vdubmod CVS
using latest Avisynth CVS
-----------------------

1st pass is successful.
But 2nd pass always fails at the last frame.

and here's what I get (http://f1.pg.photos.yahoo.com/ph/jarthel/detail?.dir=/divx&.dnm=xvid-error.jpg).

[mf]

Originally posted by LigH
(@ mf: Did you explain your "recommended settings" somewhere?)
Nope, but there's not much explaining to do. It's just the settings that I consider best for my average XviD encode. I put it in my sig so I can update it anytime and the change would be reflected in every post I ever made, since "what's best" tends to change quite rapidly during active public XviD development (it was kinda frozen for a long time because of the halt of all api3 development and api4 being non-public).

[nanji]

Please read this thread
http://forum.doom9.org/showthread.php?s=&threadid=66208
If the 2nd-pass size is greater than 2G, xvid will keep using quant 2 value to compress. I guess it's because there are some issues about file size over 2G, which didn't happen before. It is very annoying for 4CD or 5CD files.

[jarthel]

Originally posted by nanji
Please read this thread
http://forum.doom9.org/showthread.php?s=&threadid=66208
If the 2nd-pass size is greater than 2G, xvid will keep using quant 2 value to compress. I guess it's because there are some issues about file size over 2G, which didn't happen before. It is very annoying for 4CD or 5CD files.

have you tried the latest beta? You used the older beta.

[outlyer]

Originally posted by Arhu
This would be nice, but it's not what I experience. If I set the keyframe modifier on the start frame of a zone and run the job, only I-frames are produced.My (only) frustrating test with KF modifiers showed same results.

[Manao]

nanji : in the source code of the interface ( config.h , beta 2 ), I found a "int desired_size", so effectively, if you enter a size over 2GB, it'll lead to an erratic behavior. The good news is that it should be ( I hope ) only a bug of the interface, because inside the core of the codec, the size is coded by an uint64. Anyway, it's very late here, so I may be totally wrong, and so wait for confirmation by Koepy or another developper.

[nanji]

Originally posted by jarthel
have you tried the latest beta? You used the older beta.
I read the fixed bugs, there is nothing about the error I got. And it worked in old versions of xvid.

[nanji]

Originally posted by Manao
nanji : in the source code of the interface ( config.h , beta 2 ), I found a "int desired_size", so effectively, if you enter a size over 2GB, it'll lead to an erratic behavior. The good news is that it should be ( I hope ) only a bug of the interface, because inside the core of the codec, the size is coded by an uint64. Anyway, it's very late here, so I may be totally wrong, and so wait for confirmation by Koepy or another developper.
I looked at the code and somewhat I think xvid codec addresses or at least considered about the problem, evidenced by /* Total length of each frame types (1st pass) */ uint64_t tot_length[3];. somehow this does not solve the problem.

[jarthel]

Originally posted by nanji
I read the fixed bugs, there is nothing about the error I got. And it worked in old versions of xvid.

Isn't it better to use the new beta and re-test and post back if the error still exists? It's possible that they themselves changed the code of that part and the problem was fixed.

[nanji]

Originally posted by jarthel
Isn't it better to use the new beta and re-test and post back if the error still exists? It's possible that they themselves changed the code of that part and the problem was fixed.
Yes, I have just tested with the new beta version as well. The problem still exists.

[nanji]

this might be the problem (i only have the code for beta1 version, but since beta2 still has the same problem it still applies)

/* Compute the target filesize */
if (rc->param.bitrate<0) {
/* if negative, bitrate equals the target (in kbytes) */
rc->target = (-rc->param.bitrate) * 1024;
else
...

/**********************************************/

line 4
bitrate is int\
(-rc->param.bitrate) * 1024 is over sized
a int type * 1024 represents -2G <-> +2G

[LigH]

Originally posted by mf
It's just the settings that I consider best for my average XviD encode.

Well - I cannot imagine any relation between those 3 numbers, and any of the edit fields of the XviD codec. Where may I e.g. insert numbers around 30.000?

[Manao]

nanji : I think you're right ( and I don't know how I came to think one could enter a 2GB+ filesize in the interface, since the size is in KB :rolleyes: )

koepi, P0l1m0rph1c, zettai : effectively, I was totally wrong ( one more time :p ). I compared the two first pass stats, and there were far more differences than I could have thought ( 250 more keyframes, 7000 less p-frames, 7 more b-frames ). So thanks for avoiding me to lose 8 more hours on this encoding :)

[GolovachLena]

If you haven't considered yet a name for Beta 3, i can give you my version: "Privet". It's the same as "Aloha" but in russian :D

[jarthel]

I must include that with my problem, I was able to successfully complete 2-pass encoding with the vob using 17-july-2003 Nic's Xvid binary. So it can't be a corrupted vob.

[Tuning]

Thanks XviD developement team for the speed and quality improvements in XviD 1.0 betas.

One problem, Every time when I open XviD encoded content ( Both XviD dev-api-3 and dev-api-4 ) in virtualdub(1.5.10) the B-frame decoder lag warning is shown. This started showing only after installing beta2. Eventhough there is no problem other than this, can anyone explain why this warning is shown, please... Sorry if this has been explained before.

Thanks.:)

[Manao]

Tuning : The warning has been here since dev-api-3. Due to avi limitations ( I think, but I may be wrong ), when you use b-frames, you have to introduce a lag if you want to keep audio and video synchronized. What happened is that before you installed beta 1.0, the decoding was made by another decoder ( FFDShow, DivX5 ? ) than XviD's one, which is the only one to show that it introduce a black frame at the beginning. But it's normal, look here (http://forum.doom9.org/showthread.php?s=&postid=408450&highlight=DECODER+LAG#post408450)

Jarthel : for a long time ( a month ), almost every encode I made with dev-api-3 was crashing at the last frame, but the output file was however correct. It was due to memory problems ( hardware ), so perhaps you could check that way. It was very subtle ( the ram did pass RAMtests with success ), but as soon as I changed it, there was no more crashes.

[Tuning]

Thanks Manao,
Oh! it was told before, i didn't looked to it in depth. :D
Currently I'm reading the aloha thread and understand situations. After that I might get time to read ciao thread.;)

Thanks for the info.:)
Edit:
So are you saying if I use mkv/ogm this warning will go off ?

[mazzo]

I can't use xvid because there is no place where I can put in how big I want my file to be. The Button for this is grayed out in the encoder. What can be wrong?

[Tuning]

Mazzo ,

Are you using first pass of 2-pass to put size ?

[Manao]

Tuning : ... ( /me is testing ... ) ... No, you'll have the same problem, so perhaps avi wasn't so guilty this time ( but perhaps it is, I don't know how an avi is muxed inside a mkv / ogm ). I think this also implies some restriction of the VFW Api ...

Well, I'll stop trying to remember. A search gave me that (http://forum.doom9.org/showthread.php?s=&threadid=59933&highlight=directshow+lag+decoder) Look for the first post of Tommy Carrot.

[birdy]

The problem I have is that after installing Beta1 AND Beta2 GordianKnot is no longer able to open ANY avi files that I captured using Xvid codec (No matter if the files are compressed with the older codecs or the 2 latest betas)!

I personally capture a lot of Avi's from tv directly to XVID and then sometimes resize them or recompress again. Too bad I can't open them anymore in Gknot :(

The Error I get when trying to open a AVI file is: "File is not a valid dvd2avi project, Avi or avs file!

[sysKin]

If you don't like the "decoder lag" thingy, just use "packed bitstream" option and it's gone.
I would make it default, but ffdshow doesn't seem to decode that well :( I've already posted the problem to ffdshow forum but there is no answer.

Anyway, if the packed-bitsream file is opened in virtualdub, all strange problems are gone.
There is no known bugs about packed bitstream - if you find something, tell us.

Radek

[AgeOfPanic]

Some feedback from my part. I have encoded an entire movie with the beta-2 Koepi build. Compared to the latest Koepi-build of dev3 it was 100 MB smaller (581 instead of 681, both encodes are saturated, because the target filesize was 1000MB). Also the codec is faster, 8-10fps, to 4-6fps in dev3).
My settings were to enable almost anything, GMC (not that slow at all), adaptive quantization, B-frames, Qpel, chroma-optimizer, MPEG, Motion Search 6, VHQ 4, Trellis.
The result looks great. Thanks for all your work.

[Tuning]

Manao, I was testing too, I could conclude the same. Mkv also has the same warning.
Btw I tried some clips in FFDshow (athos latest) and i could see the warning persists.
As, this thread is not related to this topic, lets stop our discussion on the decoder lag.
Thanks for your help. :)
Edit:
Syskin thanks for explanation.
:thanks:

[Koepi]

Tuning: it's no problem at all, it's a warning message. Don't draw wrong conclusions. (It's useful i.e. if you do PSNR comparisons - don't forget to chop the first frame...)

Packed Bitsream can be found by using a simple search (make sure to not just search the last 30 days because the explanations for that are rather old (but still valid)).

Koepi

[Tuning]

Thanks koepi, I will :search: on that.
Thanks.

[Assault]

@ sysKin

I just tried a "packed bitstream" encode and you're right the message about "b-frame decoder lag" doesn't appear in VDub. BUT when I open the file with the xvid directshow filter there appears something like "broken b-frame, mising ref frame". The last word could also be something else because I can't see the end of it. What does this message mean?

Assault

[Alxemi]

Here (http://138.100.51.162/~alxemi/XviD-1.0-Beta2-05122003.exe) is a mirror of this new release.
Thanks to all the developers.

[mf]

Originally posted by LigH
Well - I cannot imagine any relation between those 3 numbers, and any of the edit fields of the XviD codec. Where may I e.g. insert numbers around 30.000?
The gray thing isn't my recommended settings :eek:! That's just my sigcounter. My recommended settings say: "Current recommended XviD settings: Being revised due to XviD1.0b1 release." Meaning there aren't any at the moment.
Originally posted by sysKin
If you don't like the "decoder lag" thingy, just use "packed bitstream" option and it's gone.
I would make it default, but ffdshow doesn't seem to decode that well :( I've already posted the problem to ffdshow forum but there is no answer.

Anyway, if the packed-bitsream file is opened in virtualdub, all strange problems are gone.
There is no known bugs about packed bitstream - if you find something, tell us.

Radek
Actually, in both vdub and ffdshow packed bitstream files stutter like hell. Guess it wasn't made for anything more than 1 consecutive B-frame, or else the frame decoding times get screwed up.

[jarthel]

any reply on my problem? Thanks

I just tried the following (based on previous settings):

- disabling gmc
- no gmc and no closed GOV
- no cartoon mode and no gmc

I'm still getting errors. Any ideas?

jayel

[Koepi]

jarthel:

I can't reproduce that problem here at all. That's why at least i can't answer that question (why does vdubmod crash on the last frame on 2nd pass).

Regards
Koepi

[jarthel]

thanks Koepi for trying. It's quite weird as my P4 box is not giving me the error. Only my AthlonXP box.

[mazzo]

Tuning

Sorry, I wrote this too early - I found out myself what you are suggesting in your answer.

Birdy

I couldn't open them either before I changed to libavcodec in ffdshow.

[philtre]

Some usability issues.

I was looking at the new interface and, frankly, I found it very confusing. I know it's not final or anything, but keep in mind for the final release, that it would be very nice to design the interface, so all the options are accessible on one page (no tabs).
Also, a wizard for newbies based on recommended settings would be nice.

I never figured out why the codec can't do both passes by itself. Why do you need to first use it for first pass, and then again for second. Is there a special reason for that? As far as I know, you usually don't change any settings between passes.

I'd also like to know, Koepi, what has to work before you release the final version? Will it have to be playable on standalones, and such?

thanks,
philtre

[Manao]

jarthel : if you can, try swapping ram between computers.so all the options are accessible on one page (no tabs).You're kidding ? Did you count the number of parameters ?Never figured out why the codec can't do both passes by itselfI would guess "because of the VFW API"Will it have to be playable on standalones, and such?Depends of the standalone, depends of the settings, that is why you have 'profiles' in the new GUI.

[jarthel]

Originally posted by Manao
jarthel : if you can, try swapping ram between computers.

Well, the AthlonXP box has been encoding xvid using july-2003 and earlier versions for months now. So I really doubt it's the RAM.

[philtre]

Originally posted by Manao
Did you count the number of parameters?

Yes, I have, and they don't fit in such a small window. But if you make the window larger and apply some creative interface design, you can fit even more parameters.
Usability is a big issue and it can make or break the product, so if you can streamline the interface, it will be more useful to users and save a lot of their time.

philtre

[HarryM]

Originally posted by sysKin
If you don't like the "decoder lag" thingy, just use "packed bitstream" option and it's gone.
I would make it default, but ffdshow doesn't seem to decode that well :( I've already posted the problem to ffdshow forum but there is no answer.

Anyway, if the packed-bitsream file is opened in virtualdub, all strange problems are gone.
There is no known bugs about packed bitstream - if you find something, tell us.

Radek

I have the simplest solution of "decoder lag message" and etc. thingy. Deactivate this message for user choice.

Add one checkbox into VFW (with default set up ON) -
"Dont display internal in-frame messages"

:cool:

[sysKin]

Originally posted by HarryM
I have the simplest solution of "decoder lag message" and etc. thingy. Deactivate this message for user choice.

Add one checkbox into VFW (with default set up ON) -
"Dont display internal in-frame messages"Unfortunately, API is not supposed to change anymore - and decoder does not have such flag in its API.
Originally posted by philtre
Never figured out why the codec can't do both passes by itself
Codec just encodes, it can't do even a single pass by itself! It's up to external encoding application to give it all the frames, how do you expect a codec to force external application to start over again 'by itself'?
I was looking at the new interface and, frankly, I found it very confusing. I know it's not final or anything, but keep in mind for the final release, that it would be very nice to design the interface, so all the options are accessible on one page (no tabs).
Also, a wizard for newbies based on recommended settings would be nice.You are absolutely welcome to write it for us. There is not a single XviD developer who can and is willing to rewrite the gui (I wish I could, but I can't).

@jarthel: several people reported that. However, I can't reproduce that and I can't see how can this happen :( In other words: we have a problem.
Your screenshot didn't help at all, do you think you could paste/pm/email me what the "advanced" part of Vdub crash dialog told you?
Also, could you take a look at 1st pass stats file and tell me if there's something interesting at the end of it?

As for 'packed bitstream' decoding, it appears I have to find/download our dshow decoder ;)) and see how it works.

Radek

[kastro68]

Can you call the next build "Sayonara"?

[jarthel]

Originally posted by sysKin

@jarthel: several people reported that. However, I can't reproduce that and I can't see how can this happen :( In other words: we have a problem.
Your screenshot didn't help at all, do you think you could paste/pm/email me what the "advanced" part of Vdub crash dialog told you?
Also, could you take a look at 1st pass stats file and tell me if there's something interesting at the end of it?
Radek

check you're email. I've looked at stats and seems normal to me. I'll attach that as well. As for the vdub crash dialog, I save the text to a text file. You should expect that as well.

Thanks syskin.

jayel

ps. what's your email? I can paste the crash info here but it's too long. :)

[bob0r]

Originally posted by mf

Edit: oh and next beta, do name it "Ahoy", I specially came to #xvid to ask that. :D

#xvid on what irc server would that be?



.. keep up the good work, i can not wait untill xvid 1.0 will be the new video standard!

[jarthel]

Originally posted by bob0r
#xvid on what irc server would that be?



.. keep up the good work, i can not wait untill xvid 1.0 will be the new video standard!

look at syskin sig. should be there.

[philtre]

Originally posted by sysKin
You are absolutely welcome to write it for us. There is not a single XviD developer who can and is willing to rewrite the gui (I wish I could, but I can't).[/B]

I'll try to figure out how it can be optimized and then send in some suggestions. But since i'm not really a programmer, I'll ask one of my programmer friends to help me write it, or something.

As for the "two-pass" question, I don't know how the encoding process actually works. I always thought there's some kind of 2-way communication between the codec and the app, hence the silly question.

philtre

[jarthel]

just tried encoding the last 4500+ frames of the vobs. It's around 36000+ in total. Well I was able to complete both passes. Increasing no of frames now to 16000+ frames.

[Tuning]

Originally posted by philtre
As for the "two-pass" question, I don't know how the encoding process actually works. I always thought there's some kind of 2-way communication between the codec and the app...

I think it is the time for you to check Doom9 XviD Guide based on GK and Vdub (http://www.doom9.org/xvid.htm)

[Leak]

By the way - there's one thing I've been thinking about: why does the statfile default to "\video.pass"?

Wouldn't ".\video.pass" (or just "video.pass") be a more sensible location, as it should go right next to the video and thus be writable in any case, preventing people getting an error because the root of their drive happens to be unwriteable?

Oh, and one more thing... is the minimum I-frame distance going to make a comeback, or is removing the option and keeping it at 1 a permanent solution?

Just wondering... :)

np: Monolake - Linear (Momentum)

[P0l1m0rph1c]

@Leak: look at the 2 pass 2nd pass configuration. There is a box that says "I frames closer that ... frames" and below "are reduced by ... %". With these options we dont need "minimum I frames interval" anymore.

[amango]

@Koepi

Won't there be a 1-Pass qualitybased mode anymore in the new builts? All codecs like WMV9 and DIVX are offering this feature, too.

I liked this feature, because it's saving time. Size doesn't matter.

[Blight]

What I find odd is that the "Default Settings" are a far-off cry from being very good as a starting point. Quite a few helpful features are turned off by default. Things which are beneficial and don't cause any stability issues should be on by default as a lot of newbies won't know what they are and may be afraid to enable them.

[P0l1m0rph1c]

Just finished making some tests. The source was Matrix Reloaded trailer, 1000×540, @ 3000 kbps. Used 2 pass for all codecs. I didn't use adaptive quant.

Results:

3ivX 4.5

Overall PSNR: 42.5432
Average SSIM: 0.969915

DivX 5.1.1

Overall PSNR: 43.9748
Average SSIM: 0.975774

On2 Vp6

Overall PSNR: 43.5583
Average SSIM: 0.974484

XviD 1.0 beta 2

Overall PSNR: 44.1614
Average SSIM: 0.976664

Nice works guys! :D

[Bulletproof]

Is reduced resolution supposed to be working? I seem to be getting some weird artifacts when enabling it or it just crashes sometimes when decoding.

BTW polymorphic, what's interesting about that test is that VP6 has the lowest VQM, I think lower VQM value means better quality, when you took a look at both of them which one looked better to you?

[P0l1m0rph1c]

@Bulletproof: Both of them are very good indeed, but as far as i saw, vp6 tended to blur a bit the image, compared to XviD. Maybe that's the explanation to the lower VQM value, who knows?

[Hylas]

Originally posted by amango
Won't there be a 1-Pass qualitybased mode anymore in the new builts?
It is still there. Click on a zone and choose a quantizer (you can use non-integer values too, which is exactly what the quality rating was doing). I think, it is a lot more transparent this way and not as unpredictable as the old "constant quality" setting that relied on max and min quantizer settings.

[phrentec]

#xvid on freenode(i.e. leguin.freenode.net)

[haibane]

There is something strange occured when i am encoding with the beta2 from koepi's site.
During 2nd pass, the b frame quantizers seems to not follow what i used in the b-frame setting(3/1.00/1.00), the following is part of the debugview capture:
[4044] [ 691] type=P Q: 5 length: 4983
[4044] [ 692] type=B Q: 5 length: 1933
[4044] [ 693] type=B Q: 4 length: 4114
[4044] [ 694] type=P Q: 5 length: 4866
[4044] [ 695] type=B Q: 5 length: 1909
[4044] [ 696] type=B Q: 5 length: 2077
[4044] [ 697] type=P Q: 5 length: 5002
[4044] [ 698] type=B Q: 4 length: 3810
[4044] [ 699] type=B Q: 5 length: 2045
[4044] [ 700] type=P Q: 5 length: 4925
[4044] [ 701] type=B Q: 5 length: 1993
[4044] [ 702] type=B Q: 5 length: 2034
[4044] [ 703] type=P Q: 5 length: 4900
[4044] [ 704] type=B Q: 4 length: 3768
[4044] [ 705] type=B Q: 5 length: 2026
[4044] [ 706] type=P Q: 5 length: 4942
notice that the b-frame has the same or higher quantizer than the p frames. The result has much worse PSNR than my previous encode, which is a intro of an animation. Is this getting better psnr on other types of material?


edit:
i'm sorry for bring up a false repoprt......
after carefull examination.........
i mistakenly enter that wrong quantizer setting......
instead use 2/5 for p frame quantizer, i somehow entered 5/5.......
that is causing the problem........

[Koepi]

haibane:
nope, the formula changed quite a bit. To get the results you'd like to see try an offset of 1.5 (if that doesn't work out try ratio 1.5).

Regards
Koepi

[Hoschi]

Unfortunately we don't have something useful as ffdshow -automatic bitstream & workaround detection- in our xvid decoder (yet). There are plans to add something like that, but they don't seem to be high on the "urgent to do" list.


OK, thanks for the answer. ffdshow does work. Anyway, that means further working with the file does not work, as VD/VDM only use ffdshow for preview (with ddraw enabled), but not for transcode etc. Thats the second time for me I can't decode files done with earlier versions without tricks. So xvid seems not to be archive ready :(

Anyway Ciao still produces files smaller than targeted. It is slightly faster then Aloha. Is it possible the size is caused by adding a zone with lower weight (credits @ 0,30 ) ?

[Manao]

Originally posted by Hoschi
as VD/VDM only use ffdshow for preview (with ddraw enabled) What ??? Since when ? ( that's wrong, DDraw doesn't mean DirectShow ) Anyway, that means further working with the file does not workNo, you can discard the first frame easily, by selecting ranges with VD/VDMAnyway Ciao still produces files smaller than targetedPlease provide data, since nobody else reported that behaviorSo xvid seems not to be archive readyWhy ? Because of the frame diplayed at the beginning of a video ?

@Koepi : When did the formula change ( is this formula (http://forum.doom9.org/showthread.php?s=&threadid=59649&highlight=bframes+formula) still correct ? )

[homersapien]

These new xvid codecs really don't like me...

2-Pass encoding
All options default except VHQ=6 and B-Frames=2
Latest VDubMod
Latest AviSynth 2.5

Problem #1: On large files 1.5+ gigs, video gets largely out of synch after ~the 1 hour mark. Playback is not a hardware problem on my part (tried 3 different machines.) Anyone else do a ~2gig file with b-frames and have this problem?

Problem #2: I sometimes can't run avs files. Even with: avisource(c:...) and all codec settings at default. Both jobs run like normal, except each pass lasts for less than a second.

[cipher]

@Manao
The formula of bframe quantizer given by your link is NOT right.
B frame qaunt. equation has never used that equation if I remember correctly :)

I'm wondering why mf and sysKin didn't correct that formula in the thread, maybe they just didn't pay too much attention on the formula? :)

bframe, by its name - bidirectional frame, should reference previous AND future frames, how could its formula use only the previous p frame only ? :)

and bframe has been using this equation by now:

bvop= ((previous vop Q. + future vop Q.)/2)*ratio + offset

bye

[BoNz1]

Originally posted by Bulletproof
Is reduced resolution supposed to be working? I seem to be getting some weird artifacts when enabling it or it just crashes sometimes when decoding.


Yup, it works but only for ARTS profile. It doesn't work with b-frames, qpel, gmc and interlacing. Well, I don't know if it does work but who knows it may but it certainly will not be compatible. If you want to decode reduced resolution you must use the XviD decoder and _not_ ffdshow or else you will see nasty artifacts like you described b/c ffdshow doesn't support reduced res decoding.

[nanji]

Originally posted by Manao
nanji : I think you're right ( and I don't know how I came to think one could enter a 2GB+ filesize in the interface, since the size is in KB :rolleyes: )

Beta3 yet?

[Alxemi]

Hi all, here is my crash report.
This is the first time XviD crashes in my system, i´m under a duron800 with 128 SDRAM (133), graphics ati radeon 9100 and Windows XP SP1

Using latest (1.5.10.1) Vdubmod and Ciao, crash in the first pass.
Here are my XviD settings:

Profile: Unrestricted
Matrix: HVS better, Trellis quant activated
QPEL, GMC, Reduced resolution

BVOPS 2, 1.50, 1.00, closed GOV
MTP 6 (ultra high)
VHQ 1
Maximun I-frame 250
Special Zone for credits starting at frame 138960
Desired size 604000
Other settings by default, credits at quant 24

The movie was DareDevil, and here is my avisynth script (using 2.53):

#Avisynth Script Starts
LoadPlugin("C:\ARCHIV~1\GORDIA~1\mpeg2dec3.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\undot.dll")
LoadPlugin("C:\ARCHIV~1\GORDIA~1\mipsmooth.dll")
mpeg2source("E:\daredevil\p1.d2v")
crop(2,74,716,428)
BicubicResize(576,240,0,0.5)
Undot()
Lumafilter()
MipSmooth (preset="movieHQ")
#Avisynth script ends

Also here (http://138.100.51.162/~alxemi/error.zip) i have a zip file with a screenshot of XviD stats at the moment of the crash, and a txt file with the info XP gave me.

The reduced resolution setting was a mistake :/ I don´t know what it really does... anybody who could please explain? :)
And what about Bframes-trheshold? is it lost forever or will return in future versions?

Thank you all and take care.

[Koepi]

Alxemi:

As you were editing zones you'll sure just have overseen that bvop threshold can be adjusted exactly there.

As stated many times in the aloha and this ciao thread, reduced resolution is for ARTS (Advanced Real Time Simple) mpeg4 profile - it's for streaming only. It encodes a Reduced Resolution and thus degrades quality significantly, don't use it for backup purposes.

Does "XviD" still crash if you set credits quant to 16 instead of 24? Maybe we didn't cap quantizers correctly(and bframes quant would be >31 if you use quant24 setting), but i fail to see where this would happen, it always worked correctly here.

Koepi

[Manao]

@cipher : thanks ( strangely enough, when I read the formula given by superdump, I understood it as yours ). But then, I don't understand Koepi's answer, since in haibane's case ( asserting he didn't make his mistake with capping quants ), B-frame's quantizer should have been 6 ( with your formula ). That's why I asked if the formula changed.

@Alxemi : can you reproduce the crash ? And you're very hard on your system, because b-frames / gmc / qpel / mipsmooth are very demanding concerning the memory ( and so, what happens without some of these options / filter ? ).

Oh, and a tip for screenshots of such windows : use png format, it's lossless and it compress better than jpg with that kind of picture.

[Alxemi]

Koepi:
Thanks a million for your help and explanations. As you said, I overseen the bframe sensitivity in the zone tab... or i thought it was something different that threshold.
About the credits quant, well (as you can see in the xvid stats screenshot) the crash was at frame 28893, and my credit zone started at 138960... could be but it sounds weird to me :P
I will try again tonight without the reduced resolution setting and with the same credit quant. If it fails, i´ll change the quant and see what happens. Unfortunately i can only encode at night so my reports will be distants in time.
Anyway i think the most probably cause is the operating system itself... i have only 128 mb of ram and xp uses to joke with me.

Ciao all! :)

[Alxemi]

Manao:
Well you are right about my system... but this last encode was at 6/9 fps... I encoded animatrix at 1 fps (VHQ=4 was not a very good idea xD)
Anyway as i said in the post before i´ll try tonight and post.

read ya :)

[raz0r]

could you please try to get it working on ess players for the next build? i think its very important that it is playable on standalone players. Or does anyone have an ess player and can play the new xvids on it? perhaps im doing something wrong...

[crOOk]

When using certain zone scenarios the rate control seems to be disabled. SecondPass size is then equal to FirstPass size. I've already mentioned it in another thread (http://forum.doom9.org/showthread.php?threadid=66181) (along with the keyframe bug). I'm sorry to post it again and hope I'm not bugging (I finally found out that word's origin :D) anyone.
This has also been mentioned by Emp3r0r in this thread (http://forum.doom9.org/showthread.php?threadid=66268).

crOOk

[wannabe]

raz0r: I think thats already fixed, since this new beta 2 is MPEG4 compliant it should be supported by standalones. Altough you have to have players(such as the KiSS DP-500) that supports the approparite profile level (AS @ L5).

[olnima]

No, Beta2 seems not to work on ESS-Playern (yamada 6100). devAPI3 does.

Olnima

P.S.: I'm still waiting exactly for this point to use it as my new "default-codec" :)

[Nibor]

OT:
I think the Codename of the new Beta will be the Japanese word for 'Hello' ;)
My thoughts:
Aloha is 'Hawaiian' for 'Hello'
Ciao is Italian for 'Hello'
-> the next letter in alphabetical order is J
-> Japanese for 'Hello'

:D

Cheers!
Nibor

PS: Thank you all (developers, testers...) for XviD 1.0 :)

[mazzo]

As far as I know, there are two dvd players that play Divx - Kiss and Liteon. What settings should I use to ensure compatibility with these players and what settings should I avoid?

[raz0r]

Originally posted by mazzo
As far as I know, there are two dvd players that play Divx - Kiss and Liteon. What settings should I use to ensure compatibility with these players and what settings should I avoid?

dude, there are dozens of dvd players playing divx and xvid.

dont use qpel, gmc or bframes. there is a new player which can decode qpel, but xvid+gmc is still not working 100% right (divx+gmc works since long time with every ess/sigma player). bframes+divx works, but with xvid you get a fucked up picture.

[Koepi]

To explain the GMC-thing:

it was working well when xvid had such a limited GMC implementation like DivX has - 1 warppoint GMC. But XviD has 3 warppoint GMC which is currently not supported by i.e. Kiss players.

Using a search on this topic, using more than the last 30 days will give you some results concerning GMC, bframes et al.

Regards
Koepi

[Teegedeck]

Hm, I've done two first passes on the same movie, with beta1 and beta2; beta2's filesize was smaller by 4.8%. Could the effect of some tweaks on mode-decision (edit: and ME) be that big? Anyway, guess I'll have to use Andreas' 78er matrix, now, and do another first pass. :D

No problems to report from here.

[Hoschi]

@ Manao:



As I have a large number of files encoded with xvid - I noticed that some files do not decode properly. Keyframes are OK, but all other frames are scrambled.

Is 1.0 incompatible to older releases or are these problems caused by errors of earlier releases ?

24062003 decodes properly...
I do not use ffdshow, playback using divx5 improves the image, but still some errors. What did I miss ?


OK, you missed my first post and I forgot to quote it - my fault with mixing up topics.

I had with 24062003 trouble to playback a few files done with 04102002, and now I can't play a few files made with 24062003 using ciao for decode. ffdshow fixes playback for wmp etc., but not for VD.

Koepi stated that one day xvid may be able to decode all the streams done with earlier versions.

-> not ready for archiving ?
Any ideas ?

[Manao]

Originally posted by Hoschi
ffdshow fixes playback for wmp etc., but not for VD.In that case, change the FourCC code of your video to DX50, and VDub will use DivX5.1 to decode the XviD files properly. But I didn't have that issue ( well I didn't try thoroughly neither ) Is it systematic ?

Edit : @Teegedeck : well, I got 7000 more b-frames on one encode, that explains the drop in filesize.

[Teegedeck]

Do you perceive (not measure) any difference between the two files? I haven't spotted one on those two 2nd passes, yet.

[Alxemi]

Hi guys.
I am now encoding again with the same settings but reduced resolution.
In the first pass, actual frame is 45550 (20000 more than the frame that crashes) so it seems that the problem was my system, or Reduced Resolution (¿?)
Anyway i have something strange here when comparing with the first encode:

NOW:
Actual Frame: 45550
Minimun I-Frame Size: 1667

CRASH:
Actual Frame: 28893
Minimun I-Frame Size: 578

How can it be? there is a frame that was enconded to 578 that now doesn´t exist... Could be because of reduced resolution? All the other settings are the same... :?

Thank you all and take care

[Manao]

Well no, because I didn't make the second pass with beta 1.0 ( look at the beginning of the thread to know why ) But I compared with the beta 1.0 + Qpel, and visually I prefered the result ( I don't like QPel, at least on animes ). SSIM value was also higher, but that doesn't mean a lot a thing. And frame by frame, the comparison was difficult ( because b-frams weren't at the same place... )

[wing1]

It's been a long time since I've download new build from xvid community, and the beta2 version is kicking a** and taking names!!!!! "you have come a long way baby" :D All hail to XVID.

[MajinMarc]

Hello Everyone. I'm an encoder who has been using Xvid for a little over a year and a half now and I'd have to say that my knowledge on the codec is pretty good although I know it's not the best. I'm sure I'm gonna say somethings that have already been said but I'd like to give my full opinion of the new codec. From what I been testing since it was released is a slight increase in speed of the second pass. for me usually 15-20 mins on a full length approx 25 min encode. The cartoon mode seems to give my encodes(I'm exclusive to anime) a nice quality boost as well as I'd have to say better motion detection. I have noticed however that some of the avisynth filters such as Warpsharp are having at times strange effects on the very begining of the video when running Xvid Beta 1 or 2. In the upper left corner it is always pulled out usually for the first 5-7 seconds of video and then is not seen again throughout the rest of the encode. I have tested the same avs with the older xvid binary and have not seen this error at all. Might be a problem with Xvid or something very different. one can only guess. Next I'd like to comment on the Gui. This may seem like an old topic but I think the old Gui blows this one out of the water. the other one was more organized and easier to use, and was the best use of space. I really think you should consider going back to the old one and just adding the new profiles, and the cartoon mode onto it. The Overall Quality of this codec is very nice and has about 20% less blockyness on encodes which I purposely undersized for testing purposes which I'm proud to say is the reason that I choose Xvid, amzaing quality for low size. I'd like to thank the Entire Xvid team for putting out a superior codec.

[Teegedeck]

Thanks for your feedback! The GUI is definitely subject to change.

Could you describe your problem with warpsharp a little more detailed? Don't forget to use resolutions and other settings identical to those of your encodings that didn't show problems.

BTW, using paragraphs makes for easier reading. ;)

[MajinMarc]

Originally posted by Teegedeck
Thanks for your feedback! The GUI is definitely subject to change.

Could you describe your problem with warpsharp a little more detailed? Don't forget to use resolutions and other settings identical to those of your encodings that didn't show problems.

BTW, using paragraphs makes for easier reading. ;)

Yeah sorry about the whole paragraph thing. I'm a little new to posting on message boards so sometimes I just type. I thought since these boards have given me so much it's about time I began to give back.

ok the warpsharp problem. I got done testing it on 2 different resolutions with the same result. 640X480,512x384(setting in which I discovered the problem). I'm gonna give as best a description as I can. if you take the video to fullscreen in the upper left corner. there is a drastic fold inwhere you can see the film reel and a black space in the upper left. I don't have any program onhand that can take a picture of directshow videos or I would put it up. To give this problem a better view it's like turning warpsharp up WAY too high the setting I was using is ridiculously low. Warpsharp(Video,7,2) on this particular encode. if you can find me somewhere to send a clip I'll gladly recreate it again and send it to someone for viewing.

Yeah and lastly I forgot to mention this before. I have been having problems with filesizing. using the latest vdubmod(Excluding Gknot cause I know they aren't fully compatible yet) I have set a full 25 min episode to 225000Kb and then encoded it, and it came out to 25MB. now I've had it do this intermittently 4-5 times while I was testing. so I'd say every 2 or 3 encode tests it would mess up the size. I currently use-HDTV profile. Cartoon mode, VHQ1 or 4(sometimes I switch for testing purposes) Chroma Motion. all the rest are defaults.
The Xvid testing seems to be going well with alot of feedback. So I look forward to future fixes but it looks like Xvid is on the right track, in my opinion it has passed Divx as the best video codec.

[Xndo]

though i do tend to agree with marc, warsharp has its limits, but the question i would ask him is, with the extremeness of your setting, why do you want to use it, cause it can cause a 2 to 3fps loss when encoding, also msmooth used at higher settings result into a 1fps encoding time. Though i have to say, the filesize program has been there along time. I've resently tested with a few encodes and got a 30min episode undersized by 100mb's from a target size of 200mb's. The quality lose is out of this world, kinda looks like looking at a rm file at 4x2 sometimes. yes the GUI of xvid 1.0 beta 2 has alot of work to do. The old one is a better choice, cause its easy navigation. warpsharp has major affects depending on what your using. if your using deen with a3d and 8,10,2,8, it has some unwelcomed blurryness. As for your Divx Comment, to hell with that crap. 5.05 was better compaired to 5.1 or 5.1.1 it seems it renders avi's useless or gives you that lovly -100 or 100 error code in vdubmod. so Divx can bite me on that note.


Also if anyone else is haveing this problem. Xvid resently has been giving me messed up avi errors, errors like " file type unsupported, or no codec installed" this is after I changed back to the one in the GKnot codec pack. I have to mux it into a ogm before I can even view it. Funny seems as if its missing headers or something. Must be a registry problem or something.

[MajinMarc]

Originally posted by Xndo
though i do tend to agree with marc, warsharp has its limits, but the question i would ask him is, with the extremeness of your setting, why do you want to use it, cause it can cause a 2 to 3fps loss when encoding, also msmooth used at higher settings result into a 1fps encoding time. Though i have to say, the filesize program has been there along time. I've resently tested with a few encodes and got a 30min episode undersized by 100mb's from a target size of 200mb's. The quality lose is out of this world, kinda looks like looking at a rm file at 4x2 sometimes. yes the GUI of xvid 1.0 beta 2 has alot of work to do. The old one is a better choice, cause its easy navigation. warpsharp has major affects depending on what your using. if your using deen with a3d and 8,10,2,8, it has some unwelcomed blurryness. As for your Divx Comment, to hell with that crap. 5.05 was better compaired to 5.1 or 5.1.1 it seems it renders avi's useless or gives you that lovly -100 or 100 error code in vdubmod. so Divx can bite me on that note.


Also if anyone else is haveing this problem. Xvid resently has been giving me messed up avi errors, errors like " file type unsupported, or no codec installed" this is after I changed back to the one in the GKnot codec pack. I have to mux it into a ogm before I can even view it. Funny seems as if its missing headers or something. Must be a registry problem or something.

Well All I can say is it differs depending on the anime. I usually work with anime's that have an insane amount of video noise. almost to the point to where I should just put a overlay saying the people who mastered the DVD's should be shot in the head(sorry for the graphic gratuity).

Secondly I do know that the filesize problem isn't very prolific in any of the other xvid codecs. I can only assume that you have an incorrect setting or something cause I have done somewhere around 500 tests and it has hit my filesize everytime except once or twice. The new codec however is doing it blatently to me but when I reverted back to the old version the problem went away. so I can probably safely assume that it is probably a minor glitch in the codec itself.

ok and lastly it's all about settings when messing with Warpsharp. Sure it's possible to lose 3fps if you set it too high. but usually when I take my encoder to the max and use no filters other than cropping and resize I usually only get 10fps anyway. so when I add my filters(Deen, Warpsharp, convolution, Fluxsmooth among others I usually at my best cleaning settings get around 4-6fps which isn't bad considering how great the noise cleaning that these filters provide.

I'm gonna recommend you take a look at your rgistry for GKnot and Xvid, and make sure that something isn't messed up, or just format and start over if you have the time and resources. So Good luck with that.

[DaveQB]

Thanx to all developers and contributors; XviD is the best current codec going IMO.


Originally posted by Hylas
It is still there. Click on a zone and choose a quantizer (you can use non-integer values too, which is exactly what the quality rating was doing). I think, it is a lot more transparent this way and not as unpredictable as the old "constant quality" setting that relied on max and min quantizer settings.

I am struggling with this. Where is it ??? and what do you mean by zones ?? /me lost

I also, found that Beta 1.0 encodes slower then previous builds (having been using Nic's 16th of July build. It seems only 1-3 FPS. Getting QB encoding working will give me a more accurate comparision (other then that all other variables are the same...besides codec :) )

My limited use hasnt presented any errors or problems thus far.

Thanx all once again.

[m0rtal]

I've found a bug... I think :)
Last night I've playing with my AverTV and new XviD build... and found out that Chroma optimizer brokes picture - look:
http://m0rtal.offers.ru/bnw_w_croma_optimizer.jpg
turning Croma Optimizer off removes artifacts...
but this issue is actual only in Grayscale mode...

[dimzon]

Just GUI Suggestion - please add CLI (Command Line Interface) ability (like in DivX)

[DaveQB]

Originally posted by DaveQB
Thanx to all developers and contributors; XviD is the best current codec going IMO.

I am struggling with this. Where is it ??? and what do you mean by zones ?? /me lost

I also, found that Beta 1.0 encodes slower then previous builds (having been using Nic's 16th of July build. It seems only 1-3 FPS. Getting QB encoding working will give me a more accurate comparision (other then that all other variables are the same...besides codec :) )

My limited use hasnt presented any errors or problems thus far.

Thanx all once again.

i think i have found Zones. So let me get this right (and for others in the same boat as me)
if you add a Zone to start at frame 0 and set a Quantizer for it, the bitrate settings is overriden for the entire video ???
The bitrate settings dont fade out, so this makes it a big ambiguous as to whether it takes and effect or not

signed
Lost with new GUI

[mf]

Originally posted by m0rtal
I've found a bug... I think :)
Last night I've playing with my AverTV and new XviD build... and found out that Chroma optimizer brokes picture - look:
http://m0rtal.offers.ru/bnw_w_croma_optimizer.jpg
turning Croma Optimizer off removes artifacts...
but this issue is actual only in Grayscale mode...
Chroma optimizer is useless in greyscale. Greyscale means no chroma, so it's better to turn chroma opt off too.

[m0rtal]

Originally posted by mf
Chroma optimizer is useless in greyscale. Greyscale means no chroma, so it's better to turn chroma opt off too.
ok, but isn't it strange that CromaOpt generates such artifacts?

[mf]

Originally posted by m0rtal
ok, but isn't it strange that CromaOpt generates such artifacts?
Yes and no. I don't know XviD internals, but it's easily possible that when such settings conflict the chroma optimizer gets strange chroma data, causing weird effects, etc. There are only two solutions: The developer changes the code so that when greyscale is turned on chroma optimizer can't be turned on, or, the user recognizes that it's better not to use conflicting functions with eachother, and doesn't use them together :sly:.

[Alxemi]

Ok but what happens when you have a movie with both color and B/W scenes (like American History X or The Pianist or many others) If you want to use chroma optimizer in the colored parts, It´s mandatory to create zones to avoid the problem? Or the artifacts only appears when you use the greyscale setting in XviD? (in that case the solution could be not to check it and thats all)

[Teegedeck]

There should be no problem as long as you don't use these two contradictory switches at the same time. But to be 100% sure: Just test it and report back to us. ;) I'd be very surprised if XviD couldn't handle B/W-movies all of a sudden with chroma-optimizer.

[m0rtal]

Alxemi
what's the problem? just make new zone, where turn off chroma opt and turn on grayscale mode... and vice-versa :)

[Alxemi]

I will encode The Pianist tonight, with color and BW scenes mixed, everything with Chroma Optimizer and without Greyscale... lets see what happens

[Koepi]

Thanks Alxemi,

that's the spirit :-)

Best regards
Koepi

[mikeson]

Thanks all XviD devels for their great work!! :)

May I ask if it is normal that when I use Adaptive quantization, some quantizers are not integers but floats (like 3.11, 4.16 and so on)? It only happens in 2nd pass of Twopass encoding (I haven't checked Single pass) when I turn Adaptive quantization on no matter what other options are used. Checked by ffdshow's OSD.

[m0rtal]

BTW, I have minor cosmetic change proposal:
in XviD Status window in "Quant" section it would be useful to add "Average Quant" value besides "Min" and "Max" :)

[Teegedeck]

Originally posted by mikeson
Thanks all XviD devels for their great work!! :)

May I ask if it is normal that when I use Adaptive quantization, some quantizers are not integers but floats (like 3.11, 4.16 and so on)? It only happens when I turn Adaptive quantization on no matter what other options are used. Checked by ffdshow's OSD.
Yes, that's the way it's supposed to be. What you see is the average quantizer of that frame, calculated from all the blocks in the frame - which have different quantizers due to adaptive quantization.

[mikeson]

@Teegedeck: Thanks for clearing it up. ;)

[MajinMarc]

Just curious. When using custom matricies does anyone else have the problem with it crashing vdub/nandub/vdubmod 40-60% of the time? I try to stick with the basics but I'm usually heavily curious sometimes and like to mess with things I find(Filters, Matricies, programs, avs scripts(mf's slow ass mftoon,1fps no matter how fast your pc is :p). Any help would be appreciated. I'm currently using Xvid 1.0 beta 2.

[Hoschi]

@manao:

changing the fourcc does not work for VD.
HM, if you like to try it:
http://hoschi.roko.goe.net/crash.avi

its a 20 second sample (2 keyframes), 1,67 MB.

[Manao]

Hoschi : changing the fourcc to DIVX does allow VDub to use DivX5 to decode the file. But of course, first, it has to be installed on your computer, and second, it will still present some artifacts since you used GMC for encoding your clip ( at least that's what FFDshow told me ). GMC never worked well with Dev-Api-3, and was never ( I'm not sure about this ) compatible with DivX5 implementation. It's GMC which causes the artifacts. What you may tried is to install ffvfw, and use it to decode your clip ( I didn't try, I don't know if it can handle GMC properly ).

[Dreassica]

Originally posted by MajinMarc
Just curious. When using custom matricies does anyone else have the problem with it crashing vdub/nandub/vdubmod 40-60% of the time? I try to stick with the basics but I'm usually heavily curious sometimes and like to mess with things I find(Filters, Matricies, programs, avs scripts(mf's slow ass mftoon,1fps no matter how fast your pc is :p). Any help would be appreciated. I'm currently using Xvid 1.0 beta 2.

ahem... I'm getting 2fps with mftoon in the script and im only on an Athlon xp 2000+ :D

[mf]

Originally posted by Dreassica
ahem... I'm getting 2fps with mftoon in the script and im only on an Athlon xp 2000+ :D
I get 3fps average :devil:.

[MajinMarc]

Originally posted by mf
I get 3fps average :devil:.

HAHA very funny guys but I dun think my p3 1.3ghz 256MB RAM can even hope to match you guys. now if you wanna send me some free hardware be my guests. :cool: Although your filter is highly effective mf I think you might consider somehow speeding it up.......I forgot to say something.....STOP GLOATING OVER YOUR MAD SPEED... HAHA. :sly:

[Hoschi]

@ manao:

thanks, I had 5.0.1 div5 installed, but in VD that crashes. Playback is with less errors, correct. At last we know the reason for the trouble, with some time maybe the gods (aeh, developers) may help :p

[alucard83]

Originally posted by mf
I get 3fps average :devil:.

Same, actually, more like 1-2 with hardly any filtering on. Beta1 gave me 8-11 FPS on avg. =\

[Emp3r0r]

I wanted to chime in here and give some positive feedback on the new GUI. I really like the new GUI and think that once any bugs are smashed, it'll grow on people. My first impression was "this is different" but after looking around it is much easier and faster to use. Also, the zones seem to be causing some confusion, however, once there is some documentation, I think everyone will realize how powerful these zones can be. Just my 2 cents.

[EthanoliX]

That's what I think, too.

After you got used to it, it's as easy to handle as the old dev3 one.

But there ist one feature missing (don't know how difficult to implement): an "import chapter list button" to make it more easy setting up the zones.

[Northpack]

Firstly, many thanks to the XviD Team for continuesly developing an open source codec that´s going to beat out all the commercial ones!

Then i wanted to say that i got the very same artifacts as m0rtal posted after encoding the bw-movie PI with chroma optimizer turned on. There are big blocks of different colors in almost every scene consisting of a cyan-colored grey and a yellow colored. Is it a bug in Xvid or is chroma optimizer a no-no when encoding bw-material?

[Blueseb]

Funny GUI bug:
in zones configuration set the rate control slide to 0, then raise it using arrow left key: it hangs at 0.28, actually 0.29 is not selectable at all. The same appens with 0.57 and 1.13 :confused:

[mf]

Originally posted by MajinMarc
HAHA very funny guys but I dun think my p3 1.3ghz 256MB RAM can even hope to match you guys. now if you wanna send me some free hardware be my guests. :cool: Although your filter is highly effective mf I think you might consider somehow speeding it up.......I forgot to say something.....STOP GLOATING OVER YOUR MAD SPEED... HAHA. :sly:
Read the last post in my mftoon thread, and see how I've been busy with it.

[DaveQB]

Originally posted by alucard83
Same, actually, more like 1-2 with hardly any filtering on. Beta1 gave me 8-11 FPS on avg. =\

i am getting 6FPS with no VD filters just resize and sharpen with AVSynth

was on ~8 with the pre 1.0 builds

early days, see how we go ....

[sysKin]

Originally posted by Northpack
Firstly, many thanks to the XviD Team for continuesly developing an open source codec that´s going to beat out all the commercial ones!What do you mean "is going" ? Was there ever a time when XviD was worse (or even equal) than commercial mpeg-4 competitors?
Then i wanted to say that i got the very same artifacts as m0rtal posted after encoding the bw-movie PI with chroma optimizer turned on. There are big blocks of different colors in almost every scene consisting of a cyan-colored grey and a yellow colored. Is it a bug in Xvid or is chroma optimizer a no-no when encoding bw-material?This shouldn't happen but I can't reproduce this. Do you remember to insert a keyframe every time Greyscale is turned on/off? If yes, when the bugs appear: at this keyframe? At another keyframe maybe? Or at a p-frame maybe... ?
Also, does it happen at two-pass or one-pass too?

Radek

Hah! My 300th post ^^

[m0rtal]

Originally posted by sysKin
Also, does it happen at two-pass or one-pass too?
In my case it was one-pass.
Radek
is this kinda polish name?

[mf]

Originally posted by m0rtal
is this kinda polish name?
Yep :).

[hellgauss]

@blueseb
mmmm... it seems to be 0.28*2^n + 1
eheh

Ciao
HG

PS
Italians say it better :D

[Alxemi]

Hi people, i´ve just encoded the pianist, full color movie with a short black and white intro. I used HVSBest with a high bitrate (1300 more or less), qpel, vhq1, bframes 2 150 75 and gmc. Chroma Optimizer was ON and grey scale OFF all the movie (no zones), and there aren´t any artifacts in the B/W escenes. It´s a short intro, so the results cannot be conclusive at all.
Ah and it was 10 KB oversize ;)

Funny testing guys

[AgeOfPanic]

I have two questions. First I read in some topic a while ago that a feature would be implemented in Xvid to make it possible to do an anamorphic encode. I'm not an expert, but it had something to do with writing the correct AR in the header. How far are you with implementing this?
The second question is about the problem the codec has with decoding. Is this problem because the beta does something wrong when encoding or is this just a decoding problem?

[DaveQB]

anyone find the QB settings ??

i tried making a zone starting at frame 0 and using a Quantizer, but it didnt matter what i picked it encoded at the bitrate set on the previous page; the first GUI page.

[Pen-Pen]

Originally posted by EthanoliX
That's what I think, too.

After you got used to it, it's as easy to handle as the old dev3 one.

But there ist one feature missing (don't know how difficult to implement): an "import chapter list button" to make it more easy setting up the zones.

that would be nice indeed :)

and thx to the developers ! my first tests were astonishing ;)

@DaveQB, you just have to define a zone and chose your quality based mode (weight or quantizer) in the edit tab ;)

[Sofus]

I have one question. Has any one tried using the new Intel 8.0 compiler, making XviD builds, any speed improvement?

Sofus

[DaveQB]

Originally posted by Pen-Pen

@DaveQB, you just have to define a zone and chose your quality based mode (weight or quantizer) in the edit tab ;)


Hmm i tried that, made it 3.00 and got a 2.8 gig file
made the Quant 5.5 and still got a 2.8 gig file; didnt change the file size at, expecting it to be a different size with different quant value.

I'll have to test this some more.

start frame should be 0 or 1 ??

thanx Pen-Pen

[Pen-Pen]

0

I don't get it, it works perfectly for me...

[DanielSun]

Sorry for my crap English.Thankx for the hard work on xvid.Beta1&2 have an obvious speed increment on my computer.But i got some problems when i encoded the movie "big fish" trailer yesterday(using beta2). The trailer was 147 seconds long,and i aimed at 750 kbps.The setting was beta2:h.263,2passes,bf2/150/100 qp,trellis,cm on,vhq4,mp6,nothing else was on.And result was unacceptable at all!
The problem was that the visual quality of the clip was not even,some times it looked good and some times it looked ugly.(especially in the beginning).In other word,IMO,the bits was not properly assigned to keep a constant quality.

Since the clip was short ,maybe that was one of the reasons.But i also encoded the clip in divx511,the result was much better.So i thought some changes in settings may help.But first i'd like you to see the state window of xvid when encoding this clip,the final quant dstribution was shown in the pic.

No matter how i changed the settings(i even make a zone let 0-360 frames weight as 1.50,because big quantizers were almost in the first 15 seconds)there were still a lot of frames' quantizers are 17 or even higher.(Sorry i do not have DRF analyser).And I splited the result in 15 seconds per file.The actual bit rate of the first 15 second is only 385kbps.(501kbps after wighted 1.50).I aslo changed bf settings(like 1/150/0 1/1.50/0.75 2/1.50/0 2/1.50/0.5).But it did not help much.And i also disabled the QP and even trellis,but the result still looks horrible.

I don't know if i had made myself clear.But what i want to konw is:

1.Were the big quantizers appeared in the clip normal at 750kbps???(576*304,normal compressibility i think)

2.Is it a bug or the codec's defect or my wrong settings? Xvid status window (http://cn.f2.pg.photos.yahoo.com/ph/danielsunone/detail?.dir=/Xvid&.dnm=219.jpg)
blocky frame (http://cn.f2.pg.photos.yahoo.com/ph/danielsunone/detail?.dir=/Xvid&.dnm=220.jpg)
ugly frame with strange green lines (http://cn.f2.pg.photos.yahoo.com/ph/danielsunone/detail?.dir=/Xvid&.dnm=221.jpg)

[BiaTch 5.0]

XviD has always had trouble with water, smoke.

EDIT (by koepi, next time do it yourself instead posting 2 posts Biatch): What is the source (DVD, Capture, etc.)?

[Koepi]

DanielSun:

Set the min/max overflow increase/decrease to 20% instead the default 60% and see if it helps the 2nd pass.

Regards
Koepi

[EthanoliX]

Originally posted by Koepi
Set the min/max overflow increase/decrease to 20% instead the default 60% and see if it helps the 2nd pass.

Alway thought it's the other way around: larger values result in a stronger variation of bitrate?

[Ocularis Infernum]

I have finished the daunting task of reading ALL of these replies and I have a few questions. While I have just started encoding no more than a month or two ago, I am no new user and picked up on it quickly (through a lot of reading on here though) and I don't have questions about terms in Ciao.

With beta2, what would you guys say are optimal settings that you have found? I've been tweaking settings and encoding clips again and again, searched through these recent postings, but still had to ask to clear things up for me :). If I missed any, then i'm sorry:) but I just need some bearings here. I'm searching for great image quality around a bitrate of 900-1500kbps.

The DVDs (that I own) that I was using to test my settings are the best quality ones that I have: Gangs of New York and The Whole Nine Yards. The reason I am going to encode some of these is for a computer in the house that has a dead DVD-ROM and the sibling is getting mad :). I've switched between H.263/MPEG and enabled/disabled AQ, etc. I am really not going for a very very small source, because i'm going to transfer it across the network, not burning it, and they have a 160GB HDD in the system.

I realize it can vary but thanks for any starting point with the beta you can give me (I love beta testing and currently have done it with Uru: Ages Beyond Myst)!

Ciao
Ocularis Infernum

P.S.
I have encountered the odd colorful artifacts recently:(

[Manao]

DanielSun : when posting screenshot, use png, not jpg, because here I see more easily JPEG artifacts than MPEG's ones. It won't help you solve your issue ( which is kind of weird, btw ), but it'll help us see your problem.

Ocularis Infernum : it's too soon to give settings. And optimal settings do not exist, they're too depends of the bitrate, picture's size, filters used, watcher, phase of the moon... If time is not an issue, just make sure to use motion estimation 6, VHQ4 and chroma motion. For the rest, the defaults are a good basis.

[Ocularis Infernum]

Originally posted by Manao
DanielSun : when posting screenshot, use png, not jpg, because here I see more easily JPEG artifacts than MPEG's ones. It won't help you solve your issue ( which is kind of weird, btw ), but it'll help us see your problem.

Ocularis Infernum : it's too soon to give settings. And optimal settings do not exist, they're too depends of the bitrate, picture's size, filters used, watcher, phase of the moon... If time is not an issue, just make sure to use motion estimation 6, VHQ4 and chroma motion. For the rest, the defaults are a good basis.

Alright thanks, I'll work from there. Yeah, time isn't an issue...I have forever to do this :)

[Manao]

A possible bug, in the two pass algorithm. I was making encodes of The Hours, using different settings ( matrices, treillis ), and I never hit the wanted final size :

I made five encodes, each having the same basis : An avs with only cropping and lanczosresizing to 640x352, adaptive quant, gmc, b-frames 2,1.5,0.75,0, ME 6, VHQ 4, chroma motion. No QPEL, no cartoon mode, no reduce resolution, no quant restrictions. Credit beginning was set to 158400 ( of 165088 ), with a ratio of 0.2. ( I think the problem is here ), and no force keyframe nor greyscale. I was aiming at a final size of 579 384 Kb, and second pass's settings were defaults ( 0,1,20,60,60,0,0,10 : it's beta 2.0 )

Then, the specific settings, for each encodes, plus first and second pass size :HVS_GOOD + treillis : 1 047 592 --- 586 790
HVS_GOOD - treillis : 1 037 162 --- 586 602
H263 + treillis : 1 182 586 --- 583 448
H263 - treillis : 1 242 448 --- 583 308
HVS_GOOD + treillis + undot : 1 011 640 --- 586 202I investigate more closely on the quant distribution in the credit range, and the codec didn't saturate. But strangely enough, the size of the credit was smaller with HVS_GOOD than with H263, whereas deviation is greater.

I don't see where I could have messed up : the quants are not restricted, the compression ratio between first and second pass is normal, so I really think somethings wrong with ratio in zone settings. I didn't get any problem when using zones with const quantizers on another movie.

PS : I really do not like the interface. I did several mistake while configuring the codec for each encodes, because I had to reach each settings I wanted to change in a lot of different places, and I often forgot to change one or two settings. I prefered the tabbed version, at least for bench-testing.

[MoonWalker]

Hi,

I just a test on Adaptive quantization (Lumi masking) on a very dark movie(They).They Movie was 1h26m long..I did a first pass (quant 2) with Lumi and No Lumi masking on. The avs was a standard one with only crop na lacnzos resize.I used MP6, H.263, CM. All the others were off.


Without Lumi Masking : 575 MB (603.867.136 bytes)
With Lumi Masking : 566 MB (594.536.448 bytes)

The speed was the same in both tests..The quality was quite similiar.(although I prefer the No Lumi avi :) )

MoonWalker

[Koepi]

manao:

it's possible to not reach 20% bitrate even at quant 31 - watch out for that. Better use fixed quant credits encoding.

Regards
Koepi

[Manao]

I've just checked : most of the time, quants are around 16-18. Sometimes, they reach 31 for a period of 1-2 sec, then go down to 16-18 again. Sometimes, they go down to quants 2-3 ( in case of fades between black and fixe credits )

Credits last 259 secondes, and have a size of 3118 Kb in case of HVS_GOOD, and 3948 with H263, which gives us a bitrate of 96 kbits / sec ( didn't think could be so low ) and 122 kbits / sec. The whole movie ( +credits) should be encoded at a bitrate of 702 kbits / sec, so it should be able to respect the 0.2 ratio. What is strange is that the more compressible the matrix, the more deviation there is ( and the smaller the credits are ).

Anyway, I'll stay away from this mode for the moment, using fixed quants instead.

[Roger]

Hello.
I've just checked XviD 1.0 b2 and I have one problem - when I select "Force keyframe" option for 1st pass in zone dialog (I have only 1 zone, beginning at frame 0), I get ONLY I-frames (in video.pass, XviD status window and resulting avi). Video I get is AWFUL (all blocky etc.). This happens regardless other options.
I've read Doom9's guide for XviD, but he doesn't mention this, as far as I know. Is this a bug, or a feature (= and I didn't understand this option)?
Thanks.

[Koepi]

This feature is meant to start a zone with a keyframe, but we implemented it in b1 and b2 as make all frames in the zones keyframes.

Consider this a bug (already solved in prebeta3, let's see when it's time for the release...)

Regards
Koepi

[celtic_druid]

Cool just did a CVS compile... no more bframe decoder lag with the dshow decoder and it has pp and brightness control as well as vertical flip.

[Heini011]

hi,

sorry if the following problem is already known, but here so are many postings, which confusing me ;-)

if i enable 'display encoding status' the quantizer bars at are shown in the wrong window or at other positions on the screen. i use windows me and encode with virtualdubmod.

the b-frame quantizer offset should be 0.5 for default. see: http://forum.doom9.org/showthread.php?s=&postid=411881#post411881

the '%' marking on the quantiszer ratio field is wrong in xvid 1.0 api.

the quality is very impressive. thank you for the great work!

greetings, Heini011.

[Stigma]

Im very impressed by the test results ive seen so far, but I really iss an in-depth look atthe options, especiallythose that are new to 1.0 beta from the old pre-1.0's.

For example cartoon mode. Its supposed to help motion estiamton or anime/cartoons, but a little more detail as to what it does differently from normal would be nice.

IS there info on this around somewhere, or do i just have to searcing the forums until i stumble upon some info by chance?

EDIT: I'd also like to ask the bright people of this forum, what the general concencus for GMC in beta2 is. I hear its not very effective, but that all errors and artifacts that it used to make is now gone, so basicly the only drawback is that you use a lot of CPU for little gain (but without risk). Is this accurate? For reference, i only usually encode anime.

Trellis quant - can someone gimme a quick rundown on what it does differently than standard quat, and wether or not it would be advisable to use for v.high-quality level anime encodes?

How much gain is beeing reported on the cartoon mode BTW? We should expect a slight decrease in size for no decrease in quality right? (I have ittle idea about whats different for the cartoon motion estiamteion compared to normal-mode). Im glad the devs are accomodating us anime freaks tho ^_^

-Stigma

[Teegedeck]

Please Stigma! You must have realized that there is a search button. It's all been said in the threads about the 1.0 beta releases (this is one of them), you can find the info easiest if you choose the 'show as posts' option in search. You'd also have found a thread called 'Cartoon Mode' (http://forum.doom9.org/showthread.php?s=&threadid=65938).

Except for cartoon mode, I'd answer your questions: yes,yes,yes,yes,yes; all of them, combined, + VHQ, slowest motion search, wait a day, enjoy the result. But that's me, Cpt. Spaulding; I'm a loonie and not an otaku.

[Stigma]

Heh, allright sorry. I could have swore i did a search for "cartoon", but i allready read thru 2 XviD threads like this with 10+ pages... gets a bit tedious to say the least.

Thanks for the answers tho, allthough they weren't real deep ^_^

-Stigma

[Leak]

Originally posted by Teegedeck
Except for cartoon mode, I'd answer your questions: yes,yes,yes,yes,yes;

I guess it's worth mentioning that the upcoming next generation of DivX/XviD standalone players will still choke on XviD's GMC, so if it doesn't have much of an effect it's probably better to leave it turned off if you plan on buying such a standalone unit... :)

np: Triosk Meets Jan Jelinek - On The Lake (1+3+1)

[Stigma]

Thanks for the warning, tho im allready aware of this. My encodes arent really designed for standalone units tho, since i use ogm (And i havent heard anything about standalone units beeing able to play ogm in the near future). So, i guess il grab every little extra I can get.

I do have one quick question tho. Does a clip encoded with GMC and Qpel take extra CPU-cycles to decode? Or do i only have to worry about the performance hit in encoding it?

-Stigma

[Blight]

From my HD encode experiments, QPel takes a massive CPU hit. Not sure about GMC, but probably "some" hit.

[ominte]

My encodes arent really designed for standalone units tho, since i use ogm (And i havent heard anything about standalone units beeing able to play ogm in the near future) Just for future reference - It is possible to strip back an ogm file and create a seperate avi file when required for a standalone player.

[Tuning]

Originally posted by ominte
Just for future reference - It is possible to strip back an ogm file and create a seperate avi file when required for a standalone player.
If the audio is mp3 or ac3 then its very easy changing to avi. If its any other audio type you have to transcode them to either mp3 or ac3.(Most standalones only support these audio types for the time being)

[Koepi]

Elta will support OGM in ~2months from now with their Mediatek based standalone I heard in some rumours (-> new firmware).

Regards
Koepi

[Kb_cruncher]

I use ogm for my encodes.I aim for 1050Mb(fitting 4 on a DVD-5)I have been conducting some ongoing XviD1.0beta2 testing over the last week and have come to some conclusions.

My test settings where

SOURCE---DVD:NTSC:29.97FPS:238947Frames:132mins

5% of the movie using the first pass and keeping the file for perceived quality assessment.No prefilters and using the max cropped resolution and resized vertically only to keep AR.

REFERENCE TEST:- BFrames on(3, 1.75 ,1.25) ,VHQ1 ,H.263, No other settings enabled

Then i ran the same test with Adaptive Quantisation on ,then Chroma Motion ,then Trellis.


AdQuant gave the smallest size but gave the worst quality While using Chroma Motion together with Trellis gave better perceived quality (less ringing and sharper edges while smoothing larger areas slightly)and giving a smaller size than the reference test.Not as much as AdQuant though.

So as a conclusion to this part of my testing i will use - H.263 VHQ1, My chosen Bframe settings, chroma Motion and trellis.No Adquant and i never use QPel or GMC because XboxMediaCentre cannot use them either and they slow encoding down a lot(especially QPel).

I used sharp resizing so using H.263 rather than MPEG gave acceptable sharpness while adding to the perceived quality.

This gave me a whole movie filesize of 1733Mb(Using no BFrames or VHQ was over 2.1Gb)

I will carry on using the first pass test with my chosen xvid settings and try some avisynth prefilters and reduced resolution to try and reduce the filesize some more without taking away from the original reference test percived quality.

I'm pretty sure i won't reach my chosen filesize so once i have found the best prefilters and resolution i will go on to the second pass and restrict quantisers until i reach my filesize.All previous tests use Quant2 for I,P frames and Quant4 for B Frames as these are what the first pass use(XvID Status is a great tool)

If, after all this, My lowest allowable personal perceived quality is not kept then i guess i'll consider uping the target size.


Obviously i won't use this method(i'm not even sure if its a valid method but the results speak for then selves) on every encode but i have learned a lot about what settings give good results and hopefully i won't be left wondering "did i encode this one well enough ?"

My post went on far longer than i expected but i hope someone gets something from it.

Just when i thought i was out XviD1.0 pulled me back in(GodFather anyone)I've been using rv9 for a while. Shame on me :rolleyes:

Keep up the great work guys.

[Stigma]

Originally posted by ominte
Just for future reference - It is possible to strip back an ogm file and create a seperate avi file when required for a standalone player.

I'm aware of this too, but since my ogms use ogg audio format (2 audio tracks), and subtitles for atleast 1 language, it not possible to convert it back to avi without dropping the subs atleast. (unless i reencode and "burn" the subs into the vid.

-Stigma

[Yasu]

My first post.

I use "Koepi's XviD-1.0-Beta2-05122003.exe".

From "Koepi's Xvid-1.0-Beta1-30112003.exe"
I have these matters.

My Os
Windows XP Japanese Edition + SP1 + Bugfixpathes

Profile Tab
BVOPs section
I see the "Packed bitstream" checkbox.
But I can't see below it.
In Doom9's guide for XviD 1.0, I saw what I could't see, "Closed GOV".

Advanced Options...
Debug Tab
I see the "Print debug info on each frame"
I can't see below it.
According to Doom9's guide for XviD 1.0,
what I could't see is "Display encoding status".

Can I make me understood?
I apologize my poor English.

Yasu

[Koepi]

Welcome aboard Yasu!

Can you please check whether you enabled "big fonts" in your windows display properties? If it's checked, switch it off.

I hope this helps.

Regards
Koepi

[HarryM]

Here is modified version of 'xvid.ax' (http://sgfan.ic.cz/download/xvidaxmod.zip), without nag 'B-FRAMES DECODER LAG' messages. ;)

[Koepi]

HarryM,

beta3 doesn't have that anymore as well. I'll put the proper standalone decoder online soon.

EDIT:
New standalone decoder is online - fresh "from CVS". Included: new, very fine postprocessing (but it's slow, have a 1GHz+ machine at hands ;) ). Also the nice brightness slider. Find it on my site in my sig.

Regards
Koepi

[HarryM]

Originally posted by Koepi

beta3 doesn't have that anymore as well. I'll put the proper standalone decoder online soon.

Regards
Koepi

Thanks!!! :p

[poochie2]

Can someone hint me where's the old chroma optimizer option, supposing that it's still there?

Another question: using devapi3 or 4 am I allowed to make the first pass in VHQ 1 and the second one in VHQ 4? I did it once but I got shaky stills and I don't know if it was because of that...

Thanks

[mikeson]

@poochie2:
Can someone hint me where's the old chroma optimizer option, supposing that it's still there?

Yes, under zone control (select zone and click Edit).

using devapi3 or 4 am I allowed to make the first pass in VHQ 1 and the second one in VHQ 4?

No, do NOT change codec settings between passes.

[aaar9800]

You can change VHQ in between passes, of course bit allocation won't be as accurate, but it will never be higher than 1% off of what it should have been for a different vhq setting.

The only thing that is not bad to change is VHQ, all others are realy bad to change, afaik.

[sysKin]

I could probably add GMC to the list of options it's *reasonably* safe to change between passes - GMC doesn't change frame sizes too much (even less than VHQ).

Radek

[HarryM]

To stand-alone Koepi's 'XviD dev-api-4 prebeta3 decoder' - On win98se I must activate 'overlay mixer' or forced 'dvobsub', otherwise error in xvid.ax... :mad:

[Koepi]

Originally posted by HarryM
To stand-alone Koepi's 'XviD dev-api-4 prebeta3 decoder' - On win98se I must activate 'overlay mixer' or forced 'dvobsub', otherwise error in xvid.ax... :mad:

Can you enlighten me where the problem is? In plain setups this doesn't happen (else we would have gotten plenty of messages about that before as this is the decoder that ships with my XviD-1.0-betaX-builds....).

Seems somehow ....strange.... to me. Lemme guess, with your "modified decoder" this doesn't happen?

Koepi

[HarryM]

Originally posted by Koepi
Can you enlighten me where the problem is? In plain setups this doesn't happen (else we would have gotten plenty of messages about that before as this is the decoder that ships with my XviD-1.0-betaX-builds....).

Seems somehow ....strange.... to me. Lemme guess, with your "modified decoder" this doesn't happen?

Koepi

Problem is win98se and its default 'system renderer', as per usual...
Under VMR7(VMR9) at win2k/XP is all O.K., as per usual...
At evening I give here the coresponding windows error message.


Simple xvid.ax from beta2 plays fine, also under 'system renderer' on win98se. But it has other vice - when I have installed DivX decoder (divxdec.ax) and xvid.ax together(!), DivX decoder is using for decoding of 'XVID' 4CC.
Seems, that DivX decoder has paradoxly higher MERIT(?) than xvid.ax. If I uninstaling divxdec.ax, xvid.ax is used normally for decoding.

Note: Your newest prebeta3 decoder is O.K. at this problem.

[Yasu]

Koepi, thank you for your reply.

I checked my window's display propaties.
My setting is
-Display-
DPI setting:
Normal Size (96 DPI)

If I check wrong place, please tell me.

I captured my display image.
http://www.h7.dion.ne.jp/~alcadia/png/xvid-1.0-beta2-BVOPs.png


I will appreciate your advice.

Yasu

[Manao]

Just to confirm the bug in the two pass algorithm, using ratio instead of constant quants for the credit range.

I made the same encode, using this time fixed quants ( 16 ), and I got the size I was asking for. The credit size was finally 1 928 Kb ( which is less than what I got in the previous case, which means I didn't saturate in the credit when I was specifying 20% for the credits ).

I hope this will help to find the bug.

@Yasu : I can only confirm that you checked at the right place, and that indeed the checkbox is missing ( well, we can see only its top here on your screenshot ).

[Koepi]

Unfortunately I can't reproduce that :(

It must be something weird with chinese/korean/taiwanese/japanese windows versions :(

Regards
Koepi

[GolovachLena]

I must be missing something. It's about "Display aspect" option on your screenshot. Is it a feature of beta-3? I didn't notice it in Ciao.

[Koepi]

That's new and still being tested.

Regards
Koepi

[HarryM]

@Koepi: My partial mistake, sorry. Interest. ONLY ZoomPlayer (my best-loved player) has troubles with newest xvid decoder. :( Other players, e.g. WMP 6.4 or MPC plays fine, seems... :D

http://sgfan.ic.cz/download/ax1.gif

[symonjfox]

Originally posted by Koepi
That's new and still being tested.
Regards
Koepi
Finally my whishes are true! :D :D :D
I really hope it works; and I hope that future MP4 players (both hardware and software) will support it as well!

Thanks :D

[poochie2]

Originally posted by mikeson
@poochie2:
Can someone hint me where's the old chroma optimizer option, supposing that it's still there?

Yes, under zone control (select zone and click Edit).

using devapi3 or 4 am I allowed to make the first pass in VHQ 1 and the second one in VHQ 4?

No, do NOT change codec settings between passes.

Got it!

[leo_fischer]

@Koepi, Yasu
The fonts used for western characters on japanese windows versions are a bit larger than the default fonts for western windows versions. This can lead to the kind of problems yasu is seeing.
Unfortunately, the only solution is for the window to calculate the proper size based on the font or control sizes, or to make the window resizable (or bigger)

[chemmajik]

Some how XVID just sucks for 1 pass HQ someone needs to fix it, my sheet has worked fine for the last 2 year until the latest builds... Specifically the compression is fried, as u see I am not a newbie I have been here before most except doom9 & a few. I just never did regain my stats from the prior forums... Someone screwed up 1pass somewhere... The priority takes over the whole system makes it crawl... Thats with debug disabled... On a Tbred System well near 2Ghz... Anyways there is a problem Houston...

[Koepi]

Weird post.

How about setting your vdubmod priority to idle(or whichever encoder you use). That's what i do.

Koepi

[mikeson]

@chemmajik:

You proclaim you've been here since beginning (on forum.doom9.org) but you post worse than newbie. You should now how to report bug. If you don't I suggest using Search button and reading FAQs and Stickies... :rolleyes:

[Yasu]

Manao ,Koepi and leo_fischer, thank you for your reply.

It must be something weird with chinese/korean/taiwanese/japanese windows versions.
No, probably only Japanese Window's version.

I reproduced this.

Control Panel ->
Day, Time, Area and Language Options ->
Area and Language Option ->
Area Options ->
Standard and Forms ->

Default Japanese

If I change it for:
English(US) - Ok I can see it.
Korean - I can see it.
Chinese(China) - I can see it.
http://www.h7.dion.ne.jp/~alcadia/png/xvid-1.0-beta2-BVOPs-USENG.png

But
Japanese - I can't see it.
The image is in a former post.

I called Microsoft support but they could't solved this matter.
Only they admitted it.

I found a temporary solution.
When I encode my avis with XviD-1.0-Beta2, I will change Japanese for
English(US).

I appreciate your advices.
Thank you very much.

Yasu

[gino25]

Does vhq work only with p-frames or with p and b frames?

[HarryM]

Originally posted by gino25
Does vhq work only with p-frames or with p and b frames?

What I keep in mind, VHQ works without problems with use of b-frames, but VHQ is applied _only_ for P-frames.
Syskin said at one time, that VHQ algorithm can be principially modified for B-frames too, but VHQ isn't efficient for B-frames.

[Teegedeck]

But that doesn't mean that you shouldn't use it with B-frames, of course.

[gino25]

thank you

[m0rtal]

small GUI tweak:
if chroma optimizer and grayscale can't work together, why don't change checkboxes to radio buttons?
to make sure people don't use them together :)

[HarryM]

Originally posted by m0rtal
small GUI tweak:
if chroma optimizer and grayscale can't work together, why don't change checkboxes to radio buttons?
to make sure people don't use them together :)

I am not big programmer, but I know (I use Delphi and VB at one time), that you can programing 'smart dependencies' of check boxes with help of their attributes (checked=ON/OFF, alowed(state)=ON/OFF, etc.) a relations between them. It is very simple for programming.


e.g.

If (grayscale_checkbox.checked==true) then chromaoptimizer_checkbox.checked=false

etc.

[m0rtal]

Originally posted by HarryM
If (grayscale_checkbox.checked==true) then chromaoptimizer_checkbox.checked=false
good example!

EDIT: this is even better because in this case you can turn either option off, which is impossible using radio buttons ;)

[cypher_soundz]

very nice build , i have some strange results to do with speed. I hope this does not belong in the newbies section :o. Encoding DVD TV episodes (22-29min long) i get around 20/25fps. while encoding a movie i get ~53fps. The first time i installed this build i encoded a episode and i got around 60fps, i just uninstalled xvid and reinstalled and now i am encoding a movie at 53fps.This i find strange , my rig is below in my Sig.
Regards
cyph

EDIT: i'm using b-frames , trelis, luma masking (or what ever the new name is).

[mf]

Originally posted by Yasu
I captured my display image.
http://www.h7.dion.ne.jp/~alcadia/png/xvid-1.0-beta2-BVOPs.png
Looks like the checkbox is there, but it doesn't fit. How about Clicking packed bitstream twice, then press TAB on your keyboard and then spacebar. That should fix it.

[Bluedan]

A few things:

I.
I like to come up again with an error reported by Leak in the beta 1 thread.
It's about the target filesize which will be outranged as soon as you set min I-frame intervall other than 1-3.

So I don't believe it's got anything to do with changing settings after entering the target filesize, as I only entered it once and everything was okay while I didn't touch the min. I-frame interval *and* everything went back to normal after setting it back to 1, but not touching anything else.

This is only an excerpt.please have a look for more detail on page six of this thread (http://forum.doom9.org/showthread.php?s=&threadid=65913&perpage=20&highlight=target%20size&pagenumber=6).

I cannot confirm that setting min I frame interval to 2 is safe for beta 2!
My first encode ended up with aprox 1,2 GB as 2nd pass output with quant being constantly 2 (_not_ intended or capted quants)!
I did then some unreasonable harmless changes in curve compression settings and voilà it worked.
Or maybe it was the sequence of boxes that I opened ..or not? I cannot see an obvious dependency.
Obviously no changes in the dialogue boxes which reflect the "mis"-setting.
At this point I should offer extensive testing as Leak did, but... lack of computing power ATM.

As there's no more need for external curve compression (i.e. statsreader linear scale) it has been stressed out in doom9 guide that now actually all required data for two pass encoding could be entered in toto before beginning with the first pass: Make two queues in VDubMod and let them run one after the other.
For now with the above error occuring I have to check 2nd run while in process!

II.
When I hit the replacement button (...) for the calculator next to the filesize entry and then return to previous window the filesize still shows the number entered. Here it differs from beta 1.

III.
Though cosmetic it might be confusing for the not so experienced users:
When referring back to first pass stats file in 2nd pass setting dialogue the pop up window asks for "save as" filename instead of "Load".
The description here should be more explicit.
Not every former dev-api3 user was always sure about choosing the right stats files in "2pass ext. scaling"-mode.

I start getting used to the new interface.
And also not to forget, I really appreciate the huge step in development for this release! Great thing!

[sysKin]

Originally posted by Bluedan
I cannot confirm that setting min I frame interval to 2 is safe for beta 2!But beta2 doesn't have min i-frame interval at all :confused:

Radek

[Bluedan]

But beta2 doesn't have min i-frame interval at all

You're right. It's not precise. What I refer to is the sequential I-frame treatment:

I-frames closer than...frames

...are reduced by ...%

Though Leak used that term as well he surely refers to it, too.
Whereas he wrote about min.I-frame under advanced options, where I can only find max I-frame interval in beta2 GUI.

[Yasu]

mf, thank you for your reply.
Originally posted by mf
How about Clicking packed bitstream twice, then press TAB on your keyboard and then spacebar. That should fix it.

1.Click the "packed bitstream"; "Packed bitstream" was checked.
2.Click the "packed bitstream"; "Packed bitstream" was unchecked.
3.Press 'TAB' on my keyboard;
4.Press 'Spacebar' on my keyboard.
There is the screeshot.
http://www.h7.dion.ne.jp/~alcadia/png/xvid-1.0-beta2-mf.png

I see selection moved to unseen "Closed GOV" and now I think "Closed GOV" is unckecked.

mf, your method can't fix it.
I appreciate your advice.

Yasu

[mf]

Originally posted by Yasu
mf, thank you for your reply.
1.Click the "packed bitstream"; "Packed bitstream" was checked.
2.Click the "packed bitstream"; "Packed bitstream" was unchecked.
3.Press 'TAB' on my keyboard;
4.Press 'Spacebar' on my keyboard.
There is the screeshot.
http://www.h7.dion.ne.jp/~alcadia/png/xvid-1.0-beta2-mf.png
I see selection moved to unseen "Closed GOV" and now I think "Closed GOV" is unckecked.
mf, your method can't fix it.
I appreciate your advice.
Yasu
When you click "Load defaults", "Closed GOV" is on. So if you follow my instructions, "Closed GOV" will be off. The only nasty thing is that if you forget what you last set "Closed GOV" too (on or off), you won't be able to see if it's on or off.
But let's set this straight, you wanted to be able to change the setting, right? My method allows to.

[GolovachLena]

Is anybody encoding with "Discard 1st pass" option checked off ? I'm constantly getting absolutely silent VirtualDub's crash on the second pass near the end of movie. The first pass goes ok, and the movie looks pefrectly fit into the size/quality i need, but the second pass crashes everytime. How could it be?

[Manao]

GolovachLena : I'm making a lot of test with 'discard first pass' uncheck, and I have no problem at all. Check if you have enough spacedisk to make two passes. The other reason which can make VDub crash silently, is when having another process which has a higher priority than Vdub's. But in that case, enven if VDub is crashing, you're getting your movie just fine. Anyway, I don't think it's the codec.

Oh, and one last thing, perhaps the issue is wiht the first pass, and you're missing a part of the filestat because VDub crashed before closing it. But the most plausible cause is still a disk full.

[Yasu]

mf, I'm sorry.
I misunderstood what you wrote.
When I read your post, I guessed I could see the "Closed GOV".
That is why I wrote my former post that your method could't fix it.

Why I reported this matter is that nobody had reported it.
By the time I read Doom9's XviD guide, I had hardly guessed what I
could't see.

In WindowsXP Japanese version, This happens.
When I called Microsoft support, he used WindowsXP Professional.
He downloaded XviD-1.0-Beta2-05122003.exe and installed it.
On his WinXP Professional version(of cource, Japnanese Edition) this happened.
I found a temporary solution.
I wrote it in my former former post.

I appreciate your advice.

Yasu

[Chainmax]

Do bframes still have to be set at 0/whatever if you don't want to use b-frames but do want to activate syskin's I/P/B frames thingy (can't remember exactly what it was)?

[sysKin]

Originally posted by Chainmax
Do bframes still have to be set at 0/whatever if you don't want to use b-frames but do want to activate syskin's I/P/B frames thingy (can't remember exactly what it was)? It was 0 and it's your only option now. Old -1 b-frames with old keyframe decision is gone.

Radek

[olnima]

Is there any difference between setting B-frames to 0 or disable them?

Greetz Olnima

[Nibor]

Hi!

So here's the first odd thing I've seen so far in beta2 which I think nobody already reported...

The movie is The Lord Of The Rings - The Two Towers (Special Extended DVD Edition), so it's quite a long movie (3 hours 45 minutes)...
I'm doing a first pass with 'Discard first pass' turned off.
I run the encode and everything is just fine, output is ok and the resulting file is around 3GB.

But the status window at the end of the encoding looks like this:

http://niborvisions.gmxhome.de/files/XviD-1.0-beta2_StatusWindow.png

What's strange here is obvious ;)
I mean the screwed average P-VOP frame size, which seems to be causing all the other odd values!

Has anybody spotted something like this before?
Is it already fixed in beta3?

.: Nibor :.

PS: 340 MBit/s :p

[fps]

Originally posted by olnima
Is there any difference between setting B-frames to 0 or disable them?

Greetz Olnima
Setting B-Frames to 0 turns off B-frames(the only way you can do).

[LigH]

The only way? Does disabling the whole BVOP group not deactivate B frames?!

[bond]

you have to set b-frames to -1 to disable them

[Seiby]

Originally posted by LigH
The only way? Does disabling the whole BVOP group not deactivate B frames?!

Uncheck the BVOP box deactivate bframes. There is no need to set the bframes to -1 to disable them in 1.0 beta for me...

[Soulhunter]

[EDIT: Removed... See here !!! (http://forum.doom9.org/showthread.php?s=&postid=415627#post415627) ;)]

[Manao]

@Soulhunter : you may have made some mistakes while copying the numbers : sizes / PSNR for MPEG with or without treillis are exactly the same. It should not ( afaik )

Else, very interesting tests. Astonishing that higher VHQ lowers the PSNR, but since it drastically lowers size, that's OK with me. Seems that VHQ4 is more useful than some were saying. I'm glad not using anything else than VHQ4, else I would find it too slow :)

[Soulhunter]

you may have made some mistakes while copying the numbers : sizes / PSNR for MPEG with or without treillis are exactly the same. It should not ( afaik )
I thought the same, so I run the PSNR test twice on this files !!!

But result was again the same... :(

Only thing I could imagine is that Ive encoded with the same settings twice... :confused:

But I'm 99% sure I haven't done this... :rolleyes:

I gonna check this tomorrow !!!

PS: Here (http://forum.doom9.org/showthread.php?s=&postid=412191#post412191) are the results with DivX 5.1.1

Bye

[Manao]

Damn, even as an XviD addict, I would not have thought XviD would give such high PSNR compared to DivX 5 :D

For the Treillis thing, I didn't test with MPEG matrix, only with HVS_GOOD, and size / SSIM values were different when Treillis was activated / deactivated.

[Soulhunter]

Damn, even as an XviD addict, I would not have thought XviD would give such high PSNR compared to DivX 5
Yeah... XviD v.1 rocks !!! :D

Bye

[Seimour]

I downloaded the first beta of XviD, and I couldn't find the credits tab, I'd like to know it won't be no more on the following releases of this codec. Thnx & bye