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)

[wotef]

p.s. i've learned a lot of valuable stuffs going through this process and it makes me appreciate the sheer amount of quality and hard work that's (been) put into xvid and the helpfulness of the community as a whole!

[CruNcher]

@all sorry i have to admit i did wrong in comparesion of the MS Compiler it was a bad mistake thats happened in the .dsp, their is no /02 compiler optimization activated so what happened was it used no optimizations @ all so here are now the new benchmarks after some new optimizations that took place by syskin, so i hope you will enjoy them are as much as me and are excited about the coming release of XviD 1.0 :D


qpel+gmc+vhq4+cm+trellis+b-frames: 40.2323, 8.106.496 bytes, 00:10:35.259 <- MS Compiler SSE2 OFF
qpel+gmc+vhq4+cm+trellis+b-frames: 40.2323, 8.106.496 bytes, 00:10:27.018 <- MS Compiler SSE2 ON

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

[Prettz]

Originally posted by CruNcher
@all sorry i have to admit i did wrong in comparesion of the MS Compiler it was a bad mistake thats happened in the .dsp, their is no /02 compiler optimization activated so what happened was it used no optimizations @ all so here are now the new benchmarks after some new optimizations that took place by syskin, so i hope you will enjoy them are as much as me and are excited about the coming release of XviD 1.0 :D


qpel+gmc+vhq4+cm+trellis+b-frames: 40.2323, 8.106.496 bytes, 00:10:35.259 <- MS Compiler SSE2 OFF
qpel+gmc+vhq4+cm+trellis+b-frames: 40.2323, 8.106.496 bytes, 00:10:27.018 <- MS Compiler SSE2 ON

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

It looks as though VC++ is performing pretty good compared to Intel's compiler. How much of Xvid's critical code is still pure C?

[Defiler]

Admittedly, I might just be stupid.. but can someone give me some tips on getting this to build in Visual Studio.NET 2002? I have the recommended version of nasmw.exe camped out in c:\Windows\system32, as the install text recommends. However, I still get various nasm-related error messages when I try to build xvidcore/release.
The settings inside VS.NET all look correct, but I'm not very experienced with assembly, so I'm probably doing something wrong.

[zulu]

did you read the how-to-compile-using-vs-net-summary posted 5 post abobe?
Additionally, make sure you're using nasmw 0.98.36 renamed to nasm.exe.
What errors do you get exactly?

[wotef]

follow the vc6 guide - you gotta rename the nasmw.exe to nasm.exe!

[Koepi]

I just added dev-api-4 support to my statsreader. maybe you'll find this useful.

Regards
Koepi

EDIT: note that you can't do external curve compression in dev-api-4. So you can do useless things like convert dev-api-4 statsfiles to "old style" statsfiles, but those statsfiles are of course useless. But you can still do things like checking the first pass filesize etc.

[mikeson]

@Koepi: Thanks a lot, Koepi! :) I've been waiting for this update...

[Defiler]

Originally posted by zulu
did you read the how-to-compile-using-vs-net-summary posted 5 post abobe?
Additionally, make sure you're using nasmw 0.98.36 renamed to nasm.exe.
What errors do you get exactly? I did, yes.. and nasmw has been renamed. I'm still getting this:
libxvidcore error PRJ0019: A tool returned an error code: "Assembling d:\Projects\xvidcore\src\image\x86_asm\colorspace_yuyv_mmx.asm"
Edit: Durhrh.. I replaced the "quot;" markup with a regular double-quote, rather than removing it. I'll try it again without screwing it up this time.

[mikeson]

@Koepi:
Originally posted by Koepi
But you can still do things like checking the first pass filesize etc.
That's the feature I use StatsReader for. ;)
Thank you again...


@Defiler:

IMHO this is the thing with %include directive I wrote several posts above. Please have a look there.

[Defiler]

I am still getting a fatal error though, this time in qpel.c
Once again, it's probably something simple I am doing wrong.
Error log: http://hellninjacommando.com/misc/xvid_build.txt

[Gaia]

Originally posted by Defiler
I am still getting a fatal error though, this time in qpel.c
Once again, it's probably something simple I am doing wrong.
Error log: http://hellninjacommando.com/misc/xvid_build.txt

Replace every "#include __FILE__" with this "#include "qpel.c"

[Defiler]

Originally posted by Gaia
Replace every "#include __FILE__" with this "#include "qpel.c" Awesome. That worked.
I get the feeling this would be easier if I went back to VS6-SP5. Heh.

[haibane]

This may sound stupid.....
but i still haven't find the api4 source code.....
i download the daily snap shot from xvid.org, there is a api4 corelib in there, but the vfw code in there is api3.
Then i checked the cvs (http://cvs.xvid.org/)and find that the vfw folder inside xvidcore folder is empty.
Do i need some special software to accecess the api4 build?

[cipher]

This may sound stupid.....
but i still haven't find the api4 source code.....
i download the daily snap shot from xvid.org, there is a api4 corelib in there, but the vfw code in there is api3.
Then i checked the cvs (http://cvs.xvid.org/)and find that the vfw folder inside xvidcore folder is empty.
Do i need some special software to accecess the api4 build?

Let's go thru this once again.:)
U may want to install a free software called WinCVS, and then go to
Admin---> Command Line,
put this in the "Cvs command line":

cvs -z9 -d:pserver:anonymous@cvs.xvid.org:/xvid checkout -P -r dev-api-4 xvidcore

You may check "execute for directory" and select whatever directory you wanna put your dev-api-4 sources in, otherwise WinCVS will dl them to Desktop as default.

then press ok and wait for WinCVS to download.

I don't know if dev-api-4 brach has a webpage you can download the source files directly via browser, but I've been using wincvs all the time.

Good Luck!

[haibane]

cipher.....
thank u very much......
now i got the code and ready to compile....
^_^

[Tuning]

Finally,the complete dumb question to all,(Yes I'm stupid...:D )

Will there be performance difference(improvement..) on account of using VC7 as compiler than using VC6?
Any comments?

[Assault]

Hi

I finally managed to comile a devapi4 build today. I only had to change the compile target for libxvidcore.lib from debug to release and it worked. ;) I also compiled xvid.ax but I probably did something wrong. When I try to playback movies with xvid's directshow filter I get the following error message: "xvid_global() not found". ffdshow works for playing back my videos so I think it's an error in xvid.ax. Does anyone know what's the problem?

Thanks,
Assault

[BoNz1]

Yes, you must add this to the .def file in the vfw/src so that it will export this. Add:
xvid_global
xvid_decore
and possibly others I dunno, just keep adding them till it doesn't complain anymore ;).
EDIT: Wups, I think it is without the ()

[Koepi]

Hehe. We had those to include-lines 2 pages ago in this very same thread. Seems some people just don't read it properly ;)

Koepi

[BoNz1]

Hehe, Koepi it seems I don't read too well either because I totally missed that too :confused:. Anyhow, GomGom fixed the rate controller today and it seems to work a lot better IMO with the rather little testing I have done so far. But it seems that your statsreader doesn't work anymore with my build from today just to let you know, :). I think the formating of the .pass file changed, each frame no longer has its own line anymore.

[Koepi]

That would be a bug - I'll let GomGom know.

Thanks for the hint, I'm currently at work and can't do xvid testing.

Regards
Koepi

[tiki4]

Now, that I've managed to compile dev-api-4, another question comes to my mind:

I tried to capture debug output during encoding but it seems there is no output at all. Under debug options I find an option for debug output that is set to '0x0' by default. What do I have to do to get some output? Does anyone know what hex number enables the debug output?

Regards,

tiki4

[Koepi]

You must do a debug-build for the verbosity setting having effect.

else you have to hack the vfw frontend to spit out that output - that's what I usually do as i like to have some more info about the quant distribution.

regards
Koepi

[Assault]

Thanks BoNz1 for your help. :) I added those lines to driverproc.def and it looks like this now(I hope that's right):
EXPORTS
DriverProc
Configurexvid_global
xvid_decore
xvid_encore
xvid_plugin_single
xvid_plugin_2pass1
xvid_plugin_2pass2
xvid_plugin_lumimasking
xvid_plugin_dump
xvid_plugin_psnr
Playbacking my videos works fine now except of two things. First it doesn't work through ffdshow("use xvid" checked) and secondly the message about b-frame decoder lag everyone knows from VDub appears for a very short time when I open my videos in any medial player. Are these two "bugs" normal with devapi4's decoder? (btw, I hadn't those problems with the devapi3 directshow filter)

@ Koepi

Sorry that I haven't read the thread carefully. :rolleyes: When I read it (yes I read the whole thread ;)) I hadn't managed to compile my own build yet. So perhaps that's the reason why I didn't remember the post you mentioned.

Assault

[tiki4]

@Koepi:

Thanks. I will look into that.

tiki4

[BoNz1]

Originally posted by Assault
Playbacking my videos works fine now except of two things. First it doesn't work through ffdshow("use xvid" checked) and secondly the message about b-frame decoder lag everyone knows from VDub appears for a very short time when I open my videos in any medial player. Are these two "bugs" normal with devapi4's decoder? (btw, I hadn't those problems with the devapi3 directshow filter)


Yup, this is normal. ffdshow for some reason can't use the vfw decoder in dev-api-4. The vfw decoder is the one that is used when you open your video in virtualdub. I can't really see any huge advantage to using the xvid decoder over ffdshow, if you set the idct to xvid in ffdshow it will look exactly the same. I have tested this side by side about 1 month ago and there was zero noticeable difference at least to me.

[tiki4]

@Koepi:

I hacked the VfW frontend in some way (commented out some lines in debug.h) as you suggested. Now I really get some output in DebugView. Unfortunately is has a complete different syntax than dev-api-3, so no way to use xda on that. I think the debug formatting flags are ignored as long as you don't make a debug build of libxvidcore. I will try that. Yesterday's CVS seems broken in some ways. Apart from statsreader that can't read the *.pass output also the second pass settings don't show the values of all fields. But I think that is only a display problem.

tiki4

[Koepi]

I'm currently testing the actual CVS code. I need such a stats-file to adopt statsreader (again) as GomGom changed the statsfile format.

The output fetchable with debugview is completely different from dev-api-3- all those tools have to be adopted for coping with that.

Regards
Koepi

[tiki4]

Very sad. So no easy comparison of quantizer distributions and similar stuff. And thanks for your continuing work for XviD.

tiki4

[Tuning]

Thanks koepi,for yet another version of wonderful codec.
I could not see h.263/MPEG dropdown box.So dev-4-api is using MPEG as default one?
And the feedback like window,will it reduce encoding speed?

Thanks

[NiTroGen]

Originally posted by Koepi
I'm currently testing the actual CVS code. I need such a stats-file to adopt statsreader (again) as GomGom changed the statsfile format.Is there any information available on the new stats-file format? I'd like my next version of StatsViewer to support it.

[Assault]

Originally posted by BoNz1
Yup, this is normal. ffdshow for some reason can't use the vfw decoder in dev-api-4.

Thank you for the explanation.

Assault

[tiki4]

Tested yesterdays CVS shortly. The issue with the 'not-displaying-second-pass-options' is fixed. Otherwise the debug output is now re-enabled, seems to be a patch by Koepi.

Thanks,

tiki4

[Tuning]

Originally posted by Tuning
Thanks koepi,for yet another version of wonderful codec.
I could not see h.263/MPEG dropdown box.So dev-4-api is using MPEG as default one?
And the feedback like window,will it reduce encoding speed?

Thanks

Sorry Koepi,I just noticed the small button right to profiles,everything was there.My borne-in absent mindedness :D .
The matter related to feedback window is still unanswered.
May be this is not the right time to ask on yet to public XviD-dev4-API.
Thanks waitnig for its release.............:p
Bye.

[Koepi]

It sure will reduce speed. Taken the several 1000 of cpu cycles per each macroblock of a picture it will not make up a noticable difference - it's just updating once or twice a second - virtualdubs routines definatly spend more cpu cycles.

Regards
Koepi

[Tuning]

Thanks koepi for the info.
Have a nice day.:)

[unplugged]

I'm testing latest dev-api-4 by GomGom.
The 2nd pass setup layout has changed, I can't manage to set up it correctly, shortly... bitrate isn't respected (triplicates!).

As changelog says, I know that the 2-pass code has been revamped, but how works now?

About the 1st-pass I think I have understood it correctly: first I have set the 1st entry with the global quantizer, second I have added a 2nd entry specifing the higher quant. for titles.

[ookzDVD]

@Koepi,

any news about the new statfile format which changed by GomGom ?
I'm still waiting the next StatReader :)

btw, I should can find out the first pass size if I disable the
"discard the 1st pass" option isn't it ?

thank you.

[BoNz1]

ookDVD, I believe that the stats file format was fixed. And yes, you can check your first pass size, I just checked it for one of my last encodes.

[ookzDVD]

Originally posted by BoNz1
ookDVD, I believe that the stats file format was fixed.


I just open the first pass file with the StatReader 2.1,
and somehow the StatReader is crash. :(

[winman]

Try this

-Make a copy of the pass file
-Open it it with a text editor
-Delete the first 3 lines
-StatReader 2.1 should be able to open this pass file

[Koepi]

Updated StatsReader for reading new statsfiles again (let's hope that only # gets used for comments, else i have to code again...)

Still no support for saving dev-api-4 statsfiles (keyframe insertation), no time for that yet.

Regards
Koepi

[tiki4]

Thanks, Koepi.