Log in

View Full Version : Aloha!


Pages : 1 2 [3] 4 5 6 7

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! :)