Aloha! [Archive] - Doom9's Forum

superdump

30th November 2003, 12:09

Originally posted by Teegedeck
@kastro68: No, GMC still doesn't help with VHQ=4.

But Trellis now works with MPEG-quantization, give it a try.

Thanks to all developers out there who sacrificed their spare-time to give us this! We follow your activities on the ML; though you can't hear us cheering everytime you submit code, we certainly do.

Errrrm, wrong. Qpel, GMC, B-frames, Trellis (for MPEG and h.263), Chroma Motion, VHQ 1-4, Adaptive Quantisation, etc, are all working well. I'm not certain about Reduced resolution but none of you guys should use it. It's just there for completeness really. I don't know if interlacing works either but they are two features that I never use. Oh, cartoon mode works too.

GMC and VHQ 4 work well together. Go for it, use full options if you have time. Use adaptive quantisation (used to be lumi-masking) in certain situations which may require a lot of bitrate but if you play around and get used to it your judgement will be as good as anybody else's. CruNcher's taken a liking to b-frame settings 1/1.50/0.00 and I agree, but the defaults are good too. Someone will have to run a thorough test with a number of sequences to find out if there are any better methods.

Anyway, have fun.

sysKin

30th November 2003, 12:13

Allrighty, let me give you some answers and summarize some bad things we already know:

All options work. GMC also works, but it only helps if you also use VHQ (any VHQ lvl but 0). The gain is pretty small however, and it's very very slow. I don't recommend it as your default setting but you can use it if you want to.

@all: if you want to share any artifact-related bugs PLEASE try at least two decoders: xvid and ffdshow. It's important to tell us what are the results of both.

@mfluder: the above is for you (lol) but I think I know the answer right now: dev-api-3 couldn't encode non-mod16 properly. If I'm right, ffdshow's output should also be wrong.

Known problems: Virtualdub crashes if you use job control. I'll contact VDM developers in a hope that they'll do stuff I should do myself - find the error *in XviD* ;)

Please try: lumimasking. Say what you think. The principe is the same as the old lumimasking but it shouldn't do some mistakes, like the old one did. Ah, it's called "Adaptive quantization" and lies under "profiles" setting.

Have fun :)
Radek

raz0r

30th November 2003, 12:37

i know this is only a beta but somehow the quality is just...bad.
perhaps i did some thing wrong, but i don't think so. also i like the old GUI better :) speed hasn't changed here. oh and my standalone player doesn't play them anymore. i'll wait for final and stay with 24062003

edit: seems like the source is the thing to blame, 24062003 did even worse. well so quality is ok but still wont play on ESS player :(

hellgauss

30th November 2003, 12:39

Thanks to Koepi and all xvid team for this new build!!!

I've seen that there are a lot of changes!
Where can i find the source of this new build without using tools like wincvs...? I'm just looking for something like xvid1_0source.zip to download, if exists...

I need to know how exactly is defined the new config struct to configure VirtualDub.

Sorry for my very bad english...
HG

Blueseb

30th November 2003, 12:44

YABBA-DABBA-DOOOOOOOOO :p

iago

30th November 2003, 12:44

Great news! I was looking forward to this for a long long time! ;)

Thanks a lot,
iago

Teegedeck

30th November 2003, 12:47

Why haven't I read about GMC working with VHQ anywhere on the devel-list. Maybe I should join this IRC thingie.

iago, how nice to see you!

Lefungus

30th November 2003, 12:49

Congratulations to all xvid dev !

About the settings, trust default ones, they're optimal in most situations.

Originally posted by raz0r
i know this is only a beta but somehow the quality is just...bad.
perhaps i did some thing wrong

Without any more informations, we'll just assume you borked the encoding.

crOOk

30th November 2003, 13:04

YEEEEEHAAAAW! Let the testing begin...

Koepi

30th November 2003, 13:10

*caugh* yes, hitting "load defaults" after first installation over an old (dev-api3)-build is mandatory. Else you might screw up your encode.

Koepi

bilu

30th November 2003, 13:21

Just tried a small and dark first pass, quality seems very good. :)

I've now been trying to use the Interlaced option (after load defaults) with a Telecined clip, using AVS2AVI. It crashes after encoding 4 frames :confused:

Does anyone know if those standalone players with the Sigma and ESS chipsets can handle XVID interlaced mode?

Bilu

bond

30th November 2003, 13:22

first of all:
a huge thanks a lot to all of you who worked on xvid, making the best codec even better :D

i am currently running my first test encode with it: what i already saw is that the xvid stats interface seems to be a bit buggy (messing around with my taskbar...), is it possible to disable it by default from inside the gui?

hm, speedwise it seems to be as fast as devapi3, if not faster...

great work :)

Blueseb

30th November 2003, 13:44

status windows doen't work with avs2avi, it completely blank.

"zone" is a replacement for start/end credits control, i suppose...

raz0r

30th November 2003, 14:10

Originally posted by bilu
Does anyone know if those standalone players with the Sigma and ESS chipsets can handle XVID interlaced mode?

Bilu

mine (ESS) couldnt play the new xvid at all. but ill try some more encodes

KpeX

30th November 2003, 14:15

Kudos to the whole XviD team, this is an impressive release.

I definitely like the new GUI, haven't had time to test anything yet, hopefully soon.

Thanks again,

jkwarras

30th November 2003, 14:37

HI, maybe i'm dumb and i don't find it, but is 1 pass quality based gone in XviD 1.0 beta? If not how to enable it or make it work?

THANKS TO DEVELOPPERS

Regards

iago

30th November 2003, 14:37

After a couple of short initial tries using a variety of options and different combinations, my first impressions are quite positive indeed! Quality is really good. Congratulations and many thanks for your great work, all XviD developers! :)

However, I guess it will take me quite some time to get used to the new GUI, which I find a bit difficult to deal with and which imho can be pretty intimidating for the new/inexperienced users.

best regards,
iago

cipher

30th November 2003, 14:53

okay, this was told on the mailing-list, but for those who don't know already:
trellis quantization has also been available for MPEG since a couple of days ago.
And on my tests it brings down 12-18% in filesize, with also decrese in PSNR, but increse in PSNR-to-filesize ratio.

Happy testing!
Bye!

Yuuhi

30th November 2003, 14:55

Thanks a lot guys, I'll go immediately testing this new release!

30th November 2003, 15:00

So, anyone wanna code me GUI Doubletabs (http://mf.onthanet.com/xviddoubletabs.png) ? I'll hack in the rest (like I did with api3), but I can't do the tabs stuff. :D
suxendrol was gonna do that but he seems to be MIA.

cipher

30th November 2003, 15:12

Originally posted by Blueseb
"zone" is a replacement for start/end credits control, i suppose...

"zone" is not just a simple replacement for credits control :)
what we can do more now in "zone", at least as I figured out, are:

we can force a range of frames to use one single quantizer, leaving others treated normally(this is familiar to us as credits used it)
but with it, you could also set ,like,quantizer=2 to certain frames for which you don't want 2nd-pass to use higher quantizers, in order to preserve quality;

and in "zone", we could also force a range of frames to
use keyframes(I frames) only;
-----------------------edit---------------------------------------
sorry, guys, I was wrong with this "force keyframe" option
plz see sysKin's correction below
---------------------edit over-------------------------------------
use a different bvop sensitivity("threshold" as in dev-api-3);
and all other options in "zone", ie. chroma optimizer, greyscale, etc.

Of course this is only my interpretations for zone, you probably could find more than I did. :D

One thing bothering me is the "weight", can someone plz explain what it is?
Is it the weighting coefficient used in quantization matrix formula, or something else?
Thx!
----------------------------edit-------------------------------------
thx to sysKin's for explainations on "weight" :D
plz also see below
---------------------------edit over---------------------------------

mfluder

30th November 2003, 15:14

Originally posted by sysKin
@mfluder: the above is for you (lol) but I think I know the answer right now: dev-api-3 couldn't encode non-mod16 properly. If I'm right, ffdshow's output should also be wrong.
I forgot to mention that ffdshow with libavcodec doesn't have this bleeding problem. But I prefer ffdshow using XviD's decoder because of the problems libavcodec has with qpel decoding (even with XviD IDCT).

Please consider fixing this bug as I know I'm not the only one who uses resolutions that are not mod 16.

mfluder

gurabli

30th November 2003, 15:33

Hi!

I just wanted to say THANX!

Sorry for the space, but this is an opportunity that no one can miss!

XVID rulez!

Keep on with this wonderfull job!

Regards,

Gurabli

iago

30th November 2003, 15:41

OK, a short test at quant 2 without b-frames using a 20 seconds episode just to illustrate the efficiency of Adaptive Quantization and Trellis Quantization:

h263-CM-VHQ4 -> 5732 kb
h263-CM-VHQ4-ADAPTIVE -> 5214 kb
h263-CM-VHQ4-ADAPTIVE-TRELLIS -> 5038 kb

Both do a fantastic job indeed, especially adaptive quantization decreases filesize drastically, and no weird visual problems observed so far! :)

regards,
iago

mfluder

30th November 2003, 15:48

Originally posted by bond
first of all:
i am currently running my first test encode with it: what i already saw is that the xvid stats interface seems to be a bit buggy (messing around with my taskbar...), is it possible to disable it by default from inside the gui?
You can disable it in 'Debug' tab in 'Advanced options' dialog.

And yeah, encoding status doesn't work with avs2avi :(

mfluder

Teegedeck

30th November 2003, 15:50

The only thing I know about lumi-masking (now 'adaptive quantization') is that is has been "fixed". Anyone who knows whether this means Ishibaar's code, ReferenceDivX' code or something completely new?

Alxemi

30th November 2003, 16:03

For those who having problems with download managers, etc, here (http://138.100.51.162/~alxemi/XviD-1.0-Beta1-30112003.exe) is a mirror.
Congratulations to all developers, you did an awesome work, and thank you for share it with us.

wannabe

30th November 2003, 16:19

Koepi:

Feature Request for the 'stable' XviD 1.0:

Some builds used Simple iDCT(like the popular 14052003) and we all know that it causes degrade in quality(especially if Qpel is enabled) when playbacked with Walken iDCT. What i would like to ask is to implement an autodetect mechanism that would detect Koepi and Nic Encodes iDCT (by the date in the bitstream???) and would use different iDCT to decode for playback.

I asked the same thing in the XviD developer mailing list and they said it is impossible on the codec level, but i think it should be possible via this date thing, that supposed to be there in Nic and Koepi encodes bitstream.(Not in Umaniac, but this problem is spread via mostly the more popular Koepi and Nic builds.)

It would be a really really good thing, appreciated by mainly common people who just watch videos, and never write here. There are a lots of encodes floating around with simple iDCT, and i have a quite good amount of them in my own collection, and i wouldnt like to throw them away, or keep re-uninstalling the various builds to ger proper quality. Not mentioning not my own encodes that i got, or ll get in the future(some ppl keep using the old builds...) in those cases i dont know what build was used.

Thank you, i hope i made sense and im looking for your answer.

sysKin

30th November 2003, 16:24

Originally posted by Teegedeck
The only thing I know about lumi-masking (now 'adaptive quantization') is that is has been "fixed". Anyone who knows whether this means Ishibaar's code, ReferenceDivX' code or something completely new? OK, let me summarize what I've done with it:

* I made it working correctly with b-frames - b-frames's quantizer is correctly derived from p-frames' quant again (which is not that obvious)

* The thresholds below/above which a macroblock is concidered too dark or too bright (and thus, masked-out) are relative to mean brighness of the frame now. It prevents weird effect with frames which are generally very dark and were masked-out as a whole.

* I removed a piece of code that definitely didn't do anything right. It caused frames that were completly dark or completely white to have a uniform, very high quantizer. The threshold depended on picture size (!) and in fact could even be always-on for very small resolutions.

* The maximum quant that can be assigned to any single macroblock is 150% of frame's requested quant - used to be 200%. This means that lumimasking is less aggresive, but mostly I did that to prevent a situation where b-frames have lower quants than p-frames in some places.

And that's it I guess. The actual changes to lumimasking took me 10 times less lines of code than this explaination :D :D :rolleyes:

Allow me to thank Milan for ffdshow's quantizer visualization - I would go nowhere without it.

Originally 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.
One thing bothering me is the "weight", can someone plz explain what it is?A weight zones use bitrate scalling proportional to the weight: if a "zone" weights 2.0, it will have twice the bitrate (assuming equal complexity) of a 1.0 zone.
Just use 0.5 if you want credits taking 50% of what it originally took. I'm not sure if weght zone is working however - I must make some tests. 2pass might not have the weight zone implememented correctly atm :/

Radek

UMP

30th November 2003, 16:37

Hello,

I slightly changed the FairUse code to use the XviD 1.0 beta DLL, and I'm experiencing acces violations in xvid.dll after a few frames encoding.

This does not happen with the latest Koepi's stable build (2002.10.04) and with DivX releases. I only experience this with all xvid.dll that were built after Koepi's 2002.10.04, including the new beta.

After talking with Avery Lee, his opinion was that the problem *might* no be on the FU side.

Here are links to the modified FU executable, and to the modified source code :

http://fairuse.free.fr/FU_XviD10.zip
http://fairuse.free.fr/xvid_1.0_FU_source.zip

Hope this helps,

ump

EDIT :

I'm working on a WinXP SP1 system, and the problem occurs with any clip I tried, no matter what settings I used. I also tried to disable all CPU optimizations, but nothing does.

EDIT2 :

The problem was on my side :

More info here in the development forum : http://forum.doom9.org/showthread.php?s=&postid=405820#post405820

@Koepi: Please excuse me for bothering you with this "issue". I'm feeling stupid. :o

Teegedeck

30th November 2003, 16:41

Thanx for the explanation, sysKin - you're always there to put me right when I'm wrong or to hand me a torch when I'm lost the dark! :D

cipher

30th November 2003, 16:42

quote:
--------------------------------------------------------------------------------
Originally 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.

quote:
--------------------------------------------------------------------------------
One thing bothering me is the "weight", can someone plz explain what it is?
--------------------------------------------------------------------------------

A weight zones use bitrate scalling proportional to the weight: if a "zone" weights 2.0, it will have twice the bitrate (assuming equal complexity) of a 1.0 zone.
Just use 0.5 if you want credits taking 50% of what it originally took. I'm not sure if weght zone is working however - I must make some tests. 2pass might not have the weight zone implememented correctly atm :/

Radek

oh thank you sysKin for clearifying this.:)

Mango Madness

30th November 2003, 16:43

mf, that is the best prototype i've ever seen! ;)

so how bout 1.1? haha, jk...sorry for my useless post. i'll have some hard numbers in a couple of hours to make up for it.

OBcecado

30th November 2003, 17:08

Just want to thank every develloper the hard work they've been having on writing a great codec as XviD certainly is.

Long live to XviD, and it's great devs ;)

RathO

30th November 2003, 17:26

YEAH! Now that XviD 1.0 beta is out, i'm cancelling my wishlist for christmas. Im calling my family right away since i wont be there for christmas eve 'cause i have some testing to do during my hollidays! :D

Regards

symonjfox

30th November 2003, 17:28

Great Job guys!

I've just a little question: is it possible to add the A/R flag in the GUI (for example as 3ivx does)? AFAIK the AR flag was implemented since Devapi 3 but never used in the VfW GUI. Never mind if a directshow filter won't handle it, but just to create good anamorphic encode to play in future MPEG4 players.

PS: I push a lot for this AR Flag, because I used to rip from sat channels, and most of them are 352*576 interlaced, so to create non-anamorphic clips, I would upsize to 720*576 or downsize to 352*288, with loss of quality in both encodes. And also it's a good way to improve compression (reducing horizzontal resolution).

OUTPinged_

30th November 2003, 17:37

Is alternate curve compression completely gone or it will be back when things are settled?

Also, is there now a way to see a size of first pass having only a .pass file?

Bulletproof

30th November 2003, 17:39

I see a definite improvement without even using the new features, this also has lumi masking/adaptive quant disabled:

Older XviD Build:

http://www.boomspeed.com/boya/Older.PNG

XviD 1.0:

http://www.boomspeed.com/boya/Latest.PNG

Zoom Up (Left: XviD 1.0/Right: XviD Older Build):

http://www.boomspeed.com/boya/Quickcrop.PNG

A tiny cosmetic suggestion I have is that it would be nice to have that new status window "Always on top" so a checkbox for that would be nice. Also, when in two-pass mode and you hit the ".." button under filesize dialogue it always reverts the filesize setting to 700. BTW to everyone, take careful note that the filesize box says "Kbytes" now, so the default setting of 700 is NOT going to make a 700 meg file.

Can't wait to test this against VP6 when they release their fixed build :D

Koepi

30th November 2003, 17:50

Outpinged:

look at the statsreader which gets shipped with the binary. open the first pass statsfile with it and enjoy the display of the first pas size and the bitrate graph.

Bulletproof:
Very cool, that's useful feedback (and it's even positive :) ). Thanks!

Regards
Koepi

Teegedeck

30th November 2003, 17:52

Originally posted by OUTPinged_
Is alternate curve compression completely gone or it will be back when things are settled?

Well, the plans have been to remove it completely, so I guess it's gone for good.

BTW: I slowly begin to realize that there's now
b-frames
lumi-masking
quarterpel
trellis; for mpeg-quant, too
custom mpeg-matrices
vhq
cartoon mode
GMC
all actually working and all actually working together!
My dreams have come true. Thank you again, XviD-team.

mikeson

30th November 2003, 18:09

All XviD devels, great work!! ;)

@sysKin: I have a question. Does Trellis work together with custom matrices?

kxy

30th November 2003, 18:10

This thread is going to get big. Soon it will be hard to read between all the praises and bug reports.

May I suggest a sticky on already know bugs, along with some of the things that syskin's explained?

wannabe

30th November 2003, 18:13

Koepi, it seems that u jumped out my message, plz try to revisit it, and make a response thank you :)

Koepi

30th November 2003, 18:20

Wannabe:

this is the 2nd rules violation you did in this thread. The first one is: use the search function, we discussed it many times, you found the results of the xvid ml - and now you're posting again just to point out your post is more important than others. Another rule vioaltion.
Since you know the answer already it makes no sense to bug around :P

Mikeson:

Yes, trellis even works with custom matrices. Teegedecks summary is quite accurate.

Regards
Koepi

P0l1m0rph1c

30th November 2003, 18:21

Originally posted by mikeson
All XviD devels, great work!! ;)

@sysKin: I have a question. Does Trellis work together with custom matrices?

Yes, it does.

kxy

30th November 2003, 18:30

Originally posted by sysKin

@all: if you want to share any artifact-related bugs PLEASE try at least two decoders: xvid and ffdshow. It's important to tell us what are the results of both.
Radek

Using this aloha decoder decoding the old xvid clips(assuming b-frame usage), it will always output a b-frame lag msg at the beginning of the clip, and it will display the same msg whenever you are seeking.

Using ffdshow libavcodec, the problem does not exist.

EDIT: This happens while decoding the aloha clips too.

m99

30th November 2003, 18:34

A Aloha standalone decoder DirectShow filter would be nice.

mikeson

30th November 2003, 18:37

So I think today it is Christmas and Birthday for every XviD user... :)

@Koepi and P0l1m0rph1c: Thanks for answering.

OUTPinged_

30th November 2003, 18:39

@Koepi: thank you. Old statsreader from nandub doesnt work anymore (prob. a change in a first pass file format) so i was confused.

Comments: I dont see a bframe treshold setting. Either it is hardcoded into a value that is different from default from older releases or bframe decision algo is changed.

No "constant quantizer" mode.

No "scaled" framesize shown in debug.

I did a quick test with what i was able to do and i get 0.8% better compressibility with all goodies off, chroma me on and me=6.

... and 4% better compressibility with same settings and VHQ=4.

Good job here.

Sofus

30th November 2003, 18:43

Great that XviD 1.0 Beta finally is out

Here are some small bugs that I found

First, there is a problem with the new XviD, ffshow and zoomplayer together. When playing back old and new XviD encoded material and selecting XviD in ffshow under decoder, zoomplayer (ore ffshow?) is crashing.

When under XviD configuration, target size is selected and then pressing the “…” button, where there is suppose to be a bit rate calculator, after going back again, the default value for target size is back to default (570000)

The new XviD is very slow, using the same settings, compared to the older builds

---

Ffshow 20031028
Zoomplayer 3.20final

Sofus

P0l1m0rph1c

30th November 2003, 18:45

Originally posted by m99
A Aloha standalone decoder DirectShow filter would be nice.

But there is. Disable libavcodec in ffdshow and maybe other filters, like DivX 5.1.1 filter (for generic mpeg-4) or 3ivX 4.5's filter. Aloha brings a Dshow filter, that's for sure.

OBcecado

30th November 2003, 18:45

@OUTPinged_ it's name bvop threshold find it selecting the 0 frame and clicking in edit http://ptbox.net/~ob/bvop-threshold.jpg
Greetz.
about constant quantizer: just cap quants :P

All the best.

cipher

30th November 2003, 18:50

Originally posted by OUTPinged_
No "constant quantizer" mode.

In "zone" you can do it.

about constant quantizer: just cap quants :P
that's a pretty hopeless attempt in trying constant quantizer :D
Nervermind, OBcecado, just kidding.:D

P0l1m0rph1c

30th November 2003, 18:51

Originally posted by Sofus
Great that XviD 1.0 Beta finally is out

Here are some small bugs that I found

First, there is a problem with the new XviD, ffshow and zoomplayer together. When playing back old and new XviD encoded material and selecting XviD in ffshow under decoder, zoomplayer (ore ffshow?) is crashing.

When under XviD configuration, target size is selected and then pressing the “…” button, where there is suppose to be a bit rate calculator, after going back again, the default value for target size is back to default (570000)

The new XviD is very slow, using the same settings, compared to the older builds

---

Ffshow 20031028
Zoomplayer 3.20final

Sofus

Sofus: Don't use the XviD option in ffdshow. Use the Aloha dshow filter or libavcodec. In order to use Aloha's dshow filter, select "disable" in ffdshow, for XviD.

OUTPinged_

30th November 2003, 19:01

find it selecting the 0 frame and clicking in edit

Good place to hide it where no one would find out. :-)

seewen

30th November 2003, 19:15

First of all, thanks for the amazing job ( I don't know about the quality yet, but it's faster than before on P4).

With this new build, it's impossible to limit the bitrate (so that it's playble on a standalone) without choosing a profile.

But when you choose a profile, for example "DXN HT PAL/NTSC", you can only use H.263 matrix.

But standalones (at least the Kiss-Technology family) are able to read xvid with MPEG/Custom Matrix.

Is it possible to change this so that one could limit the bitrate AND use a Custom Matrix at the same time.

--

In the same idea, when you choose "DXN HT" profile, you cannot use QPEL anymore.
But the first standalone able to play QPEL is (quite) out ( http://www.elta.de/english/artikel.asp?Artikel=8883+MP4&Artikel1=8883&x=76&y=23).
But again, the bitrate has to be limited...

--

In fact those profile are great, but you should add the possibility to tweak ALL the settings without it.

Hiro2k

30th November 2003, 19:23

Originally posted by kxy
Using this aloha decoder decoding the old xvid clips(assuming b-frame usage), it will always output a b-frame lag msg at the beginning of the clip, and it will display the same msg whenever you are seeking.

Using ffdshow libavcodec, the problem does not exist.

EDIT: This happens while decoding the aloha clips too.

That is not a problem in Xvid, in fact you'll see the same problem with any DivX clip with b-frames. The problem lies with VFW.

Originally postedy bye Stux
It happens because a B frame is a bi-directionally predicted frame. This means you need two frames to predict from

so

I1 B2 P3 B4 P5 might be your display sequence

Now, the B2 frame is predicted from the I1 and P3 frame, so in order to decode the frame the decoder must have I1 and P3 first. So the encoder will write the frames in this order

I1 P3 B2 P5 B4

The problem is the decoder needs the 3rd frame in the file in order to decode the 2nd frame in the original file. So there has to be a frame of delay... unless the decoder runs a frame ahead, which the VfW architecture doesn't allow.

The normal hack is to pack the 3rd frame into the second frame so that its present at the right time.

Now, if you weren't using VfW (say you were using DirectShow instead) then you could simply take the 1 frame of delay into account and run the decoder 1 frame ahead, end of problem.

zettai

30th November 2003, 19:23

Originally posted by seewen
In fact those profile are great, but you should add the possibility to tweak ALL the settings without it.

Um... that's what the "unrestricted" profile is for...

(also the AS profiles etc allow you to choose different matrices)

amango

30th November 2003, 19:30

I used the 1Pass-Quality mode in XVID all the time for my encodings (size doesn't matter). How can I do this with this new build?

P0l1m0rph1c

30th November 2003, 19:36

@amango: you can do that using the zones configuration. Set start frame to zero and then below set the desired quantizer. This version will only allow quantizers, not % of quality.

amango

30th November 2003, 19:46

What quantizer-value do I need to get the same size/quality as before? I usually set quality to 95% to encode my videos. Which quantizer is equal to 95% quality?

HarryM

30th November 2003, 19:49

Very good news - new XviD version. 1.0beta finally! :D

But I have problems with XviD decoder (xvid.ax). Is DS decoder fully functional for now (I use win98se)?

I can't using a 'dev-api-3' decoders. It is imcompatible? I don't use special div-api-4 features, only b-frames + q-pel. Why is this stream is'nt dev-api-3 compatible???

Bear

30th November 2003, 19:50

Yeah, I want to know too. Cos I do 1 pass-quality mode in old xvid only. I always set the quality level to 90-92%.

P0l1m0rph1c

30th November 2003, 19:50

Originally posted by amango
What quantizer-value do I need to get the same size/quality as before? I usually set quality to 95% to encode my videos. Which quantizer is equal to 95% quality?

Quantizer 3

communist

30th November 2003, 19:54

Great work XviD team :D

Feature request (probably already in work):
A brightness slider for the decoder :) (as in older builds)
Its easier to access this one instead of having to go to display-properties > gfx driver tab... ;)

Oh and the statsreader crashes (exits) if you hit one of the foward / reverse or the "insert keyframe" button when no stats file is loaded.

Manao

30th November 2003, 20:03

XviD's dev : thanks a lot !!!

Just a few remarks on the GUI :

- I think it would be better if the three panels commanded by the encoding type were tabbed, and if the tab related to the encoding type selected was shown first.

- A bug : I clicked on the bitrate calculator and since I'm not able to set a final size when doing a second pass : I'm stuck with the "target bitrate".

- It would be great if we could add custom matrices permanently to the list of quantization type.

- If no zones are defined, the encodes doesn't follow the expected settings ( in my case, it didn't use bframes which were activated )

- The GUI is more powerful, but more confusing imho.

I can't make positive statements on the codec itself, since I can't make any encode yet, but I'm certain I won't be deceived.

Keep on the marvellous work !

cipher

30th November 2003, 20:06

I can't using a 'dev-api-3' decoders. It is imcompatible? I don't use special div-api-4 features, only b-frames + q-pel. Why is this stream is'nt dev-api-3 compatible???

dev-api-4's qpel+brames indeed cannot be decoded by dev-api-3's DS decoder, confirmed(long ago):D. But let's wait for someone powerful enough to explain it.

It wouldn't be a big problem anyway. Everybody's gonna update their decoders to XviD 1.0 beta and latter version, aren't they? :D

ssjkakaroto

30th November 2003, 20:14

thx a lot all xvid devs for this new release! :D keep up the great work!

this is not actually a bug and you probably know this but since from older builds if you select Twopass 2nd pass and click on the '...' of the target size it'll set the bitrate from single pass as the desired size.

and i have a question, if i have a 1000 frames movie and set the following zones:
0 - W:1.00
500 - Q:5.00
600 - W:1.00
frames 0-499 and 600-1000 will be encoded normally and 500-599 will be encoded using quantizer 5.00?

tia

P0l1m0rph1c

30th November 2003, 20:19

Originally posted by ssjkakaroto

and i have a question, if i have a 1000 frames movie and set the following zones:
0 - W:1.00
500 - Q:5.00
600 - W:1.00
frames 0-499 and 600-1000 will be encoded normally and 500-599 will be encoded using quantizer 5.00?

tia

The answer is yes, it will encode 500-600 with quantizer 5.:)

mfluder

30th November 2003, 20:24

Originally posted by Hiro2k
That is not a big in Xvid, in fact you'll see the same problem with any DivX clip with b-frames. The problem lies with VFW.
Yes, but this is DirectShow, and DirectShow doesn't have this problem. If it works without showing this message with dev-api-3 filter and ffdshow then it is possible with dev-api-4 filter too. I'm sure that XviD devs already know this and will fix it soon.

mfluder

XenoDaSouljah

30th November 2003, 20:25

I Would like to thank koepi and his team for this release. Testing as we speak... :)

Teegedeck

30th November 2003, 20:30

Originally posted by P0l1m0rph1c

Originally posted by amango
What quantizer-value do I need to get the same size/quality as before? I usually set quality to 95% to encode my videos. Which quantizer is equal to 95% quality?

Quantizer 3

Actually it's a bit more complex; it depends on your minimum and maximum quantizer-settings and thus 95% may mean a different quantizer for you than it means for amango.

See this thread (http://forum.doom9.org/showthread.php?&threadid=65449)

P0l1m0rph1c

30th November 2003, 20:36

@Teegedeck:

I know what it means, i also read that thread. But he asked for a quantizer that would be equivalent to the previous quality standart of his, 95%. So, the most aproximate integral quantizer for 95%, was 3. One correction I should have made was that it wasn't 3, but around 3. Anyway, thanks for the correction :)

amango

30th November 2003, 20:39

Originally posted by P0l1m0rph1c
Quantizer 3

Thanks! I just made a test with a 25 second anime video sample.

1-Pass Quantizer 3 new built
3.340 KB

1-Pass Quantizer 3 old built
3.254 KB

1-Pass Qualitybased 95% old built
2.658 KB

Its an old vhs-capture. It seems quality-based encoding is different from quantizer-based encoding. All encoded files looks very equal. I hope that 1-Pass qualitybased will be included in a newer built.

kxy

30th November 2003, 20:53

Xvid status window is very nice! It sure beat out the debugview method.

How can we can save the final output either to an ascii or graphic format?

Hylas

30th November 2003, 21:25

Can someone confirm that the interlaced mode is working correctly? I get completely screwed output, when I activate that option (colorful macro blocks, etc. in both ffdshow and Xvid decode filters).

winman

30th November 2003, 21:25

I don't know if this is too early to ask but:

Could someone put together a "XviD 1.0 Beta FAQ" thread?

It would make it easier o find info on "zone", adaptive quantization, b-frames, trellis, cartoon mode ..etc. I can see this thread is going to be very long.

jkwarras

30th November 2003, 21:25

Originally posted by amango
I used the 1Pass-Quality mode in XVID all the time for my encodings (size doesn't matter). How can I do this with this new build?

That's what i will like to know man :D

Ac3Dc3

30th November 2003, 21:40

thank you to all the developers for the great new Xvid release !

can some1 put together a comprehensive guide, like koepi's excellent guide for the 24062003-1 release, aswell as a new sticky, preferably asap ? - dont wanna press you guys too hard after such a lot work, but i think i speak for a lot of newbie to intermediate xvid encoders who need a little help with the new gui.

Ac3Dc3.:devil:

Koepi

30th November 2003, 21:58

Interlacing is broken currently (I think it's missing for bframes).

Regards
Koepi

communist

30th November 2003, 22:30

*Cosmetic* Bug:
If you set weight bigger than 2.00 and hit OK it will show as that value in the "XviD Configuration" window. This *might* be confused with a quantinizer of that value (though the weight values lack the brackets...).

Or does it indeed work with those values bigger than 2.00?

Chainmax

30th November 2003, 22:58

This is just awesome. I'd like to express my thanks to all the XviD dev team for putting so much hard work on this great codec. I can't help but feel sorrow for whoever tries to make an "XviD 1.0 options explained" document, since the number of new or combinable features has gotten so big. I wish I could beta test, but alas, I don't have my computer right now (I'm writing from a cybercoffee, long story) :(.

P.S: can anyone test how well does 1.0 beta handle quantizer 2 encodes?

bond

30th November 2003, 23:25

heya

xvid quality is awesome :D
great work guys!

one question about the zone feature:
it seems we only can define the start frame!
now how can i define where it should end (for example when the credits dont go till the end)? will i have to define 3 zones if i only want 1 zone inbetween the movie?
what if i only want to insert 1 keyframe at a position? do i have to define a new zone right after the keyframe?

if yes, perhaps it would make things easier if we could define the startframe and the endframe of a zone (like with the old credits feature)...

Leak

30th November 2003, 23:42

When trying to encode something in 2-pass mode I was getting a severely undersized second pass (with most frames having quantizer 31... o_O); it turns out that setting the minimum I-frame interval to 5 instead of 1 seemed to be the culprit...

Has anybody else experienced this?

EDIT: Just tried this again using "Load Defaults" and setting the minimum I-frame interval to 5 - same result: almost all frames get quantizer 31.

Using the statsfile from the first pass works fine when turning this option off for the second one, so either the option isn't used for the first pass or it works then, but not for the second one... *wonders*

Looks like a bug to me... (not that I can't live without this option, it's just a nasty pitfall as it's totally non-obvious... :))

np: B. Fleischmann - Take Your Time (Welcome Tourist)

jarthel

1st December 2003, 00:29

Originally posted by kxy
This thread is going to get big. Soon it will be hard to read between all the praises and bug reports.

May I suggest a sticky on already know bugs, along with some of the things that syskin's explained?

I agree. Praises outnumber useful info.

wannabe

1st December 2003, 00:50

Leak: I got the same problem with Trellis enabled(all frames at quant 31). It returns to normal if i disable Trellis. I made some encodes with Minimal frame interval 5, and it wasnt buggy.

iago

1st December 2003, 00:58

wannabe,

I think it has got nothing to do with trellis being enabled or not. I have done several two-pass test encodes, all with trellis enabled, and not encountered such a problem.

You should search the problem elsewhere. Maybe the problem is the third "..." box from above near the target size setting (that leads to the bitrate calculator) not keeping the entered value, a bug that was reported somewhere before I guess.

regards,
iago

EDIT: aaar9800 also points to the same issue below, and I suppose he is right.

aaar9800

1st December 2003, 00:59

Wannabe and Leak, I think that you set your desired size of second pass and then go around to check other options. If this is the case then the size will be reset to 700kb and you should change it again.

That thing occured quite a lot for me in early dev-api 4 builds

Leak

1st December 2003, 01:37

Originally posted by iago
wannabe,

I think it has got nothing to do with trellis being enabled or not. I have done several two-pass test encodes, all with trellis enabled, and not encountered such a problem.

You should search the problem elsewhere. Maybe the problem is the third "..." box from above near the target size setting (that leads to the bitrate calculator) not keeping the entered value, a bug that was reported somewhere before I guess.

regards,
iago

EDIT: aaar9800 also points to the same issue below, and I suppose he is right.

Ummm... I just tested this again.

Loaded the defaults and encoded a 30 second clip with the default settings in VirtualDubMod.

Then I just switched to 2 pass second pass, set the target size to 2500kB (first pass was 7MB) and lo and behold, it didn't use a quantizer higher than 6.

Then I went to the Advanced options page, ticked "Chroma Motion" and okayed my way out of everything. The target filesize still was 2500 and it still worked.

Then I went to the Advanced options page again, changed the minimum I-frame interval to 5, okayed out again (target filesize still was 2500) and then the 2nd pass again went bonkers, but yes, it looked as if it targeted 700.

Still, the target filesize box still contained 2500 (while it really reverts back to 700 if you hit the bitrate-calc-placeholder-button) and setting the minimum I-frame interval back to 1 and doing another 2nd pass yielded normal results.

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.

Oh, and deliberately setting the target size to 700kB yielded a 750kB file with a max quantizer of 22, not 31:

http://desdemona.ssw.uni-linz.ac.at/XviD1.0B1_700kB_MinIFrameInterval_1.png

On the other hand, as soon as I increased the min. I-frame interval to 5 and left everything else (especially the target size of 700) the same:

http://desdemona.ssw.uni-linz.ac.at/XviD1.0B1_700kB_MinIFrameInterval_5.png

And, as expected, setting it back to 1 fixed the problem again.

Hope somebody can make sense of that... :)

EDIT: Actually, min. I-frame intervals 1-3 all yield the same good result, while everything >= 4 freaks out.

np: David Holmes - No Mans Land (This Film's Crap, Let's Slash The Seats)

Leak

1st December 2003, 01:48

Originally posted by wannabe
Leak: I got the same problem with Trellis enabled(all frames at quant 31). It returns to normal if i disable Trellis. I made some encodes with Minimal frame interval 5, and it wasnt buggy.

Are you sure you did a second pass with this setting? It *does* work in the first pass or in single pass mode - it's just the second pass that goes completely out of control, as I elaborated in my other post.

Well, I'm off to bed - maybe someone elsewhere where it's not quarter to two in the morning can reproduce this? :)

np: Autechre - Squeller (EP7)

m99

1st December 2003, 02:37

Originally posted by P0l1m0rph1c
But there is. Disable libavcodec in ffdshow and maybe other filters, like DivX 5.1.1 filter (for generic mpeg-4) or 3ivX 4.5's filter. Aloha brings a Dshow filter, that's for sure.

Sorry, yes I know, I was a bit diffuse. It was the "Nic's latest standalone decoder DirectShow filter (installer)" I was interested in, I don't encode and I don't want to install more than I have to. Anyway, thx.

winman

1st December 2003, 03:17

@Leak

I can reproduce the problem with 40 seconds clip

-Load Defaults...
-Set Encoding type: Twopass - 1st pass
-Uncheck Discard first pass
-Encode resulted in a 9.47MB file with all frames at quant 2

-Set Encoding type: Twopass - 2nd pass
-Encode resulted in a 9.41MB file with almost all frames at quant 2

-Set Encoding type: Twopass - 2nd pass
-Set Minimum I-Frame Interval: 5
-Encode resulted in a 1.68MB file with almost all frames at quant 31

Any Minimum I-Frame Interval other than 0 or 1 will produce file with almost all frames at quant 31. Changing target size have no effect unless the min i-frame int is 0 or 1.

Is 0 a legal value for Minimum I-Frame Interval?

seewen

1st December 2003, 05:06

Originally posted by zettai
Um... that's what the "unrestricted" profile is for...

(also the AS profiles etc allow you to choose different matrices)

Ok, so tell me HOW I can limit the bitrate with the "unrestricted" profile....
(Bitrate has to be limited to 4'000 to be correctly decodec by kiss standalones)

skizm

1st December 2003, 05:33

Is anyone else having trouble connecting to koepi's site? I wanna test this out, but I can't connect or find anywhere else to download it :(

RadicalEd

1st December 2003, 06:20

Originally posted by zettai
Um... that's what the "unrestricted" profile is for...

(also the AS profiles etc allow you to choose different matrices)

Still doesn't allow a max bitrate, which is what he was saying.

LigH

1st December 2003, 08:25

Wow - so many people praising the XviD development team for finally releasing a beta.

I don't.

In fact, I'm quite pissed that you released the codec too early. :angry:

You released it, although you knew that some important part does not work correctly, as we privately discussed:

2-pass file size prediction in XviD dev4api does not work without B frames!

http://www.ligh.de/software/XviD/status_255kbps.gif

And even with B frames, at least the "average bitrate" display is totally confused:

http://www.ligh.de/software/XviD/status_Gbps.gif

http://www.ligh.de/software/XviD/status_low-bps.gif

Koepi

1st December 2003, 08:38

LigH:

instead of crying or yelling around you should provide us with code to fix the problem :P

Regards
Koepi

d'Oursse

1st December 2003, 09:03

@Ligh : read carefully the first message of this thread. Perhaps you don't know the meaning of a beta release ;)

and great thanks to the xvid team for that geat piece of code :)

zettai

1st December 2003, 09:07

Originally posted by seewen
(Bitrate has to be limited to 4'000 to be correctly decodec by kiss standalones) [/B]

Well you could just use cbr (which is really abr anyway) or you could

1) Burn your encodes to DVD
2) Use the dvd-rom version of the drive firmware instead of the speed-limited one (see rpc1.org)

The bitrate issue with the kiss player is just a problem with the drive's inability to spin that fast with cds. The above methods overcome that.

RadicalEd

1st December 2003, 09:49

Originally posted by LigH
a bunch of stuff

Funny... I haven't had any problems with my 1.5 min test clip at 700 or 1000 kbps, bframes or not o.o

Audionut

1st December 2003, 10:36

Probably a silly question, but how do you get B frames.

I can only get I & P frames.

Thanks.

BTW, Sweet release.

iago

1st December 2003, 10:44

how do you get B frames.Just activate them in the "Profile @ Level" tab! ;)

bond

1st December 2003, 10:46

guys, cool down
it should be possible to critize xvid on doom9 without getting beaten :)

Audionut,
its called "BVOP" in the profile menu.

perhaps it would be great if in the new gui it will be labelled as something like "BVOP (b-frames)" or so...

hm, perhaps it would be also usefull to place the "sensitivity", now under "edit", also under "profile" to keep the b-frames settings together (and if someone sets a different sensitivity under "edit", it "overrules" the "profile" setting for the specific zone...)

Bushman

1st December 2003, 10:55

is it possible to use lumi masking again???
i dont know, coz i wont use bugged beta-versions. ;)

ah, there was another "bug" in the old versions: if you use "chroma motion detection" combined with "encoding credits in greyscale" there were still some colors in the credits... (e.g if you have a colorized background behind the credits).
(possible bugfix: turn the chroma detection in credits off)

hmmm...
how much faster is the codec now? coz @the moment i rip with 2pass, quarterpel, chroma motion/optimizer, biQubic, VHQ 4, motionsearch ultra high, and much more slow-down-options)...
how's the quality of the compressed files?

ah, btw: koepi, if you want to translate something to german, you can send me an email! (if there IS something to translate ;) )
my mail-adress is: graalandria-at-web.de (without the two "-")

Audionut

1st December 2003, 11:49

Thanks people.

Again great release.

LigH

1st December 2003, 12:03

Originally posted by d'Oursse
Perhaps you don't know the meaning of a beta release ;)

In general, well ... I think I do, because I have some experience as software developer as well.

In my opinion, "beta" means that the developers don't know of any serious bugs anymore, after testing with all the material and systems they could get. And then beta testers may find bugs which the developers did not discover before. But already known and unfixed bugs shall be a reason not to release it.

And so not only in my opinion; Selur thinks the same (in our german forum); Hybrid and bond are bilingual readers, too...
__

@ koepi:

Unfortunately, I'm not a C programmer, and I don't have experience with CVS.

But okay - sorry for looking so angry; it's monday morning, this may be a reason why I shouted so loud.
__

@ RadicalEd:

:confused: Where do you quote me from?

Teegedeck

1st December 2003, 12:29

Perhaps it helps remembering two things that we've told over and over to those who couldn't wait for XviD 1.0:

1) A version number is a smersion number = it means next to nothing. Only the constant talk about it has given such disproportionate meaning to it. Perhaps most of us have been using devapi-4 for a long time before this release.
2) It's only up to the active developers to decide what they want to label 1.0 (in a majority vote I guess). Nobody else's business. They do all the work thus it's only them who suffer from criticism of their work (if there is any), and it's only them who deserve all the praise from content users.

It's a shame if we forget that and use an inadequate tone when asking those who don't owe us for favours (developers don't owe developers improving their software, either). Let's please keep this thread mainly a collection of positive as well as negative experiences with this release and not make it a debate with personal feelings thrown in.

XenoDaSouljah

1st December 2003, 12:41

Hi,

When i encode a movie, the green meter is only showing up at 2 (in the xvid status windows). Is this becuase min en max quantizer is set to 2 ?

Thanks.

I tested 1 movie so far, and it really looks good. Lots of detail you can even see the film grain :D No blurring there. Nice Job !!!!

:)

LigH

1st December 2003, 12:45

@ Teegedeck:

Okay - I'm not a man who denies own mistakes. :p

I hope my bug reports (also the private ones) helped, and my opinions didn't disturb too much. :rolleyes: And I'm surely one who wishes good luck for anyone involved in the XviD development.

Nevertheless, I won't give up telling my opinion - that's just a human right! :sly: - But I expect you to moderate me when I loose my self control a bit...

http://forum.gleitz.de/images/smilies/cheers.gif
__

@ XenoDaSouljah:

For a 1st-pass, this is pretty much what it is supposed to do: So the statistics for calculating the bitrate distribution is collected.

Teegedeck

1st December 2003, 12:51

Hehe, thank for giving me chance to moderate a mod a bit, old pal!
:D

LigH

1st December 2003, 12:57

"Tu mal lieber die Möhrchen in's Katzeklo"! :D

GolovachLena

1st December 2003, 13:01

Originally posted by Bushman
ah, there was another "bug" in the old versions: if you use "chroma motion detection" combined with "encoding credits in greyscale" there were still some colors in the credits... (e.g if you have a colorized background behind the credits).

Yes, it seems that this bug has been fixed. I just encoded some old b/w movie in grayscale with chroma motion detection set on and the bug didn't appear. I wasn't too lazy to re-check the results with older dev-3-api codec (nic's build actually), the same settings, and got some green-colored boxes all over the movie. Thanks to the team for fixing this, it was really ugly bug having me upset for days (i used to encode old bw movies too often).

Teegedeck

1st December 2003, 13:30

Originally posted by LigH
"Tu mal lieber die Möhrchen in's Katzeklo"! :D
Now how in the world would we translate that joke for our non-German users? I guess not at all, sorry for being OT. Got something to do with my avatar (OT for the last time now definitely).

JimiK

1st December 2003, 14:39

First things first: thank you for this great codec. I have to admit, I tested with some builds I made from CVS, so I know it's great. Did not run into trouble (never encode without b-frames ;) )
Originally posted by Bushman
is it possible to use lumi masking again???

Yes it is. You find the sysKin's explanation in this very thread. Iago already did a short test and was very pleased by the filesize decrease without an obvious quality loss.
Quality is awesome, speed is alright (not slower than old dev-api-3, I would say dev-api-4 is a bit faster).
What you might not know: Koepi is german, so I don't think he'll have to much problems translating his stuff into german. But maybe here I did not get your meaning.
Best regards,
JimiK

LigH

1st December 2003, 14:47

For all the german users here: Selur wrote a quite comprehensive documentation about dev3api XviD builds. For dev4api, he would like to wait for a more final user interface, though. You shall find "Wissenswertes rund um XviD" in the german doom9/Gleitz forum:

http://forum.gleitz.de/showthread.php?t=901

kxy

1st December 2003, 15:36

Originally posted by d'Oursse
@Ligh : read carefully the first message of this thread. Perhaps you don't know the meaning of a beta release ;)

and great thanks to the xvid team for that geat piece of code :)

I personally think LigH's comment is Ten times more useful than all the praise comments out there.

iago

1st December 2003, 15:48

I personally think LigH's comment is Ten times more useful than all the praise comments out there.kxy,

I personally think it's enough already and high time this pointless argy-bargy ended, so that people can focus on other important issues!

Rash

1st December 2003, 15:58

Sorry for asking a question I know you guys don't like to answer. But does anyone have a suggestion for B-Frames yet? :D

Thanks a lot all XviD developers. You guys rule. ;)

LigH

1st December 2003, 16:08

Which kind of suggestion - how many, or how to activate?

'Browse' "Profile @ Level" -- activate "BVOPs".

How many "Max. consecutive"... some say, 3 is best; some change the thresholds. This might all depend on the material, though; usualy I trust that koepi's default settings are useful for most purposes, and then I try to search the forum for hints on special material (e.g. anime will require different settings than action movies).

iago

1st December 2003, 16:14

I'm usually quite comfortable with the default values of 2/1.50/1.00. In some other threads in the "codecs" forum, I remember something like 1/150/75 (equivalent of 1/1.50/0.75 in dev-api-4) being suggested in terms of reaching a higher PSNR.

regards,
iago

Koepi

1st December 2003, 16:32

I tested (after sysKin recommanded that value...) and with the new bitrate scaling routines the defaults are "better" than those for dev-api-3. (In fact, these defaults behave like the values you gave for dev-api-3 - a bit more like i wanted them to behave before, so they are ideal for my purposes ;) )

(Just as a hint, iago dostum! :) I hope you and your family are well and didn't suffer from the events 2 weeks ago in Istanbul.)

Best regards
Koepi

iago

1st December 2003, 16:47

Sorry, completely O/T
---------------------
(... I hope you and your family are well and didn't suffer from the events 2 weeks ago in Istanbul.)Koepi,

Merhaba, mate! Yeah, as you see, (un)fortunately (:D), good old iago is still alive. Many thanks for your concern! Though I don't know how long that'll go with 60 cigarettes a day!..

Btw, next time you come by -something that I still feel extremely sorry about- I'll definitely put you up in Istanbul!

take care,
iago

iago

1st December 2003, 16:52

Back to topic ;)
--------------
... the defaults are "better" than those for dev-api-3 ... so they are ideal for my purposes ...I hold the same opinion. The defaults 2/1.50/1.00 would be fine for most jobs I guess.

regards,
iago

Boulder

1st December 2003, 17:17

What are the Aloha decoder defaults, no PP or some deblocking and/or deringing? Is there any way to alter them (both VfW and DShow) ?

Thanks for the new beta, looking good so far:)

outlyer

1st December 2003, 17:33

Thanks for the beta guys :)

I love the encoding status window and as someone posted it would be nice to be able to "export" it.
Originally posted by sysKin
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. Any chance to add some kind of chapter file parser to the gui to add automatically the keyframes? It would be cool :P (=> /me lazy)

JihaD

1st December 2003, 18:09

1. As usual: sorry for my english, especially the grammar, but i hope it's at least understandable.

2. I encountered following Problem using XviD-1.0-Beta1-30112003:

After installing 1.0b I activated "adaptive quant", "GMC" and "BVOP" features in the profile settings for encoding type "Twopass 1st pass". In "Advanced Settings" "Motion"-Tab I changed "VHQ mode" to "4 - Wide Search", "Use chroma motion" and in "Quantization"-Tab I checked "Trellis quantization".
After launching the 1st-Pass I was getting between 30-40 fps, which seemed a "little" bit high for the selected source (640x256/mpeg2 @ Athlon 2100+). So I stopped the encoding and looked if the selected codec-features were applied.
This was the case and so I decided to give it a try. After finishing the 1st- and starting the 2nd pass I was getting only I-Frames at a fixed quant (think it was 2 or 3), encoding speed, again, around 30-40 fps and the resulted clip was, as expected, full of artifacts (bitrate was around 2024 kBit/s).
A second try, after using "Load defaults" and applying the settings mentioned above, had the same result.
I uninstalled the codec, deleted the HKEY_CURRENT_USER\Software\GNU\XviD key, which, for some reason, wouldn't be deleted during the normal deinstallation process.
After reinstalling XviD, I used the "out of the box" settings to make an test-encode. Chanced nothing except switching between 1st and 2nd pass + entering the target size of the clip and everything went ok: I- and P-Frames at different Quants and an acceptable image quality. So, again, I switched back to my first settings, selected 1st pass, started encoding and: the same bug. Fps around 30-40 which is the same I archieve without the "special" features and, after the 2nd pass, again an "I-frame"-only clip.
Changing everything back to default produces an "valid" clip again, trying encoding via the "DXN HT Pal" profile had the same effect like custom changes made to (unrestricted) profile, means I-frame only.
At last I was doing an 1st pass with the "out of the box" settings, and before starting the 2nd, I changed to the same settings I allready described, and this time it "works". I was getting I- and P-Frames, no B-Frames, encoding speed around 10 fps and a much steadier, cleaner picture, which means that at least the features selected via "Advanced options" are working.
From this moment on, I was able to choose all features I tried at my first steps with the new XviD-Codec for the 1st pass too and everything went ok.
Made 3 short encodes and all are working (with B-frames). Don't have a clue what solved the problem, I'm running an "little" bigger encoding-test right now. When it's finished, I'll try to reproduce this strange behaviour.

seewen

1st December 2003, 18:29

Originally posted by zettai
Well you could just use cbr (which is really abr anyway) or you could

1) Burn your encodes to DVD
2) Use the dvd-rom version of the drive firmware instead of the speed-limited one (see rpc1.org)

The bitrate issue with the kiss player is just a problem with the drive's inability to spin that fast with cds. The above methods overcome that.

I'm really sorry to say that, but it seems that you really don't understand what I/you say.

I think you should have a look at the sigma-designs www.
The bitrate limitation comes from the chips.

That's right that Kiss introduced a new firmware to slow down the drive. But this limit the FF/FR and the noize, and NOT the bitrate).

And I could add that the bitrate limitation IS THE SAME on a CD-R(W), DVD-R(W), DVD+R(W)

And there IS a bitrate limit with VBR and CBR !!! No difference with those 2 modes...

Your 2 previous messages in this thread ar wrong. So please, don't add more.

zettai

1st December 2003, 18:42

Originally posted by seewen
I think you should have a look at the sigma-designs www.
The bitrate limitation comes from the chips.

We'll have to agree to disagree. I've done pratical tests rather than read specifications, which is what I am basing it on. When I enquired about the most effective way to do bitrate limited encodes during api-3 I was told (repeatedly on this this forum) that the cbr algorithm was actually preferable over doing a 2-pass with a bitrate ceiling.

P0l1m0rph1c

1st December 2003, 19:11

Hi! Thanks for all the wonderful work you guys have done!

I've made up some tests and here are some results:

XviD dev-api-3:

Average PSNR: 42.5424
Average SSIM: 0.959621
Average Scaled SSIM: 71.91143
Average VQM: 0.862986

DivX 5.1.1:

Average PSNR: 41.9562
Average SSIM: 0.955423
Average Scaled SSIM: 69.43294
Average VQM: 0.881833

XviD 1.0 beta 1:

Average PSNR: 42.9869
Average SSIM: 0.960911
Average Scaled SSIM: 72.68844
Average VQM: 0.838574

The results talk by themselves! :)

ferrous66

1st December 2003, 19:16

I have read this thread and I am not sure which DS filters I should use to playback xvid1.0 encoded video(all codec features on).
Is Nic´s 16072003 DS decoder fully compatible, or should I use the Xvid1.0 DS filters? It was pointed out that devapi3 decoders might have problems, does that include Nic´s 16072003 DS filters?
Thanks.

P0l1m0rph1c

1st December 2003, 19:25

Originally posted by ferrous66
I have read this thread and I am not sure which DS filters I should use to playback xvid1.0 encoded video(all codec features on).
Is Nic´s 16072003 DS decoder fully compatible, or should I use the Xvid1.0 DS filters? It was pointed out that devapi3 decoders might have problems, does that include Nic´s 16072003 DS filters?
Thanks.

@ferrous66: don't use devapi3 decoders. They work bad, if they work at all. In order to decode XviD 1.0 content, it is recomended using either XviD 1.0's dshow filter or ffdshow.

RadicalEd

1st December 2003, 19:44

Originally posted by LigH
@ RadicalEd:

:confused: Where do you quote me from?

Originally posted by LigH
2-pass file size prediction in XviD dev4api does not work without B frames!

cipher

1st December 2003, 19:50

@P0l1m0rph1c
Thx for your tests, but I've got little comments :)
Are the results from 2nd-pass or they're from 1st-pass? If they're from 1st-pass, could you please also include the filesize?
And from what I experienced, DivX5.1.1 was not a crap anymore, it performed really good. Maybe you guys don't wanna hear this, but without using a custom matrix, , dev-api-3 could hardly beat it. But fortunately, dev-api-4 still rulez :D That's why I was a little suprised when the results showed that dev-api-3 had a huge PSNR difference of 0.5db higher than DivX5.11.
So could you plz tell your settings, like, are XviD and DivX using pretty much the same settings? b/c if DivX used bframes while XviD used no bframes + custom matrix + qpel, it wouldn't be a fair test, would it? :)

P0l1m0rph1c

1st December 2003, 20:05

@cipher: I was a bit surprised with the results too. Here are the settings I used:

For DivX, No psychovisual enhancements, GMC, B frames.

For XviD, GMC, BVOPS 2/1.50/1.00, Trellis, VHQ4, Chroma Motion and h.263 quant.
I used the same settings for api3 and 1.0.

I aimed for 700 kbps, and i used 2 pass for both.

I tried to make it as fair as i could.

stax76

1st December 2003, 20:52

the new build looks great. Two bugs I encountered (present already in older builds):

1. decoder gives screwed image here too
2. codec calculates the AVI overhead

sapient

1st December 2003, 21:09

The pop-up help for the encoding type lists 1-pass quality and 2nd pass external as available options, but they're not actually there... Will they be available in future releases?

LigH

1st December 2003, 21:59

@ RadicalEd:

Aah... I think I got it. You mean:

'I wrote a bunch of stuff.';

I thought you mean

'I wrote "a bunch of stuff"'

and I couldn't remember any thread where I would have used the words "bunch of stuff", because usually I never use the word "bunch" in such a circumstance... :p

temporance

1st December 2003, 23:08

@P0l1m0rph1c:

Watch out when using an average for PSNR etc. It can be biased against codecs with better rate control. Do you have an Overall-PSNR result?

KpeX

1st December 2003, 23:42

Here's the results of some tests I performed so far on Beta 1, with one-pass quant 2 encodes. Results are pretty impressive. (Sorry for the large table size, you'll probably need to scroll to the right to see all the data). The first 9 files are a comparison between different b-frame settings. Files 10-14 are a vhq comparison. Finally, files 15-20 compare some of the other advanced xvid options. Then I repeated all the tests (b-frame, vhq, advanced settings) with MPEG quant instead of H.263, as seen with files 21-40. All settings not listed are default. Listed here are features, filesize, and fps.
File # Name, Features (All 1-pass Quant 2, res 640x272, 9 minute high-motion DVD source) Size(KB)Speed(FPS)

1 TestScene_H.263.quant_MS6_-1MaxBframes_VHQ0.avi 274312 26.89

2 TestScene_H.263.quant_MS6_1MaxBframes_Ratio100_Offset75_VHQ0.avi 274918 24.82

3 TestScene_H.263.quant_MS6_1MaxBframes_Ratio125_Offset100_VHQ0.avi 246255 24.47

4 TestScene_H.263.quant_MS6_1MaxBframes_Ratio150_Offset100_VHQ0.avi 230142 24.66

5 TestScene_H.263.quant_MS6_1MaxBframes_Ratio150_Offset75_VHQ0.avi 246255 24.3

6 TestScene_H.263.quant_MS6_2MaxBframes_Ratio100_Offset75_VHQ0.avi 275185 23.08

7 TestScene_H.263.quant_MS6_2MaxBframes_Ratio125_Offset100_VHQ0.avi 245642 24.53

8 TestScene_H.263.quant_MS6_2MaxBframes_Ratio150_Offset100_VHQ0.avi 229053 24.8

9 TestScene_H.263.quant_MS6_2MaxBframes_Ratio150_Offset75_VHQ0.avi 245642 23.95

10 TestScene_H.263.quant_MS6_1MaxBframes_Ratio150_Offset100_VHQ0.avi 230142 24.66

11 TestScene_H.263.quant_MS6_1MaxBframes_Ratio150_Offset100_VHQ1.avi 226337 19.39

12 TestScene_H.263.quant_MS6_1MaxBframes_Ratio150_Offset100_VHQ2.avi 224749 15.11

13 TestScene_H.263.quant_MS6_1MaxBframes_Ratio150_Offset100_VHQ3.avi 224309 12.56

14 TestScene_H.263.quant_MS6_1MaxBframes_Ratio150_Offset100_VHQ4.avi 222716 9.91

15 TestScene_H.263.quant_MS6_1MaxBframes_Ratio150_Offset100_VHQ4.avi 222716 9.91

16 TestScene_H.263.quant_MS6_1MaxBframes_Ratio150_Offset100_AdaptiveQuant_VHQ4.avi 205586 10.28

17 TestScene_H.263.quant_MS6_Trellis_1MaxBframes_Ratio150_Offset100_AdaptiveQuant_VHQ4.avi 204911 9.81

18 TestScene_H.263.quant_MS6_Trellis_1MaxBframes_Ratio150_Offset100_AdaptiveQuant_QPel_VHQ4.avi 206707 6.76

19 TestScene_H.263.quant_MS6_Trellis_1MaxBframes_Ratio150_Offset100_GMC_AdaptiveQuant_QPel_VHQ4.avi 205333 4.46

20 TestScene_H.263.quant_MS6_Trellis_1MaxBframes_Ratio150_Offset100_ChromaMotion_GMC_AdaptiveQuant_QPel_VHQ4.avi 204892 4.26

21 TestScene_MPEG.quant_MS6_-1MaxBframes_VHQ0.avi 281162 26.32

22 TestScene_MPEG.quant_MS6_1MaxBframes_Ratio100_Offset75_VHQ0.avi 280761 24.69

23 TestScene_MPEG.quant_MS6_1MaxBframes_Ratio125_Offset100_VHQ0.avi 251047 24.83

24 TestScene_MPEG.quant_MS6_1MaxBframes_Ratio150_Offset100_VHQ0.avi 238967 24.86

25 TestScene_MPEG.quant_MS6_1MaxBframes_Ratio150_Offset75_VHQ0.avi 251047 23.76

26 TestScene_MPEG.quant_MS6_2MaxBframes_Ratio100_Offset75_VHQ0.avi 281008 24.58

27 TestScene_MPEG.quant_MS6_2MaxBframes_Ratio125_Offset100_VHQ0.avi 250458 24.67

28 TestScene_MPEG.quant_MS6_2MaxBframes_Ratio150_Offset100_VHQ0.avi 238048 24.69

29 TestScene_MPEG.quant_MS6_2MaxBframes_Ratio150_Offset75_VHQ0.avi 250458 23.24

30 TestScene_MPEG.quant_MS6_1MaxBframes_Ratio150_Offset100_VHQ0.avi 238967 24.86

31 TestScene_MPEG.quant_MS6_1MaxBframes_Ratio150_Offset100_VHQ1.avi 237083 23.72

32 TestScene_MPEG.quant_MS6_1MaxBframes_Ratio150_Offset100_VHQ2.avi 233878 14.35

33 TestScene_MPEG.quant_MS6_1MaxBframes_Ratio150_Offset100_VHQ3.avi 232989 11.26

34 TestScene_MPEG.quant_MS6_1MaxBframes_Ratio150_Offset100_VHQ4.avi 229363 8.67

35 TestScene_MPEG.quant_MS6_1MaxBframes_Ratio150_Offset100_VHQ4.avi 229363 8.67

36 TestScene_MPEG.quant_MS6_1MaxBframes_Ratio150_Offset100_AdaptiveQuant_VHQ4.avi 208955 9.04

37 TestScene_MPEG.quant_MS6_Trellis_1MaxBframes_Ratio150_Offset100_AdaptiveQuant_VHQ4.avi 208186 8.6

38 TestScene_MPEG.quant_MS6_Trellis_1MaxBframes_Ratio150_Offset100_AdaptiveQuant_QPel_VHQ4.avi 219664 5.82

39 TestScene_MPEG.quant_MS6_Trellis_1MaxBframes_Ratio150_Offset100_GMC_AdaptiveQuant_QPel_VHQ4.avi 216968 4.03

40 TestScene_MPEG.quant_MS6_Trellis_1MaxBframes_Ratio150_Offset100_ChromaMotion_GMC_AdaptiveQuant_QPel_VHQ4.avi 216304 3.79

As far as conclusions, here's what I got out of it: all features tested appear to be fully working and doing their job in this beta. The bframe tests I did show that for me it looks like my preferred b-frame settings will be 2.150.100 or 1.150.100. I only noticed one thing that really surprised me - note files 15 vs.16 and 35 vs. 36. In both of these, adding Adaptive Quantization actually increases speed slightly! I'd be interested to see if anyone can duplicate this.

All encoding was done with avs2avi on a P4 2.0 Ghz.

Here's a link (http://www.freewebs.com/kpex/XviD_Beta1_test.sxc) (right-click, save target) to a full spreadsheet with more data, it's in OpenOffice format.

Regards,

P0l1m0rph1c

1st December 2003, 23:46

Originally posted by temporance
@P0l1m0rph1c:

Watch out when using an average for PSNR etc. It can be biased against codecs with better rate control. Do you have an Overall-PSNR result?

Overall PSNR's:

DivX: 41.6106
XviD api3: 42.2349
XviD 1.0: 42.3870

Rash

2nd December 2003, 02:20

Hey! Thank you all for replying my question about B-Frames. :)

@Ligh, I was asking about B-Frames values, not how to activate it. ;) Thank you all.

I've just made a perfect rip with it today. So, nothing new. :D

Calculon

2nd December 2003, 04:59

I've been ripping my Deep Space Nine dvds with this build and I must say I like the results. No problems to report from me. Nice work. :D

GolovachLena

2nd December 2003, 06:15

Guys, you're doing great job!
This night i re-encoded Matrix Reloaded 640x256@25, b-frames default, chrome motion, vhq4 and VERY modest quantizer settings, aiming to two CDs with english+russian audio streams, and i got undersize upto 100 Mb comparing to previous encode with dev3! But i couldn't notice ANY visual quality loss! I may be wrong, but the quality even a bit better then previous encode. And it was done at least 1.5 times faster. The greatest tool for CD-rip so far :)

b00zed

2nd December 2003, 06:50

@GolovachLena: You're not really stressing its compressibility capabilities much if you're using 640x256 for a 2CD rip. Try at least 688x288 ;)

LigH

2nd December 2003, 07:35

My usual "quick stress test": The PAL trailer of "Mortal Kombat 2 - Annihilation" = 2000 frames, completely used picture area (no letterbox or any black frame) in 16:9, rather old-and-dirty quality, in-/out-/cross-fades, rapid scene changes, flashes, rich blue lighting, much action, and finally: blazing flames! Just about verything an MPEG codec hates... And at 512x288 pixels with only 900 kbps, it clearly shows every flaw and weakness (e.g. did you know that the "dicas mpegable" codec even needs to drop frames to reach 'watchable' results?!).

GolovachLena

2nd December 2003, 08:17

Originally posted by b00zed
@GolovachLena: You're not really stressing its compressibility capabilities much if you're using 640x256 for a 2CD rip. Try at least 688x288 ;)

Actually i prefer to follow the old rule to keep width mod 32, not 16, so 688x288 is not acceptable for such purist like me ;) You think if i set it 704x288 it'll be stressed way too much? Ok, i'll give it a try tonight.

m0rtal

2nd December 2003, 09:38

yesterday night I've tried the brand-new XviD beta on "Catch me if you can" DVD.
Awesome quality, more than 2 hours of slow motion video, mostly dark scenes...
The result is... strange.
I've got some "color strangeness" - when some area not in focus of camera (walls, ceiling, etc) receives pink shade besides it's own color.
And I've got some "color moving areas" - when dark area of pixels moves (e.g., suit, or car, etc), it leaves same pink trace... very small, even unrecognizable, but it still exists!

XviD settings was:

Motion search: 6
Quantization: H.263
FourCC: XviD
VHQ: 4
Chroma motion on
B-frames: 2-150-70
DX50 b-vop
Trellis quantization on

Koepi

2nd December 2003, 09:42

mortal:

when decoding with ffdshow you have to set the IDCT in ffdshow configuration to XviD IDCT. Simple IDCT decoding will show these artefacts.

Regards
Koepi

b00zed

2nd December 2003, 09:49

@GolovachLena: I can't argue with you there ;)

I found since the source is clean and there are a lot of low/no motion scenes that it compressed rather well, and 688x288 came out very nicely. It could probably be pushed higher (eg 704x304) but I doubt there's much point.

GolovachLena

2nd December 2003, 10:12

May be it is a FAQ question but i still didn't find an answer, please don't beat me too hard :) What will Xvid do when quantizer set to relatively small value (2-5), frame drop ratio set to 0 and finally it can't fit the movie to the size desired? Will the size grow? Or the quantizer will be set higher value beyond initial settings?

m0rtal

2nd December 2003, 10:14

Koepi
ok, I'll try, thanks! :)

m0rtal

2nd December 2003, 10:39

GolovachLena
Why are you restricting encoder doing what it can do best of all? It's his work - determining frame quantizer, not your's! :)

GolovachLena

2nd December 2003, 11:04

m0rtal, you mean i should leave default settings 2-31? Then why most of manuals i have read mention lesser values such as 2-6, 2-12 etc. ?

m0rtal

2nd December 2003, 11:10

GolovachLena
I personally set I-frames to 2-16 and all other to 2-31...
why bothering yourself if encoder could make it better than you? :)

Then why most of manuals i have read mention lesser values such as 2-6, 2-12 etc. ?

to make absolutely sure that I-frames will look better :)

Manao

2nd December 2003, 11:22

Then why most of manuals i have read mention lesser values such as 2-6, 2-12 etc. ? Because they still think XviD needs help as DivX3.11 needed. But note that the two reference guides on encoding in XviD ( Snowbeach's and Doom9 one's ) are both saying not to cap in order to let the codec do its wonder.

2nd December 2003, 12:07

Originally posted by GolovachLena
Actually i prefer to follow the old rule to keep width mod 32, not 16, so 688x288 is not acceptable for such purist like me ;) You think if i set it 704x288 it'll be stressed way too much? Ok, i'll give it a try tonight.
Mod32 won't help you any more than mod16. Really. Unless you like to believe in myths.

GolovachLena

2nd December 2003, 12:32

2 mf: under the myth you possibly mean the fact of incorrect overlaying mpeg4 movie to the TV ? I used mod32 only for such a case. Never tried any other mod values, actually.
2 all: well, i think i got your point with quantizers... but how the heck do i beat the undersize problem? I thought the only way is manual lowering quantizer values.

m0rtal

2nd December 2003, 12:38

Originally posted by GolovachLena
2 all: well, i think i got your point with quantizers... but how the heck do i beat the undersize problem? I thought the only way is manual lowering quantizer values.

no, there are many other ways: turning b-frames off, increasing resolution, lovering motion search precision, increasing quality of audio stream, etc...
whats the problem with undersizing?

HarryM

2nd December 2003, 12:49

What is 'Aloha', in real?

Rober2D2

2nd December 2003, 13:06

I think this was not in the list.

a) Using ffdshow + xvid 1.0 makes all video playback application to crash. Tried using bsplayer, media player classics and directshow sdk. ffdshow 28-11-2003 from athos site.

b) I really haven't used them for a long while, but where is modulated quantization? Will it disappear to avoid non-MPEG 4 compliant stream?

Koepi

2nd December 2003, 13:11

ffdshow can't use xvid.ax for decoding the content. set it to use libavcodec for decoding xvid and you'll succeed with ffdshow decoding.

regards
Koepi

2nd December 2003, 13:14

Originally posted by GolovachLena
2 mf: under the myth you possibly mean the fact of incorrect overlaying mpeg4 movie to the TV ? I used mod32 only for such a case. Never tried any other mod values, actually.
Well you could of course use Bicubic Resize Dshow filter (http://www.doom9.org/software2.htm#filters) to expand to mod32 or just use ffdshow (http://prdownloads.sourceforge.net/ffdshow/ffdshow-20030424.exe?download)'s internal resize filter to do so. To me it just looks like a nasty bug in whatever it is you're using to output to TV. No reason to cripple yourself in encoding sizes.

mazzo

2nd December 2003, 14:31

I'm doing my first 2 cd encoding right now. The first pass took over 15 hours!!!

superdump

2nd December 2003, 15:15

Mazzo: What CPU/RAM/RAM Speed? What settings did you use? What source is it? What resolution are you encoding at? How long is the source? What filters are you using?

mazzo

2nd December 2003, 15:23

I used the default settings, I haven't touched anything in the codec. (I think, BTW it is Wide search). I used XVid earlier and it encoded 3 times faster than this, and DivX 5.1.1 is five times faster.

I have encoded DivX for more than a year. The source was 1h 54m long. Bitrate 1400Kbps (approx) 1.7 Gb processor 1024 Mb Ram

m0rtal

2nd December 2003, 15:27

Originally posted by mazzo
I used XVid earlier and it encoded 3 times faster than this, and DivX 5.1.1 is five times faster.

it is hardly beleivable!
what filters are you using?
does avisynth comes to play?
what is the source? dvd or smthng else?
"1,7GHz processor" - what kind of processor? intel? amd? celeron? duron? maybe it's even mac's g4! :)

P0l1m0rph1c

2nd December 2003, 15:42

@mazzo, are you sure you using the same settings? In my machine it's faster then api3 and a little bit slower than DivX (not 5 times at all!). What processor are u using?

Koepi

2nd December 2003, 15:43

Hit "Load defaults" after installing a new build (I already posted that in this thread, didn't I? It's in the stickies as well...)

You should notice a "slight" speed agin - beta1 is at least 10% faster than dev-api-3 for me, so it must be your settings.

Koepi

wannabe

2nd December 2003, 16:12

I made two, 2 pass encodes on the same source with the following settings:

1) AS @ L5, BVOPS, Packed Bitstream, Trellis / everything else default

2) AS @ L5, BVOPS, Packed Bitstream, Qupel, GMC, VHQ4 (i disabled trellis for this one)

1) = Max Frame Quantizer was 10 (avarage of 5.56)

2) = Max Frame Quantizer was 27 (avarage of 3.97)

So it seems that some of the advanced settings (or the combination of em) has a negative effect on the max frame quantizer ceiling.

bugsan

2nd December 2003, 16:43

xp2000+, avs2.53, dvd2avi 1.77.4
xvid3 with xvid.ax 24/06/2003
xvid4 with xvid.ax 01/12/2003
postproc-4 with ffdshow 28/11/2003
4775 frames processed
640x256, 1000kbps, 2pass
very high motion scene (codec killer) comp 36%

loadplugin("d:/divx/avisynth/mpeg2dec3.dll")
mpeg2source("D:/MATRIX_RELOADED_DISC_1/VIDEO_TS/matrix2.d2v",cpu=2,idct=2)
Trim(122112,126886)
Crop(0,78,0,-78)
LanczosResize(640,256)
----8<-------8<----------8<-----
LoadPlugin("D:\DivX\avisynth\compareyv12.dll") #recompiled version
#with fopen() bugfix (didnt work for me)

clip1 = AviSource("matrix2.avs")
clip2 = AviSource("xvid4_xxx.avi") #.Trim(1,0)
Compareyv12(clip2,clip1,"YUV","psnryv12.log")
----8<--------8<----------8<-----
this table shows time encoding (in seconds), real time fps,
psnr overall and mean square error/pixel/frame.
xvid encoding time = total encoding time - avisynth processing time.
sorry to do not show xvid4 encoding time because i have lost my virtualdub jobs :(
avisynth processing time: 94secs/pass, 50.8fps

|---------------------|-------------|-------------|---------|--------|-------|
| | avs+codec | codec | PSNR | Sq err | SSIM |
| | time fps | time fps | overall | /pixel | |
|---------------------|-------------|-------------|---------|--------|-------|
| xvid3 24062003 |
|---------------------|-------------|-------------|---------|--------|-------|
| default | 333 | 28.7 | 145 | 65.9 | 41.0125 | 5.15 | |
| altcc | 332 | 28.8 | 144 | 66.3 | 41.0194 | 5.14 | |
| cm | 360 | 26.5 | 172 | 55.5 | 41.0854 | 5.06 | |
| vhq1 | 409 | 23.3 | 221 | 43.2 | 41.2624 | 4.86 | |
| vhq1 cm | 444 | 21.5 | 256 | 37.3 | 41.2863 | 4.84 | |
| vhq4 | 1090 | 8.8 | 902 | 10.6 | 41.5808 | 4.52 | |
| vhq4 cm | 1099 | 8.7 | 911 | 10.5 | 41.5984 | 4.50 | |
| mpeg | 326 | 29.3 | 138 | 69.2 | 40.9471 | 5.23 | |
| mpeg vhq1 | 454 | 21.0 | 266 | 35.9 | 41.2726 | 4.85 | |
| mpeg vhq4 | 1266 | 7.5 | 1078 | 8.9 | 41.6116 | 4.49 | |
| bf1 | 364 | 26.2 | 176 | 54.3 | 40.9945 | 5.17 | |
| bf1 mpeg | 371 | 25.7 | 183 | 52.2 | 40.9514 | 5.22 | |
| bf1 vhq1 | 427 | 22.4 | 239 | 40.0 | 41.3484 | 4.77 | |
| bf1 vhq4 | 873 | 10.9 | 685 | 13.9 | 41.5640 | 4.54 | |
| cop | 323 | 30.0 | 135 | 70.7 | 41.0128 | 5.15 | |
| trellis | 360 | 26.5 | 172 | 55.5 | 41.1759 | 4.96 | |
| gmc | 347 | 27.5 | 159 | 60.1 | 40.9950 | 5.17 | |
| gmc bf1 | 369 | 25.9 | 181 | 52.8 | 40.9874 | 5.18 | |
| qpel | 403 | 23.7 | 215 | 44.4 | 40.8329 | 5.37 | |
| qpel bf1 | 483 | 19.8 | 295 | 32.4 | 40.8744 | 5.32 | |
| mpeg vhq1 bf1 | 451 | 21.2 | 263 | 36.3 | 41.2525 | 4.87 | |
| mpeg vhq1 bf1 altcc | 451 | 21.2 | 263 | 36.3 | 41.2262 | 4.90 | |
|---------------------|-------------|-------------|---------|--------|-------|
| xvid4 01122003 (cvs build) |
|---------------------|-------------|-------------|---------|--------|-------|
| default | 345 | 27.7 | 157 | 60.8 | 41.0011 | 5.16 | 73.50 |
| // + ffds-pp0 | - | - | - | - | 40.9986 | 5.17 | |
| // + ffds-pp4 | - | - | - | - | 41.3942 | 4.72 | |
| // + divx dec | - | - | - | - | 41.3539 | 4.76 | |
| me5 | 299 | 31.9 | 111 | 86.0 | 40.8815 | 5.31 | |
| cm | 372 | 25.7 | 184 | 51.9 | 41.0720 | 5.08 | |
| vhq1 | 428 | 22.3 | 240 | 39.8 | 41.4404 | 4.67 | |
| vhq1 cm | 440 | 21.7 | 252 | 37.9 | 41.4604 | 4.65 | |
| vhq4 | | | | | 41.7316 | 4.36 | |
| vhq4 cm | 851 | 11.2 | 663 | 14.4 | 41.7429 | 4.35 | |
| hvs-best | | | | | 40.8758 | 5.31 | |
| mpeg | | | | | 40.9356 | 5.24 | |
| mpeg vhq1 | | | | | 41.3239 | 4.79 | |
| mpeg vhq4 | | | | | 41.6477 | 4.45 | |
| bf default | 342 | 27.9 | 154 | 62.0 | | | |
| bf default mpeg | | | | | | | |
| bf default vhq1 | 405 | 23.6 | 217 | 44.0 | 41.3572 | 4.76 | |
| bf default vhq4 | 673 | 14.2 | 485 | 19.7 | | | |
| trellis | 370 | 25.8 | 182 | 52.5 | 41.1697 | 4.97 | |
| gmc | 931 | 10.3 | 743 | 12.9 | 40.9935 | 5.17 | |
| gmc bf1 | | | | | | | |
| qpel | | | | | 40.8138 | 5.39 | |
| qpel bf1 | | | | | | | |
| cartoon | | | | | 40.9395 | 5.24 | |
| bf-1-1.2-0 | | | | | 41.0003 | 5.16 | |
| bf-1-1.5-0 | | | | | 41.0326 | 5.13 | |
| bf-1-1.8-0 | | | | | 40.9267 | 5.25 | |
| bf-1-2.0-0 | | | | | 40.8361 | 5.36 | |
| bf-1-1.5-1 | | | | | 40.9837 | 5.18 | |
| bf-1-2.0-1 | | | | | 40.7459 | 5.48 | |
| bf-1-3.0-1 | | | | | 40.3142 | 6.05 | |
| bf-2-1.5-1 | 342 | 27.9 | 154 | 62.0 | 40.9510 | 5.22 | |
| bf-2-2.0-1 | | | | | 40.7063 | 5.53 | |
| bf-2-3.0-1 | | | | | 40.2506 | 6.14 | |
| bf-3-1.5-1 | | | | | 40.9498 | 5.23 | |
| bf-1-1.5-0_v4_cm_tr | | | | | 41.7270 | 4.37 | |
| vhq4_cm_tr | 958 | 10.0 | 770 | 12.4 | 41.8116 | 4.28 | 76.25 |
| // ffds pp4 | | | | | 42.1085 | 4.00 | |
| // divx dec | | | | | 42.0843 | 4.02 | |
|---------------------|-------------|-------------|---------|--------|-------|
| divx 5.1.1 |
|---------------------|-------------|-------------|---------|--------|-------|
| fastest 2pass no-bf | 343 | 27.8 | 155 | 61.6 | 41.2395 | 4.89 | |
| // (ffds pp0) | - | - | - | - | 40.8215 | 5.38 | |
| // (ffds pp4) | - | - | - | - | 41.1819 | 4.95 | |
| slowest 3pass bf | 3161 | 4.5 | 2879 | 5.0 | 41.4807 | 4.62 | |
| // (ffds pp0) | - | - | - | - | 41.1792 | 4.96 | |
| // (ffds pp4) | - | - | - | - | 41.4930 | 4.61 | |
|---------------------|-------------|-------------|---------|--------|-------|
| fvfw mpeg4 |
|---------------------|-------------|-------------|---------|--------|-------|
| default | 545 | 17.5 | 357 | 26.8 | 40.8780 | 5.31 | |
|---------------------|-------------|-------------|---------|--------|-------|
| wmv9 |
|---------------------|-------------|-------------|---------|--------|-------|
| faster simple (avis)| 367 | 26.0 | 179 | 53.4 | 40.5280 | 5.76 | |
| better complex(avis)| 1533 | 6.2 | 1345 | 7.1 | 41.0502 | 5.11 | |
|---------------------|-------------|-------------|---------|--------|-------|
| rv9 ehq |
|---------------------|-------------|-------------|---------|--------|-------|
| ehq very high | 1045 | 9.1 | 857 | 11.1 | 41.9565 | 4.14 | |
|---------------------|-------------|-------------|---------|--------|-------|
sqerr/pix: 255*255/(10**(psnr/10))
vhq is faster and more effective :)
any question ?

communist

2nd December 2003, 16:53

Originally posted by HarryM
What is 'Aloha', in real?
An island?

cipher

2nd December 2003, 17:27

What is 'Aloha', in real?

It's the traditional way ppl in Hawaii say "hello" or "goodbye" :)

fisix

2nd December 2003, 17:34

ack, bugsan, those encoding times are important!

sorry to hear you lost the jobs..

thanks very much for the table, outstanding.

-fiz

mazzo

2nd December 2003, 17:49

Hi guys, my processor is 1,7 GHz Intel. I encode an segmentedavisource, recorded from television with some trimming (not much). No deinterlacing. Natural bicubic. As I always do, the movies on my tv here in Norway are mostly progressive. I use this XViD new encoder together with Gordian Knot.

Tueurne

2nd December 2003, 17:58

well great thx to every Xvid dev

trellis H263 , Qp, GMC, Adp Q are all Ok ;)

I have somme problem with reduce resoltion which doesn't work (H263)
And trellis with HVS matrix. Size on first pass is biger with trellis than without :(

A known bug but I don't know if you remember. The last answer was It's hard to correct it's in the core. This is the problem of MPEG matrix after loading a custom matrix you must load default setting if you want to use MPEG matrix anymore, or saving the MPEG matrix before loading the custom

wannabe

2nd December 2003, 18:10

Size on first pass is biger with trellis than without

yes, thats true, i can confirm that also.

Bushman

2nd December 2003, 20:56

ehm... koepi, i can't download your beta-version... :(

it always tells me:
Your browser didn't send the correct referer for my site, thus you are following a direct link from some page on the net. I'm sorry, but due to massive bandwidth stealing, producing a real workload, and in the end doing us financial harm we had to disallow this.

but: i use opera 7.22, and NO downloadmanager. what's the problem? i tried with IE6 SP1 too. failed! i also turned off my Firewall (ZoneAlarm)... failed again.

may someone can send me the installer (win32) to my email? its: graalandria[at]web[dot]de

thx!

(ps: normally i dont use beta-versions... but i'm wondering about the new settings of the codec...)

Alxemi

2nd December 2003, 21:16

Bushman there´s a mirror posted in one of the first pages of this thread

Have fun testing ^_^

Regards

mazzo

2nd December 2003, 21:16

Encoding time so far:

BeSweet transcoding: 5 minutes 50 seconds
First Pass: 15 hours 37 minutes 22 seconds
Second pass: 10 hours 34 minutes and 4 more hours to go ....

Soulhunter

2nd December 2003, 21:23

BIG THANKS TO KOEPI !!!

Great work this beta, and a really nice X-Mas present too... !!!

I have done some sample encodes with different settings, but Ive found not a single bug so far... :)

Quality is very pleasant... :D

Only thing I'm waiting now for, is a PSNR-decision based 2Pass mode !!! ;)

Bye

Chainmax

2nd December 2003, 21:30

I have a couple of questions:

1) Is devapi4's implementation of QPel any different than in devapi3?

2) Does Trellis still imply a slight IQ drop (thereby not making it a good option for mid-to-high bitrate encodes)?

3) Is Chroma Optimizer still there?

4) Can QPel be used with custom matrices now? [edit: from reading Tueurne's and wannabe's posts, it seems like it doesn't]

BTW, did anyone have a chance to test the cartoon mode, especially on anime?

LigH

2nd December 2003, 21:45

About 3): Yes, but you have to 'Edit' the frame range.

And yes, I tried to test the cartoon mode - unfortunately on ANIMATRIX, which has a horrible I-P/B-Frame pumping and bad quality - when the source already is blocky, the copy will be, too (especially in the scene where the robot corpses are thrown into the sea); will need to look for other sources.

http://www.ligh.de/software/XviD/pumping.avi

BoNz1

2nd December 2003, 22:20

Originally posted by Chainmax
I have a couple of questions:

1) Is devapi4's implementation of QPel any different than in devapi3?

2) Does Trellis still imply a slight IQ drop (thereby not making it a good option for mid-to-high bitrate encodes)?

3) Is Chroma Optimizer still there?

4) Can QPel be used with custom matrices now? [edit: from reading Tueurne's and wannabe's posts, it seems like it doesn't]

BTW, did anyone have a chance to test the cartoon mode, especially on anime?

1) Yes, some bugs were fixed + isibaar's qpel was merged into dev-api-4 quite a while ago so it should be a little faster and a little better quality.

2) Use trellis always.

3) Chroma optimizer is in the zones.

4) you can use it with custom matrices.

EDIT: I tried cartoon mode on some of my simpsons dvds and it looks very good. It skips quite a few frames lowering the bitrate quite significantly but the visual result is good, no ghosting or any other nastiness.

riggits

2nd December 2003, 22:27

Originally posted by BoNz1
.....

2) Use trellis always.

...

What is trellis, and what does it do? Technical details would be nice! I've read this whole thread trying to find out.
I'm doing X2 on 1 CD as a test, and it's almost done .. 2h06min without trellis. I'd like the best possible settings for low bitrate, high-action, somewhat-dark video. I tested with and without BVOP, and BVOP certainly makes a huge difference (unlike DivX 5.1.1). Is there anything else I should do?
Thanks!
rigg...ts

KpeX

2nd December 2003, 22:43

Originally posted by riggits
What is trellis, and what does it do? Technical details would be nice! I've read this whole thread trying to find out.
I'm doing X2 on 1 CD as a test, and it's almost done .. 2h06min without trellis. I'd like the best possible settings for low bitrate, high-action, somewhat-dark video. I tested with and without BVOP, and BVOP certainly makes a huge difference (unlike DivX 5.1.1). Is there anything else I should do?
Thanks!
rigg...ts

Hi riggits, and welcome to the forums,

Background info on trellis quant:
This thread (http://forum.doom9.org/showthread.php?s=&threadid=53383) was the first public build with trellis, Koepi's post explains some of how it works. Here (http://forum.doom9.org/showthread.php?s=&threadid=53308) are some early trellis quant tests by mf and CruNcher. Search button is powerful isn't it ;).

Also see my test results (http://forum.doom9.org/showthread.php?s=&postid=406347#post406347) on beta 1 from earlier in this thread, and note files 16 vs. 17 and 36 vs. 37. In my tests, trellis quant provides slightly smaller file size (makes the codec more efficient) and decreases speed slightly as well, for both MPEG and H.263 quant. Therefore I would recommend using Trellis under any conditions except when going for extremely high speed settings.

outlyer

2nd December 2003, 22:46

I've just noticed the number of zones is limited. Any good reason for this? Any chance to raise the limit in the public builds?

Alxemi

2nd December 2003, 22:59

2) Use trellis always.
always means Always?
Even when trying to increase size/quality with codec saturation?

iago

2nd December 2003, 23:06

Even when trying to increase size/quality with codec saturation?No! ;)

P0l1m0rph1c

2nd December 2003, 23:50

Hi guys!

I've made new tests. This time with XviD 1.0, DivX 5.1.1, VP6 (i know it's b0rked, but give it a try anyway) and 3ivX 4.5.

Results:

3ivX 4.5

Average PSNR: 39.6499
Average SSIM: 0.935640
Average Scaled SSIM: 58.73138
Average VQM: 0.922518

DivX 5.1.1

Average PSNR: 40.4819
Average SSIM: 0.949206
Average Scaled SSIM: 65.89975
Average VQM: 0.859133

VP6

Average PSNR: 41.7322
Average SSIM: 0.947302
Average Scaled SSIM: 64.84965
Average VQM: 0.855174

XviD 1.0

Average PSNR: 41.0088
Average SSIM: 0.951314
Average Scaled SSIM: 67.07970
Average VQM: 0.820282

I aimed for 910 kbps, 2 pass in every codec.

Chainmax

3rd December 2003, 00:50

Originally posted by BoNz1:
2) Use trellis always.
Originally posted by Iago:
quote:
--------------------------------------------------------------------------------
Even when trying to increase size/quality with codec saturation?
--------------------------------------------------------------------------------

No! ;)
So, what would you guys say is a good turning point of sorts for using/not using Trellis? 1000kbps? 1200kbps?

gizmotech

3rd December 2003, 01:06

Good Day guys,

I'm wondering if there has been any discussion concerning xvid automattic solutions to codec saturation in 2pass encoding?

It's quite frustrating ATM to perform an encode and have to perform manual codec setting reconfiguration over and over again to reach target file size. (through max i-frame adjustments, removing of most compression assistants).

I was wondering if there are any options that xvid developers could add which would perform file padding? Dynamically increasing key-frame count would be greatly appreciated.

Thanks Guys, And great work with the new cartoon mode.

Gizmo.

PS: And before people start replying "but why should you pad out the video. It's better if it uses less", I've heard all the arguments before, and I appreciate the advice and believe it myself, however there are too many people out there still fixated on certain file sizes in encodes.

iago

3rd December 2003, 01:07

So, what would you guys say is a good turning point of sorts for using/not using Trellis? 1000kbps? 1200kbps?Depends (on many factors such as resolution, target-size, compressibility, etc.). Bitrate alone doesn't mean anything and is no measure by itself for anything...

For example, personally, I wouldn't use Trellis (and neither Adaptive Quantization nor b-frames) for a q2 encode, where I aim for the highest possible quality regardless of the file/frame size.

I suppose Trellis, Adaptive, and B-frames are most useful for 2-pass scenarios.

But these are only my thoughts of course...

regards,
iago

Sigmatador

3rd December 2003, 01:11

XviD Dev-api-4 fresh CVS checkout:
CM+VHQ4+BF1/1/0 @Q2
Decoding with xvid --> PSNR: 45.0192 47.7236 56.5961
Decoding divx5.1.1 --> PSNR: 45.5070 47.9361 57.5104

now CM+VHQ4+NOBF @Q2:
Decoding with xvid --> PSNR: 45.3652 47.8114 56.6605
Decoding divx5.1.1 --> PSNR: 45.5255 47.8518 57.4761

it seems to have a decoding problem (specially with bframes)

ps: PSNR with avisynth and compareyv12

Arcon

3rd December 2003, 01:30

Originally posted by BoNz1
I tried cartoon mode on some of my simpsons dvds and it looks very good. It skips quite a few frames lowering the bitrate quite significantly but the visual result is good, no ghosting or any other nastiness.
does that mean it doesn't add new ghosting or does that mean it magically removes the ghosting present on the dvd (examples (http://vektor.ca/dvd/dvd/simpsons.html)).

ookzDVD

3rd December 2003, 03:46

@forum,

I think the best why to test a codec is try to encode at the low bitrate (below 500kbps), isn't it ?
Lot's of people is test with the high bitrate :( all codec should be
good in high bitrate isn't it ? :(

gizmotech

3rd December 2003, 03:55

OokzDVD;

you'd figure that would be the case, but try doing the same work that XviD does in 200MB at 1100kpbs in WMV 9 and you'll understand why that isn't the case.

All codecs will perform beautifully at 2-3K kpbs, but at 1-1.5 there are still some questionable contenders.

Gizmo.

sysKin

3rd December 2003, 06:08

(About trells)
Originally posted by Alxemi
always means Always?
Even when trying to increase size/quality with codec saturation? OK it's not that easy. Both h263 and mpeg quantization tried to achive some kind of R-D optimum by use of fast and easy approximations. The results were a little bit different, however: h263 quantization type was rather throwing details away, while mpeg quantization tried not to throw them away (on average).

As a result, trellis quant when used with h263 is bringing some details back rather than throwing away more, so it increases filesize and quality at quant 2.
When used with mpeg quant type, it rather throws more details away than brings back (again, on average) - so it reduces filesize and psnr at fixed quant 2.

In any case, trellis quant is much more efficient than non-trellis approximations. If you saturate the codec, you should rather use high-quality custom matrix instead of disabling trellis.

Radek

mazzo

3rd December 2003, 07:22

@forum

Well, since there is no adequate answer to why my first encode with XViD 1.0 took over 30 hrs (!), I think I have to kick it out and return to the old one (if it's possible) or use DivX 5.1.1. XViD is better, but I'll have to weigh cost / benefit here.

m0rtal

3rd December 2003, 08:01

Originally posted by Koepi
when decoding with ffdshow you have to set the IDCT in ffdshow configuration to XviD IDCT. Simple IDCT decoding will show these artefacts.
yep, turning on XviD IDCT turns off artifacts :)
thanks!

Tuning

3rd December 2003, 08:25

Originally posted by sysKin
As a result, trellis quant when used with h263 is bringing some details back rather than throwing away more, so it increases filesize and quality at quant 2.
When used with mpeg quant type, it rather throws more details away than brings back (again, on average) - so it reduces filesize and psnr at fixed quant 2.syskin, please explain what is done under adaptive quantization.
Is trellis prefered when using adaptive quantization ?
Thanks.:)

Teegedeck

3rd December 2003, 09:14

@tuning: sysKin alread has explained it thoroughly in this thread. It must be on page 3 of it or something.

And BTW, Trellis and AQ seem to perform beautifully with almost saturated encodes. For my eyes (again, how subjective! different from most users, I prefer going for anamorphic resolution over switching off b-frames when it comes to high-bitrate encodes) the gain provided for the overall quantizer in two-passis realizable, i.e. more details seem to have been discarded without Trellis and AQ than with them. It is really fascinating to study those block-based quantizers with ffdshow. Nothing wrong as far as I can see. (I was close to submitting a negative report until I realized that the artefacts actually were present in the source and rather looked more unobstrusive in my encode due to changed block-boundaries.) Encoded at 1800 kbps, 704x550 resolution, HVS-best matrix, default b-frame-setting, Trellis, AQ, GMC, VHQ=4 (edit:) and quarterpel.

This file wasn't really apt for a test, but it wasn't meant to be one, I just wanted to encode it when 1.0 came official. Next one will be a bit more demanding.

Cyfer

3rd December 2003, 09:25

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

m0rtal

3rd December 2003, 09:30

reading all these posts I've reach a conclusion: XviD is not beta, it's release candidate! :D
good job, guys!

mazzo

3rd December 2003, 09:33

@m0rtal

I figure you read about my 30 hrs experience, too. If I do something wrong here, I really like to know, or else I will not draw the conclusion that this is a release candidate.

m0rtal

3rd December 2003, 09:38

mazzo
yes, I remember about your issue and trying to figure out what's wrong...
still no ideas :(
have you loaded default settings after installing?

Tuning

3rd December 2003, 09:43

Thanks Teegedeck, I'm currently doing encoding with AQ, trellis, vhq2 and single pass. Which is a movie. I have done test encode and found this combination is good in preserving details.

@Cyfer

Please look
here (http://forum.doom9.org/showthread.php?s=&threadid=66098)

Rober2D2

3rd December 2003, 09:46

ffdshow can't use xvid.ax for decoding the content. set it to use libavcodec for decoding xvid and you'll succeed with ffdshow decoding.

Thanks Koepi, but some of my films where encoded with 3 B-Frames and Packed Bitstream (Yes, I know I shouldn't have done that). Xvid.ax seems the only able to properly decode that, while libavcodec shows frames in wrong order. I'm afraid I'll have to wait until ffdshow is ready for the new API or use a dev-3-api version for the moment.

mazzo

3rd December 2003, 09:48

@mortal

No, I haven't, actually, I just installed it and ran GKnot as if nothing new had happened. Maybe that's where I should start.
And try with smaller files .... ;)

Koepi

3rd December 2003, 10:08

Maybe you shouldn't use GKnot but setup the avs and vdubmod "manually". I haven't a movie at hand, even my 3 hrs movies, which would take as much as 15hours. max total time for 2passes is 16hrs here - and that's with heavy filtering in AVS.

Regards
Koepi

mazzo

3rd December 2003, 10:11

@koepi

Would it be possible for me sending you the avs that GKnot has made in this particular case? I am not very familiar to avs scripting.

m0rtal

3rd December 2003, 10:16

mazzo
post it here :)

Hylas

3rd December 2003, 12:15

Originally posted by Koepi
Interlacing is broken currently (I think it's missing for bframes).

Regards
Koepi
Thanks for the info.:(
But according to this thread (XVID - interlaced encoding) (http://forum.doom9.org/showthread.php?s=&threadid=62485) the problem is already fixed.:confused:

And, I can't even get a proper encode without B-frames.

bilu

3rd December 2003, 12:23

Originally posted by bilu
I've now been trying to use the Interlaced option (after load defaults) with a Telecined clip, using AVS2AVI. It crashes after encoding 4 frames :confused:

I got the same problem.

bilu

3rd December 2003, 12:26

Originally posted by iago
Though I don't know how long that'll go with 60 cigarettes a day!..

You could start by changing your picture :D

Bilu

m0rtal

3rd December 2003, 12:29

bilu
are you turning postprocessing of the frames off? I mean, telecining usually decombs frames too, and after that you are trying to save interlaced frames...
maybe that is the problem...

Hylas

3rd December 2003, 12:55

Originally posted by bilu
I got the same problem.

I'm not sure about that. It doesn't crash here, but the output is screwed:
interlaced-xvid-dev3.jpg (http://stud4.tuwien.ac.at/~e0025119/video/interlaced-xvid-dev3.jpg)
interlaced-xvid1b.jpg (http://stud4.tuwien.ac.at/~e0025119/video/interlaced-xvid1b.jpg)

Manao

3rd December 2003, 13:16

There was a bug with dev-api-3, concerning transcoding of XviD to XviD, when the quant matrices used were different. A friend of mine tested that case with dev-api-4, and he encountered the same issue ( described here (http://forum.doom9.org/showthread.php?s=&threadid=57872) )

His system was (alas) linux + avisynth ( avisource ) + virtualdubmod + wine + athlon 1.4 Ghz. I can't make same the test right now on windows, I'll confirm later.

Tueurne

3rd December 2003, 13:21

Some options seem not to have been explained, could you explain it please ?

Reduced resolution
BVOP sensitivity

cweb

3rd December 2003, 14:26

(Searched for this problem, there's no reference to it in the forums)
I loaded the new XviD 1.0 beta... it looks great. Set it to defaults.

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

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

Thanks to Koepi and everyone else involved...

sysKin

3rd December 2003, 14:39

Originally posted by Manao
There was a bug with dev-api-3, concerning transcoding of XviD to XviD, when the quant matrices used were different. A friend of mine tested that case with dev-api-4, and he encountered the same issueYes, it was fixed a few hours after beta1 was released. I guess you have to wait for beta2 :)
Originally posted by Koepi
Interlacing is broken currently (I think it's missing for bframes).Nope, the bframe support was added some time ago. The bug which you all see was fixed one day after beta1 release.

Radek

bilu

3rd December 2003, 14:45

Originally posted by m0rtal
bilu
are you turning postprocessing of the frames off? I mean, telecining usually decombs frames too, and after that you are trying to save interlaced frames...
maybe that is the problem...

I wasn´t decombing at all, I was trying to encode without any filtering from a pure FILM source (Telecined 24fps -> 30 fps)

Bilu

m0rtal

3rd December 2003, 14:51

bilu
sorry, I was thinking about inverse telecining :)

3rd December 2003, 15:39

Originally posted by Tueurne
Some options seem not to have been explained, could you explain it please ?

Reduced resolution
Not bothering reading all replies, are we? :sly:
http://forum.doom9.org/showthread.php?s=&threadid=65913&perpage=40&pagenumber=1#post405504

:D

Chainmax

3rd December 2003, 15:57

iago, syskin: most of my encodes are made with two-pass mode and hover in the 1100-1800kbps range (so the codec will probably never be saturated), so I guess that always enabling Trellis will benefit IQ. Thanks for the answer :).

gizmotech

3rd December 2003, 16:07

Chainmax,

It is very possible to over saturate the codec at 1000kbps.

Believe me, I do it on a regular basis w/ no compression assistants enabled.

Gizmo.

JimiK

3rd December 2003, 16:13

Sure that's possible. But there is no way the codec is handling this. Quant2 is maximum and that's what's used in first pass. So you will always have to increase resolution or use a sharper resize by hand.
Best regards,
JimiK

iago

3rd December 2003, 16:18

It is very possible to over saturate the codec at 1000kbps.Man, I really don't know how many times it should be repeated to make some sense! ;) Still, one more time, I wanna point out that bitrate alone doesn't mean anything. It depends on many other factors as well, such as resolution, compressibility, etc.

And believe me it is sometimes very possible not to get the codec to be saturated with a bitrate of even 2000kbps... :D

regards,
iago

arno

3rd December 2003, 16:27

Does anybody have any recommendation what settings to use for encoding credits. I haven't got the slightest idea what weight-factor is reasonable or what my old XviD api-3 codec's default quanitizer for credits is.

wannabe

3rd December 2003, 16:31

Weight 1.00 = Desired Rate 100% / thats the normal
Weight 0.5 = Desired Rate of 50%

I would say something between 0.5 and 0.3.

Btw if i understood well u have to have 2 Zones if u have Ending titles. And 3 if you have a sequence after credits right ? And 4(or +1) if you have an opening credits as well ?

krtek

3rd December 2003, 17:39

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

Sigmatador

3rd December 2003, 18:56

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

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

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

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

powerslave

3rd December 2003, 19:27

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

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

sapient

3rd December 2003, 20:06

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

cweb

3rd December 2003, 20:13

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

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

Thanks to Koepi and everyone else involved...

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

3rd December 2003, 21:06

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

iago

3rd December 2003, 21:25

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

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

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

regards,
iago

Hoschi

3rd December 2003, 21:29

Hi,

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

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

3rd December 2003, 21:43

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

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

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

wannabe

3rd December 2003, 23:09

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

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

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

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

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

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

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

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

wannabe

4th December 2003, 00:32

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

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

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

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

Chainmax

4th December 2003, 00:35

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

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

Manao

4th December 2003, 00:51

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

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

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

wannabe

4th December 2003, 01:09

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

loni_blues

4th December 2003, 01:13

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

P0l1m0rph1c

4th December 2003, 01:14

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

Manao

4th December 2003, 01:21

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

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

wannabe

4th December 2003, 01:26

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

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

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

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

Prettz

4th December 2003, 02:16

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

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

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

ChronoReverse

4th December 2003, 08:52

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

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

Manao

4th December 2003, 10:03

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

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

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

HarryM

4th December 2003, 15:43

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

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

Manao

4th December 2003, 16:33

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

communist

4th December 2003, 16:33

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

RadicalEd

4th December 2003, 17:31

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

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

outlyer

4th December 2003, 18:07

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

BoNz1

4th December 2003, 18:14

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

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

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

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

Prettz

4th December 2003, 18:52

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

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

Manao

4th December 2003, 18:54

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

Edit :

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

outlyer

4th December 2003, 19:23

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

wannabe

4th December 2003, 20:05

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

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

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

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

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

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

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

homersapien

4th December 2003, 20:13

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

Latest Avisynth 2.5
VDubMod 1.4.13

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

Manao

4th December 2003, 21:01

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

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

LigH

4th December 2003, 21:20

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

homersapien

4th December 2003, 21:35

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

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

Manao

4th December 2003, 21:42

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

cipher

4th December 2003, 22:08

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

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

wannabe

4th December 2003, 22:16

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

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

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

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

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

Manao

4th December 2003, 22:34

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

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

RadicalEd

4th December 2003, 22:48

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

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

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

Zep

4th December 2003, 22:49

Cool Feature Xvid is missing and needs IMHO.

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

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

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

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

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

Thanks

Zep

Prettz

4th December 2003, 22:56

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

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

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

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

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

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

Thanks

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

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

Manao

4th December 2003, 22:57

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

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

AgeOfPanic

5th December 2003, 00:06

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

iago

5th December 2003, 00:11

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

Manao

5th December 2003, 00:12

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

AgeOfPanic

5th December 2003, 00:14

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

LigH

5th December 2003, 00:35

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

So okay, now a few more technical details!

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

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

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

Manao

5th December 2003, 00:47

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

Leak

5th December 2003, 01:01

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

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

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

Movie Maniac®

5th December 2003, 01:28

I took a look to the new release

I'm not here to report any bug since I haven't enough tyime for testing at the moment, I'm studyin' hard...

I just want to say that, in my opinion, the new GUI is a little bit complicated, and this may have the effect of discouraging many users, especially newbyes. I think that the old GUI interface was more logical (i mean the disposition...) and intituive than the new one.

Especially the new profiles smells like divx, and that's not really good. i think that divx is really miles far (behind) xvid, so why imitate it? A famous spot in italy says don't himitate, just innovate! I think this should be xvid developer's anthem.

Anyhow, this is not a bug :D, and the official release is far from coming, so there's enough time for you to make necessary changes to make the guy look better and more user friendly.

Please, dont be angry with me, it's just my opinion. I'll carry on using xvid and suggesting it to my visitors, whatever will happen!!!

Bye

P.S. I forgot to say that somewhere in the GUI it is written "Global motion compenation"

Joe Fenton

5th December 2003, 01:32

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

Yep! In Gordian Knot. It doesn't handle the new 1.0 XviD properly. It gives you some outrageous FPS rate for the first pass when it really did absolutely nothing. The second pass is really the first pass, and the real second pass never gets done.

I had to quit GK and use VirtualDubMod directly to get it to work correctly.

KpeX

5th December 2003, 02:09

Any program that automated devapi3 xvid two pass encoding will not work without an update, mainly because some of the registry values are different now. Mainly the mode, before the 'mode' value could be 0-5, i think with 3 and 5 corresponding to the first and second pass, and now 1 and 2 correspond to the first and second pass modes. Therefore GK thinks it's in a different encoding mode than it is, so don't look to use any automated tools without an update to support devapi4. hth,

jarthel

5th December 2003, 03:29

The most common bug I encountered is vdubmod crashing on the last frame maybe near it. It's already 99% and vsubnmod suddenly spews out an error. I'm not so sure what is it (I will post again if it happens again) but it's something related to thread.cpp? maybe not the exact filename but it should be near that.

jayel

ps. more details or better yet a screenshot.

Prettz

5th December 2003, 03:42

Originally posted by Movie Maniac®
I took a look to the new release

I'm not here to report any bug since I haven't enough tyime for testing at the moment, I'm studyin' hard...

I just want to say that, in my opinion, the new GUI is a little bit complicated, and this may have the effect of discouraging many users, especially newbyes. I think that the old GUI interface was more logical (i mean the disposition...) and intituive than the new one.

Especially the new profiles smells like divx, and that's not really good. i think that divx is really miles far (behind) xvid, so why imitate it? A famous spot in italy says don't himitate, just innovate! I think this should be xvid developer's anthem.

Anyhow, this is not a bug :D, and the official release is far from coming, so there's enough time for you to make necessary changes to make the guy look better and more user friendly.

Please, dont be angry with me, it's just my opinion. I'll carry on using xvid and suggesting it to my visitors, whatever will happen!!!

Bye

P.S. I forgot to say that somewhere in the GUI it is written "Global motion compenation"
I think having this kind of support for profiles and levels is extremely extremely necessary for any professional MPEG-4 encoder. That said, Xvid's current user base fully expects to be able to bypass all that junk and just use the options they want to (and it appears you can still do all that, it just takes a little extra effort).

The GUI can definitely use a good deal of streamlining and simplification. However, you're now being given a good deal more power and flexibility than with dev-api-3, so there's no possible way to make AS SIMPLE as the old GUI while still giving all these extra options.

I think that the popup tooltips for every single object in the GUI needs to be crammed full of as much information and as many recommendations as possible. I like when the tooltips give you so much information that you don't even feel the need to consult any guides.

dragongodz

5th December 2003, 04:12

sorry if i missed someone reporting this already. ead all the pages very quick.

1-pass with b-frames (1 or 2) on playback first frame shows "warning: noithing, bframe decoder la"(asume lag since its cut off) using xvid beta1 decoder(playback or loading in virtualdub). using divx 5.1.1 for decoding does not produce a message.

jarthel

5th December 2003, 07:32

I forgot to add the settings

2-pass with 2nd-pass target set to 273000.
bframe (3/1.5/1 which I think is the default)
lumamasking (or whatever they call it now)
default quantization with trellis enabled
cartoon mode
ultra
wide-search
h.243

1st pass works flawlessly. it's the 2nd pass that has given me fits and it happens all the time for that particular vob and other vobs (encoding an anime). It doesn't have any problems with the encodes. I don't think it's the vob that is the problem cause it was encoded previously using 17-july-2003 Nic's xvid.

I'll provide a screenshot.

Hylas

5th December 2003, 09:25

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

Any plans for a non-secret release? I'd like to have a working interlaced mode. :)

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

5th December 2003, 09:59

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

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

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

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

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

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

Thanks

Zep
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. 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.
Originally posted by Prettz
I'm sure that filtering takes absolutely nothing at all compared to the amount of time it takes to encode Xvid at that resolution. I don't even want to imagine how large a VBLE video at HDTV resolution would be, either. (BTW, how large would it be?)
My 1600x864 matrix reloaded trailer in VBLE was about 1.5GB. That is for a trailer of about 1 or 2 minutes.