Xvid 1.3.1 out

[hajj_3]

Changes since 1.3.0:

xvidcore library
Enabled noexec stack for both elf and elf32 obj format for better NASM compatibility
Fixed edging bug for non-mod16 image dimensions
Generated configure scripts with more up-to-date autconf version
Fixed error with pthread check in configure.in script
DShow/MFT frontend
Disabled rgb_flip for MFT decoder
Modified icon/gui graphics for better visibility
Changed VC8 project files to use static LIBCMT runtime

installers here: http://www.free-codecs.com/xvid_codec_download.htm

[PiPPoNe92]

Cool! Thanks a lot.

[Lenny_Nero]

Installed Jawors version install went fine...

But no decoder installed. On my 2k encoding box.

www.digital-digest... version had download problems, or Firefox, I just got script is taking a long time... after 30'ish seconds.

Gone back to v1.21 VAQ as its never given me problems

[Jawor]

Installed Jawors version install went fine...

But no decoder installed. On my 2k encoding box.

Unfortunately my build of the DirectShow decoder requires Windows XP or newer. RegSvr32 fails to register it on Windows 2000 (I'm not sure why, but probably my Windows SDK is too new). That's why my installers detect Windows 2000 and skip the DirectShow decoder installation.

You don't have to give up on my build of the 1.3.1 VfW codec (it should work fine on Win2k). ffdshow-tryouts (http://ffdshow-tryout.sourceforge.net/) can be used for decoding on Win2k (“unstable” builds are updated almost every day on www.xvidvideo.ru (http://www.xvidvideo.ru/ffdshow-tryouts-project-x86-x64/)).

<EDIT>
Actually the bleeding-edge ffdshow-tryouts (rev. 3800 (http://www.xvidvideo.ru/ffdshow-tryouts-project-x86-x64/ffdshow-tryouts-project-svn-3800-x86-x64.html)) doesn't work either. Beta 7 (http://sourceforge.net/projects/ffdshow-tryout/files/Official%20releases/generic%20build%20%28stable%29/ffdshow_beta7_rev3154_20091209.exe/download) (“stable”) should work.

Windows 2000 is pretty old after all...
</EDIT>

BTW, Koepi's 1.3.0 decoder requires Vista.

[clsid]

Try my ffdshow builds. Those might still work on Win2k.

[Jawor]

Try my ffdshow builds. Those might still work on Win2k.

I just tried using your rev. 3785 “generic 32-bit” build on Win2k Pro SP4, but RegSvr32 “cannot find the specified module” (just as with recent builds from www.xvidvideo.ru (http://www.xvidvideo.ru)).

rev. 3154 (“Beta 7”) works, though.

<EDIT>
My latest 64-bit build (April 2nd, 2011) includes 64-bit DirectShow decoders (both MFT and non-MFT).

The 02.04.2011 builds should fix issues with the DirectShow decoder on Windows 7.

The minimum Windows version for DirectShow decoders is still XP (the latest Service Pack may be necessary).
</EDIT>

[v0lt]

@Jawor
Installation on a clean Windows XP SP2
http://img64.imageshack.us/img64/4192/xvid131error.th.png (http://img64.imageshack.us/i/xvid131error.png/)

[space1999]

@Jawor
Installation on a clean Windows XP SP2
http://img64.imageshack.us/img64/4192/xvid131error.th.png (http://img64.imageshack.us/i/xvid131error.png/)

Registers fine on XP SP3

( OTOH, old filters like "Channel Downmixer" do not work with SP3 :( ).

@ Jawor:

next time, please save the file "polski.txt" as *UTF-8* ;)
Too bad we all still have to deal with "locales" and "codepages".

[v0lt]

Registers fine on XP SP3
really clean system? or or you installed Microsoft Visual C++ 2008 SP1 Redistributable Package?

[space1999]

2005,

2008,

2010.

[Jawor]

really clean system? or or you installed Microsoft Visual C++ 2008 SP1 Redistributable Package?
The decoder registers without errors on XP SP2 with Visual C++ 2008 Redistributable Package 9.0.30729.17.

This time I used Windows SDK 7.0 to avoid problems on Windows 7. And since SDK 7.0 has higher minimum requirements, the decoder may not work on XP without updates. Pick your poison :p

Many applications require the Visual C++ 2008 Redistributable Package, so installing it is a good idea anyway.

next time, please save the file "polski.txt" as *UTF-8*
Too bad we all still have to deal with "locales" and "codepages".
You're absolutely right about that ;) I'm a big Unicode fan myself (quite often I have to deal with alphabets other than Latin), but sometimes I just forget to change the encoding when saving files in Notepad. Will be fixed.

[Virtual_ManPL]

the decoder may not work on XP without updates.

Thank GOD, all updates should be always installed, especially SP3(32bit)/SP2(64bit) on XP, because this system is unsupported in this days by M$ ...

[MickJT]

VirtualDubMod using the DirectShow AviSynth template doesn't like the changes to YV12 that 1.3.x has brought about. Disappointing. Using ffdshow VfW for YV12 works fine.

[Jawor]

The so-called “fix for YV12 colorspace pass-through mode” that was done in 1.3.0 created this problem, but my builds have a workaround for it.

My installers contain a “Decode YV12 through VfW” option that addresses this issue. If there's no VfW codec associated with “YV12” FourCC on your system, this option appears during installation. If you check it, Xvid will be associated with “YV12” in your system registry (and thus VDM will use Xvid for decoding YV12).

[hopstiii]

Hi

My video doesn't run smooth at all in XviD 1.3.1,
i encoded with max quality settings and with 2.5 MB/s bitrate. Only Luma is of.

The thing is there almost isn't any CPU use 3-10% (c2d e4500, HD3870).
My video is large still image and camera is panning on it (there i can see fps isn't smooth) 720p 30fps, therefor i used GMC, also QP and ISC.

I turn of ISC, i think i need GMC but it might be the problem because it doesn't buffer smooth frames for me, even there are enough cpu power.

[henryho_hk]

I've modified xvid_encraw (back-porting some of squid_80's work actually) and uploaded it here and to Easy Share (http://www.easy-share.com/1914610307/xvid_encraw.7z):

1) The total size variables are now declared as int64_t so that they won't become negative for big files.
2) "-stats" accepts a optional filename (for obvious reason)
3) "-frames" seems to be specifying the end frame but not number of frames. Fixed.
4) Catching "Ctrl-C" and flushes the output files properly.

Sorry, only "-o" (m4v) output supports >4GB.... and such output is basically unusable unless got muxed as a mp4 by mp4box.

[Rumbah]

I got a reproducable xvid crash with xvid_encraw and the VfW Codec.

My Avisynth script:
DSS2("Alice_lossless_error.mkv")

It doesn't matter if I use DSS2 or DirectShowSource ot FFVideoSource. If I encode it with Xvid 1.3.1 via encraw or Virtualdub with the following settings Xvid crashes on me everytime on Win7:

xvid_encraw.exe -i script.avs -type 2 -o error.m4v -max_bframes 3 -cq 2.0 -bvhq -metric 1 -qpel -masking 2 -progress 10

I hope anyone can reproduce it. I didn't find the right place to post it to the Xvid developers so if anyone can help to get it to the right place it would be great.

Here is the video file producing the crash:
http://www.megaupload.com/?d=WW4DXSZX


PS: I'm using Jawor's build.

[henryho_hk]

My own compile (http://www.easy-share.com/1914630681/xvid_encraw_core2duo.7z) (GCC 4.5.2 32bit Core2Duo or above) does not work @XP64. But Jawor's 64bit compile works ok

[Rumbah]

Hmm, your build crashes for me, too, at the same position (frame 16-17).

I'm using Win7 64 bit with avisynth 2.5.8 32 bit and a core2quad.
Is there anything I can do to help identify the problem?

[henryho_hk]

1) Don't use "-qpel".
2) Don't use "-threads 4" .... (1, 2, 3, 5, 6, 7 work while 4 & 8 don't)
3) Install Avisynth x64 and then use Jawor's 64bit compile

[Rumbah]

Thank you. As Xvid doesn't seem to scale very well I'll just use -threads 3 .

I would never have guessed this problem, as I didn't use threads 4 directly but the autodetect just set it to 4.

[henryho_hk]

It's just the empirical result from my computer. I am not sure it can run stably for long clips.

[Jawor]

Is there anything I can do to help identify the problem?
Adding SetMemoryMax(128) at the beginning of the script is always a good idea with 32-bit AviSynth (to avoid potential problems with the 2 GB per-process memory limit). 64-bit AviSynth probably won't need it (there's no 2 GB limit there), but it won't hurt either.

[henryho_hk]

It crashes in the same way with SetMemoryMax(128). QPel has always been causing weird crashes recently.

[Tuik]

Is the problem of creating corrupt avis when size is over 2GB still existing?

[hopstiii]

Is the problem of creating corrupt avis when size is over 2GB still existing?

Yes i'm pretty sure it is.
Camstudio has allways had 4gb limit they say it's avi limit.

[Tuik]

When will it get fixed?

[Rumbah]

As I posted in the 1.3.0 thread as a workaround for the 2GB problem you can encode your video to m4v, then mux it to mp4 with mp4box, then remux that to mkv and then mux the mkv to avi with avidemux.

[Tuik]

As I posted in the 1.3.0 thread as a workaround for the 2GB problem you can encode your video to m4v, then mux it to mp4 with mp4box, then remux that to mkv and then mux the mkv to avi with avidemux.

It's much simplier to just encode to .avi normally and then open the buggy .avi on Mpeg4Modifier and just save it.

[space1999]

^ Just wondering, why the :devil: that annoying design flaw in Xvid hasn't been fixed yet... «AVI sucks» :rolleyes: is not an explanation, nor a good reason.

[henryho_hk]

It's much simplier to just encode to .avi normally and then open the buggy .avi on Mpeg4Modifier and just save it.

Have you tried creating a >4GB avi? That old AVI routine simply wraps around.

[henryho_hk]

then mux it to mp4 with mp4box

Isn't MP4Box (or YAMB) able to demux the video stream as AVI? Not sure if it can handle >4GB files though.

[Rumbah]

I don't know, I just found that it worked and wrote a script to automate the process (encoding BDRebuilder output to PSP and avi for the old DVD player) ;)

[henryho_hk]

^ Just wondering, why the :devil: that annoying design flaw in Xvid hasn't been fixed yet... «AVI sucks» :rolleyes: is not an explanation, nor a good reason.

No, it is not a design flaw of XviD. I believe "xvid_encraw" was not meant for production use.... it is merely a test application of the xvidcore library.

[vlada]

Can someone help me explaining why this doesn't work with Jawor's xvid_encraw binary:
avs2yuv.exe -raw video.avs - | xvid_encraw.exe -type 0 -framerate 25.0 -w 520 -h 400 -frames 5008 -max_bframes 2 -qpel -qtype 1 -turbo -nopacked -progress 10 -stats -pass1 video.stats

I have an old build of xvid_encraw (dated 2007/08/31) in which this command line works fine. Both with XviD 1.3.1 library.

Thank you.

[Gusar]

What exactly is the problem? The only thing I can see is that you're missing the option for colorspace. avs2yuv outputs i420, so add -csp i420 to the xvid_encraw command.

[vlada]

Gusar> Unfortunately this didn't help. I also tried the other advices I found in this thread (not to use -qpel and use only 1 thread) without any success.

This is the output I get:

http://img690.imageshack.us/img690/2127/xvidencraw.png (http://imageshack.us/photo/my-images/690/xvidencraw.png/)

If I replace xvid_encraw (and keep new XviD library) with an old version, everything works fine.

[henryho_hk]

I have made my own compiles of non-squid80 xvid_encraw (static-linked with xvidcore 1.3.1). Do you want to try? Is your CPU of K8 w/ SSE3 or K10 family?

[vlada]

henryho_hk> Yes, I would like to try it. My CPU is K10 I believe (Phenom X2).

Btw. Yesterday I tried to convert a movie to AVI with old xvid_encraw and new XviD 1.3.1. I got completely wrong size, Over 2GB instead of 650MB. 6Mbps for a VGA resolution movie. The command line was the same as above, just modified for the 2nd pass with this:
-stats -pass2 "video.stats" -size 663268.0 -avi "video.avi"
Do you have any idea what caused this problem?

[henryho_hk]

A bunch of x86 and x64 compiles with modded source files: http://www.easy-share.com/1915564978/xvid_encraw_131jaworhh_gcc460_mingw.7z

The binaries are for testing purposes only. Please do extensive virus scanning before trying them. "-O3 -fexcess-precision=fast -mmmx -msse -msse2 -msse3 -march=[cpu_type]" is added when compiling pthreads and "-O2 -fexcess-precision=fast -mmmx -msse -msse2 -msse3 -march=[cpu_type]" is added when compiling XviD. The compiler being http://www.xvidvideo.ru/component/docman/doc_download/6167-cross-mingw-x86x64-20110506-with-gcc-460-stable-release-v2.html

There is no need to put xvidcore.dll in its directory as the required version is statically linked already. If xvid_encraw.exe does not load your AVI or AVS, please install Jawor's XviD 1.3.1 binaries first. It should be somehow related to the registry settings.

Sources are also included. I fixed some number formatting bugs and a bug when both "-start" and "-frames" are both specified, then add output buffering in various places (I thought it will be nicer to my new SSD... heehee) and hacked in file output for statistics, SSIM and PSNR-HVMS figures. And sorry, no OpenDML AVI output.... it's too hard for me.

Hope my code hacks did not break anything. Enjoy.

[vlada]

henryho_hk> Thanks for uploading your builds. Unfortunately I get the same error with your xvid_encraw as with Jawor's. Only first 20 frames are encoded and the process ends....

[henryho_hk]

What about using the AVS as input directly without piping?

[vlada]

Using AVS directly works fine, but I ant to use avs2yuv to make my application portable. The usage of avs2yuv allows me to use avisynth even if it is not installed.

Avs2yuv piping works fine with old xvid_encraw builds, so something must get broken...

[henryho_hk]

What about avs2pipe?

[ANGEL_SU]

@vlada
Don't use recent builds for piping, because stdin is in text mode under Windows. The following code need to be added into the source.

#include <io.h>
#include <fcntl.h>

_setmode(_fileno(stdin), _O_BINARY);

[henryho_hk]

Thanks, Angel_SU! Time for a new compile :)

But I think I will do core2, corei7-avx and K10 march compiles only. I guess no one will use Atom for XviD encodes, and probably not K8-SSE3 either.

[ANGEL_SU]

@henryho_hk
If you are ready to build a new one for piping, please also modify at #LINE 853(referring to yours):
// if (ARG_INPUTFILE != NULL) {
if (ARG_INPUTFILE != NULL && strcmp(ARG_INPUTFILE, "stdin") != 0) {
with this, '-i stdin' can be really omitted at a command line.

[vlada]

Is it not possible to build a binary, which would use the advanced instructions only if they are available? Also how big is the performace boost?

I have a UMPC with Atom and I might need to use it for encoding when I'm traveling.

[henryho_hk]

The encoding core of XviD is in assembly language already. Hence, the performance boost may not be big.

[SilaSurfer]

Has anyone noticed any bugs with metric1 (PSNR-HVS-M) option since its a new feature and Jawor mentioned, it could contain bugs. I haven't noticed anything though.