Aloha!

[Koepi]

Tadaaa!

We are very proud to announce..... *whirling drums*

XviD-1.0-Beta 1 (codename Aloha)!

There will be plenty of bugs, your bitstreams might be not mpeg4 compliant ;), the usual stuff... but it's there, it's real, it's fresh, we're alive 'n kicking!

Enjoy this release and give plenty of feedback please! We want XviD-1.0 to be rock-solid, so we need your input now as we found most of the important bugs ourselfes and think you are way better in finding the remaining (hidden for us) flaws.

Btw.: the GUI might be subject to change. Play around with it in any case, you'll find some features are a bit "hidden" compared to the old GUI.

Ok, stopping the babbling now, follow the link in my signature to find the build - and enjoy the all new, close-to-final XviD-1.0!

Best regards,
Koepi

[gldblade]

I guess I should have waited for it to be announced officially :)

About the GUI, I've always been wondering why hovering over the options does not consistently bring up the pop-up yellow descriptions. Is this just a problem with my computer, or is anyone else having this problem?

[Koepi]

Some items don't have a description :-/ But vfw GUI isn't major concern now, it's the codec internals (as I wrote, GUI is subject to change, so it'll be all different from the interface side some time soon hopefully).

Regards
Koepi

[cipher]

WOW!!
I'll just leave my name here for future historical records :D
'been waiting for this for a long damn time, tho I know this is not quite different than the latest dev-api-4 cvs, but XviD 1.0 sounds just cool.:D

[Lobuz]

....finally!!!
It sounds cool. But just take a look at the backstage of xvid dev mailing list. ;)

Regards
Lobuz

[mfluder]

I guess I will be the first one to open this bug hunting season. What an honour :)

I noticed this during the testing of my dev-api-4 compiles but I wanted to wait for the official betas. When decoding dev-api-3 streams (Koepi's latest) and the height is not multiple of 16 (it's multiple of 8, 640x360) there is a bleeding at the bottom of the clip. I don't have any webspace so I can't post a screenshot but you can spot it easily. There is no problem when the clip is encoded with dev-api-4.

Other than that, so far, I haven't found anything serious. It's worth mentioning that the speed has quite improved compared to dev-api-3. Oh wait, that's not a bug :D

Congratulations to the whole XviD team, you are doing a great job.

mfluder

[yeeyy]

Cool!!! I have been waiting for today. :)

[cipher]

....finally!!!
It sounds cool. But just take a look at the backstage of xvid dev mailing list.

yeah I know :p there's been little arguments regarding the XviD 1.0 and its code, and honestly, I was a little shocked when I saw this beta released, coz' I thought they hadn't reached an agreement.
Anyway, the more important thing for us to do now is testing and giving feedbacks. :D

[BoNz1]

Hey, hey it has been too long! Anyway, even though I have been testing dev-api-4 a lot since the summer I'm going to do some encodes tonight and I will report tommorow maybe. I think I'm going to encode the Grinch w/ qpel, bframes: 1 1.5 1, adaptive quant, trellis, h263, vhq1, cm. Hopefully, I will be able to put it onto 1 cd at 704x384 res.

[K-Dash]

Great work!
I was wondering if b-frames works since I can't seem to find the old options for it in this one and I've tried several passes with bframe quant 2-6 2-4 and it doesn't show up on the xvid frame encoding window.

[Tuning]

Alohamora!
Opening new year of encoding, with XviD 1.0. How wonderful!.
Thanks koepi.

[winman]

Wow...this is nice.

@K-Dash

- Click on the [...] box next to Profile @ Level (you need to select AS or higher profile inorder to enable b-frames).
- Check the box BVOPs

@Koepi

Is there a way to read the info for the first and last 173 frames in the StatsReader?

BTW...does the "Display encoding status" option work with avs2avi?

[Enigmax]

:D :D :D :D :D :D :D :D :D :D
Thanks.

greetings

[kastro68]

When doing 2passes and using a quantizer ratio of 5,

The first pass and second pass have the same file size.

ie. The second pass does not shrink to the target size.

I'll try it again on a different source, I'm pretty sure I didn't do two first passes.

Is GMC safe to use with VHQ4?

edit: Thanks for new build. I like the new gui...comes in handy especially for managing credits.

[K-Dash]

Originally posted by winman
Wow...this is nice.

@K-Dash

- Click on the [...] box next to Profile @ Level (you need to select AS or higher profile inorder to enable b-frames).
- Check the box BVOPs

@Koepi

Is there a way to read the info for the first and last 173 frames in the StatsReader?

BTW...does the "Display encoding status" option work with avs2avi?

I see, thanks. Woah the first thing I noticed about this is the speed upgrade from the old build.

[amirlsm]

Nice work developers!

I'm already trying encoding with the new beta.

Since the options GUI changed, Can anyone post an updated "Xvid Options explained"?
Could anybody shade some light on the "profiles"
Will using a pre-defined profile, guaranty playing the disk on a hardware "Divx" player or a future MPEG-4 player?

Tnx,
Amir

[VincentRPGz]

Finally! A new xvid! this is what everyone has been waiting for! Good job so far from what I see, another amazing thing from the xvid team!
As usual, keep up the good work!

[b00zed]

That codename sounds eerily similar to those released by DivX labs, coincidence? :D

I recognise, and can appreciate, the effort that goes into some of these fairly complex open source projects. I'm consistently impressed by the abilities of the various beta codecs that have been released, and a solid representative v1.0 release might be just the thing to convince me to turn to the dark side, at least for high bitrate work :)

I think congratulations are appropriate for everyone involved in the development of this project.

Edit: I have to say I like the interface, and the addition of selective quantization zones is very nice :)

[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.

[ammer]

woohoo! yay

[geoffman]

Great stuff!

/me backs away from his new foray into MPEG2 and DVD authoring to have a play! :D

[superdump]

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]

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]

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]

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]

YABBA-DABBA-DOOOOOOOOO :p

[iago]

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

Thanks a lot,
iago

[Teegedeck]

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]

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]

YEEEEEHAAAAW! Let the testing begin...

[Koepi]

*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]

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]

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]

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

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

[raz0r]

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]

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]

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]

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]

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]

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

[mf]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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