Some questions about Xvid development and future

[mac1929]

Hi there!

Since I read the famous doom9's codec comparison I've been interested in Xvid development. Mostly because I don´t like the way that Divx Networks is taking. For sure, I'm in the same situation as a lot of new Xvid fans!! :)

I've been having a look to xvid.org and doom9.org forums to figure out the state of development of the core, and there are some things that I don´t understand:

As I see in xvid CVS there is a dshow project. There is also another directshow filter provided by NIC. Are they two different filters or NIC's one is an evolution of xvid's?? Anyway, if NIC has a filter that works fine why not including it in CVS??

Koepi's binary distribution with chm help and NullSoft Installer really rocks! However, every time the core changes, Koepi adds some changes before making his binary distribution. Why is necessary to reaply those changes every time? Why not including chm help and koepi's mods in cvs (and maybe the installer!)?

Just now Xvid does not support b-frames and divx3 but AFAIK GPL conversion is almost finished since this weekend changes and codec seems to be stable, and have good quality. I suppose that there are plans to release an "official" version soon or later, if not why
to develop divx backwards compatibility?? Does anybody know when we will se it?

Thanks for your attention and regards!!

[avih]

deleted my answer. -h's is better :)

cheers
avi

[-h]

As I see in xvid CVS there is a dshow project. There is also another directshow filter provided by NIC. Are they two different filters or NIC's one is an evolution of xvid's?? Anyway, if NIC has a filter that works fine why not including it in CVS??

Nic's still working on his dshow filter. It is "easier" to work with a private branch of code, making large changes therein, than sticking little bits into CVS every now and then. It'll be in there soon, don't worry :)

Koepi's binary distribution with chm help and NullSoft Installer really rocks! However, every time the core changes, Koepi adds some changes before making his binary distribution. Why is necessary to reaply those changes every time? Why not including chm help and koepi's mods in cvs (and maybe the installer!)?

We cannot distribute an installer, as the XviD project has not paid the appropriate licensing fees to the MPEG-LA group. I'm integrating Koepi's changes into the CVS, among a few other changes, but these things take time.

Just now Xvid does not support b-frames and divx3 but AFAIK GPL conversion is almost finished since this weekend changes and codec seems to be stable, and have good quality. I suppose that there are plans to release an "official" version soon or later, if not why
to develop divx backwards compatibility?? Does anybody know when we will se it?

GPL conversion is "finished" yes, but that doesn't mean the codec is ready for an official release. What would an official release actually consist of? Big version numbers are mostly a carry over from commercial marketing schemes - with a CVS repository, you can be fairly sure that the later the build, the better. I certainly wouldn't want people using some old "official stable" version, as that just means more to support, and most likely inferior rips still being produced :)

DivX3 decoding is working (though not committed to CVS, it's still slightly buggy and 6 times slower than MPEG4 decoding). B-frame decoding is almost finished, but B-frame encoding is waiting on some developer coordination to get everything working together.

These things will happen, they just take time :) One of the more attractive facets of open-source development, is that you're not under pressure to churn out some "working code" by a deadline - you have time to make things pretty, try out some experimental options here and there and just enjoy yourself. Asking an open-source developer "when will you get around to xyz!" is likely to remind them of the kind of pressure you get when you code for a living, and the answer you get is always overoptimistic. Just like at work :)

-h

[mac1929]

avih, -h tnx for your soon reply!!

[Nic]

Sorry my codes not in the CVS, it will be shortly, if you want it in the mean time, then just shout me.....


(.....I did alot more optimising yesterday, the deringing filter is now as quick as it will get in C)

Cheers,
-Nic

[rui]

First, i want to say: greetings mac1929 :)
It's good to see some neighbords here. I am from Portugal, a city called Braga. Where are you from, in Spain?
How about that player Figo?? Great guy, isn't him? :) (hope you aren't from Barcelona... :D)

Now..

Originally posted by -h

GPL conversion is "finished" yes, but that doesn't mean the codec is ready for an official release. What would an official release actually consist of? Big version numbers are mostly a carry over from commercial marketing schemes - with a CVS repository, you can be fairly sure that the later the build, the better. I certainly wouldn't want people using some old "official stable" version, as that just means more to support, and most likely inferior rips still being produced :)
-h

This could bring problems to Gnot supporting Xvid. I am not seying TheWef releasing a new Gnot version everytime Xvid has some new feature, that can't be used with the current Gnot version.
I for one prefere to have the Xvid feature, and keep working with Vdub manually ;)

By -h:
B-frame decoding is almost finished, but B-frame encoding is waiting on some developer coordination to get everything working together

I guess that big sunday release was only a little hype ;)

[athos]

i understand that opensource development is different in many aspects from commercial, closedsource. still, wouldnt it be good to aim for a "1.0" release somewhere in the future? with this, i mean that the addition of new features should temporarily freeze, as much bugs as possible should be squeezed out and a stable release built. i think this would be good because lots of people are staying away from xvid because its is still "in beta" or whatever you want to call i. after this "1.0" release, development would continue, and even further in the future a new stable "2.0" would be release if new features warrant it.

i do understand that xvid is an educational project, but lets be honest, we do want to use this codec dont we? im not saying that this "1.0" release has to be soon, and i am definately not saying that xvid should turn "commercial" but i think it would be good to sometime finalize a sort of base release for people to use.

[canadian_fbi]

how many divx-encoding programs do you use that are even 1.0? i know i use gordian knot 0.23 (granted i'm not including the various programs it uses that are 1.xx+), headac3he 0.22b, the 0.9.8.6 oggds filters and "unnumbered" xvid. and the quality's better than divx 4.12 with lame 3.91 audio in an opendml (2.0?) avi container. :)

i agree that version numbers are somewhat unnecessary. they could name tomorrow's release "1.0" if they wanted to, it wouldn't change anything, and it wouldn't make it any more official than it is now. it might sound more official, but it would work just as well as it does currently.

maybe b-frame support would be a leap ahead significant enough to warrant numbering for the sole reason that you know from the release number that it's a breakthrough. but it doesn't appear to me like the current development process would really lend itself well to an official numbered release. but then again i went off on a big rant a couple years ago about how the year 2000 was just as much the new millennium as 2001 because it's all an arbitrary numbering system anyway, so maybe i have a pet peeve against this or something :)

or you could just hastily add a few bug-ridden features to it, call it xvid 5.0 and charge $30 to download it. either way.

[-h]

or you could just hastily add a few bug-ridden features to it, call it xvid 5.0 and charge $30 to download it. either way.

Don't tempt me ;)

I'd only expect to see "official" XviD releases when it reaches full (bug-free) compatibility with an mpeg4 profile - advanced simple, or core for example. Both are a long way off.

Even in that case, I'd still like people to use the latest versions. How many people used crappy old builds of LAME 3.xx, just because it was deemed "stable" compared to the latest (and superior by far) CVS build? And how many lower-quality MP3s are floating around now because of that?

Many versions means support headaches too - I'll probably just refuse to support older versions if questions about 3-month-old builds start showing up.

-h

[gnoshi]

I don't know about you guys, but I kind of think that video and audio codecs are not as well suited as many other things for 1.0-type releases, as there are always refinements going on.
This goes even more for video codecs that audio codecs I think, because of the nature of bitrate tuning in audio codecs which (in my head, however wrong it may be) is not so present in video encoding.

I mean, yeah sure smartripper reaches a release which does what it is meant to do, and subreleases come out to fix bugs, but with a video encoder it is not so cut and dry, because the goal is more idealistic - ie. rather than saying 'I want to be able to rip and decode DVD files' as in the case of smartripper, it is 'I want to be able to compress video as well as possible as small as possible'. A tad less defined, no?

That said, go for it XVID coders; you (along with the ogg/vorbis crew) are the kind of people I really look up to. You represent (to me) the kind of skills, dedication, and altruistic attitudes that I really admire.
Good work chaps :)
smile

gnoshi

[mac1929]

Version numbers are not a sin, not even an artifact created by corporations to mess us up!! :) It´s simply a way of identifying a binary and differentiate it from another. There would be too tiring to say that you have "the versión without b-frames, and divx3 support, with 2 pass encoding bug removed and...", it's easier to say, versión x.x works fine!
Nevertheless my original question has already been replied, there will one day be something like an official release, and it will happen when code implements all features planned and gets stable. For sure, this will help non-technical ppl to use Xvid.
Don´t get me wrong, I did not want to start a discussion about versións, I'm only interested in Xvid progress. Xvid is alive, improving fast and GPL, that´s what really matters!!

@rui:
I'm not from Barcelona, I'm from Bilbao, and would have prefer Figo not to have gone to Real Madrid, don´t symphatize much with em. I'm also glad to meet a neighbor over here!!

cheers!

[Neo Neko]

Xvid releases are numbered. the greater the number the newer the build!

[davidrv]

Hi,
I've met this site by chance and I delighted!
This project is really cool.
Come on, please, keep coding this way, I've tested your
binaries and work really fine!

[robUx4]

Originally posted by -h
Koepi's binary distribution with chm help and NullSoft Installer really rocks! However, every time the core changes, Koepi adds some changes before making his binary distribution. Why is necessary to reaply those changes every time? Why not including chm help and koepi's mods in cvs (and maybe the installer!)?

We cannot distribute an installer, as the XviD project has not paid the appropriate licensing fees to the MPEG-LA group. I'm integrating Koepi's changes into the CVS, among a few other changes, but these things take time.
-h

But the NullSoft installer is based on a text file that is compiled to produce the installable package. There's nothing preventing you from comitting this text file to CVS. (and it would make the installation more consistent between different builds). It's the same as saying your XviD/MP4 source code is legal.

[athos]

I was using 1.0 within quotes because i meant it not literally, but more as to denote a stable release. So I understand the goal is to, somehwhere in the future, release a stable "1.0" (quotes!) version, and this was my point. I do think that version numbers are not totally bad, because what we have now are releases that are not even identified by build numbers, but by dates, and different compiles contain diffferent additions. For example, I would assume that Nic's releases contains his latest ds filters, while koepi does his modifications etc. I understand that neither of these should be considered release versions, it is a project in development, but this makes it a little bit difficult to use the codec and to recommend it to someone.

If I want to encode something with xvid, should i wait a while to see if there are any bug releases or significant new features, because this happens several times a week? Again, this is because xvid is still developing, but this makes people wait for a stable release to use.

[davidrv]

Hi,
I'm so bored this morning :( that I even will
to read the mpeg4 license agreement
Could everyone post a link to it?
Any comments about it?
tnx