Has XviD development been discontinued?

[tommazzo]

Hi!

I really hate to ask such a question, but the last news entry on xvid.org is from April, the forum appears to be dead and the latest commits to the CVS repository date back 5 weeks. So what is going on?

[Teegedeck]

No update in 5 weeks? How dare they, I'll just go over to suxen_drol and complain! :D

Seriously, I haven't checked whether it's actually been 5 weeks - but that's not such a long time considering there's not so many active people on this project. Do you want to join?

[tommazzo]

Actually I think that there aren't more than two files, which are 5 weeks old, all the others are 8 weeks or much older.
As for your invitation to join the project, I must admit that I am quite intrested in it, it's just that I have never worked on video compression before, but if you've got some information to get me started, I'd happy to join.

[Teegedeck]

If interested, subscribe to the XviD devel mailing list (http://list.xvid.org/mailman/listinfo/xvid-devel), describe there with what you think you could contribute and ask where you can help out. Feel free to post any questions about the project's structure on the mailing list! Thanks. :)

Edit: XviD devel mailing list archives (http://list.xvid.org/pipermail/xvid-devel/)

[vlada]

Well I would just finish version 1.1 and then move all forces to x264 development. What I'm currently missing in XviD are 2 compatibility switches:

1) Force 1st frame of a movie to be an I-frame, not a B-frame.
2) Use only 1-point GMC. But I'm not sure if this is possible at all.

I don't think a lot more can be improved on the codec.

[Doom9]

There's some activity on the XviD mailing list (a few patches floating around) so I wouldn't say it's dead, but has just slowed down alot in 2005. But that's just how it is with most open source projects.. they are driven by few people, and if that or those persons decide to slow things down or take a break for a while, it just takes longer.

[Teegedeck]

Well I would just finish version 1.1 and then move all forces to x264 development. What I'm currently missing in XviD are 2 compatibility switches:

1) Force 1st frame of a movie to be an I-frame, not a B-frame.
Excuse me? :eek: The first frame IS an I-frame, always! Other frametypes can't start a video stream by design...
2) Use only 1-point GMC. But I'm not sure if this is possible at all.1-point GMC is completely useless. Encode without GMC if you don't wan't 3-warppoint-GMC.

I don't think a lot more can be improved on the codec.Yeah, well, that's what they said about LAME years ago. And it's still amazing us today! :)

Recently I looked for a good way to compress TV episodes (half-hour) at full-res to 250-300 MBs. What do you know, it turned out that - to my utter surprise - XviD with h.263 quantization (respectively Javor's 1-CD matrix for some eps) at quant=4 still looked much better than x264 or Nero AVC at the same filesize. :) And I wasn't willing to lower my viewing standards even more...

[tommazzo]

Thanks for the tip with the mainling list, I'll subscribe to that, but first I am going to take a closer look at the XviD source code to see where I could possible contribute.
But that's just how it is with most open source projects.. they are driven by few people, and if that or those persons decide to slow things down or take a break for a while, it just takes longer.
That's unfortunately a big problem with open source projects, especially with those that are better than their commercial counterparts.

[Didée]

I don't think a lot more can be improved on the codec.
Psychovisuals and HVS features, because:

- dark Scenes in general

- static objects under changing lighting conditions (objects lit by flaming fire!)


Another thing that could be improved is XviD's inability to decode its own work correcly if it had done it interlaced ... ffdshow does it right, but still shows DCT drift ...

[eb]

Recently I looked for a good way to compress TV episodes (half-hour) at full-res to 250-300 MBs. What do you know, it turned out that - to my utter surprise - XviD with h.263 quantization (respectively Javor's 1-CD matrix for some eps) at quant=4 still looked much better than x264 or Nero AVC at the same filesize. And I wasn't willing to lower my viewing standards even more...
IMHO I can't find the reason to change from Xvid to any .264 AVC

[Teegedeck]

...please note that it certainly takes XviD with QPel, AQ, VHQ=4, Trellis etc. if you want to rival AVC efficiency. And most people use none of these features...

[vlada]

Excuse me? :eek: The first frame IS an I-frame, always! Other frametypes can't start a video stream by design...


And what causes the well known problem "Nothing to output bframe decoder lag" in VirtualDub? I was told it is because the first frame is a b-frame. But you're righ, it doesen't make sense to start with other then an I-frame.

About x264 vs. XviD. When I did a comparison for myself, x264 had more details then XviD especially in dark scenes. x264 has IMHO much more potentional then XviD.

[xDrJx]

x264 has IMHO much more potentional then XviD.

would be a bad project if it wouldn't, considering that x264 is kind of a next gen codec. But I would be happy seeing XviD dev go on and kick a$$, cause its the best SAP solution nowadays (just my mind)

[unskinnyboy]

And what causes the well known problem "Nothing to output bframe decoder lag" in VirtualDub? I was told it is because the first frame is a b-frame. But you're righ, it doesen't make sense to start with other then an I-frame.
Here (http://forum.doom9.org/showpost.php?p=402558&postcount=12) is a nice explanation. I can't explain better, but yes - B-frames can't be the first frame since it has to be bi-directionally predicted. The first frame should always will be an I-frame since it is encoded without referring to anything except itself.

[Caroliano]

And what causes the well known problem "Nothing to output bframe decoder lag" in VirtualDub? I was told it is because the first frame is a b-frame. But you're righ, it doesen't make sense to start with other then an I-frame.
Here (http://forum.doom9.org/showthread.php?t=80430) is an explanation of how B-frames are put in the .avi container, that can't handle them.

EDIT:I was late... but it's two diferent pages. You can read both.

[*.mp4 guy]

...please note that it certainly takes XviD with QPel, AQ, VHQ=4, Trellis etc. if you want to rival AVC efficiency. And most people use none of these features...

A bit ot, but sometimes qpel doesn't look better to me it really depends upon the source, its great on some but on others it just looks like it adds rining.

[bond]

Here (http://forum.doom9.org/showthread.php?t=80430) is an explanation of how B-frames are put in the .avi container, that can't handle them.thx! finally someone noticing my explanations
after all thats what i wrote it for :)

[Caroliano]

Thanks for you because you wrote this explanation ;)

[bill_baroud]

and here (in french) (http://linuxfr.org/~GomGom/18881.html) an explaination (in the comments) of why xvid slowed down after GomGom left...

[Leak]

and here (in french) (http://linuxfr.org/~GomGom/18881.html) an explaination (in the comments) of why xvid slowed down after GomGom left...

Would you mind summing that up for us non-French-speaking folks? ;)

np: F.S. Blumm - Wamdel (Zweite Meer)

[bill_baroud]

ok, basically, since he left, there is nobody to maintain the code/cvs, adding patches, etc... So he's a little sorry that nobody took care of xvid after him, because there is still some works to do, unfortunatly more on the code itself (better api's) than on the functionnalities, and with the others "sexy" codec (x264 ...) xvid is not appealing a lot of coders.

I hope i didn't distorded his words too much.... "Traduttore, Traditore"

[Kostarum Rex Persia]

and here (in french) (http://linuxfr.org/~GomGom/18881.html) an explaination (in the comments) of why xvid slowed down after GomGom left...

Wait a minute,GomGom is a Koepi on Doom9 forum,isn't it,If Koepi is not GomGom,than who is?

[Koepi]

I'm certainly NOT GomGom. GomGom is Edouard Gomez and he is a linux-based developer. He did a great job on cleaning up XviD's sources.

Cheers
Koepi

[Kostarum Rex Persia]

Ok,thanks for explanation,Koepi.I have one question.Now when Edouard Gomez left Xvid development,who is in charge for further Xvid development? You,or you and few other peoples.

[Tommy Carrot]

Now when Edouard Gomez left Xvid development,who is in charge for further Xvid development?Afaik the project founder, Isibaar, plus Skal can still more or less be considered as active developers, and i don't know whats up with Suxen-drol and Gruel, perhaps they are still around somewhere. But it was definitely a big loss for xvid when Syskin and GomGom left the project, they were by far the most active developers in the last few years.

[Shinigami-Sama]

...please note that it certainly takes XviD with QPel, AQ, VHQ=4, Trellis etc. if you want to rival AVC efficiency. And most people use none of these features...
thouhg I have no idea why they don't, I don't much like trellis though, but yeah after gomgom and syskin left I don't there was a major update ;_;

[weaver4]

So is the final answer to the question "Has XVID development been discontinued?" is "Almost Completly"

[Sharktooth]

there are still active developers, but the development activity is almost reduced to zero cause the most active developers left the group.
also take into considerations it's summer too...

[ChronoCross]

well hopefully they can finish the 1.1 build and release a final.

[SeeMoreDigital]

there are still active developers, but the development activity is almost reduced to zero cause the most active developers left the group.
also take into considerations it's summer too...Yes, it's a real shame things have slowed down.... but I guess it was bound to happen at some point :(

I must admit I would be most grateful if there was a "final" release of XviD's DSdec decoder filter, that could cope with B-VOP encodes that contain AR signalling without packed bit-stream...


Cheers

[Sharktooth]

well, xvid isnt died. it lacks active developers. if someone joins and helps completing the missing parts it would be great.
i still dream the syskin's HVS plugin... but as i said, it's a dream.

[celtic_druid]

cvs was just updated by the way.

[Andrey]

Every such a project have active and passive periods...
Lets hope some talented people get to XViD in a near future. :rolleyes:

[Kostarum Rex Persia]

Yes,Andrey,you are right.

[xDrJx]

Yes, it's truely a shame that this potential isn't further developed in a speed, the community would like, including me. But on the other hand, I'm glad as hell that there is XviD in it's pesent state at all, so I've got a free alternative to commercial ASP codecs and, to be honest, a damned good alternative as it is!!

[Rash]

Hey guys, I don't mean to hurt anybody but isn't it better if they focused on developing newer codecs like x264 (or any other h.264 codec)?

I mean, the leap from MPEG2 is certainly a lot bigger with this new standard.

Anyway, my 2 cents.

[Shinigami-Sama]

I'll agree
but xvids still needs to be finished before the move
how would you like it if the buildres only made 90% of your house?
you know, put up the walls and eletricty but leave the plumbing unfinished?

thats the stage xvid is now
just that little bit more to finish it off and it's done, ready for coders to move onto other codecs

[celtic_druid]

Just covering old territory here.
@Rash, what do you do for a living? What ever it is I don't like it. Do something else.

People have a right to spend their time working on whatever they want.

[Ice =A=]

There are a lot of stand allone players out there which play XviD, but not a single one that plays h264. That's a really good reason to stay with XviD!

And the quality difference between XviD and h264 is surprisingly small!

@celtic_druid: Calm down.

[Rash]

@Rash, what do you do for a living? What ever it is I don't like it. Do something else.
Hey... ohhh... I didn't mean to hurt anyone, sorry. Maybe I sounded as if I didn't appreciate the efforts you guys put into XviD! But that's not true, really!

Specially you Celtic, whose builds I use. :)

[xDrJx]

There are a lot of stand allone players out there which play XviD, but not a single one that plays h264. That's a really good reason to stay with XviD!

my point

[[)370|\|470!2]

There are a lot of stand allone players out there which play XviD, but not a single one that plays h264. That's a really good reason to stay with XviD!

Then teh best is to stick with mpeg2. It's way more hardware-compatible than xvid. :p

And the quality difference between XviD and h264 is surprisingly small!

You're kiddin, right? I'm an xvid enthusiast myself, but claiming that asp could even
in theory get somewhere close to avc, is non-sense.

[Teegedeck]

Please stick to the topic, everyone. If you want an MPEG4 ASP vs. MPEG4 AVC quality comparison just start a new thread.

[akiza]

Well I would just finish version 1.1 and then move all forces to x264 development. What I'm currently missing in XviD are 2 compatibility switches:

1) Force 1st frame of a movie to be an I-frame, not a B-frame.
2) Use only 1-point GMC. But I'm not sure if this is possible at all.

I don't think a lot more can be improved on the codec.

Maybe there are two more things..^_^

1. a NON-MMX version

a non-MMX version can run on future M$ OS...( M$ cliam future OS won't support MMX/FPU anymore..)

2.a SSE3 optimized build...

LDDQU should improve the encoding speed..

[squid_80]

Non-MMX (plain C) code is already there.

[sysKin]

Non-MMX (plain C) code is already there.
Non-mmx BUT sse2 :)

[squid_80]

Non-mmx BUT sse2 :)

Well most would probably be easy enough... Except maybe the qpel funcs, I'm a bit lost in them... Colorspace conversions would probably be the only ones that got a speed increase rather than decrease though.

[akiza]

Non-MMX (plain C) code is already there.

I should say "Non-MMX but SSE2 optimized"..

( my poor english.... :( )

[akiza]

ascii.com have made a liitle test about the LDDQU performance

(P4 PRESCOTT 3.2G)

http://akiba.ascii24.com/akiba/column/latestparts/2004/03/01/imageview/images735647.gif.html


the chart show

when not 16-byte align MOVDQU can trans 7.5GB/s data from L1 to XMM-REG

But the LDDQU can trans 19.7GB/s data from L1 to XMM-REG when not 16-byte align

LDDQU is about 2.6X fast to MOVDQU..^_^