Mr. XviD ... We miss you!

[ookzDVD]

Trust me I really miss you. :)
I think you know why :)

[Tuning]

Yup.
"Your absence is like,
Milk without whiteness
Or world without sun
Or this forum without Doom9.":p
Developers hope you feel our curiosity.:)

[Sirber]

I know you'll say I'm a total noob, I suck hard and I should die, but who is Mr XviD? :confused:

[Tuning]

It is little brother of Dr.DivX.Very cute and inteligent.....Joking.:D
.:p .
I was refering to XviD codec.We had no new builds since Nic's 16-07-2003.Eagerly waiting for next release......;)

[ookzDVD]

Sirber,

I was talking about XviD binaries :)

the best part is the RV9 is getting better and better while XviD is taking a break, thanks to karl to make this thing happen :)

[CruNcher]

@ookzDVD

XviD is taking no break everyday it's worked on to improve it so please don't say something like that you insult the work of the Devs with such nonsense talk :( many bugs have been fixed and many improvements have been achived in the last months and some are still in production so just stay a little more pationed for the inevitable XviD 1.0 :)

[celtic_druid]

If you absolutly can't wait, then just download the latest devapi4 CVS source and build it yourself.

[Mango Madness]

Gomgom is at patch 87 (devapi4) at the posting of this...ummm...post. So there have been 87 updates to xvid in the past couple of monthes and you claim that it's dead? I think i must redefine what stagnation is then.

[TheXung]

You'd think that after enough curiousity, you guys would bother to learn how to compile it yourself. Or at least ask how to compile it.

[Tuning]

Originally posted by TheXung
You'd think that after enough curiousity, you guys would bother to learn how to compile it yourself.Or at least ask how to compile it.
Already done!.I'm using it now.;)

[ookzDVD]

@forum,

Please do not mis-understand about my posting,
I'm not under estimated the xvid dev-team with saying "taking a break". I understand they have made great work with xvid and make it
free.

thank you.

[Neo Neko]

I too miss the regular binaries to test and break. :( Though I know they are hard on their way to 1.0. For those of us(who are many) who have never gotten Xvid to compile sucessfully or even know how to compile it has been quite a dry summer/winter(depending on your hemisphere). I have aleviated that a bit though with testing of ffvfw. I must say I hope they tune the hell outa Xvid 1.0. The quality I am getting out of some of the more recent ffvfw builds is so good it is scarry. Though it seems I am getting problems with the output streams not starting with Keyframes ATM. :| Perhaps I should just compile ffmpeg for myself and get it overwith. :P

[tiki4]

Want candy :o

No, seriously, who has compiled dev-api-4 by himself? I found a tutorial in the XviD forums and that sounds rather easy. I will try that tonight. Otherwise did anyone find any pitfalls?

tiki4

[majerle]

quite strange, i found at least 3 sities with dev4 build.

Till now i use Gomez build. Stable as rock !!! (Thanks a lot Gomez !!! )

and btw you can click (http://ed.gomez.free.fr) here. Or as Syskin say "wait,wait and wait all patience will be refunded with next stable build"

greetings from Italy

Andres

[ominte]

Be warned when using Gomez's builds that these are based off his personal development and may be in front or behind of the current XviD status.

[majerle]

@ominte
sure ! but without a "official unstable dev-api4" to test (and play) , i think Gomez build is enough.

Andres

[Neo Neko]

Originally posted by tiki4
Want candy :o

No, seriously, who has compiled dev-api-4 by himself? I found a tutorial in the XviD forums and that sounds rather easy. I will try that tonight. Otherwise did anyone find any pitfalls?

tiki4

I am trying to compile with GCC and no luck. Lots of errors unfortunatly. And I don't really want to put the bloat that is Visual Studio on my HD. I got the modules from CVS ok. But I get alot of "undefined" errors about things which are defined in files included in the project. So has anyone had sucess building with Dev-C++ or Msys under MinGW GCC?

[iago]

Thanks for the link, majerle! I'm now starting to play with it. Hehe, that will be my first experience with dev-api4...

Go XviD Go! :)

best regards to all developers,
iago

PS (O/T): Koepi, hope you are fine my friend! I can't write to you often, due to several reasons. Hope you understand. Take care!

[bill_baroud]

@tiki4 : well i did it, and it's not really difficult :)

grab it from cvs (perhaps the hardest part :p), launch the Visual Studio project and click on "build" :O .

here you go with a dev-api-4 build :cool:

well i can remember of some errors (with __int64 conversions but perhaps it has been corrected)

[lazyn00b]

Originally posted by Neo Neko
I am trying to compile with GCC and no luck. Lots of errors unfortunatly. And I don't really want to put the bloat that is Visual Studio on my HD. I got the modules from CVS ok. But I get alot of "undefined" errors about things which are defined in files included in the project. So has anyone had sucess building with Dev-C++ or Msys under MinGW GCC?

Neo Neko, I too have tried to compile from CVS with MinGW and MSYS (on Win XP) and cannot get past the errors. Just as a test I was able to successfully compile xvidcore.dll from the 0.9.2 package, so I figure the compiler works OK. I have Visual C++ 6 from when I was running Win 2000 but I am scared to install it on XP and maybe screw up my system with "old" libraries or whatever.

I still do not understand the logic behind discouraging "the usual suspects" from distributing dev-api-4 binaries. All along the xvid.org developers have stressed that XviD is for "testing only", but now it sounds like they are going to spring XviD 1.0 on the world with hardly any user-testing at all? Whatever happened to Open Source mottos like "release early, release often" and "many eyes make bugs shallow"? I just think it would be a shame if XviD 1.0 was finally born and the first thing you hear about it is "it's buggy!"

[CruNcher]

@all i wouldn't suggest to compile @ the moment with plain MSVC +SP5 + PROCESORPACK, because it looks like as the generated code efficency is very very bad in recent tests this happened


qpel+gmc+vhq4+cm+trellis+b-frames: 40.2289, 8.105.472 bytes, 00:14:50.728 <- MS Compiler SSE2 OFF
qpel+gmc+vhq4+cm+trellis+b-frames: 40.2289, 8.105.472 bytes, 00:14:52.212 <- MS Compiler SSE2 ON

qpel+gmc+vhq4+cm+trellis+b-frames: 40.2327, 8.105.984 bytes, 00:09:30.869 <- Ic 7.1 SSE2 OFF
qpel+gmc+vhq4+cm+trellis+b-frames: 40.2327, 8.105.984 bytes, 00:09:10.057 <- IC 7.1 SSE2 ON


it took ca. 5 minutes longer to encode then the IC 7.1 code

[communist]

Originally posted by lazyn00b
I still do not understand the logic behind discouraging "the usual suspects" from distributing dev-api-4 binaries. All along the xvid.org developers have stressed that XviD is for "testing only", but now it sounds like they are going to spring XviD 1.0 on the world with hardly any user-testing at all? Whatever happened to Open Source mottos like "release early, release often" and "many eyes make bugs shallow"? I just think it would be a shame if XviD 1.0 was finally born and the first thing you hear about it is "it's buggy!"
Their main problem (I think) is that 3rd party people are calling these binaries *OFFICIAL*.
In the future i would like that binary makers/distributors take more care about their releases. You can't just grab sources and lable them "official". Respect our hard work, and respect users.

They just dont want to hear 1000 times that feature x in the supposed *official* binary version y doesnt work... though it has long been fixed or whatever.

In other words - yes respect their hardwork - and respect the xvid users by not calling and of your personal compiles *official*. Just state that it is a personal compile with CVS version Z used and that it is unstable etc...

[tiki4]

O.K.,

I managed to compile yesterdays CVS snapshot on Windows XP with VS 6 SP 5 + PP against DirectX 9.0b SDK. Funnily the CVS checkout I did in the afternoon missed important Visual Studio project files for the VfW and the DirectShow part so I couldn't compile that.

Unfortunately my build was very unstable and slow as hell. Regarding the numbers you give in comparison to ICL 7.1 I wonder a bit. I thought the most time-critical operations are in assembler anyway, so that shouldn't matter which compiler is used. I don't have ICL and don't feel to opt for a 30 day trial (and I can't afford to buy it). So maybe in some days CVS gets more stable again and I'll retry.

tiki4

[Koepi]

The CVS is quite stable as you can see with cruncher and my experiences.

Open the dsp file, it generates a dsw file after a warning dialog.
(And remember to open every dsw and dsp file once with wordpad and save it to convert *NIC cr to dos style.)

Regards
Koepi

[mikeson]

I completely agree with Koepi. Lastest CVS is quite stable and I've done several successful encodings with it. So people please stop whining, grab your own sources from CVS, compile it and test/use it. If you're disappointed with its speed, you are free to optimize it.
All XviD developers are coding/improving XviD for free, so please respect their hard work and their decisions.

@bill_baroud:
well i can remember of some errors (with __int64 conversions but perhaps it has been corrected)
These were no errors with __int64 conversions, its just because you haven't installed Processor pack.

@lazyn00b:
Whatever happened to Open Source mottos like "release early, release often" and "many eyes make bugs shallow"? I just think it would be a shame if XviD 1.0 was finally born and the first thing you hear about it is "it's buggy!"
What are you talking about? :rolleyes: XviD is as OpenSource as it could be, all people are allowed to download/compile/use it so please make your mind before you say something like that.

[Gaia]

Originally posted by mikeson
I completely agree with Koepi. Lastest CVS is quite stable and I've done several successful encodings with it. So people please stop whining, grab your own sources from CVS, compile it and test/use it. If you're disappointed with its speed, you are free to optimize it.
All XviD developers are coding/improving XviD for free, so please respect their hard work and their decisions.

@bill_baroud:

These were no errors with __int64 conversions, its just because you haven't installed Processor pack.

@lazyn00b:

What are you talking about? :rolleyes: XviD is as OpenSource as it could be, all people are allowed to download/compile/use it so please make your mind before you say something like that.

You can't install processor pack if you have only standard edition of MSVC++ 6.0

[lazyn00b]

Originally posted by mikeson
@lazyn00b:

What are you talking about? :rolleyes: XviD is as OpenSource as it could be, all people are allowed to download/compile/use it so please make your mind before you say something like that.

Most of the people using XviD now can't be bothered to buy/borrow/steal Visual Studio, install a zillion other little things like WinCVS, DirectX SDK blah blah, struggle through the compile guides fixing a zillion little errors (unix line breaks blah blah). The result? Most people are still using months old Koepi/Nic binaries so all the bugs/problems they encounter and report were likely fixed months/weeks ago (right?). Meanwhile, the code base that will actually become XviD 1.0 is kept in the dark, so to speak, with only a very small pool of testers. Please, at least tell me that the developers plan to endorse an XviD 1.0 "Release Candidate" for binary distribution through the usual channels before calling XviD "Final"!

BTW, I just finished spending all night setting up Visual C++ and whatnot to successfully compile a working xvid.dll and xvid.ax from CVS. It works. But now it's 5 in the morning LOL so further testing will have to wait. :rolleyes:

[tiki4]

Originally posted by Koepi
The CVS is quite stable as you can see with cruncher and my experiences.

Open the dsp file, it generates a dsw file after a warning dialog.
(And remember to open every dsw and dsp file once with wordpad and save it to convert *NIC cr to dos style.)

Regards
Koepi

Sorry,

but I didn't complain about XviD development at all. I have great respect for the work of all developers.

It was my first try, obviously I missed some things but hey, I will try again. Only thing I didn't understand was that my own CVS checkout (under Linux) didn't have the project files under ./vfw and ./dshow that were in the daily snapshot .tgz one can download from xvid.org. That's all. I compiled that and my build on my system was quite unstable. So I guess I did something wrong.

I might compile against older DirectX SDK as I don't use 9.0 because of my TV card that doesn't work with DirectX 9. So please keep up the great work and don't bother about a VisualC++ newbie who hates IDEs.

Thanks for your attention.

tiki4

Edit: O.K., I found out now that I'm just too stupid. I didn't realise that you have to check out not only xvidcore, but also vfw and dshow. I didn't see that mentioned anywhere and I didn't wonder as the xvidcore tree contains vfw and dshwo subdirectories.

[bill_baroud]

Originally posted by mikeson

These were no errors with __int64 conversions, its just because you haven't installed Processor pack.


errrm well, i did some modification myself, and it compiled, and worked very nicely.

[mikeson]

@bill_baroud:
errrm well, i did some modification myself, and it compiled, and worked very nicely.
I guess you've typecasted __int64 to double, haven't you? Yes, this is a workaround, but I'm not 100% sure you don't lose any information doing this...

[TheXung]

Are people remembering to install NASM?

[wotef]

has anyone successfully compiled today's snapshot with visual c++ 7?

i'm getting a nasm error with colorspace_yuyv_mmx.asm

[Nic]

(When MSVC .net converts VC6 projects it often ruins the custom build information on the files. Check that it hasn't put unnecessary quotation marks and other characters in the build information for the .asm files)

[Wilbert]

i'm getting a nasm error with colorspace_yuyv_mmx.asm

You should install 0.98.36 instead of 0.98.38:

http://sourceforge.net/project/showfiles.php?group_id=6208&release_id=184186

More info:

http://edu.bnhof.de/pipermail/xvid-devel/2003-October/003558.html

and the follow up. I guess they didn't adapt the XviD builds to this yet :)

[mikeson]

i'm getting a nasm error with colorspace_yuyv_mmx.asm
In following two files:
xvidcore\src\image\x86_asm\colorspace_rgb_mmx.asm and xvidcore\src\image\x86_asm\colorspace_yuyv_mmx.asm
replace directive %include "colorspace_mmx.inc" with fullpath to file colorspace_mmx.inc. That should be enough.

And for those who have troubles to get XviD decoder to work, its IMHO because xvid.dll doesn't export function xvid_global(), so you should add following lines to file xvidcore\vfw\src\driverproc.def under EXPORTS directive:
xvid_global
xvid_decore
xvid_encore
xvid_plugin_single
xvid_plugin_2pass1
xvid_plugin_2pass2
xvid_plugin_lumimasking
xvid_plugin_dump
xvid_plugin_psnr
...and make sure that this file is included in vfw.dsp.

Hope this helps.

BTW last ffdshow decodes files made by dev-api-4 very good (through libavcodec).

[wotef]

thanks for the suggestions, but neither dropping down to nasm 98.36 nor editing to state %include "e:\xvid\xvid_20031105\xvidcore\src\image\x86_asm\colorspace_mmx.inc" has solved the problem yet :(

the nasm error says: no input file specified

this is what i have in property pages of colorspace_yuyv_mmx.asm:

nasm -f win32 -DPREFIX -I"$(InputDir)" -o $(IntDir)\$(InputName).obj $(InputPath)

any other ideas, or do you think VS7 is a no-go?

[Assault]

I also want to compile a devapi 4 build but I'm a total noob. I haven't compiled any program until now. What I have done so far: I downloaded latest sources with WinCVS and opened xvidcore\build\win32\xvidcore.dsw in Visual C++. But what do I have to do then? I can't click on "Kompilieren von" (Ctrl+F7). (I think that's "compile" in the English version of Visual C++ but I'm not sure) Am I doing something wrong or do you have to do anything before you can compile? Perhaps someone can help me.

Thanks in advance,
Assault

[Prettz]

Originally posted by CruNcher
@all i wouldn't suggest to compile @ the moment with plain MSVC +SP5 + PROCESORPACK, because it looks like as the generated code efficency is very very bad in recent tests this happened

So far as I've been able to tell (and I've attempted to look into this as much as possible in the past), all the "processor pack" does is add support for all the MMX/SSE/SSE2 intrinsics. It does not alter the compiler and how it optimizes in any way whatsoever. The VC++ compiler optimizations only go up to Pentium Pro, and even then the compiler can be quite dumb at times (especially with register allocation).

MS however doesn't worry about this because of the arrangement they have with Intel. Intel's compiler is designed to be fully compatible with everything generated by VC++, so (if I understand the situation correctly) people write and debug their programs using VC++, then use ICL to compile a fully-optimized release build.

[mikeson]

@wotef: VS7 usually converts .dsw and .dsp files with errors. In my case there were errors because of quotes where there shouldn't be. Please have a look at VS7 compile errors output and at project (solution) files and you should easily find these errors (I'm sorry, but I have VS6 installed on my system, so I can't tell you exact solutions).

@Assault: You should download and install following software/update:
Netwide Assembler (NASM) from SourceForge
Visual Studio 6.0 Service Pack 5 from M$
Visual Studio 6.0 Processor Pack from M$
Microsoft DirectX9 SDK from M$(only if you want to compile dshow decoder)

Compile/build xvidcore.dsp, vfw.dsp and dshow.dsp (if you want to compile dshow decoder), but don't forget to open .dsw files when compiling.

[zulu]

Originally posted by wotef
thanks for the suggestions, but neither dropping down to nasm 98.36 nor editing to state %include "e:\xvid\xvid_20031105\xvidcore\src\image\x86_asm\colorspace_mmx.inc" has solved the problem yet :(

the nasm error says: no input file specified

this is what i have in property pages of colorspace_yuyv_mmx.asm:

nasm -f win32 -DPREFIX -I"$(InputDir)" -o $(IntDir)\$(InputName).obj $(InputPath)

any other ideas, or do you think VS7 is a no-go?

it's not only colorspace_yuyv_mmx.asm, that's just the first line nasm has problems with. :) As others have stated, it's a problem with quotes. Try to open the libxvidcore.vcproj in notedpad and run a search&replace for "&.quot;" (without the dot). This solved the problem for me.

EDIT: if you remove the quotes you have to make sure that there are no whitespaces in your sourcecode path.

[Assault]

@ mikeson

Hmm...I think I have that installed. But I don't know which xvid source files I have to open in Visual C++ and in what order I have to compile them. So perhaps you or someone else can answer this: What files and in which order do I have to compile to get xvid.dll?

Thanks,
Assault

[mikeson]

@Assault:

I've already told you how to in my previous post...
Compile/build xvidcore.dsp, vfw.dsp and dshow.dsp (if you want to compile dshow decoder), but don't forget to open .dsw files when compiling.

[Assault]

Did you mean xvidcore.dsw? Because I can't find xvidcore.dsp only .dsw

[zulu]

xvidcore.dsw is a workspace file, meaning it holds several projects (project libxvidcore.dsp and the example projects).
just open the project libxvidcore.dsp.

[Assault]

Ok, thank you for your help guys. I finally succesfully compiled libxvidcore.lib. But when I open vfw.dsp and try to compile xvid.dll all I get is this error: Eingabedatei "pthreadVC.lib" kann nicht geoeffnet werden. I think that's something like "the file pthreadVC.lib cannot be opened". Has anyone the same problem?

Assault

[tiki4]

I think you should change the compile target from Release_SMP to just Release.

tiki4

[Assault]

@ tiki4

Thanks, that helped to solve this issue but now I got 25 new errors. I think I'll perhaps try to reinstall Visual C++ and if this doesn't help I'll simply wait for the XviD 1.0 release.;)
Nevertheless thank you for your help.

Assault

[wotef]

zulu! that's it! vc7's xml conversion of all libxvidcore.dsp introduces the erroneous "&.quot;" [without the dot] into the converted *.vcproj file - a simple edit replace allows the assembly to proceed

it's all works now!!!

[zulu]

Hmm...don't know what wrong there, since i never compiled encraw.
However,Encraw is an example program demonstrating how to encode raw frames using libxvid. It's not necessary to compile it.
Only compile libxvidcore instead of the whole solution, or just open libxvidcore.vcproj instead of libxvidcore.sln.

[wotef]

sorry zulu, i edited my previous post after after you replied

- everything works now from vc 7!

summary of issues:

- for libxvidcore, the key thing is to remove all instances of "&.quot;" (excluding the dot) from libxvidcore.vcproj; these occur when vc7 converts the vc6 project files to xml

- for dshow, you must set 2 tools/options/projects vc++ directories:
1) "include files" your dx9 sdk baseclasses directory
2) "library files" your dx9 sdk directory that contains strmbasd.lib or strmbase.lib

everything else works in accordance with discdude's vc 6 compile guide (http://www.discdude.net/xvid/compile.html)