possible improvements beyond XviD 1.1 final [thread split]

[olnima]

The Problem might be, that most (including me) people think that there hasn't been too much changes since beta 2, so there might be not a big "step" between beta2 and beta3/final.

What I am thinking about is, if it would be better to optimize xvid for realtime capturing. IMO the "2-pass-race" against the new MPEG4-AVC-codecs is or will be lost but xvid has still a great advantage in speed for realtime-encoding.
Maybe this could be the future for xvid and after releasing 1.1 fin. it would be the right time to change its "developement-direction".

But anyway, xvid is still bombastic!!! Thanks again to all the devs.

Just a thought,
Olnima

[dragongodz]

i would like to make 1 little plea for the next version, a strict scaling option as koepi did for his beta1 version. i am not the only one who liked it as an option.
http://forum.doom9.org/showthread.php?t=92343

Just to let you know I appreciate it - and I guess I represent the 'silent majority' on this one!
yes there is always more noise for problems than posatives. ;)

[suxen_drol]

olnima: agree, but we're short on people to who are willing to implement the changes and (more importantly) spend the time tweaking/perfecting them.

dragongodz: the 2-pass code is "fragile" and this is why foxer's patch never made it into the 1.1.x series. that said, i will contact koepi about this to see if we can merge it into the next version after this release.

smd(1): are u talking about the "build=<somedate>" userdate text? i dont believe this came from libxvidcore.

smd(2): done!

[SeeMoreDigital]

Many thanks you guys :D

Nice to see that XviD development has not died...... I used it yesterday afternoon to generate a full movie "anamorphic" 2-pass back-up for use with my stand-alone player..... great stuff.

May I ask what kind of refinements are on the development agenda?


Cheers

[SeeMoreDigital]

Might it be time for XviD's GUI to be re-designed?

Anybody remember this thread (http://forum.doom9.org/showthread.php?t=79873)?


Cheers

[Teegedeck]

Oh; you bet I remember that thread. ;)

But any redesign-plans for XviD's GUI have crumbled till now. First there is of course the shortage of manpower, then there is the split among users. As long as about half of them are reluctant of the notion to make XviD's GUI more accessible or inuitive there simply won't be enough demand for that.

My favourite design is by niamh... Only that I would hide the lower part of it which should come up if you hit a 'more' button. (Ah, wishful thinking!) Like this:
http://img111.imageshack.us/img111/4199/gui21ne.th.png (http://img111.imageshack.us/my.php?image=gui21ne.png)
After hitting a theoretical 'more'-button:
http://img111.imageshack.us/img111/8713/guiforimbeciles3uy.th.jpg (http://img111.imageshack.us/my.php?image=guiforimbeciles3uy.jpg)
(minus the b-frames options - choosing a 'profile' should be enough for most people!)
Enough imbecile off-topic talk by me, or I'll have to strike myself! Shall we revive the GUI-thread? :)

[DeathTheSheep]

Yes...yes, I believe we should. Darn, truth to be told, the first time I loaded up the VFW, I exclaimed to myself something along the lines of:

"O! But it is rightly deplorable
That an interface so plain
With looks short of horrible
Can cause eyes such pain!

For DivX's is much better
And colorful besides
So DivX must be better!:
Less an affront to my eyes..."

Additionally, I believe that once the GUI is made more accessible and inuitive, demand would inevitably ensue for an "insane quality mode" to better compete with x264 (in quality and....speed;)). Indeed, a modern look entails modern quality...and vise versa. In a thread below, I described what I believe should be implemented in the final release. These posts can be found here (http://forum.doom9.org/showthread.php?p=717680#post717680) and here (http://forum.doom9.org/showthread.php?p=719765#post719765).

[Yuri Khan]

GUI? Design? A jedi craves not these things!

[DeathTheSheep]

True:D

But what about the various other (useful) suggestions I linked to? I think they are definately worth a peek. :)

here (http://forum.doom9.org/showthread.php?p=717680#post717680) and here (http://forum.doom9.org/showthread.php?p=719765#post719765).

[edit]
In fact, I think I might wanna quote it below. You know, just so it gets out there more easily. ;)

[unskinnyboy]

Tooltips for all options needed please! Tooltips are still missing for many options.

[SeeMoreDigital]

Tooltips for all options needed please! Tooltips are still missing for many options.Agreed.... That's why I had an "Information Window" in my GUI design ;)


Cheers

[DeathTheSheep]

I still think the existing features could use a bit of tweaking or optimization. Perhaps a few more of the "essentials" (according to this sheep, at least) include:
1. Sexy new FWV/GUI!! Heck yes. Look at x264 right now... *gurgle*
2. Different modes for B-frame bias (cartoon mode might want to use fewer B-frames on scenes with hardly any motion. P-frames in cartoons tend to be smaller and better looking than overquantized Bs in stiller scenes, not to mention the gap in P prediction caused by B-frame insertion. B-frames are still awesome in high-motion/high-bitrate scenes IMO).
3. Revamped, dynamic N-VOP insertion (3ivX 4.9b quality or better). Suggestion: If a frame has only a very small bit of motion (unnoticable), just stick in a P-frame. If it has no motion (or just about no motion, or no noticeable motion), insert an N-VOP.
4. Insane mode with (possibly?) limited layer detection, AQ for B-frames, P vs B experimentation (the codec takes time to calculate which would actually be preferable in the video), Quantizer noise shaping, loop filter (like ffdshow's), more advanced motion prediction, etc.

If you encode at a quality that you perceive as 'indistinguishable from the original' ('transparent'), regardless what codec you use, then you need never worry about quality. All that improvements in encoding technology bring you then is smaller filesizes. That's all there really is to it.

Exactly--A great way to give words to the current ASP encoder's situation. With an "Insane"-type mode for XviD (doesn't have to be "MEGA-insane layered mode"--an extended option implemented like "Turbo Mode" would suffice I suppose), the quality will remain the same but the filesize will decrease-- it would literally fit the definition of "an improvement in encoding technology":)!
Essentially, people with faster computers (2 Dual-Core Hyperthreading Pentium4 Extreme Editions) would be able to actually make Uber-high quality video while maintaining total decoder-side compatibility with all of their ASP-certified devices. This seems to be the crux of the matter.

Ever try playing back VGA AVC on a PPC? :D You need ASP here, and at transparent quality, any little twitch of extra storage space would help tremendously.
I'd happily wait the long hours common with encoding AVC if all of my players/pdas/handhelds/older computers/etc supported it. Since that is not an option, I'd happily wait an equal (or even increased) amount of time encoding in the ASP we know and love (and that works), if any amount of much-needed quality/filesize benefits were attained in doing so.

So, if its possible to milk out even a little bit of extra quality for the power user (at least enough to rival DivX's Insane mode speed ;)), I think its well, well worth the longer encoding time, especially given the complexity and current incompatibility of AVC with many of the devices/players which, quite frankly, need it most but do not have it.

In my philosophy, XviD will not have reached its prime until a "insanier quality" mode appears; only then can ASP's maximum potential finally be fully realized and taken advantage of... before AVC deems it too late, and ASP is never improved much again.
In conclusion, if AVC is so darn slow, and XviD can almost rival its quality, wouldn't it make sense to slow XviD down to x264's speed with an "Insane mode?" I suggest this instead of simply switching to AVC due to all the problems AVC is still having (incompatibility and an "emerging" codec's problems among them).

Insane mode. Needed. Badly. That's the biggest thing I have to say.
Anyone with me? (If you aren't I will shut up anyway :D)

[ChronoCross]

In conclusion, if AVC is so darn slow, and XviD can almost rival its quality, wouldn't it make sense to slow XviD down to x264's speed with an "Insane mode?" I suggest this instead of simply switching to AVC due to all the problems AVC is still having (incompatibility and an "emerging" codec's problems among them).

Insane mode. Needed. Badly. That's the biggest thing I have to say.
Anyone with me? (If you aren't I will shut up anyway :D)

Slowing the codec down more will give almost a non-visible increase in quality. Take a look for example at DivX's Insane mode. It looks like death and is slow as a snail and doesn't even match xvid with default settings. Slowness doesn't always mean better looking/compression. Sometimes it just becomes useless calculations. AVC will definitely be better in the long run for high end encoding. Xvid is still my encoder of choice atm due to it's speed and really good compression.

[dragongodz]

dragongodz: the 2-pass code is "fragile" and this is why foxer's patch never made it into the 1.1.x series. that said, i will contact koepi about this to see if we can merge it into the next version after this release.
thanks. one of the great things about xvid is having options and strict scaling IMHO would make a good, non-default- one. :)

[DeathTheSheep]

Slowing the codec down more will give almost a non-visible increase in quality. Take a look for example at DivX's Insane mode. It looks like death and is slow as a snail and doesn't even match xvid with default settings. Slowness doesn't always mean better looking/compression.
Here you are comparing XviD with DivX. I am really not speaking of such a cross-codec comparison--such a comparison does not mean anything in terms of what I was proposing. Whether or not DivX can beat XviD at any speed (which, by the way, is subjective) is not in question.

For more accurate comparison purposes, consider this:
When DivX's "balanced" mode (a bit faster than XviD) is compared to its "Insane" mode, there are blatantly obvious quality increases. Therefore, this:
Slowing the codec down more will give almost a non-visible increase in quality is a bit ... inaccurate. Quite frankly, slowing the codec down more will give almost a clearly visible increase in quality, at least for DivX.
So, by these standards, the same may be true of XviD. Correct?

[ChronoCross]

For more accurate comparison purposes, consider this:
When DivX's "balanced" mode (a bit faster than XviD) is compared to its "Insane" mode, there are blatantly obvious quality increases. Therefore, this:
is a bit ... inaccurate. Quite frankly, slowing the codec down more will give almost a clearly visible increase in quality, at least for DivX.
So, by these standards, the same may be true of XviD. Correct?

the quality increase is not worth the speed loss. you get maybe 3% better compression quality between insane and balanced modes. It's not impressive when you consider the time it's taking to do all these extra calculations.

[sbp]

What I am thinking about is, if it would be better to optimize xvid for realtime capturing. IMO the "2-pass-race" against the new MPEG4-AVC-codecs is or will be lost but xvid has still a great advantage in speed for realtime-encoding.


I agree, this would be a very nice feature - making xvid THE codec for real-time capture


Steen

[DeathTheSheep]

the quality increase is not worth the speed loss. you get maybe 3% better compression quality between insane and balanced modes. It's not impressive when you consider the time it's taking to do all these extra calculations.

Oh, come on... This, my friend, is the single most incorrect assumption I've yet heard in all of my time at Doom9's forum. I simply can't imagine why you'd say such a thing--you obviously haven't tested Helium at all.

With exactly the same encoder settings and general setup, at quantizer 4, I performed these tests.
Encoder: DivX Helium build 1612, no noise reduction, no psychovis, H263+, chroma bias 6, 3 B-frames
Computer: 3ghz, 512ram, 533fsb

TEST RESULTS:
BALANCED mode--balanced.avi (908 KB) (http://www.filepost.us/userfiles/xsquaredx/balanced.avi), encoding time: 51 seconds
INSANE mode--insane.avi (783 KB) (http://www.filepost.us/userfiles/xsquaredx/insane.avi), encoding time: 1 minute 7 seconds

It is starkly obvious that a 16% increase in compression quality entails a 31.4% decrease in speed.

If this isn't "worth it" to you, I don't know what is. A 16% quality increase for a 31% slowdown is definately "worth it" to me and many other users. These are certainly not "worthless calculations."

edit 1:
Additionally, I somehow got a filesize of 774KB in "2147483647"-performance mode. (with a 1 min 9 second encoding time).

So clearly an "Insane" mode isn't that bad of an idea, especially if you want some extra quality out of your encodes. Given the above results, it would greatly benefit to slow XviD down a bit (I'm not suggesting ultrauuber layer detection-style insane, per se, but just some kind of extra quality pump).

edit 2:
Updates with PSNR!!
#ASP Decoder: Helium vfw w/out PP
#HuffYUV Decoder: ffdshow w/out PP
#Source and all encodes used yv12 colorspace

insane=converttorgb32(avisource("insane.avi"))
balanced=converttorgb32(avisource("balanced.avi"))
yv12=converttorgb32(avisource("huffyuv.avi"))
compare(balanced,yv12)
#compare(insane,yv12)


#PSNR RESULTS
#---------------
#Balanced: 41.43
#Insane: 41.53

Given these results, it's actually more than a 16% quality increase with Helium. So, a 16% filesize decrease and a 0.1db PSNR increase is absolutely worth it, and such a mode would help XviD tremendously.

[Manao]

DeathTheSheep : your comment is totally groundless : you forgot to talk about psnr. So, for example, the file reduction might be 15 %, and the psnr drop 0.5 dB. You must take both figures into account when making comparison.

[Sagittaire]

DeathTheSheep : your comment is totally groundless : you forgot to talk about psnr. So, for example, the file reduction might be 15 %, and the psnr drop 0.5 dB. You must take both figures into account when making comparison.

yes but seem to be the opposite if test from divxlabs are correct ... it's illustrate with this comparison.

http://labs.divx.com/archives/TESTFusion.gif

size_balanced_quantN > size_insame_quantN
and in same time
opsnr_insame_quantN > opsnr_balanced_quantN

with this graph with q4 insame mode is ~12% better that balanced mode

but the demontration is correct : if you want make size comparison, you must use exactly the same quality level.

[suxen_drol]

on the subject of gui improvements, syskin has proposed an interim solution to improve the usability of the current user interface. basically, xvid will provide some "motion presets" to simplify the configuration of motion-search-precision, vhq, chroma-me and trellis-quant options. these presets will be selected from the main config window, meaning that inexperienced users wont have to delve into the existing motion/quant pages. these pages will of course be retained for experienced users.

below i have included a screen shot of what it might look like. the software changes here are fairly trivial and could be put it into the 1.1 release. the difficulty is coming up with some meaningful presets. e.g. real-time, natural-video, cartoon, extra detail, etc. ideally, these presets will be unified between vfw and encraw.

http://img27.imageshack.us/img27/4355/xvidguiproposal1kl.png

-- pete

[Elias]

And if it's possible to alter parts of XviD's GUI, can somebody please re-name "Picture Aspect Ratio" to "Display Aspect Ratio"...

http://img32.imageshack.us/img32/6831/xviddar1ft.png


It's been bugging me for years!Yes, please do that. It's confusing when you're not in the know-it-all business.

[DeathTheSheep]

So in the graph above, it's red line (balanced) vs. yellow line (insane).
DeathTheSheep : your comment is totally groundless : you forgot to talk about psnr. So, for example, the file reduction might be 15 %, and the psnr drop 0.5 dB. You must take both figures into account when making comparison.

Yeah, I know, I just depended on DivX's quantizer-quality ratio to stay about the same ;). edit: PSNR results below!

But whatever way you add it up, it's not totally groundless-- it all amounts to the same thing--Insane mode far outperforms the standard "balanced" mode and only sacrifices 30% speed.

And consider how many people use it--Doom9 used it for his codec comparison, I use it when I need DivX files, other quality-hunters don't even hesitate, especially for shorter clips.

Doesn't all this make Insane mode a worthy canditate for consideration in XviD Final?

edit:
Updates with PSNR!!
#ASP Decoder: Helium vfw w/out PP
#HuffYUV Decoder: ffdshow w/out PP
#Source and all encodes used yv12 colorspace

insane=converttorgb32(avisource("insane.avi"))
balanced=converttorgb32(avisource("balanced.avi"))
yv12=converttorgb32(avisource("huffyuv.avi"))
compare(balanced,yv12)
#compare(insane,yv12)


#RESULTS
#---------------
#Balanced: 41.43
#Insane: 41.53

So it's actually more than a 16% quality increase with Helium (if my results are correct ;)).

[DeathTheSheep]

And another request:
Lumi Masking optimized for "Cartoon Mode"-- I've heard tales of ugly blocking in anime shadows...

[Kopernikus]

Can you be a little more specific? Screenshots, perhaps? Or a thread where this is discussed?

In German Doom9 we are currently discussing improvements for the adaptive Quantization for darker scenes. Perhaps this can help.

[DeathTheSheep]

Ah sure, no problem--looks like I was vague. Hm...
http://forum.doom9.org/showthread.php?p=720198#post720198

Sorry, that's the best I can do right now...*sigh*
But if you're discussing it in the German forum, great. Good to know it's already a WIP. :)

[SeeMoreDigital]

Going back to XviD's GUI for a moment....

I quite like the "four page" layout of the x264 GUI: -

http://tinypic.com/ega03r.png

How about adopting this type layout configuration (and terminologies) for a new XviD GUI too?


Cheers

[DeathTheSheep]

Yeah, the "sexy x264 GUI" I mentioned above is attracting some attention! Great ;)

So much for individualism (of my ideas :()
So much for individualism (of x264's gui :()

Well, I like it too, and it would be pretty cool to have the 2 big OS codecs look the same! Yeah, I'm liking this idea more and more :p

[Kostarum Rex Persia]

Well,that's a fantastic idea. With that GUI, Xvid will looks much better than curent version. I supporting this idea,it's very good. Keep going.

[Sharktooth]

The "sexy" GUI has no space for the remaining options...
It needs 5 or maybe 6 tabs to include zones, CQMs, AQ, VUI etc...
However the current layout is this:
http://www.webalice.it/f.corriga/temp/bitrate.pnghttp://www.webalice.it/f.corriga/temp/rate_control.png
http://www.webalice.it/f.corriga/temp/Frames.pnghttp://www.webalice.it/f.corriga/temp/more.png

[SeeMoreDigital]

The "sexy" GUI has no space for the remaining options...
It needs 5 or maybe 6 tabs to include zones, CQMs, AQ, VUI etc...Yep... I had a quick look at this the other day and thought we may be able to get away with 5 tabs!

If I have some time tomorrow I'll attempt to do some cutting and pasting and come up with a "starter" proposal :)


Cheers

[SeeMoreDigital]

By-the-way...

Given that the packed bit-stream AR issue has been sorted now, would there be any chance of having a separate direct-show decoder filter?

And during the installation process. How about an selectivity option to install just the encoder. And another option to install the encoder plus decoder?


Cheers

[Soulhunter]

Btw, I think it would be a good idea to improve XviDs decoder! For high bitrates XviD is still superior (imo) but we all know that for low bitrates h.264 does a better job (in-loop filtering). So, adding something like (advanced) SPP deblocking would make XviD a little bit more coequal in this area. After all XviD is a codec, and while the encoding has improved a lot in the foretime, the decoder hasnt improved at all (or at least not very much). Good idea? Bad idea? And, who is willing to add something like this?


Bye

[708145]

Btw, I think it would be a good idea to improve XviDs decoder! For high bitrates XviD is still superior (imo) but we all know that for low bitrates h.264 does a better job (in-loop filtering). So, adding something like (advanced) SPP deblocking would make XviD a little bit more coequal in this area. After all XviD is a codec, and while the encoding has improved a lot in the foretime, the decoder hasnt improved at all (or at least not very much). Good idea? Bad idea? And, who is willing to add something like this?


I'm all for it. But I fear that SmoothD might be too slow for post processing even if it is working sometime in the (hopefully near) future.

bis besser,
Tobias

[Sharktooth]

An improved decoder able to use pixel shader 2.0 (for filtering, effects etc.) would be great, but i guess it requires some knowledge, time, testing and above all thing someone that wants to code it...

[Blue_MiSfit]

If only I could code. I've been dying for someone to take advantage of the programmable GPUs on modern video cards. This is a very good idea, perhaps it's how ati/nvidia "impliment" (ha ha ha) their promised h.264 hardware decoding.

[suxen_drol]

The "sexy" GUI has no space for the remaining options...
It needs 5 or maybe 6 tabs to include zones, CQMs, AQ, VUI etc...

indeed. the current xvid layout came about because of the problems of managing too many tabs on a small window. in retospect, we could have just increased the size of the window.

[dragongodz]

So, adding something like (advanced) SPP deblocking would make XviD a little bit more coequal in this area.
agree. i use SPP deblocking in FFDshow and its very good.

[Teegedeck]

on the subject of gui improvements, syskin has proposed an interim solution to improve the usability of the current user interface. basically, xvid will provide some "motion presets" to simplify the configuration of motion-search-precision, vhq, chroma-me and trellis-quant options. these presets will be selected from the main config window, meaning that inexperienced users wont have to delve into the existing motion/quant pages. these pages will of course be retained for experienced users.
I like it. I like it enormously. Presets would be a great step towards usability improvement and all the better if it happens so much more quickly than I'd expected! :)

Include a user-definable preset and I bet we could also get the 'pros' to like the idea. I guess the presets would be meant to determin VHQ-level etc; so there'd be no need for the quality-slider I proposed.

On the subject of presets in general: Without its well-tuned 'alternate-presets' (now evolved into the 'Vn'-presets), LAME wouldn't still be the most sucessful audio-codec, rivaling much newer layouts like AAC. So I think it is time to start regarding preset-development as one meaningful part of XviD's development. One good thing about thinking-up/testing-out presets is that it doesn't need coding-abilities - which the XviD project currently is running short on.

Thank you, Pete and thank you sysKin (nice touch, feels like the old days)!

Another thing: I feel this thread is looking a bit messy right now. It started out as the simple announcement of 1.1 final and last chance to file bug-reports; now we're collecting all sorts of ideas, most of which will not be implemented in XviD 1.1, some of which may never be implemented. Shall I split the thread and move all posts that relate to improvements to a new thread titled something like 'possible improvements beyond XviD 1.1 final'? I wouldn't want to call it a 'feature wishlist' for obvious reasons...

[708145]

If only I could code. I've been dying for someone to take advantage of the programmable GPUs on modern video cards. This is a very good idea, perhaps it's how ati/nvidia "impliment" (ha ha ha) their promised h.264 hardware decoding.

biggest problem with that are the bit operations in Huffman/CABAC. current shaders can't do that. but if ati and nvidia add special HW for it then fine.

bis besser,
Tobias

[suxen_drol]

I like it. I like it enormously. Presets would be a great step towards usability improvement and all the better if it happens so much more quickly than I'd expected! :)

i have been thinking more about the proposal. the changes are rather trivial, so my intention is to put something together over the weekend.

Include a user-definable preset and I bet we could also get the 'pros' to like the idea. I guess the presets would be meant to determin VHQ-level etc; so there'd be no need for the quality-slider I proposed.

whilst a slider has much appeal, there is no "easy" way to encompass the all motion options on a linear scale. a slider could of course be used to scroll though the options. (personally) i think a combo box is more appropriate for listing such things.

On the subject of presets in general: Without its well-tuned 'alternate-presets' (now evolved into the 'Vn'-presets), LAME wouldn't still be the most sucessful audio-codec, rivaling much newer layouts like AAC. So I think it is time to start regarding preset-development as one meaningful part of XviD's development. One good thing about thinking-up/testing-out presets is that it doesn't need coding-abilities - which the XviD project currently is running short on.
Thank you, Pete and thank you sysKin (nice touch, feels like the old days)!

yep, i too feel this is where xvid is headed. that said, there has always been a steady flow of minor contributions and the like. there are some patches, such as data-partitioning, should be revisited.

Another thing: I feel this thread is looking a bit messy right now. It started out as the simple announcement of 1.1 final and last chance to file bug-reports; now we're collecting all sorts of ideas, most of which will not be implemented in XviD 1.1, some of which may never be implemented. Shall I split the thread and move all posts that relate to improvements to a new thread titled something like 'possible improvements beyond XviD 1.1 final'? I wouldn't want to call it a 'feature wishlist' for obvious reasons...

agree.

[Teegedeck]

Done.

Original thread: Proposal: XviD 1.1.0 (beta3?) release (http://forum.doom9.org/showthread.php?t=100147)

[SeeMoreDigital]

Nice one... I'll post my GUI suggestion here ;)


Thanks

[COREiP]

As you all can see, most of the developers are dedicating much of their time on x264 project. They already have their hands full so let them focus on fixing the known bugs, and optimize the codec as much as possible. Most users are switching to DVD-R ("space is not a problem now these days") and in general codecs don't improve much in quality at high bitrates. Whats special about XviD is Speed and Quality which is far beyond any ASP codec. I think the codec has given everything it can possibly give. Adding new features to XviD will just create more bugs and possibly gain a tiny amount of quality (Waste of time to the developers). With a AMD 64 3500+ you can easily hit 100+fps. Now for those who go for extreme quality H264 is the best choice at very low bitrates and there is no way any ASP codec can get close.

[Teegedeck]

This thread is not about about the sense of XviD development (which always gets dangerously near mere trolling), COREiP. Unfortunately we don't have a chit-chat subforum on Doom9, otherwise I would recommend you opening a new thread there for that topic. So, please, if you absolutely must, open a new thread about it in the XviD forum. Or should I split your post from this thread and thus create that new one?

[COREiP]

Let me clarify. XviD needs bugfixes, optimizations and a new fresh gui for the next version. :cool: :cool:

[prOnorama]

Well I'm happy to see there's some re-newed attention for XviD.

It's still my favourite codec because I strive for maximum compatibility, playable on the widest possible range of computers and stand-alone equipment, while still offering low filesize and good quality (since my rips are mostly for other people instead of myself).

Try playing x264 on a Celeron 900 ;)

So thanks to all the people spending their time on XviD development, it's much appreciated.

[Elias]

Just curious, any estimation of when XviD 1.1 will be released?

Most users are switching to DVD-R ("space is not a problem now these days") and in general codecs don't improve much in quality at high bitrates.

Let me clarify. XviD needs bugfixes, optimizations and a new fresh gui for the next version.Let me clarify: not everyone uses XviD for DVD rips. I use XviD for encoding my webcam movies for instance. And I only have an 18 GB hard drive, with a slow cpu. Not everyone has the latest stuff.

But yeah, it wouldn't hurt if Xvid got all that you wanted.

[LordIntruder]

Most users are switching to DVD-R ("space is not a problem now these days")

Space has always been a problem. Years ago a simple 1,44" diskette was a lot of space, then it started to become short. We have 4Gb on a DVD but now it become short and DVD-DL is here but quite expensive and soon in one or two year those will be short in space too.

We have enough space but at the same time there is not enough and this is why new technology goes farther as time goes by.

People switch to DVD, yes but when high resolution DVD will be available to the masses, when HD-DVD or Blur-Ray will be around the corner, again space will be a problem.

And not everybody switch to DVD-/+R.

I think the codec has given everything it can possibly give.

You think. But this is not because YOU think something has reached is maximum that it is true. Two year ago I remember some people saying that XviD or DivX had given everything or almost. No one can state that a codec has given everything unless everything is done to put the codec to its best. Did the developers worked hard to the point that no further improvement can be done? They can answer that, not you (unless you have enough knowledge). Maybe there is a lot that can be done to improve some things (speed, quality, support of SMP for dual-core processors, etc...).

Look what you have today, go back 2, 3 or 5 years ago and look again to that people that were saying that it was IMPOSSIBLE to get what today we consider for granted.



Adding new features to XviD will just create more bugs and possibly gain a tiny amount of quality (Waste of time to the developers).

And because adding new features create more bugs for a tiny amount of quality then you state that it is a waste? Even if the developers work hard to only gain almost nothing in quality, they will improve their knowledge, they will learn things from their work and maybe this knowledge will be put somewhere else, a day. Nothing is lost.

Of course it will become harder and harder to get improvements but if in a new version we can get rid of more macroblocks, if we can get rid of more ringing, etc... Isn't that worthwhile to try?

And finally if new versions are on the way, if they bring new bugs for only a tiny amount of quality, you are not obliged to test and work with those versions. Feel free to stick with the current one and let the others play with the buggued ones. There is no obligation to upgrade ;)


With a AMD 64 3500+ you can easily hit 100+fps.

And because YOU have a 3500+ and that YOU encode at 100 fps YOU think that everyone has a 3500+. No sorry, most of people don't have such processor, many still have 2400+, 2000+, 1500+, Celeron, etc... Many people encode at 10 fps or even less. Maybe those people would be happy to know that developers work hard to improve speed in Xvid encoding don't you think? Now I also understand that the one who encode at 100 fps doesn't care if developers work on a faster version but we can't forget those that do not have the last high-end processor and spend 5 hours or more per pass. Unless you give 3500+ to those who need one? :D

[ChronoCross]

I've always been curious as to how people manage to get 100fps. Only time I've seen it happen is with files loaded directly and reencoded. No one who uses avisynth and filtering has ever been that fast so speed is still an issue.