Multithreaded XviD - official thread

[sysKin]

[edit - this was updated. a lot]

Hi :)

I hope you don't mind I opened a new thread about it, but new MT code is significantly different than previews and I'd really like the first post to explain all current information, not old obsolete experimental stuff.

So, here we go:
What happened: Multithreaded XviD code is now committed to CVS. From now on, all "xvid head" or "xvid 1.2.x" versions have it.

What does it mean: If you have a multi-core, multi-CPU or just Hyperthreaded system, you get more speed by using new multithreaded capabilities. If not, you can ignore them completely. In fact you are recommended to ignore them. Everything below only applies for number of threads > 0, for equal zero there's no difference from before.

How to use it: In VfW, the number of threads can be changed by clicking on Other Options at the bottom. When using xvid_encraw, use -threads parameter. You need a new xvid_encraw for that (compiled today or later). In general, use number of threads equal to your number of cores. You can make your own measurments though - for example, fast first pass seems to be a bit *faster* on just one thread... But all that depends on your setup, settings, complexity of avisynth script etc.

Is quality lower: No, resulting file is (should be) the same regardless of number of threads.

Is there a maximum: I think a value that's waaay to high will cause a crash ;) and that's my fault. In theory, the maximum # of threads that can be used is equal to picture height divided by 16, rounded up.

Is there an option that b0rks it: Not as such. However, GMC remains not multithreaded at all, so if you use GMC you probably loose most benefits.

CPU usage is better at number of threads = 3 than = 2, should I use 3 then?: DO NOT, I repeat, DO NOT measure this code's performance by looking at CPU usage in task manager. Measure speed. In fact I get the best speed at two threads (85% cpu usage) three (~95% usage). That's the way it is.

So, can I increase CPU usage because 85% is only 85%: Yes, increase thread priority. On a dual-core system it doesn't hurt anyway, and the higher priority the less idle CPU. You probably shouldn't feel any difference, while "Higher" gives me 98% usage and is faster than "Normal". HOWEVER, "Highest" is slower again. In fact MUCH slower. Probably takes CPU power away from avisynth.

I'm looking forward for your impressions, speed results, and crash reports :)

Regards,
Radek

Until Koepi or Celtic Druid make their builds, you can get a crude binary here: Http://syskin.is.dreaming.org/xvid-smp.zip . Unzip, right click on the .inf file, select install.

[Axed]

Wow, this is great news for those lucky buggers with dual core processors! Ill give it a try on my p4 when i get a chance, but the damned thing isnt booting at the moment (again time for another new mobo!).

To be truthful, im going to be extremely suprised if theres any difference at all using threads on my p4 since i havent got a boost with any of the other programs with extra threads.

[squid_80]

How to use it: In VfW, the number of threads can be changed by clicking on Other Options at the bottom. When using xvid_encraw, use -threads parameter. You need a new xvid_encraw for that (compiled today or later).
Use the following number of threads:
* uniprocessor systems: 0
* HT pentium 4s : probably 1. I don't know really.
* Multi cores, multi CPUs: probably equal to real number of cores. I don't know really ;p

Are there plans to implement some sort of no. of cores auto-detection, so an XVID_GBL_INFO call will return the right number of threads to use? Intel has given example assembly code and it seems to have been adopted by AMD to match.

[708145]

Are there plans to implement some sort of no. of cores auto-detection, so an XVID_GBL_INFO call will return the right number of threads to use? Intel has given example assembly code and it seems to have been adopted by AMD to match.

The optimal number of threads also depends on the settings used. It is thus a bit more complex.

[sysKin]

The optimal number of threads also depends on the settings used. It is thus a bit more complex.

Actually I just removed this idea of mine, to run encoding as yest another thread. So now number of threads = number of cpus always, after all.



Are there plans to implement some sort of no. of cores auto-detection, so an XVID_GBL_INFO call will return the right number of threads to use? Intel has given example assembly code and it seems to have been adopted by AMD to match.

In theory XVID_GBL_INFO returns that, just look at the code It's old stuff though.
Anyone knows a win32 equivalent of pthread_num_processors_np() ?

Since threads = 0 is pretty much identical to threads = 1 now, I can make = 0 an autodetection.

[Doom9]

win32 equivalent of pthread_num_processors_np() ?Not exactly an equivalent, but get the number of processors environment variable.. it does the trick on NT based boxes. And if it's not there, set the number of threads to one because those pseudo 32 bit Windows can't handle more than one cpu anyway. This is how the autosetting of nbthreads works in megui (except that I'm not catching the error in case the environment variable is there.. some might argue that's a bug.. I consider it a feature you get if you use a crappy OS <evil grin>)

[captainvideo]

could someone post a link.

[dimzon]

Is quality lower: No, resulting file is (should be) the same regardless of number of threads.
WOW!
Does this technology applicable to AVC? Is it possible to make same for x264?

[ChronoCross]

MINGW32 Compilation failed. 1.1 final compiles fine. does the new 1.2 cvs require anything more than 1.1 in terms of libraries?

EDIT I did fresh checkout a minute ago and it seems as though it's working. although it throws alot of warnings. but it does indeed compile.

the vfw doesn't however.

[sysKin]

Does this technology applicable to AVC? Is it possible to make same for x264?

Yes it is, but note it's not as efficient (in terms of speed, scaling on many CPUs etc) as slices used in x264.

Then again I could have used slices for b-frames and didn't, because I wanted identical file ;)

[Kostarum Rex Persia]

sysKin, but where is the download link for official Multithreaded XviD build?

[ChronoCross]

sysKin, but where is the download link for official Multithreaded XviD build?

you have to compile it yourself.

[sysKin]

sysKin, but where is the download link for official Multithreaded XviD build?

Actually I have no reason *not* to make a build of some sorts. But don't count on installer or other fancy stuff. Koepi promised to make a build soon, too.

Http://syskin.is.dreaming.org/xvid-smp.zip

[sysKin]

Anyone knows a win32 equivalent of pthread_num_processors_np() ?

If anyone is interested, I just invented this:

static int pthread_num_processors_np()
{
unsigned int p_aff, s_aff, r = 0;
GetProcessAffinityMask(GetCurrentProcess(), &p_aff, &s_aff);
for(; p_aff != 0; p_aff>>=1) r += p_aff&1;
return r;
}


Takes affinity into account and generally does what I need :)

[suxen_drol]

Actually I just removed this idea of mine, to run encoding as yest another thread. So now number of threads = number of cpus always, after all.




In theory XVID_GBL_INFO returns that, just look at the code It's old stuff though.
Anyone knows a win32 equivalent of pthread_num_processors_np() ?

yep! have commited change to cvs.

Since threads = 0 is pretty much identical to threads = 1 now, I can make = 0 an autodetection.

ok, but be wary of other platforms for which we don't yet have a syscall to query the number of processors.

-- pete

[Yong]

MINGW32 Compilation failed. 1.1 final compiles fine. does the new 1.2 cvs require anything more than 1.1 in terms of libraries?

EDIT I did fresh checkout a minute ago and it seems as though it's working. although it throws alot of warnings. but it does indeed compile.

the vfw doesn't however.
Hmm, wired,
i can compile 1.2 vfw/ encraw/ xvidcore.dll without problem, but...
yup its throws alot of warnings," ...motion_smp.h. no new line at the end of file..."
Start from 1.2, i no longer can compile the xvid dshow decoder :(
gcc throw me a "no rules to make debug.obj, needed by xvid.ax"... O.o
Dont know what the hell is going on...

[ChronoCross]

Yong. My problems were caused by an incomplete commit. all the problems are fixed as of 8pm 02/24.

[Cyberace]

Feature request; can we please get a multithreaded decoder (option) as well as the multithreaded encoder?

[hajj_3]

is xvid 1.2 final gunna be out soon?

[sysKin]

Feature request; can we please get a multithreaded decoder (option) as well as the multithreaded encoder?

I have absolutely no idea which part of decoder can be multithreaded and how (complete rewrite with added pipeline doesn't count).

[Guilllo]

Hi, it's a great new !!

I'm using Mencoder under linux to encode in xvid. How can I set the number of thread to use ?

Thanks

[Koepi]

Ok, as promised my build is up now, too. Fetch it as long as it's still warm ;-)

Changelog to XviD-1.1:
- {core}: New experimental SMP support.
- {core}: Trellis improvements (according to sysKin).
- On uniprocessor machines set number of threads to 0!

Cheers
Koepi

[lantern]

I seem to be having a problem compiling the latest CVS build. Here is the error I get when I go to make. I am using mingw & msys.

I ran ./bootstrap.sh then ./configure and finally make. Am I missing any steps?

Thanks!

http://img123.imageshack.us/img123/6074/xvidcompile4xm.jpg (http://imageshack.us)

[sysKin]

I seem to be having a problem compiling the latest CVS build. Here is the error I get when I go to make. I am using mingw & msys.

Update your cvs, it's a mistake I made ~24 hours ago and fixed ~12 hours ago.

[hajj_3]

so when is xvid 1.2 final due to be released?

is there just gunna be SMP multithreaded support or will there be any quality improvements?

[lantern]

I can't seem to find the latest cvs build. I downloaded from here (http://downloads.xvid.org/downloads/xvid_latest.tar.gz) and it was not the latest. I used WinCVS with this command, cvs -d: pserver:anonymous@cvs.xvid.org:/xvid co xvidcore and it is still an old compile. I have tried Koepi's site but can't get the latest (www.koepi.org/xvidcore-1.2.-127.zip). The link doesn't seem to be working.

Thanks for all your help.

[ChronoCross]

I can't seem to find the latest cvs build. I downloaded from here (http://downloads.xvid.org/downloads/xvid_latest.tar.gz) and it was not the latest. I used WinCVS with this command, cvs -d: pserver:anonymous@cvs.xvid.org:/xvid co xvidcore and it is still an old compile. I have tried Koepi's site but can't get the latest (www.koepi.org/xvidcore-1.2.-127.zip). The link doesn't seem to be working.

Thanks for all your help.

the cvs from where you were downloading is the latest. koepi's is not a .zip. go to his site and in the downloads section there is an installer.

[SeeMoreDigital]

Here was a direct link to Koepi's latest Koepi's Site (http://www.koepi.org/) download :)


Cheers

[edit by Koepi]: tses ;-P

[lantern]

Thanks SMD, but I was looking for the latest source to build my own.

I did have the right cvs, but it was showing up as being created 28Dec2005. I needed to reboot after I put in in the system32 directory.

[Koepi]

Of course the latest source that I used is on my site as well, look out for "xvidcore-1.2.-127-250206.zip (861kb)" (scroll a little down. If you still see "xvidcore-1.2.-127.zip" you might wanna hit the refresh-button while holding down your shift-key. This tells your proxy to fetch the site fresh from the net.

Cheers
Koepi

[sysKin]

so when is xvid 1.2 final due to be released?
Probably never. We hardly had enough willpower to release 1.1, and today is the last day of my summer holidays. I expect 1.2.-127 to remain th "latest unstable build" forever and ever ;)

It already has multiple improvements over 1.1, such as better trellis, some packet bitsteam fixes, new VfW config, HVS plugin support (still no plugins though) and some other stuff.

[LordIntruder]

Hi,


I've been making some tests comparing first SMP build released many days ago by Syskin in the other discussion thread with this new one.

Those tests have been made using the exact same script and XviD options of course.

Encoded using 2 threads.

AMD 4200+ , Avisynth 2.5.6 , VDM 1.5.10.2


First smp build:

1st pass : 56min (41,5fps)
2nd pass : 2h 36min (14,9fps)

New build:

1st pass : 50min (46,5fps)
2nd pass : 2h 17min (17fps)

Now the new build without GMC as Syskin said GMC is not multi-threaded. Just to see how faster it is.

1st pass : 50min
2nd pass : 1h 59min (19,5fps)

My CPU usage is around 85% (fluctuating all the time around 80% to 90% and no other program running) but as you said Syskin it is essential to make tests on speed. However there is still CPU power potential that is not used.

Thanks for the work Syskin. :)

I tested 3 and 4 threads just to see if it would decrease my and encoding time by increasing my CPU usage but it takes longer so forget about that. ;)

Is it impossible to multi-thread GMC?
You say you are stopping 1.2 development but is there any plan than somebody else continue your work? We are millions to wait :D :D

Anyway again thanks you very much. :thanks:

[Kostek80]

static unsigned CalculateNumberOfThreads(unsigned numThreads) {
if(numThreads == 0) {
SYSTEM_INFO systemInfo;
::GetSystemInfo(&systemInfo);

// microsoft recomended for smp system
numThreads = systemInfo.dwNumberOfProcessors * 2;
}
return numThreads;
}
I hope it will be helpfull. i use this formula for scalable systems

[xDrJx]

Koepi site requires username and PW:confused:
Did I miss something?

Nevermind, works again!!
Sorry for useless post!!

[dimitrik]

Of course the latest source that I used is on my site as well, look out for "xvidcore-1.2.-127-250206.zip (861kb)"
Cheers
Koepi

Hi Koepi,

Pardon me for being out of date here:o , but is this compile optimised for any kind of processor? IIRC, some time ago you used to host AMD optimised builds while Celtic Druid did Intel optimised builds.

Many thanks for all you're doing.:)

[humax]

Hi
i have a Pentium Hyperthreading .
No Dual Core like 820D or something but Hyperthreading simulates 2 Cpus.

How many threads shall i choose. 0 or 1 ???

thx for help

[xDrJx]

I also have a HT shitbox and for me the number 2 works best. Test it dude.

cheers

[708145]

static unsigned CalculateNumberOfThreads(unsigned numThreads) {
if(numThreads == 0) {
SYSTEM_INFO systemInfo;
::GetSystemInfo(&systemInfo);

// microsoft recomended for smp system
numThreads = systemInfo.dwNumberOfProcessors * 2;
}
return numThreads;
}
I hope it will be helpfull. i use this formula for scalable systems

Never use a single formula for every software because optimal #threads depends on the FU/cache/memory usage of the tasks.
The best solution is to benchmark with different #thread settings at install time.
i.e. for my bus simulator real_cores+ 1/4*hype_cores was optimal from 2 to 4 CPUs.

[hajj_3]

Probably never. We hardly had enough willpower to release 1.1, and today is the last day of my summer holidays. I expect 1.2.-127 to remain th "latest unstable build" forever and ever ;)

It already has multiple improvements over 1.1, such as better trellis, some packet bitsteam fixes, new VfW config, HVS plugin support (still no plugins though) and some other stuff.


that SUCKS, why is the official not going to be released? you should make an official of this, then end development, h.264 aint gunna be mainstream for a while, scene groups arent even using xvid 1.1 yet, nevermind h264. it would be a wasted effort not making an official version of this!

[Cyberace]

so when is xvid 1.2 final due to be released?Probably never. We hardly had enough willpower to release 1.1. I expect 1.2.-127 to remain th "latest unstable build" forever and everHow about a news-post on xvid.org front-page to inform everyone about that? :(

PS! Probebly been asked before but why is xvid.org forum registration closed? :confused:

[xDrJx]

...scene groups arent even using xvid 1.1 yet...

:D complain

[Koepi]

Pardon me for being out of date here:o , but is this compile optimised for any kind of processor?

The usual build should work fast on any kind of processor (cil7 compile with some optimisations). The unstable-build is optimized for pIII and athlon/duron upwards (uses iSSE even if you deselect any processor auto detection) with icl7.1 -- I'm sorry for the k6- and pII-users, but I think it's time to assume that everyone should be using something more recent than a 7 year old processor in the meantime.

@all:

XviD isn't dead. Development is going on, but more slowly again. SysKin hasn't got anymore time, but other people sometimes contribute as well. In the foreseeable future XviD will even get AVC support, if that code hits the public development will get faster again I think.

Cheers
Koepi

[shon3i]

In the foreseeable future XviD will even get AVC supportThat was be Cool!

[split710]

just to be sure....

I have a pentium 4 3gh, with Hyperthreading support, what i have to set exactly?

[shpitz]

hello all,

i'm trying to encode a sample of a 720p from a DVB source.

i'm using xvid 1.2.127 with smp alpha from koepi's site, vdub 1.6.11, dgdecode 1.4.6, and avisynth 2.5.6.

i'm using the following script:


LoadPlugin("D:\TBS\Filters\DGDecode.dll")

mpeg2source("F:\720p_clip.d2v")
SelectEven()

Crop(170,4,-160,-4)

BicubicResize(640,480,0,0.75)



my spec is dual xeon 3ghz with 1gb ram. OS is xp pro sp2.

setting thread number from 0 to 4 results in cpu usage around 40%, all resulting in about the same encoding time (1min, about 30fps avg).

when i try 5 threads or above cpu usage goes up to 85% and above, but encoding speeds gets worse and worse.

i tried installing xvid 1.0.3, and it was faster compared to 1.2 smp. i tried installing xvid 1.1.0 beta 2 and it was faster compared to 1.2 smp.

am i doing something wrong?

could be my dgdecode settings are wrong? which idct option should i use?

the cpus have sse2 and sse3.

i will also run a test on a regular non-HD clip.

http://img528.imageshack.us/img528/4784/xvid011sr.th.jpg (http://img528.imageshack.us/my.php?image=xvid011sr.jpg)

http://img528.imageshack.us/img528/2826/xvid029xp.th.jpg (http://img528.imageshack.us/my.php?image=xvid029xp.jpg)

http://img528.imageshack.us/img528/350/xvid032ei.th.jpg (http://img528.imageshack.us/my.php?image=xvid032ei.jpg)

http://img528.imageshack.us/img528/4573/xvidusage3ku.th.jpg (http://img528.imageshack.us/my.php?image=xvidusage3ku.jpg)

[foxyshadis]

The codec is being starved by avisynth, probably. Try using the MT build of avisynth 2.5.6 and SetMTMode(2) before mpeg2source.

[shpitz]

wow, that was a quick reply, tnx m8.

i will try the MT version of avisynth from mt v0.5 .

i will report back in a few minutes.

[shpitz]

ok, i've replaced the avs dll with the MT version.

if i put SetMTMode(2) in the script, the encode speed drops conciderably.

if i change it to SetMTMode(2,2) it's fine.

i tried with xvid threads set to 0. 56 & 59 seconds for pass1 and pass2.

with xvid threads set to 2 it works with the same exact speed.

if i try SetMTMode(2,4) it drags ass as well.

so it seems like all this smp'ability just makes encoding slower on my pc ;-((

is there anything else u guys can think of that might be misconfiged or that i'm doing wrong?

[shpitz]

is it maybe because i'm actually not using any filters on this clip at all? i only crop and resize...

[sysKin]

I am very much interested in Xeon or dual core P4s. In theory, their primary design fault (no connection between cores other than FSB) can be a major problem. It might also be not a problem at all.

However, I don't like your CPU usage graphs... one virtual core is not being used at all, and this is not something windows does, when it gets the choice..... something might be funny.

Either that, or Xeons are really bad at this (they might be, really might be...)

[shpitz]

yeah, it is well known that xeons are chokers when it comes to memory-cpu bandwidth. opterons and dual-cores should do a better job in that respect.

i might disable HT and try again, from my tests it appears that 2 threads is optimal as with 4 it really chokes.

i will also disable PAT and see if it makes a difference.

expect more tomorrow ;-)

[Revgen]

@shpitz

The SetMTmode filter needs to be set before you're source like this:

SetMTmode(2,2)
mpeg2source("yourdrive:\yourd2v.d2v")
Yourfilter()

Also, are you actually using a real dual-core or dual CPU solution? HT will not gain as much as the real thing.

HT in some cases can even slow down performance.

[sysKin]

yeah, it is well known that xeons are chokers when it comes to memory-cpu bandwidth.

Yes, and with an application that works on two cpus, *additional* data transfers happen - between the cpus. They add up to the memory bandwidth because they all use FSB as the data pipe.

This code doesn't use a lot of data to communicate, but it does depend on this communication happening fast. If FSB is delaying the information, one of the threads suddenly has nothing to do (because it's not informed how much another thread has done) and must wait...


Actually, I'll make some tests how this code's speed depends on Hypertransport speed. Good idea :)

[Yong]

I failed to compile the lastest cvs code(libxvidcore)...
Here is the part of msys output:
D: =build
C: ./decoder.c
In file included from ../../src/bitstream/../motion/motion_smp.h:34,
from ../../src/bitstream/../encoder.h:158,
from ../../src/bitstream/bitstream.h:31,
from ../../src/decoder.c:40:
c:/msys/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/winbase.h:552: error: syntax error before "DWORD"
c:/msys/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/winbase.h:556: error: syntax error before "DWORD"
c:/msys/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/winbase.h:558: error: syntax error before "ftLastAccessTime"
c:/msys/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/winbase.h:559: error: syntax error before "ftLastWriteTime"
[...]
alot of erros, "make distclean && make -s" doesnt help...
But dshow decoder compiling work again, thx xvid devs :)

EDIT: may be there's something wrong with motion_smp.h,
i revert it to older revision then compling works again :p

[shpitz]

@shpitz

The SetMTmode filter needs to be set before you're source like this:

SetMTmode(2,2)
mpeg2source("yourdrive:\yourd2v.d2v")
Yourfilter()

Also, are you actually using a real dual-core or dual CPU solution? HT will not gain as much as the real thing.

HT in some cases can even slow down performance.

dual xeon 3ghz, and yes, i've added the setmtmode before mpeg2source.

i will need to thoroughly investigate it, the computer seems to choke completely in terms of smp encoding.

[Zep]

dual xeon 3ghz, and yes, i've added the setmtmode before mpeg2source.

i will need to thoroughly investigate it, the computer seems to choke completely in terms of smp encoding.


It depends on how low level syskin went. Dual CPU sucks when the code is lower level like say each CPU working on part of the same marcobock VS each CPU working on half of a video frame and never accessing the same data so no need to sync much or sync fast and thus each CPU is always crunching with very few wait states. Higher level makes scaling much better also like when throwing a render farm at a project.

[woah!]

i am getting nearly double the framerate in encoding by using Vdub with SetMTMode(2) and the lastest xvidcore.dll

it sits at about 85% cpu and from 10fps for 1 thread to 18-19fps with 2 threads:


going from 1920x1088i 30fps to 720x304 23.976fps :

SetMTMode(2)
mpeg2source("G:\INDEXED.d2v")
crop(0,144,-0,-148)
Telecide(order=1,guide=1,post=2).Decimate(mode=0)
#TomsMoComp(1,30,1)
#FDecimate(rate=23.976,threshold=3.5)
#Kerneldeint(order=1,sharp=true)
#Kernelbob(order=1,sharp=true) # double framerate 60fps
#ColorMatrix("Rec.709->Rec.601",mmx=true,hints=false)
#LanczosResize(848,480)
#BicubicResize(704, 400, 0.33, 0.33, 8, 8, 1904, 1072)
#bicubicResize(704,400)
LanczosResize(720,304)
asharp(2,4,hqbf=true)
#trim(61000, 61720)


thx for this nice upgrade which i could never have got with any single-core cpu upgrade.

http://images.dr3vil.com/files/default/2core.jpg

heres a clip of the output file:

http://s19.yousendit.com/d.aspx?id=051E4GRBM6JOI18W03XLOVCLQH

[shpitz]

woah!,

can you post a link to the xvid version you are using?

also, which avisynth version are you using?

did you install anything else (such as MT 0.5 filter) ?

can you also post your xvid encoding settings you used and which matrix? the encode looks great.

[AmazingRando]

:D I just wanted to thank you guys for your effort in making XviD SMP capable. I've used XviD for years now on hundreds of encodes and it's been great.

Last fall I reluctantly decided to move to Divx 6 since XviD wasn't SMP capable. I found that I needed to encode at "extreme" or "insane" quality to get the same quality as with XviD. But now I'm thrilled to be using XviD once again :D I did several test encodes last night to compare quality and performance between XviD 1.2 and Divx 6.1.1. On a dual-core 2.8Ghz Pentium D I was able to do a two-pass encode of a 44 min DVD ripped TV episode (720x480x24fps) in 47 mins including audio encoding and muxing. Compare that to 2 hours 2 mins for Divx 6.1.1 on insane quality. I judge the quality to be comparable between the two. BTW, the Pentium D 820 doesn't support HT, just two physical processors (cores). I have it set to 2 threads and get about 85-90% CPU utilization.

So, I'm one happy guy :D . Keep up the great work.

AR

PS. Future AVC support would be great!

[Koepi]

Igor Levicki asked me to post this (which I'll gladly do as it might be helpful):
In case you folks still haven't figured out the way to detect number of CPUs in the system let me help a bit:



#include <stdio.h>

typedef unsigned long u32;

u32 GetLogicalCPUCount(void)
{
u32 logical_cores = 0;

__asm {
xor eax, eax
cpuid
cmp eax, 1
jb no_logical_cores
mov eax, 1
cpuid
shr ebx, 16
and ebx, 0xFF
mov dword ptr [logical_cores], ebx
no_logical_cores:
}

return logical_cores;
}

u32 GetPhysicalCPUCount(void)
{
u32 physical_cores = 1;

__asm {
xor eax, eax
cpuid
cmp eax, 4
jb no_physical_cores
mov eax, 4
xor ecx, ecx
cpuid
shr eax, 26
and eax, 0x1F
add eax, 1
mov dword ptr [physical_cores], eax
no_physical_cores:
}

return physical_cores;
}

u32 HasHyperThreading(void)
{
u32 has_htt = 0;

__asm {
xor eax, eax
cpuid
cmp eax, 1
jb no_htt
mov eax, 1
cpuid
test edx, 0x10000000
jz no_htt
mov dword ptr [has_htt], 1
no_htt:
}

return has_htt;
}

int main(int argc, char* argv[])
{
u32 pcores, lcores, htt;

lcores = GetLogicalCPUCount();
pcores = GetPhysicalCPUCount();
htt = HasHyperThreading();

printf("Number of logical cores = %ld\n", lcores);
printf("Number of physical cores = %ld\n", pcores);

if (htt && ((lcores / pcores) > 1)) {
printf("CPU has HyperThreading = YES\n");
} else if (htt && (lcores == 1)) {
printf("CPU has HyperThreading = YES, DISABLED\n");
}

return 0;
}


If you have any doubts, check AP-485 (http://developer.intel.com/design/xeon/applnots/241618.htm) document. Same should apply to AMD.

Take note that logical cpu count == physical cpu count on current dual-core CPUs and that the presence of HyperThreading needs to be detected in a slightly different way than before -- having HTT bit set and 2 logical cores doesn't mean you have HTT. Pentium D 955 reports 4 logical and 2 physical cores. I understand that physical cores are counted as logical for compatibility reasons.

Perhaps it wouldn't hurt to add more checks (CPU familiy/model, etc) but I believe that this code should be safe to execute even on older CPUs, at least those which have CPUID instruction so you might at least want to add the check for that.

I would like to comment on FSB and bandwidth issues, I have done some threading of median filtering on my Pentium D 930 recently and I managed to get 2x speedup. With careful threading I bet you can do it too -- just make the threads work independently. I did it by making a queue from which two threads dequeue "packets" for processing which are queued by the third, main thread.

[squid_80]

Now that's what I was talking about.;) Would fit nicely into cpuid.asm, no?

[seehowyouare]

On a dual-core 2.8Ghz Pentium D I was able to do a two-pass encode of a 44 min DVD ripped TV episode (720x480x24fps) in 47 mins including audio encoding and muxing. Compare that to 2 hours 2 mins for Divx 6.1.1 on insane quality.

Sorry to be a party pooper but my x2 4400 Windows x64 system doesn't agree, regardless of number of threads I set :eek:
And I tried using GK, AutoGK and RealAnime. Fastest is DivX 6.11 at 75fps encoding speed, then XviD-1.1.0-30122005.exe and XviD-1.2.-127-25022006.exe is the slowest.
FWIW - the x264 standard codec uses only 1 core at 65% CPU @ 8fps. woot ! Yet to try Sharktooth's build.

Maybe my testing is wrong so if someone has an "agreed" test setup/procedure/script I can follow to fairly test the 1 thread vs 2 thread codec speeds on my PC I'd appreciate it.

Thanks

[shpitz]

anyone that experiences a speed-up, can you please post the exact versions (direct links would help a lot) of the components you are using (codec, avisynth, etc...).

seehowyouare's experience is kinda encouraging so-to-speak, maybe it's not a hardware issue on my end after all...

i did disable PAT but speed was not affected in almost any way, next thing i will try is disable HT in bios.

expect more to come...

[celtic_druid]

Well if you want an alternative to try:
http://ffdshow.faireal.net/mirror/XviD/xvid.cvs.head.2006.02.28.7z
http://ffdshow.faireal.net/mirror/XviD/XviD.cvs.head.exe
Same thing just with/without installer.

[AmazingRando]

Maybe my testing is wrong so if someone has an "agreed" test setup/procedure/script I can follow to fairly test the 1 thread vs 2 thread codec speeds on my PC I'd appreciate it.


:confused: That's strange. Is it me or does it seem like the people who are having trouble are AMD X2 users? I'll post my software, versions, etc. tonight. I have a dedicated system for encoding so it's a very clean install. Moreover, I'm using either GK codec pack 1.9 and GK rip pack .35 pack2. The only changes are keopi's latest xvid 1.2 binary and then the Divx stuff. For Divx I'm using Divx Pro 6.1.1 and Dr. Divx OSS 2.0 beta 7 with the current DrFFMPEG. Pretty stock really. More later...

AR

[shpitz]

:confused: That's strange. Is it me or does it seem like the people who are having trouble are AMD X2 users?

not only, i'm a xeon (intel) user...

[seehowyouare]

FWIW - the x264 standard codec uses only 1 core at 65% CPU @ 8fps. woot ! Yet to try Sharktooth's build.

I tried Sharktooth's x264 build set at 4 threads and encoding speed in VirtualDubMod increased from 8fps using the standard single thread x264 codec to 15fps on identical encoding job. CPU usage is much higher on both cores so I know multi thread stuff does work on my system.
Screenshots of Task Manager using single thread (http://img312.imageshack.us/img312/488/x264stdr4088gh.png) x264-Std_r408exe and multi thread (http://img401.imageshack.us/img401/8928/x264445installexe7wv.png)x264-445-install.exe

[Nic]

Yesterday I got a dual cpu box with 3 gig of ram dropped on my desk at work. Each cpu is a dual core opteron 280. Gives me a good excuse to do some XviD multithreaded encoding :)

I'm not really noticing any speed up. But at present i've got a few tasks in the background, so I need to clean things and do some proper testing.

I'll let you know.

-Nic

[dimzon]

Yesterday I got a dual cpu box with 3 gig of ram dropped on my desk at work. Each cpu is a dual core opteron 280. Gives me a good excuse to do some XviD multithreaded encoding :)

I'm not really noticing any speed up. But at present i've got a few tasks in the background, so I need to clean things and do some proper testing.

I'll let you know.

-Nic
Can You try elder too?
http://forum.doom9.org/showthread.php?t=100766

Thanx!

[Doom9]

one thing not to be forgotten (and I think I'm repeating myself here already) is that even the single threaded XviD build makes use of SMP. Not actually the codec, but since almost all people use XviD from within Virtualdub, the multithreaded architecture of VirtualDub comes to the rescue. You have one thread reading the input (and thus decoding the source), and one doing the actual encoding.. and so the thread scheduler puts the encoding thread on one core, and the decoding thread on another, which in turn means the encoder will max out one core, and the decoding thread will run as fast as the encoder thread can process the data, resulting in not such a shabby speedup. If you really want to see the raw difference, encode with a singlethreaded and a multithreaded encraw build..
At the settings used for the codec comparison, the CPU usage of XviD was in the +70% (no other tasks running but whatever windows is running) which is a lot closer to the cpu usage I'm getting when running a commandline smp capable encoder (x264, elecard, nerodigital).
If you really want to see the difference even in VDub, you can temporarily switch off one core (add /onecp uto boot.ini in the appropriate line, then reboot) ,make a test (nbthreads set to 0), remove the line, reboot, make the test again with nbthreads set to 2, and compare the encoding time.

[celtic_druid]

mencoder just got updated to support threads with XviD now to.

[seehowyouare]

and I think I'm repeating myself here already) is that even the single threaded XviD build makes use of SMP.

I am sure you are because of people like me :-)

Ok, I'm an encoding noob and just got my first dual core CPU.
Can someone confirm or deny if I got this threading/dual core right in my head.

1) Decoding only uses 1 thread
2) Encoding can use multiple threads (dep. on build etc)
3) VDM uses threads to seperate encoding and decoding tasks
4) VDM can allocates threads to CPUs.
5) Having 2 x CPU or 2 x dual core means VDM can decode on 1 x CPU and encode on the 2nd CPU.
6) Setting 2 x XviD threads on my dual core PC will make no difference to speed as VDM controls thread and CPU allocation.

PS - I will receive a dual core 2.8 Intel to keep the x2 4400 compnay next week.

[Ice =A=]

@seehowyouare:
I can at least help in some regards:
1. No, luckily there are also more and more SMP DEcoders available, like Nero, DivX6.1.1 or Quicktime 7 (which is nevertheless very slow on PCs), and some more coming (like CoreAVC).
2. yes
6. There is a difference between the two: Most encoding programs can only separate threads like decoding of source material and encoding or audio and sound. Since the encoding itself needs most of the computing time thge most gains come from multithreaded encoding, which is where the SMP optimized XviD comes handy.
There is only one encoding program I know of which can really designate seperate threads to a non SMP XviD, namely ELDER...

[sysKin]

1. No, luckily there are also more and more SMP DEcoders available, like Nero, DivX6.1.1 or Quicktime 7 (which is nevertheless very slow on PCs), and some more coming (like CoreAVC).

I consider that VERY unlikely. In fact, I consider that almost impossible. Other than postprocessing, I can almost guarantee that there's no multithreaded ASP decoders at all.


1) Decoding only uses 1 thread
2) Encoding can use multiple threads (dep. on build etc)
3) VDM uses threads to seperate encoding and decoding tasks
Yes, yes, yes.
4) VDM can allocates threads to CPUs.No, windows kernel does that.
5) Having 2 x CPU or 2 x dual core means VDM can decode on 1 x CPU and encode on the 2nd CPU.Yup.
6) Setting 2 x XviD threads on my dual core PC will make no difference to speed as VDM controls thread and CPU allocation.No, because encoding and source decoding take different processing power. The more threads there are, the more balance between CPUs.
HOWEVER if filtering and encoding take similar power, such as more complex avs script combined with fast-1st-pass, then indeed just one encoding thread seems to be faster.

[dimzon]

I consider that VERY unlikely. In fact, I consider that almost impossible. Other than postprocessing, I can almost guarantee that there's no multithreaded ASP decoders at all.
theoretically it's possible to split source bitstream by I-frame:
IpppIpbbp and decode each piece in separate thread
unfortunally this scheme is unusable for normal playback but can be used for speedup during transcoding (on more than 2 CPU machines with huge RAM avaluable)

[dimzon]

Or, maybe, it's posible to decode B-frames @ separate thread...

[Ice =A=]

I consider that VERY unlikely. In fact, I consider that almost impossible. Other than postprocessing, I can almost guarantee that there's no multithreaded ASP decoders at all. Now that I'm thinking of it technically, it really seems difficult. But I know that with Quicktime there is a big speed difference between one and two cores, and regarding Nero, I at least know it's using (whatever that means) more then one core.
Maybe they can do different threads for luminiscense and chroma channels or compute different parts of the image in parallel, no idea... :o

[foxyshadis]

I know Elecard/Nero and CoreAVC at least do Cabac decoding on a separate thread, that's a huge processor sink for dvd video and up and the most obvious and easiest speedup. I'm sure they both have a smart scheduler to go with it that tries to partition the work to be done across cpus as much as possible.

[sysKin]

I know Elecard/Nero and CoreAVC at least do Cabac decoding on a separate thread, that's a huge processor sink for dvd video and up and the most obvious and easiest speedup.
Yeah this is why I said ASP decoder. For AVC, there are at least several possibilities to either pipeline (like cabac->everything else ->deblocking) or work in parallel (deblocking itself, or decode slices in parallel if file was encoded with slices).

But ASP... yeah I suppose you can reinvent entire decoder to decode entire frames ahead (either on GOP boundary or b-frames) but that sounds weird. Within one frame, this sounds impossible.
Postprocessing can be split into slices. In fact I might do that if you say that's useful.

As for quicktime, are you sure it's not audio decoder running on another CPU that makes this difference?

[lantern]

It was built with mingw/msys. I have left the thread count to 0 or 1 or 2. I have a P4 w/Hyperthreading.

Crash report from VDub:

VirtualDub-MPEG2 crash report -- build 23843 (release)
--------------------------------------

Disassembly:
0d0495e0: ffc7 inc edi
0d0495e2: 43 inc ebx
0d0495e3: 1800 sbb [eax], al
0d0495e5: 0000 add [eax], al
0d0495e7: 00c7 add bh, al
0d0495e9: 43 inc ebx
0d0495ea: 1c00 sbb al, 00h
0d0495ec: 0000 add [eax], al
0d0495ee: 00c7 add bh, al
0d0495f0: 43 inc ebx
0d0495f1: 1000 adc [eax], al
0d0495f3: 0000 add [eax], al
0d0495f5: 00c7 add bh, al
0d0495f7: 43 inc ebx
0d0495f8: 1400 adc al, 00h
0d0495fa: 0000 add [eax], al
0d0495fc: 00c7 add bh, al
0d0495fe: 43 inc ebx
0d0495ff: 0800 or [eax], al
0d049601: 0000 add [eax], al
0d049603: 00c7 add bh, al
0d049605: 43 inc ebx
0d049606: 0c00 or al, 00h
0d049608: 0000 add [eax], al
0d04960a: 00c7 add bh, al
0d04960c: 0300 add eax, [eax]
0d04960e: 0000 add [eax], al
0d049610: 00c7 add bh, al
0d049612: 43 inc ebx
0d049613: 0400 add al, 00h
0d049615: 0000 add [eax], al
0d049617: 00c7 add bh, al
0d049619: 83900100000000 adc dword ptr [eax+01], 00h
0d049620: 0000 add [eax], al
0d049622: c7839401000000 mov dword ptr [ebx+194], 00000000
000000
0d04962c: c7838801000000 mov dword ptr [ebx+188], 00000000
000000
0d049636: c7838c01000000 mov dword ptr [ebx+18c], 00000000
000000
0d049640: c7838001000000 mov dword ptr [ebx+180], 00000000
000000
0d04964a: c7838401000000 mov dword ptr [ebx+184], 00000000
000000
0d049654: c7837801000000 mov dword ptr [ebx+178], 00000000
000000
0d04965e: c7837c01000000 mov dword ptr [ebx+17c], 00000000
000000
0d049668: c78570ffffff00 mov dword ptr [ebp-90], 00000000
000000
0d049672: c78574ffffff00 mov dword ptr [ebp-8c], 00000000
000000
0d04967c: 83b8ec00000010 cmp dword ptr [eax+ec], 10h <-- FAULT
0d049683: 89bbf0000000 mov [ebx+f0], edi
0d049689: 0f8463040000 jz 0d049af2
0d04968f: 8b7dd4 mov edi, [ebp-2ch]
0d049692: 8d47e1 lea eax, [edi-1fh]
0d049695: 85c0 test eax, eax
0d049697: 0f8e2d070000 jle 0d049dca
0d04969d: 89f9 mov ecx, edi
0d04969f: bbffffffff mov ebx, ffffffff
0d0496a4: 8b75c8 mov esi, [ebp-38h]
0d0496a7: d3eb shr ebx, cl
0d0496a9: 89c1 mov ecx, eax
0d0496ab: 89b59cfeffff mov [ebp-164], esi
0d0496b1: 21f3 and ebx, esi
0d0496b3: d3e3 shl ebx, cl
0d0496b5: b920000000 mov ecx, 00000020
0d0496ba: 29c1 sub ecx, eax
0d0496bc: 8b45cc mov eax, [ebp-34h]
0d0496bf: d3e8 shr eax, cl
0d0496c1: 09c3 or ebx, eax
0d0496c3: 8d4701 lea eax, [edi+01h]
0d0496c6: 83f81f cmp eax, 1fh
0d0496c9: 89c6 mov esi, eax
0d0496cb: 7625 jbe 0d0496f2
0d0496cd: 8b55cc mov edx, [ebp-34h]
0d0496d0: 8b75d8 mov esi, [ebp-28h]
0d0496d3: 8945d4 mov [ebp-2ch], eax
0d0496d6: 8955c8 mov [ebp-38h], edx
0d0496d9: 89959cfeffff mov [ebp-164], edx
0d0496df: 8b db 8bh

Windows 5.1 (Windows XP build 2600) [Service Pack 2]

EAX = 0d3dc5ac
EBX = 0d3baa2c
ECX = 00000000
EDX = 0000007e
EBP = 0d95ee60
ESI = 00000004
EDI = 0000001a
ESP = 0d95eca8
EIP = 0d04967c
EFLAGS = 00010246
FPUCW = ffff027f
FPUTW = ffffaaaa

Crash reason: Access Violation

Crash context:
An out-of-bounds memory access (access violation) occurred in module 'xvidcore'... ...while running thread "Processing" (thread.cpp:150).

Pointer dumps:

EBX 0d3baa28: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ESP 0d95eca8: 0d95ee28 00000003 00000000 0d95ee28 00000000 00000001 00000001 00000010
0d95ecc8: 0000000e 0d95ee28 00000001 00000000 00000000 00000000 00000000 003283d8
0d95ece8: 00000000 0d95ed4c 0d95ede0 00000001 0000000b 337f0000 0d95ed18 0d95ed18
0d95ed08: 0d215d50 80000200 000001b6 00acfd68 00000000 00000003 00000040 0000001f
EBP 0d95ee60: 0d95ef40 04602e03 0d215c80 0d95eee8 00000000 00000000 00000000 00000000
0d95ee80: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0d95eea0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0d95eec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

Thread call stack:
0d04967c: xvidcore!0000967c
0460c295: xvidvfw!DriverProc [04600000+bd80+515]
7c910833: ntdll!RtlAllocateHeap [7c900000+105d4+25f]
7c910833: ntdll!RtlAllocateHeap [7c900000+105d4+25f]
7c80b5b8: kernel32!GetModuleHandleA [7c800000+b529+8f]
7c80b58c: kernel32!GetModuleHandleA [7c800000+b529+63]
7c80b5a1: kernel32!GetModuleHandleA [7c800000+b529+78]
7c80b4b6: kernel32!GetModuleFileNameA [7c800000+b357+15f]
7c80b4cb: kernel32!GetModuleFileNameA [7c800000+b357+174]
7c910732: ntdll!RtlAllocateHeap [7c900000+105d4+15e]
7c910732: ntdll!RtlAllocateHeap [7c900000+105d4+15e]
7c9106ab: ntdll!RtlAllocateHeap [7c900000+105d4+d7]
7c9106eb: ntdll!RtlAllocateHeap [7c900000+105d4+117]
7c910732: ntdll!RtlAllocateHeap [7c900000+105d4+15e]
7c910732: ntdll!RtlAllocateHeap [7c900000+105d4+15e]
7c9106ab: ntdll!RtlAllocateHeap [7c900000+105d4+d7]
7c9106eb: ntdll!RtlAllocateHeap [7c900000+105d4+117]
7c910732: ntdll!RtlAllocateHeap [7c900000+105d4+15e]
7c911538: ntdll!wcsncpy [7c900000+10a8f+aa9]
7c911596: ntdll!wcsncpy [7c900000+10a8f+b07]
7c9106eb: ntdll!RtlAllocateHeap [7c900000+105d4+117]
7c910833: ntdll!RtlAllocateHeap [7c900000+105d4+25f]
7c910895: ntdll!RtlImageDirectoryEntryToData [7c900000+10856+3f]
7c910833: ntdll!RtlAllocateHeap [7c900000+105d4+25f]
7c910895: ntdll!RtlImageDirectoryEntryToData [7c900000+10856+3f]
7c9037bf: ntdll!RtlConvertUlongToLargeInteger [7c900000+3745+7a]
7c90da54: ntdll!NtFreeVirtualMemory [7c900000+da48+c]
7c918331: ntdll!RtlReAllocateHeap [7c900000+179fd+934]
7c90d4ea: ntdll!NtAllocateVirtualMemory [7c900000+d4de+c]
7c9180ff: ntdll!RtlReAllocateHeap [7c900000+179fd+702]
7c911bff: ntdll!RtlInitializeCriticalSection [7c900000+11b2d+d2]
7c91825d: ntdll!RtlReAllocateHeap [7c900000+179fd+860]
0050ad37: VDResamplerSeparablePointRowStageMMX::Process()
00509f9c: VDResamplerSeparableStage::ProcessRow()
00509a6a: VDResamplerSeparableStage::ProcessPoint()
75a718a8: MSVFW32!ICSendMessage [75a70000+187d+2b]
75a74c09: MSVFW32!ICCompress [75a70000+4ba6+63]
004ae882: VideoSequenceCompressor::PackFrameInternal()
004ae536: VideoSequenceCompressor::packFrame()
75a718a8: MSVFW32!ICSendMessage [75a70000+187d+2b]
75a74c4d: MSVFW32!ICDecompress [75a70000+4c10+3d]
0047f4ea: Dubber::WriteVideoFrame()
0047ee18: Dubber::WriteVideoFrame()
0047fa63: Dubber::ThreadRun()
004df5fe: VDThread::StaticThreadStart()
005285bf: _threadstartex@4()
7c80b50b: kernel32!GetModuleFileNameA [7c800000+b357+1b4]

-- End of report

[woah!]

mencoder just got updated to support threads with XviD now to.

where would this version be as i looked around the places i have linked and havent seen it?

[celtic_druid]

http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/main/libmpcodecs/ve_xvid4.c.diff?r1=1.24&r2=1.25

[devaster]

mencoder just got updated to support threads with XviD now to.

how i activate it ? i cant find it in manual ... or i am blind ?!?

[celtic_druid]

Probably the manual you are looking at hasn't been updated yet. According to the above it is just threads=#. So -xvidencopts pass=1:threads=2

[devaster]

:thanks: ooh thanx

[DiJayy]

From what I can tell, when encoding MPEG2 transport streams (~18mbps) to XviD using avisynth and vdubmod or avs2avi, using 2 threads is actually a bit slower than 0, maybe because the decoder's doing so much work on one thread that the second xvid thread crowds it, but I don't know enough about this stuff to have a fair estimate. On 0 threads cpu usage is ~80%, one 2 threads its 100%

AMD Athlon 64 X2 3800+ using Windows XP x64

I also tried playing with the process priority but it doesn't change much, usually just makes the fps less stable and more liquid, but doesn't actually speed up anything.

[shpitz]

On 0 threads cpu usage is ~80%, one 2 threads its 100%

again, cpu usage has NOTHING to do with encoding speed.

if you want to assess if you had a speed-up or not you should only look at the TIME it took to encode...

only cause the cpu is working harder doesn't mean it is working more efficient...

[ilhyfe]

Hi,
Encoded using 2 threads.

AMD 4200+ , Avisynth 2.5.6 , VDM 1.5.10.2


First smp build:

1st pass : 56min (41,5fps)
2nd pass : 2h 36min (14,9fps)

New build:

1st pass : 50min (46,5fps)
2nd pass : 2h 17min (17fps)


I'd be interested in some more details. What kind of source? Any filters? Which destination resolution?
A friend of mine gets more than 100 fps while encoding a DVB stream to xvid (512*384) while I get max 50. He's using a X2 4400+, I a X2 3800+. Both of my cores are working @ ~90% while his are both on 100%.
We are both using koepis smp build.

so long...

[Wam7]

:thanks: for the Xvid SMP, much appreciated. Doing a quick calculation I get about a 12% improvement in 2nd pass speeds using 2 threads.

[ChronoCross]

Is there a way to get the latest cvs co to recognize that I have pthread.h? I can't build the SMP version without it. Configure says I don't have it.

Building x264 SMP works fine (doesn't search for pthread as far as I know)

btw I know this thread is quite old however it is the OFFICIAL thread and therefore compilation problems might be best suited here.

[sysKin]

Is there a way to get the latest cvs co to recognize that I have pthread.h? I can't build the SMP version without it. Configure says I don't have it.
Unfortunately all pthread logic, including makefile, was put in blindly. I don't know about others but from what I know, this was only ever tested with win32 and VC++.

Test results and patches appreciated.

[celtic_druid]

checking pthread.h usability... yes
checking pthread.h presence... yes
checking for pthread.h... yes
checking for pthread_create in -lpthread... yes
checking for pthread_join in -lpthread... yes


No problem here.

[ChronoCross]

checking pthread.h usability... yes
checking pthread.h presence... yes
checking for pthread.h... yes
checking for pthread_create in -lpthread... yes
checking for pthread_join in -lpthread... yes


No problem here.


where is pthread located for you in you mingw?

[akupenguin]

Yeah this is why I said ASP decoder. For AVC, there are at least several possibilities to either pipeline (like cabac->everything else ->deblocking) or work in parallel (deblocking itself, or decode slices in parallel if file was encoded with slices).

But ASP... yeah I suppose you can reinvent entire decoder to decode entire frames ahead (either on GOP boundary or b-frames) but that sounds weird. Within one frame, this sounds impossible.
Postprocessing can be split into slices. In fact I might do that if you say that's useful.
GOPs or b-frames would only work for certain restricted bitstreams... GOP parallelism would require a ridiculously large buffer with the standard 10 second keyframe limit, and b-frame parallelism fails with adaptive b-frames.

So I propose a different method of frame-level parallelism (which, btw, is codec-agnostic and would work in encoding too):
Decode N consecutive frames with N threads. Whenever a thread tries to decode a motion vector that points into a region of the reference frame that hasn't been decoded yet, it stalls until the thread responsible for that frame has decoded enough. If the movie has enough b-frames that only one thread at a time is in an i/p-frame, then there will be no stalls and it's just like b-frame parallelism. If not, it's slightly less efficient but still works.

Alternate plan: Use dxva/xvmc except with software emulation of the video card. (probably harder to implement, and definitely uses more bus bandwidth)

[DaForce]

Hey chaps and chapettes,

My friend finally got his Dell machine up and running, it has a Pentium D 2.8ghz.
So we wanted to do some speed comparisons between my machine (x2 4400) and his.

So using Virtualdubmod and the latest Koepi Xvid SMP build (Love your work Koepi) we set off converting a sample piece of footage.

Here are my results for the tests and the details of the file used for encoding

Virtualdubmod + xvid - 2pass
2m34s thread @ 0
2m38s thread @ 1
2m 8s thread @ 2
2m10s thread @ 3

mewig + xvid - 2pass
2m11s

Original file details:
720x576 MPEG2 25FPS
1111frames (duration 0:44s)

Now his machine did it in 1m58s at the time i didnt note what his thread was set to but it could very well have been 0 (I believe it was).
So my machine is some 25% slower than his.

Next we used mewig to convert using x264 and my machine was almost 30% quicker (which is more like what i expected in xvid as well).
NOTE: we had identical settings in both VDM and Mewig

So what were we doing wrong? does xvid (smp build) not like AMDs as much as it likes Intels.

Any suggestions or ideas would be great. I really did expect my machine to beat him considerably in xvid.

[sysKin]

I really did expect my machine to beat him considerably in xvid.
And you should, that's the slowest P-D of them all.

Very few people tested with multi-core pentiums (or at least, very few people admitted it), but their results were quite bad so far. This is what I'd expect, given P4's lack of communication between cores (like hypertransport).

Perhaps you made some silly mistake, like a different setting somewhere? Or Full Recompress in vdub?

[DaForce]

Well yeah exactly.. i expected a result the same as the x264 thru mewig... where i was 30% faster.

I have retested again today and got the same problem. Even when using mewig which uses its own xvidcore.dll i get about the same time ..about 2m10s which is slower than the P4D but about 15s

in VDM we are doing a full recompress of the MPEG2 stream to an XVID video, leaving the audio as is (direct stream copy) and not much else really. I have double check the settings many times.
Im kinda stumped. So basically 2 different programs using 2 different xvidcore.dll's produce the same miserable time for me.

I did a quick render test in 3dsmax using vray and my resulting time on a benchmark scene was as expect.. so my puter isnt running funky or anything.

Any ideas mate?

p.s. Im in Australia as well... Canberra :D

[DaForce]

hmmm i can get the encoding time down down to 1m43s (instead of 2m08s) using Virtualdub (not virtualdubmod) and using avisynth and dvd2avi to be able to load the mpeg2 into virtualdub.

Which is weird. So its 25s quicker when using the above method than when using virtualdubmod. Doesnt make much sense.

Havnt tried the above on my friends P4-D tho.

[GodofaGap]

VirtualDub does encoding and decoding in separate threads, but it could also be that the MPEG2 decoder in VDM is just slower than DGIndex.

[DaForce]

I tried using the avisynth route in VDM as well and got basically the same time.

So Virtualdub uses seperate threads and VDM doesnt?

[GodofaGap]

I know VirtualDub uses separate threads, but it could be it is introduced in the 1.16.x branch. (Of which there is no VDM version)

[DaForce]

ahh i see.
Right might stick with avisynth and virtualdub then.

Still i would expect alot faster than my friend p4-d than what im getting. x264 is much better.

ahh well.

Thanks Mate

[Zep]

ahh i see.
Right might stick with avisynth and virtualdub then.

Still i would expect alot faster than my friend p4-d than what im getting. x264 is much better.

ahh well.

Thanks Mate

Something is wrong on your box. I have the same CPU as you and I get 70+ FPS on 720x576 MPEG2 source video. You are not even reaching real time of 25FPS which is just crazy. If i shut off 1 core I get about 40 FPS. I use avisynth to feed to Vdub.

[DaForce]

Hey Zep, thanks for your reply man.

Well exactly it should be running faster in xvid. However are you converting from 720x576 to a smaller size ?
As in the test we are doing we are just converting from 720x576 mpeg2 to 720x576 XVID.

I while ago i convert some DVD vob files to a smaller xvid file and was getting about 90FPS on the final pass.

In rendering test (3D) its time is spot on with other x2 4400's so its not the box as a whole but maybe some of the codecs or something.

Would you be interesting in testing the file that we are using? Would certainly let me know if there problem is with my machine.

I just tried converting to 320x256 and it was getting over 100fps on the first pass and about 85 average on the pass.
But for the test we were not resizing the footage.

[Dreassica]

I'm seeing no speedup on using smp 1.2 version compared to old singlethreaded xvid, using same avs and settings. I do notice 2nd core having considerable less load, 28% against 96 for core 1. I have xp patched etc, so thats not it.

[foxyshadis]

Framerate's only going to be as fast as the slowest part of it. If you open a new virtualdub, load the script, and use analyse video, you'll get the maximum speed any encoder could possibly run at. To get more you'd have to change your script.

To really test xvid mt's speed, try loading a plain avi file instead of a script.

[Zep]

Hey Zep, thanks for your reply man.

Well exactly it should be running faster in xvid. However are you converting from 720x576 to a smaller size ?
As in the test we are doing we are just converting from 720x576 mpeg2 to 720x576 XVID.

I while ago i convert some DVD vob files to a smaller xvid file and was getting about 90FPS on the final pass.

In rendering test (3D) its time is spot on with other x2 4400's so its not the box as a whole but maybe some of the codecs or something.

Would you be interesting in testing the file that we are using? Would certainly let me know if there problem is with my machine.

I just tried converting to 320x256 and it was getting over 100fps on the first pass and about 85 average on the pass.
But for the test we were not resizing the footage.

makes no huge difference really. The CPU eaten via the resize is gotten back because Xvid now encodes a lot less. Basically i get about the same FPS if i do not resize or if i do to 320 x 256. The CPU usage is just in a different area. In this case avisynth more than Xvid when resizing down. Note i use multi threaded avisynth so the resize is fast compared to the avisynth most are using.

let me give you an example. I JUST encoded a HDTV show 720p to 624 x 352 and got a steady 68 FPS. Both source rez and file size i/o is much greater than DVD input. In this case if I do NOT resize down I get only about 56 FPS because Xvid has to encode a lot more and the resize for me is much faster than the Xvid settings I'm using (Max quality)


Oh BTW I use PC4000 and run it @ 267MHz and it makes a huge difference also since avisynth/vdub/xvid/encoding are mega memory read/writes etc...

[DaForce]

cool thanks for your info.. really helps.

When i last tried converting.. without resize it was about 30fps i think.. with resize down to 320x240 (or so ) it was up to 100fps.

And last night i noticed my memory settings were POV.. bloody CAS3.. (dont know why ) so they are not back to cas2 and tighter timings will try again later tonight.

Thanks again.

[shpitz]

If you open a new virtualdub, load the script, and use analyse video, you'll get the maximum speed any encoder could possibly run at.

can you explain how to do that? i don't any analyze option in the vdub menus.

Note i use multi threaded avisynth so the resize is fast compared to the avisynth most are using.

let me give you an example. I JUST encoded a HDTV show 720p to 624 x 352 and got a steady 68 FPS. Both source rez and file size i/o is much greater than DVD input.

can you point me to the avisynth version you're using?

can you post your script that you get 68fps on HD material?
which OS are you using? you use vdub or vdubmod?

thanks

[Selur]

can you explain how to do that? i don't any analyze option in the vdub menus.
File->Run video analysis pass
(using Virtual Dub 1.6.16)

[shpitz]

thanks Selur

[_xxl]

checking pthread.h usability... yes
checking pthread.h presence... yes
checking for pthread.h... yes
checking for pthread_create in -lpthread... yes
checking for pthread_join in -lpthread... yes

No problem here.
Latest xvid 20070101.I don't know why
"checking for pthread_create in -lpthread" is disabled.
:confused:
http://i11.tinypic.com/3ywgrc9.jpg

[ChronoCross]

Latest xvid 20070101.I don't know why
"checking for pthread_create in -lpthread" is disabled.
:confused:
http://i11.tinypic.com/3ywgrc9.jpg

same here

[celtic_druid]

checking pthread.h usability... yes
checking pthread.h presence... yes
checking for pthread.h... yes
checking for pthread_create in -lpthread... yes
checking for pthread_join in -lpthread... yes

Check your config.log.

[_xxl]

Can you share MinGW and Msys dir?

[Yong]

Could someone please test this?
Xvid vfw and encraw(original) compiled with pthreads support
http://www.mytempdir.com/1145230
I only have p4 presscot so i cant test it :p

@drevil_xxl:
You could try this http://sourceware.org/pthreads-win32/
Donwload the source, then
make GC-inlined
copy the libpthreadGC2.a to msys/lib
rename the libpthreadGC2.a to libpthread.a
Configure xvid again see if its work.

[celtic_druid]

I wouldn't rename since some apps still expect lpthreadGC2. Windows equiv of ln -s is just to copy it though.

My mingw dir is over 1GB.

As I said, check your config.log. If something isn't detected you can generally see why and fix it.

[_xxl]

copy the libpthreadGC2.a to msys/lib
rename the libpthreadGC2.a to libpthread.a
Configure xvid again see if its work.
Works!

I have tested xvid with AMD X2.
1).xvid 1.2-127 multithreaded:
http://i16.tinypic.com/4733s4i.jpg
Total time 2:23s

2).xvid 1.1.2 no multithread:
http://i12.tinypic.com/33m3fja.jpg
Total time 3:12s

You're seeing is the kernel's habit of tossing threads around in strange fashions. It doesn't really affect performance to execute half-and-half on two cpus instead of one.

[pixelk]

As sysKin website seems down, A firend compiled the latest 1.2.x source for me, you can get the binaires ( core + wfv ) here :
http://www.knackes.com/blog/index.php?2007/09/16/151-xvid-multithread

[Lenny_Nero]

I have said quite a few times before that like for like testing needs to have the same hard drives and data on them, I get about a 30% speed change depending on which way I send to and from my 7200 rpm drives (SATA I only) and even more if going to and from the 10k drives.

Same for a big clean empty space, and again even more speed if the cluster size is tuned to the OS cache working set size, only then can you get the full use of the CPU[s].

[MacAddict]

(snip) and again even more speed if the cluster size is tuned to the OS cache working set size, only then can you get the full use of the CPU[s].

Any guides or sites that help out on these recommendations?

[Mutant_Fruit]

The fastest way to 'improve' performance (multithreaded and singlethreaded) would be to run the reading of the data from the disk in a separate thread and buffer 1-5 frames of data in memory so that when xvid itself requires data, it's already in memory and so doesn't stall waiting for the data to be read from disk. x264 does this.

If that's already done in xvid, then ignore my suggestion. For someone competent in C, it'd probably be less than a 1 hour hack (assuming xvid does all it's reading from a specific function which can be altered and doesn't require the shotgun approach of changing dozens of areas) .

[Lenny_Nero]

Any guides or sites that help out on these recommendations?
Most of my own work is just that, I have always mucked about with Hard drive cluster sizes because it was the first things my dad used to have to setup with stuff. Hdd were a bit bigger/smaller then (10 x 12 inch platters got you 40 MB) but the data is still read on and off in the same way

I have been racking my brain for the keys in the registry I will post it in this thread ASA I remember but [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\FileSystem]
has quite a few under it, or get to the other computer with the text file with my workings. There is a sysinternal's tool (IIRC) that can sort of do the same in a very simple sort of way.

I dont use XP or Vista (spit) for windows I use NT4 and NT5 AS (win2000) and 64bit 2003.

As for link's these can go some of the way to help.
http://www-128.ibm.com/developerworks/lotus/library/ls-Rules_WinNT2000/#A%20few%20tuning%20tips
http://www-128.ibm.com/developerworks/lotus/library/ls-Rules_WinNT2000/
http://www.ntcompatible.com/thread29591-1.html
http://www.dfwsug.org/cookbook.html
http://www.teamapproach.ca/trouble/CacheSize.htm
http://www.virtualdub.org/blog/pivot/entry.php?id=71

[squid_80]

The fastest way to 'improve' performance (multithreaded and singlethreaded) would be to run the reading of the data from the disk in a separate thread and buffer 1-5 frames of data in memory so that when xvid itself requires data, it's already in memory and so doesn't stall waiting for the data to be read from disk. x264 does this.

If that's already done in xvid, then ignore my suggestion. For someone competent in C, it'd probably be less than a 1 hour hack (assuming xvid does all it's reading from a specific function which can be altered and doesn't require the shotgun approach of changing dozens of areas) .

I added it to xvid_encraw just over a month ago. Virtualdub has been doing it forever.

[HarryM]

I added it to xvid_encraw just over a month ago. Virtualdub has been doing it forever.

It's good idea! But better is "customizable -read ahead-".Using the 1st pass statistics from the 2pass encoding process (in this case you know future frame type in the encoded data - significant informations, of course).

When you set e.g. 30 frames ahead reading (input buffer = 30 frames), you can theoretically start one new internal-encoding thread, if I-frames are closer than 30 frames.
But you need output buffer (=30 frames) too, for encoded frames sorting. Minor improvement, but still improvement.

If you set input buffer=(I-frames distance), you can ALWAYS use two internal encoding threads. But you need gigant input buffer at size ~100 to 200MB for distance bigger than 250.
What is 100MB of memory, today? Nothing.:)

It is idea for three- and quad-core cpu, mainly.

[Mutant_Fruit]

When you set e.g. 30 frames ahead reading (input buffer = 30 frames), you can theoretically start one new internal-encoding thread, if I-frames are closer than 30 frames.
The benefits seem marginal at best. If the encoder wants 30 frames, it can read them in, and thereafter it will only request 1 at a time (as once it finishes with 1 frame out of that 30, it'll request one more). So there's no need for the disc buffer to retain 30 (or more) frames itself.

I hope that makes sense.

[Zach]

After reading through all seven pages, I feel I'm crashing a private party here, but I'll ask anyway. :)

I take it the only way to get and test this SMP version of xvid is to download the source and compile it one's self? (The original link is now dead, but its over a year old, so that's understable.)

[imcold]

There are CVS compiles from Celtic Druid at http://mirror.celticdruid.info/XviD/ .

[Zach]

Sure, but those aren't the multi-threaded variants, are they?

You mean v.1.1.3 on Celtic Druid's site is the multi-threaded counterpart to the "official" one (found here (http://www.xvid.org/Downloads.43.0.html))?

[foxyshadis]

Anything that says "cvs head" means the latest & greatest up-to-the-minute ("nightly") builds of the development code, which right now means 1.2.

Of course they're a few months old now, I wonder if any big fixes have been introduced in the meantime.

[pixelk]

Sure, but those aren't the multi-threaded variants, are they?

You mean v.1.1.3 on Celtic Druid's site is the multi-threaded counterpart to the "official" one (found here (http://www.xvid.org/Downloads.43.0.html))?

I compile the last CVS every few days. Get the binary here : http://www.knackes.com/blog/index.php?2007/09/16/151-xvid-multithread&link1

[foxyshadis]

Thanks for the heads up! Current builds are always appreciated.

[Zach]

I compile the last CVS every few days. Get the binary here : http://www.knackes.com/blog/index.php?2007/09/16/151-xvid-multithread&link1

Thanks!

[MacAddict]

I compile the last CVS every few days. Get the binary here : http://www.knackes.com/blog/index.php?2007/09/16/151-xvid-multithread&link1

Thanks for your builds, much appreciated. I seem to be having more frequent crashes using xvid_encraw via megui with the 10-14 build compared to the September builds. Anyone else?

[pixelk]

xvidcore_20071015 binary should work much better.

[|sawo|]

I have q6600 @ 3GHz and i got 55fps with 4 threads (mpeg2 source, 1500kbps 1 pass xvid)
The fps is pretty much the same as the regular xvid and the cpu usage is around 50%
With the same settings im able to get ~111fps using divx 6 (also i set crop,resize and deinterlace directly from the divx panel almost without fps drop!)

[Ice =A=]

The usual answer: What are "same settings"?:devil::sly::confused:

[|sawo|]

1500kbps 1pass balanced profile for divx.
Even with the Insane Quality preset activated in divx6 im still able to get around ~68fps which is far more than xvid.
Also dont forget that i have many additional options such as resize,deinterlace,crop etc activated in the divx6 panel!

[Zach]

I have q6600 @ 3GHz and i got 55fps with 4 threads (mpeg2 source, 1500kbps 1 pass xvid)
The fps is pretty much the same as the regular xvid and the cpu usage is around 50%
With the same settings im able to get ~111fps using divx 6 (also i set crop,resize and deinterlace directly from the divx panel almost without fps drop!)

But I'll wager that the final xvid file is significantly smaller than the final divx file, though, right? Have you checked? I'm curious.

I've been doing a lot of Divx vs. Xvid(MT) benchmarks over the last week, and as hard as I try to match up the profiles (so that I'm comparing apples to apples), Divx 6.7 always beats the snot out of Celtic Druid's Xvid MT build (found here (http://ffdshow.faireal.net/mirror/XviD/)) in terms of encoding speed. (Xvid's 'Threads' = 2, not 4, since I only have a dual core.)

On the other hand, the Xvid encode always produces a significantly smaller file (edit: without any loss to picture quality as far as my eyes can tell).

Well, logic dictates that this is probably why DivX performs so much faster: it's spending a lot less time compressing.

But, alas, I'm admittedly a n00b when it comes to the low-level profile settings, so maybe I'm not setting up correctly. But even when just comparing the built-in "Home Theater" to "Home Theater" profiles, DivX is faster, but Xvid produces smaller files. <shrug>

[foxyshadis]

I would certainly hope that xvid wouldn't be significantly smaller than divx if both were set to 1500kbps.

But yes, xvid's threading capability isn't as refined as divx's.

However, sawo, you need to remember not to let the avisynth be a limiting factor - use setmtmode(2) at the beginning of the script (with the latest MT avisynth), and use leakkerneldeint as your deinterlacer (fastest decent-quality avisynth deint). That might boost your xvid fps. If you are feeding it a preprocessed source vid this doesn't apply.

[|sawo|]

Zach actually the difference between divx/xvid was 100-200kb with 80mb mpeg2 source so i think the size in this case is not big deal considering the fps difference.
foxyshadis im currently using the latest virtualdub with the vfw versions of the codecs(without avisynth), because it saves time for me.When i try the MT avisynth version ill post the results

[Zach]

I would certainly hope that xvid wouldn't be significantly smaller than divx if both were set to 1500kbps.

Yes, I should clarify that all my benchmarking was with using a default "Target quantizer: 4.00" rather than a "Target bitrate (kbps)" which, I guess you are saying, is basically VBR vs. CBR, right?

I don't like the concept of hard-coding a bitrate. It just seems wasteful. :p

Alright, well, sorry to intrude. Carry on.

[JCDenton]

Hi everyone,

I'm sorry to bother you with this, supposedly stupid, question but I really don't know what to do or where else to look for advice.

First off, my system:

A64 X2
WindowsXP SP2
VDub Mod 1.5.10.1

I can't get the XviD codec (tried the "offizial" one and Koepi's 28062007 build linked at doom9.net) to use both of my cores - the funny thing is, just a couple of days ago it worked perfectly fine, CPU-load was near 100% almost every time, even when I switched the priority to "idle".
I also tried pixelk's 20071031 build, but here I only get up to 70% CPU load with 4 threads and "higher" priority.

I don't remember having changed anything, even reinstalled the codecs an VDub over and over again - does anyone have an idea what might be wrong here ?

Oh, and please pardon my clumsy English, as you've obviously figured out by now, it's not my mother tounge ;)

Regards

denton

[foxyshadis]

Official and 28062007 are both part of the 1.1 branch, which explains why those won't thread. Don't use 4 threads if you only have 2 cores, though; 2 is best and 3 is the max, may help or may hurt in different situations, but 4 will always hurt by uselessly increasing the cpu meter without improving performance.

The other half of the problem is that the input is probably slowing the whole process down now: You have to use MT avisynth if you have an even remotely complex script to get full utilization.

[JCDenton]

Stupid me, could have figured for myself that ">2 Threads@2 Cores = bad" :p
Well, thanks for your reply - sadly, I've never used avisynth and don't have any experience with scripting, so I'm just going to stick with pixelk's build, at least that way I can use the remaining CPU cycles to transcode the sound stream ...

Thanks again.

Regards

denton

[humax]

i have a Q6600 Quadcore . Do I have to use 4 Threads ??
I looked at pixel k homepage but it is in french language . There was a 4 in Number of Threads . In other threads i read that a maximum of 3 Threads has to be chosen .

Thx for Help

[Adub]

You don't "have" to use 4 threads. But it should help. Actually I think it is 6 threads for you, but don't quote me on that.

[squid_80]

Actually testing on my Q6600 shows 2 threads to be optimal. 3 or 4 may improve performance very slightly, but only if you're not doing anything with the pc; otherwise they're worse than 2.

[sysKin]

You don't "have" to use 4 threads. But it should help. Actually I think it is 6 threads for you, but don't quote me on that.

Any basis for that? I'd say 3 threads. Definitely no more threads than cores, what made you think that!

[foxyshadis]

Any basis for that? I'd say 3 threads. Definitely no more threads than cores, what made you think that!

Confusion with x264's behavior. ^.~

[ilhyfe]

Any basis for that? I'd say 3 threads. Definitely no more threads than cores, what made you think that!

I never tried that before on a quadcore but I get best speed with 3 threads. Can you explain why?

[olnima]

...and with Dual-core (E6850)? 1 or 2 threads? I tried 3, CPU-usage raises without getting more speed.

Olnima

[ilhyfe]

...and with Dual-core (E6850)? 1 or 2 threads? I tried 3, CPU-usage raises without getting more speed.

Olnima

I had best resultes with 2 threads.

[pixelk]

Somebody just asked on my blog, where can we find with the latest MT avisynth ? I would like to try to get the maximum fps from my quad-core, and if I have the time post the result of my tests.
Any advice about how I can (with the latest nightly build) get the highest fps ?

[LigH]

Using celtic-druid's "head" build (http://mirror.celticdruid.info/XviD/XviD.cvs.head.MTK.exe, 2007-07-25); on an AM2, the "Threads" edit field is disabled (grayed out) with a "2". Is this the expected behaviour? And is this still the most recent Win32 build?

@ celtic-druid: Would be nice to include the version "1.2" in the filename too. Several members of the german forum were confused about "not finding a v1.2 build", not knowing sysKin's remark:
So, here we go:
What happened: Multithreaded XviD code is now committed to CVS. From now on, all "xvid head" or "xvid 1.2.x" versions have it.

[pc_speak]

@LigH. Interesting. Had the same grayed out problem also. Remembered I had Koepi's XviD-1[1].1.3-28062007.exe installed.
Uninstalled it AND celtic-druid's. Ran a registry cleaner over the system. Reinstalled celtic-druid's XviD.cvs.head.MTK.exe.

Went into 'Configure Decoder' for a quick peek at the settings. Then went into 'Configure Encoder' to set my defaults. "Threads" edit field now enabled. Set it to 4. Quad core. :)

[LigH]

I see -- XviD is not XviD, regarding installers... Always uninstall! :D

Happy New Year!

[philippas]

:thanks:

[88keyz]

For the last little while I have been playing with compiling an XviD release based on the CVS tarballs. It has taken me a while to figure it out but I think I have it now. This release includes both the encoder and decoder and comes in an EXE installer that creates config shortcuts for both. Also included is a complete uninstaller should there be any problems. If anyone would like to test the first new XviD release of 2008 then I would be curious to know how my compile stacks up. Please uninstall any previous XviD releases from your system before installing this one. Based on the XviD 1.2 code this release fully supports SMP systems.

XviD_1.2.127-29032008.exe (http://rapidshare.com/files/103434080/XviD_1.2.127-29032008.exe)

Please keep in mind that I am not a developer and that I have only compiled the CVS release available from Xvid.org for curiosity.

:)

[pc_speak]

Installed your compile as per instructions.
Seems fine. Nothing got broken. :D

Configured encoder OK. Could set threads to 4.
Used decoder & encoder. Still OK.
Uninstall worked fine.
I'll leave it installed for a bit and let you know.

:)

[88keyz]

Thanks for the feedback. I've done some testing and everything seems to work fine for me but I'm sure others out there push the codec closer to its limits than I do.

[pc_speak]

Did about 8-10 hours on my quad core machine over the weekend. All worked just fine. Congratulations.

[88keyz]

A small update to the previous codec release. Based on the January 10th tarball code. Includes new icons and a codec info link.

XviD_1.2.127-09022008.exe (http://rapidshare.com/files/90468184/XviD_1.2.127-09022008.exe)

The older compile is still being hosted for now. Thanks to all of you that have downloaded and tried this compile.

:thanks:

[Buggle]

Maybe someone can give me directions on where to find a changelog for the newest changes in Xvid, like the nice listing of x264 found here (http://trac.videolan.org/x264/log/trunk/common). I am really interested in what kind of experimental fixes and changes are before I put it in action. I have been searching for a while now, but cannot find anything but some mailings that do not get me any further.

[Ranguvar]

*bows to 88keyz*

Here, Buggle. It's as far as I have. Note that
Xvid-1.1.2-01112006 and Xvid-1.1.3-28062007 do not include the changes in XviD-1.2.*



Xvid-1.1.3-28062007:
- {core}: Fixed possible security issue in mbcoding.c


Xvid-1.1.2-01112006:
- {core}: Fixed bug when frame-drop (N-VOP) feature is used in combination with packed B-frames
- {core}: Fixed potential crash on AMD64/EMT64 architecture.
- {core}: Fix for visual_object_verid vs. video_object_layer_verid problem.
- {core}: Ensure intervening bytes are preserved in BitstreamInit()
- {vfw}: Prevent segfault when encoding application calls compress_end with NULL codec context
- {vfw}: Profile definitions updates.


XviD-1.2.-127-25022006:
Changelog to XviD-1.1:
- {core}: New experimental SMP support.
- {core}: Trellis improvements (according to sysKin).
- On uniprocessor machines set number of threads to 0!


XviD-1.2.-127-07012006
Changelog to XviD-1.1:
- {xvidcore} Experimental SMP support (2 threads hardcoded). Patch for P- and B-frames from sysKin applied by hand.
- {xvidcore} Trellis improvements (according to sysKin).
- {xvidcore} Bumped bitstream version to 42, you never know (41 is XviD-1.1.0-final).


XviD-1.1.0 final build.
Changelog:
- {core}: Field interlaced decoding.
- {dshow}: Additional fourcc support.
- {vfw}: Small updates.


XviD-1.0.3
Changelog:
- {xvidcore} Fixed trellis optimization overflow for quant 1 & qpel modes (motion search was done twice, one in SAD mode and one in RD mode)
-Fixed MV clipping with non valid DivX 5 based sequences.
-Fixed RGB 16 bit C functions.
-Fixed posible VOL header corruption for fps=1 encodes.
-DC misprediction caused by bad value clipping (bug forwarded to the ffmpeg project too).
VFW frontend
-Fixed mismatching of hintswidgets.


1.0.0 RC4, Codenamed "Hola"
xvidcore
-GMC 1 warp point (DivX5)
-GMC 2 warp point fix
-Minor postproc code fixes
-Motion Vector clipping fix for stressing test cases.
-Problems caused by wrong cooperation of bframes and frame dropping code.
-Decoder provides quant information in stats.
VFW frontend
-Multiple instance memory leak fix.
-Improved bitrate calculator.
-Some other minor changes.
-DShow frontend
-Release packages have all needed files to build from source.


1.0.0 RC3, Codenamed "Ni Hao"
xvidcore
-Workaround for dev-api-3 decoding that causes psychedelic color effects for non modulo 16 encodes. dev-api-3 builds were mostly used by win32 users during the transition from 0.9.x series and 1.0.x.
-Buffer overflow reading in decoder (read up to bytes to far).
VFW frontend
-Bitrate calculator fixes.
-Status window fixes, GMC frames get counted too now.
-Mod4 / YV12 resolutions encoding fixed.
DShow frontend
-Updates and cleaning.


1.0.0 RC2, Codenamed "Jambo"
xvidcore:
-Decoder bugfixes (GMC+interlaced).
-Changed the DivX packed user string to version 999 so DivX decodes XviD packed bitstreams like it should have done before.
-Fixed YVYU colorspace space (was using Y as V channel)
VFW frontend:
-Added bitrate calculator.
-Output a DLL linking library when compiling with MSVC.
DShow frontend:
-Video flipping fixed.
-Added MP4V to the supported FourCCs.
-Command line driving.


1.0.0 RC1, codenamed "Niltze"
xvidcore
-Scaled zones should now work in 2pass 1&2.
-Qpel is disabled during first pass now.
-Bug in PP using MB quants badly initialized.
-Changed Win32 build type to DLL.
VFW frontend
-Changed linking policy. Links against xvidcore.dll. The vfw component is now xvidvfw.dll.
-GUI improvements.
-Added PP options as in DShow frontend.
-Added easier constant quant encoding as most of users complained though the feature was available thanks to zones.
DShow frontend
-Changed linking policy. Links against xvidcore.dll.
-Better seeking.
-Fixed colorspace usage.


1.0.0 beta3, Codenamed "Selam"
xvidcore:
-Defaulted back to VGA 1:1 PAR.
-Enabled SSE2 assembly code for IA32 platforms.
-Improved and bugfixed two pass:
-better frame size scaling.
-better defaults.
-handles up to 2TB target filesizes
-1st pass disables automatically CPU hungry features.
-Added fast ME replacement routines.
-Added Post Processing to decoder:
-Deblocking.
-FILM noise.
-Various Bugfixes.
VFW frontend:
-Added AR widget.
-Added "Turbo mode" that enables core fast ME routines.
-Removed DXN profiles from the profile list.
-New defaults.
DShow decoder frontend:
-Added PP widgets.


1.0.0 beta2, Codenamed "Ciao"
xvidcore:
-MPEG4 compliance is back (beta1 was missing the VOS header)
-matrix quantization is finally thread safe
-improved vop type decision
-2pass2 plugin: min key interval was a misleading name. It's been renamed to kfthreshold. And as the kfthresholding behavior was a bit -too aggressive, it's been disabled until we decide how it should behave w/o hurting quality
-single plugin: fixed quant capping
-interlacing artefacts fixed.
VFW fontend:
-some misuses of xvidcore were fixed
-min key frame widget renamed and moved to the 2pass panel
Debian package:
-small errors in the control file reported and fixed by Nicolas Boos


1.0.0 beta1, Codenamed "Aloha"
-New API.
-New Motion Estimation system
-with SAD based algorithms,
-or Rate Distortion optimized algorithms.
-Dynamic frame type decision based on a fast motion estimation pass
-Support for bvops and svops (up to 3 warp points).
-QuarterPel precision.
-Trellis optimization for h263 and MPEG quantization schemes.
-Special mode for cartoons/anime like futuruma/the simpsons or any anime with flat color areas.
-Mod 2 resolution support.
-Two pass algorithm is now part of xvidcore.

[Buggle]

Thanks Ranguvar, but I meant more like the changes in the nightly builds, or to the cvs, like the changes noted between the latest svns of x264.

[88keyz]

That I'm aware of the Xvid team doesn't publish info about the 1.2.x family of builds. They have only ever been available as CVS source code and there is no info on the site about changes made to the code. According to the site each night at midnight they simply upload the latest source tarball, nowhere is there any info about version until you open the tarball, where all it gives you is a date. I have never seen release notes for any of the 1.2.x family of releases other than what Koepi published on his site when he released his first compile of the 1.2.x code.

XviD-1.2.-127-25022006
Changelog to XviD-1.1:
- {core}: New experimental SMP support.
- {core}: Trellis improvements (according to sysKin).
- On uniprocessor machines set number of threads to 0!

To the best of my knowledge the major change made was that the encoder will now use multiple processors. I'm sure there have been other tweaks along the line though, sysKin might be the guy to answer this question.

[professor_desty_nova]

Go to Celtic Druid's page http://celticdruid.no-ip.com/xvid/ and choose changelog next to the XviD link. The latest that he recorded is in the last page of the forum post (but only goes to midle of 2007).

[Buggle]

A small update to the previous codec release. Based on the January 10th tarball code. Includes new icons and a codec info link.

XviD_1.2.127-10012008.exe (http://rapidshare.com/files/82784043/XviD_1.2.127-10012008.exe)

The older compile is still being hosted for now. Thanks to all of you that have downloaded and tried this compile.

:thanks:

Have encoded lots and lots of stuff with your latest build, already. Haven't run into problems on neither my dual, nor my single core. And its fast, that's really cool :D. Now I encode in second pass at almost realtime speed on my 2800+ Barton. The last time I tried Xvid that was significantly lower (a few months ago), if I recall correctly. Maybe that's just some whishful thinking ;)

Good goin'!

[Cyberace]

Any updates on SMP (multi-processor) DECODING support?

[sysKin]

Any updates on SMP (multi-processor) DECODING support?

I definitely don't plan to try. What for? I can't imagine any SMP-capable computer not decoding xvid on single thread already (unless it's an ancient dual-cpu).

And anyway, what's the point of using XviD for decoding. Other decoders exist.

[OterLabb]

A small update to the previous codec release. Based on the January 10th tarball code. Includes new icons and a codec info link.

XviD_1.2.127-10012008.exe (http://rapidshare.com/files/82784043/XviD_1.2.127-10012008.exe)

The older compile is still being hosted for now. Thanks to all of you that have downloaded and tried this compile.

:thanks:

Did a little testing on this release on my Q6600, with 5 threads (which seems to be default) vdub uses 80-90% of the total CPU, all four cores. But with 5 threads, the fps is dropping and overall encoding takes longer time.. Found out that 3 threads seemed to work best, wich seems to be like 1.1.3 Final build, concerning fps. Anyone else getting more fps on q6600 with this build?

[Ranguvar]

anyway, what's the point of using XviD for decoding. Other decoders exist.
Gah. Bad logic.

What's the point of using Xvid? Other MPEG-4 ASP encoders exist.

;)

[sysKin]

Gah. Bad logic.

What's the point of using Xvid? Other MPEG-4 ASP encoders exist.

;)

Good logic. XviD compresses better than others.
XviD decompresses identically to others.

[Ranguvar]

Good logic. XviD compresses better than others.
XviD decompresses identically to others.
Yes, but through demand and work, it could work better.

[squid_80]

Decoders must produce identical output. There are already faster decoders than xvid, so why waste time speeding up xvid's decoding to try and match them when you're going to get the same identical results?

[TripleA]

I remember back in the dawn of time when I first started using XviD that the encodes I made required insane hardware requirements such as 800MHz P3s and the like.

I suppose slightly higher requirements are to be expected with the enhancements since then (that was pre-B-frames, btw), but I don't think there is any modern CPU that couldn't decode XviD on a single core without breaking a sweat or, indeed, leaving power-saving mode. Well, maybe VIA's C3 can't. But then the C3 isn't gonna benefit from multi-core optimizations, is it?

[squid_80]

The Duron 800 in my car has no probs playing back SD clips, with only 384mb ram and gps software running at the same time.

[EuropeanMan]

^ SQUID80........please help me out man...

your xvidencraw.exe file for some reason crashes on me... :( i sent you a PM and have a thread open in this forum as well...

PLEEEEEEEEAES HELP

[squid_80]

^ How not to file a bug report.

You didn't say what the problem was, so I didn't pay attention.

[audyovydeo]

Maybe an offtopic question, but it's the only thread where I saw v 1.2 mentioned - is xvid 1.2.0 the new project as described here :

http://www.xvid.org/Xvid-Codec.2.0.html

???


cheers
audyovydeo

[Ranguvar]

No.

The Xvid 1.2.x branch has seemed to focus on SMP (multi-threading) and trellis.

[hajj_3]

so how much faster is the latest 1.2 build on a dual or quad core core2duo than 1.13?

ive got a core2duo overclocked to 3.6ghz and will be getting a 45nm quad core in 2months.

also any plans to add sse4 support? divx 6.7 is 60% or something faster with sse4 capable cpus.

thanks!

[clsid]

divx 6.7 is 60% or something faster with sse4 capable cpus.That is not correct. IT IS A MARKETING STUNT.

They added 1 specific routine to DivX that performs really well with SSE4. However, that particular routine is pretty much useless in real life. So DivX encoding does not really benefit from SSE4.

[hajj_3]

That is not correct. IT IS A MARKETING STUNT.

They added 1 specific routine to DivX that performs really well with SSE4. However, that particular routine is pretty much useless in real life. So DivX encoding does not really benefit from SSE4.

i've seen reviews of 45nm quad penryn cpu's encoding movies to divx 6.7 on anandtech site and its literally about 60% faster. independant review, nothing to do with the divx company.

[Ranguvar]

i've seen reviews of 45nm quad penryn cpu's encoding movies to divx 6.7 on anandtech site and its literally about 60% faster. independant review, nothing to do with the divx company.
Link?

[Ranguvar]

so how much faster is the latest 1.2 build on a dual or quad core core2duo than 1.13?

ive got a core2duo overclocked to 3.6ghz and will be getting a 45nm quad core in 2months.

also any plans to add sse4 support? divx 6.7 is 60% or something faster with sse4 capable cpus.

thanks!
For the first, try and see. There's a very new build posted just a little bit ago.

For the second, I doubt it. It's been asked of x264 a lot, and they basically said their own software routines were faster than using SSE4. So I presume it's pretty much the same with Xvid.

[sysKin]

SSE4 only makes things faster if you use very inefficient algorithm to begin with. Basically what you need is a full search, which is pointless and horribly slow. Then, this full search can be made 60% faster.

This is pretty much what DivX did, they invented particular algorithm for the purpose of using SSE4 with it.

[Mgz]

Link?

http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3195&p=4

[clsid]

I have more trust in the expertise of sysKin, Manao, and akupenguin.

http://forum.doom9.org/showthread.php?t=133567&highlight=divx+sse4
http://forum.doom9.org/showthread.php?t=124881&highlight=divx+sse4

[lazik]

Divx in one test is slower n*times then Xvid.
Try to capture DV source with real-time compression. Yes I know is tricky test, but there is no DV capture tool that can use Divx codec. ;)

[foxyshadis]

SSE4 optimizations only work with DivX set to Insane. That's exactly what anandtech did. If you just use any of the slow speeds (let alone fast), you'll see no boost from sse4.

[cmw]

Erm, sorry if this has been answered prior in this thread, as I'm not done reading trhough, but this seems very strange to me. I use the batch semi-automatic script to encode with xvid, have the xvid built from a few days back (posted prior in this thread) installed and use the neweset xvid_encraw from squid80. I have an Intel Core 2 Duo E6600, Windows XP SP2 32bit.

Commandline input:

start "TGHQ-30 - Pass 1/2" /b /wait /normal "C:\autok2\bin\xvid_encraw.exe" -zon
es 0,q,3,KO -threads 2 -progress 100 -max_key_interval 300 -packed -quality 5 -v
hqmode 1 -max_bframes 2 -bquant_ratio 162 -bquant_offset 0 -qtype 1 -qmatrix "C:
\autok2\matrix\eqm_v3ulr_rev3.xcm" -nochromame -turbo -lumimasking -bitrate 1373
-pass1 "C:\Temp\dvd\tmp\extrem.pass" -type 2 -i "C:\Temp\dvd\extrem.avs"

As you can see, it specifies threads=2

Subsequent encoding:


xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003


Trying to retrieve width and height from input header
xvid [info]: Avisynth detected
xvid [info]: Input colorspace is YV12
xvid [info]: Input is 640 x 352, 29.970fps (30000/1001), starting from frame 0
xvid [info]: Number of frames to encode: 214758, Bitrate = 1373kbps
xvid [info]: xvidcore build version: xvid-1.2.0-dev
xvid [info]: Bitstream version: 1.2.-127
xvid [info]: Detected CPU flags: ASM MMX MMXEXT SSE SSE2 TSC
xvid [info]: Detected cpus = 2, threads requested = 1, threads in use = 1
xvid [info]: Threaded input reading active

Only 1 thread requested? Only 1 thread used? Umm... help pls :)
Does it have something to do with the threaded input reading active? What does that mean? oO

Edit: I've just installed the MT version of avisynth. Encoding speed went up considerably, however, xvid still displays that only 1 thread is used :/

Edit2: I just tried and used an older version of xvid_encraw, and it says cpu's used = 2 there. The line about threaded input reading ist missing there though, so I guess it has something to do with that. Encoding speed is pretty much the same on both versions though.

[squid_80]

1 thread for encoding + threaded input = 2 threads. If you want to try forcing 2 encoding threads use -nothreadedinput or -threads 3, but you'll probably lose speed.

[88keyz]

As a little birthday present to myself I decided to compile a new tarball.

XviD_1.2.127-29032008.exe (http://rapidshare.com/files/103434080/XviD_1.2.127-29032008.exe)

Enjoy.

[clsid]

I hope you know that the tarball is generated automatically, and not just whenever something has changed. Judging from the file dates inside the tarball, nothing has changed since your previous build.

[88keyz]

No, I didn't know that. But to be honest I don't really care either, it was just fun to release a compile on my birthday. Its not like its a lot of work, probably took less than 5 minutes to do so I'm not worried about any time I may have wasted.

:rolleyes:

[audyovydeo]

sorry guys which is the official link for the 1.2.x branch tarballs ?
I couldn't trace it through xvid.org ...


thanks
audyovydeo

[clsid]

It's right there in the download section:
http://downloads.xvid.org/downloads/xvid_latest.tar.gz

[totya]

As a little birthday present to myself I decided to compile a new tarball. This one is based on the February 9th release, just like me!

XviD_1.2.127-09022008.exe (http://rapidshare.com/files/90468184/XviD_1.2.127-09022008.exe)

Enjoy.

Thanks!

My problem with xvid (all version) : preset manager is unusable. Only 1 (one!) user preset available. This is impossible. Different preset required for tv capture, avi recompress etc... :(

[olnima]

As a workaround: Import/export your setting via regedit.
The xvid-settings are stored into the registry under

HKEY_CURRENT_USER\Software\GNU\XviD

Using this way, You can create your own profiles and reimport them before using xvid.

If You use VirtualDub for capturing/postprocessing there is another way called "V2CRS".

http://v2crs.sourceforge.net/

Here is a little program included called VDubProfileCreator to do the same as described above but with a GUI.

Hope that helps,
Olnima

[totya]

As a workaround: Import/export your setting via regedit.
The xvid-settings are stored into the registry under

HKEY_CURRENT_USER\Software\GNU\XviD

Using this way, You can create your own profiles and reimport them before using xvid.

Thank you, this works!


If You use VirtualDub for capturing/postprocessing there is another way called "V2CRS".

I'm use ex this: VirtualVCR, this is supported too :)

[DivXko]

I download the last stable Xvid 1.13 - http://downloads.xvid.org/downloads/xvidcore-1.1.3.zip

but i don't know how to install it
can sameone help me??

[_xxl]

That is the source code.You have to compile it using MinGW GCC, or just download bin from:
http://rapidshare.com/files/90468184/XviD_1.2.127-09022008.exe
or just search on doom9 forum.

[Buggle]

I download the last stable Xvid 1.13 - http://downloads.xvid.org/downloads/xvidcore-1.1.3.zip

but i don't know how to install it
can sameone help me??

If you just want a stable release go to koepi.org, if you have a multicore search the latest post in this thread for a link to a 1.2 build.

But if you have to ask this question you might want to start by reading some of the guides on the main Doom9 site.

[clsid]

Koepi's site no longer exists.

[Prettz]

This is pretty much what DivX did, they invented particular algorithm for the purpose of using SSE4 with it.
Well to be fair, that's what you're supposed to do when you rewrite an algorithm to take advantage of the latest instruction set extensions. How else are you supposed to take advantage of new SIMD extensions of the instruction set other than a gigantic rewrite using an algorithm that's only awesome because of the new SIMD instructions?

Not that I could ever believe a DXN encoder is better than Xvid, since it hasn't ever been since I freaking joined Doom9.

I only expected that DXN would quickly produce a build optimized for the latest SSE extensions, since they make a profit from their codec (well, I assume) and therefore have the resources to have their devs produce this. And I don't have to have any experience in writing video encoding software (although I'd like to!) to know that producing a highly-optimized binary using a new SIMD algorithm from an already highly-optimized C/C++ algorithm is no fun at all. I've already got plenty of experience writing MMX/SSE code to know how difficult it can sometimes be to convert algorithms to different methodologies.

[squid_80]

Well to be fair, that's what you're supposed to do when you rewrite an algorithm to take advantage of the latest instruction set extensions. How else are you supposed to take advantage of new SIMD extensions of the instruction set other than a gigantic rewrite using an algorithm that's only awesome because of the new SIMD instructions?

No no no. They wrote a NEW algorithm (not a rewrite). When used without SSE4 it was very slow. When used with SSE4 it was much faster. However the EXISTING algorithm is already just as fast.

[olnima]

...VirtualVCR, this is supported too :)


Yes, but VDubProfileCreator is useless in that case (any reason not to use newest VirtualDub for capturing?). Btw., as the name of this tool says, it does NOT the same as creating/importing xvid-profiles via regedit, it does the same for VirtualDub but I guess You already have noticed that :). If You want, changing the code from VDubProfileCreator to use this explicit for xvid shouldn't be too difficult (but on the other hand wouldn't give You big advantages)

Olnima

[DivXko]

I found Kopei Xvid 1.1.3 final - http://www.free-codecs.com/download/Koepi_XviD.htm

[totya]

Thanks, but VirtualVCR much better than VirtualDub.

Yes, but VDubProfileCreator is useless in that case (any reason not to use newest VirtualDub for capturing?). Btw., as the name of this tool says, it does NOT the same as creating/importing xvid-profiles via regedit, it does the same for VirtualDub but I guess You already have noticed that :). If You want, changing the code from VDubProfileCreator to use this explicit for xvid shouldn't be too difficult (but on the other hand wouldn't give You big advantages)

Olnima

[Ranguvar]

Thanks, but VirtualVCR much better than VirtualDub.
"Better", along with "best" is not a good term to describe something. (rules) Either narrow down what it is "better" in, and say why, or don't use it, please.

[totya]

"Better", along with "best" is not a good term to describe something. (rules) Either narrow down what it is "better" in, and say why, or don't use it, please.

Hi, if u like virtualdub then use this. I cant write long detailed answer, because my english is terrible. But true, virtualvcr not only "better", but really best capture application - for me. Thats all.

[Ranguvar]

Hi, if u like virtualdub then use this. I cant write long detailed answer, because my english is terrible. But true, virtualvcr not only "better", but really best capture application - for me. Thats all.What I'm saying is, regardless of each's ability, the terms "better" and "best" are general terms that should not be used. Check the Rules.

[olnima]

Better or not..., developement of VVCR stopped years ago and VirtualDub is going on and on...

Olnima

[totya]

Better or not..., developement of VVCR stopped years ago and VirtualDub is going on and on...

Olnima

Many old software better than new. My english is bad, but i wrote programs (yes I can) i know. VirtualDub/Mod is excellent, great, and free(!) application, i like it, but capture function not for me. I think this is offtopic...

but ontopic: latest beta xvid works for me (i dl from here). 1 core and 2 core mode works correctly. But under capture, two core mode is unusable. If CPU usage higher than 50% with two core mode (2 cpu usage), I get dropped frame with any capture applications. I dont know why.

Sorry my english.

[olnima]

strange. I use xvid 1.2 (2 cores/2 threads) for capturing without any problems.

Onima

P.S.:

<
but capture function not for me.
>

did You ever try to post your problems in VirtualDub-forum?

[totya]

strange. I use xvid 1.2 (2 cores/2 threads) for capturing without any problems.

did You ever try to post your problems in VirtualDub-forum?

This is not my problem... VDub is tipically poor capture apps, because very sensitive, if i do anything (ex i see taskmanager) under capture, i get frame drop/insert...

[Ranguvar]

That's why he asked whether you had brought this up before. VDub may be capable of better capturing, perhaps something odd was enabled on your system.

I don't know much in this field; my cap card only works with proprietary if one wants to use the hardware MPEG-2 encoder, which I do.

[olnima]

This is not my problem... VDub is tipically poor capture apps, because very sensitive, if i do anything (ex i see taskmanager) under capture, i get frame drop/insert...

VDub isn't more or less "sensitive" then any other capture Software. Dropping/inserting frames depends on CPU-comsumption during capture and/or on your timing-settings. You can set up VirtualDub in a way that your dropping/inserting frame-counter is allways 0. BUT maybe sometimes it needs more then 10 min. to set up everything the right way. And that seems to be your problem. I really do not want You to switch to VirtualDub (and also I don't get money for this :-) ) but please, do not post such a nonsense here.

Olnima

P.S.: This has gone a little bit OT, sorry.

[totya]

but please, do not post such a nonsense

Please dont write me, if u stupid, thx.

Edit:
1. Sorry my poor english. "nonsense post" i think equal with "ur stupid".
2. Dropped frame DEPEND on application quality. If u dont know this - not my problem.

[totya]

That's why he asked whether you had brought this up before. VDub may be capable of better capturing, perhaps something odd was enabled on your system.

I don't know much in this field; my cap card only works with proprietary if one wants to use the hardware MPEG-2 encoder, which I do.

Thx, but my dvd player is divx/xvid capable, not need for me mpeg2 output. Mpeg4 result is smaller file. VDub is not my problem, anyone say this app. Thx.

[Ranguvar]

totya, the second thing I posted had nothing to do with you, just random chatter.

And I was explaining what he said...

[CaMoTblku_OnToM]

Hi! Plz help
i cant use 100% CPU load for compression, CPU usage when i compress video in virtualdub about 73-77% with normal or even higher priority :(

XviD_1.2.127-09022008
VirtualDub 1.7.8
threads was set 2
Pentium E2160 4Gb Windows XP SP2 x86 + all updates

[Buggle]

Hi! Plz help
i cant use 100% CPU load for compression, CPU usage when i compress video in virtualdub about 73-77% with normal or even higher priority :(

XviD_1.2.127-09022008
VirtualDub 1.7.8
threads was set 2
Pentium E2160 4Gb Windows XP SP2 x86 + all updates

Then try to set the amount of threads to 3, that will max your CPU usage to 100%. The problem is, however, that this will not higher (even lower) your encoding spead, according to some.

I personally have not yet tested the difference, and I do not really care that much, since I let it encode overnight or when I am at work. Having it at a slightly lower usage means less power consumed.

[Ranguvar]

And if you are using AviSynth input, multithread that. (MT)

[CaMoTblku_OnToM]

Then try to set the amount of threads to 3, that will max your CPU usage to 100%.
set threads to 3 don't solve the problem :(

[totya]

set threads to 3 don't solve the problem :(

if you uses avs script with filters, or you uses virtualdub with built-in filter, this is normal...see msg from Ranguvar, but MT is compicated (need manual switch MT level depend on used filter).

[CaMoTblku_OnToM]

if you uses avs script with filters, or you uses virtualdub with built-in filteri don't use avisynth and i tested without built-in filters in virtual dub, in fast recompress mode with no audio, result is the same :(
also i tested x264-vfw which works right and loads CPU 100% with or without built-in filters in virtual dub

[totya]

Hi! Plz help
i cant use 100% CPU load for compression, CPU usage when i compress video in virtualdub about 73-77% with normal or even higher priority :(

Sorry, i dont read exactly your problem :) 73-77% CPU usage is good. Me too 70-90%. CPU usage is higher if (xvid) compression quality is higher, or/and you use avs input (with vdub). 100% CPU usage is very hard on more cpu, ask programmers.

[Buggle]

set threads to 3 don't solve the problem :(

Strange. Maybe check the power options of your comp? Once I had my laptop set to max 50% usage or something like that and it wasn't exactly that fast... Come to think of it, it might also be a problem of warmth, it might be a problem of input buffer, might be something else I cannot think of :P. Have you looked in the taskmanager if there is a clear difference between cores?

[clsid]

Maybe harddrive access (reading/writing) is the bottleneck.

[SoRiX]

:thanks::thanks::thanks::thanks::thanks::thanks::thanks::thanks::thanks:

Hi,

Thanks for this release, it works fine for me with AutoGK, StaxRip any VirtualDub and it is much faster than the "SingleCore variant" 1.1.3 and again --> :thanks:

I dont recognize any quality or compatibility differences to the release from ww.xvid.org


thx from Germany :)

[KML]

http://img101.imageshack.us/img101/2594/adszwd1.png

Hi friends My processor is "PentiumD 3.00 GHZ"
And you see my xvid settings i can't chance "number of threads"..
Can i use multithreading or not?

[Ranguvar]

Do you have a multithreaded Xvid? v1.2.x SMP?

[KML]

i have this one
http://www.free-codecs.com/Koepi_XviD_download.htm
(1.1.3 Final)

[Zarxrax]

Out of curiosity, what keeps xvid 1.2.x from replacing 1.1.3 as a stable release? Are there any problems with it?

[Lenny_Nero]

i have this one (1.1.3 Final)
That is the single thread version try Xvid? v1.2.x SMP as said.

...and as to
what keeps xvid 1.2.x from replacing 1.1.3 as a stable release? Are there any problems with it?
Its not the same branch as I understand it, so it cant replace 1.1.3, but I have not found anything to cause problems, in fact the Jan 2008 version I am using is pushing out some very good encodes at around 10 to 20 per night.

If you have multi chip/core use it.

To CaMoTblku_OnToM
I have found that the hard drives make a big deal on the CPU load, so much so I can go from 60~70% when working on 80+% full drives to 97.3% when using 10% full de-fragged drives and even better when out to my arrays.

[hajj_3]

mirror for: XviD_1.2.127-29032008

http://www.sendspace.com/file/flcbir

[devil-strike]

I have a question, i have downloaded the latest smp 1.2 from 3apr 2008, and i have a quadcore amd 9600 2,3Ghz @ 2,6Ghz but if i use 0 Threads than it is faster than 4 threads, is this a bug or do i something wrong.

ps, sorry for bad english.

[Ranguvar]

0 is automatic, and it tends to use more threads than you have cores in order to get the most performance. So no, not a bug.

Try manual values higher than 4 though... on my Q6600, 6 gets better performance than both 0 and 4. Any higher and speed decreases.

[devil-strike]

0 is automatic, and it tends to use more threads than you have cores in order to get the most performance. So no, not a bug.

Try manual values higher than 4 though... on my Q6600, 6 gets better performance than both 0 and 4. Any higher and speed decreases.

Thnx 3 is the best number for me both passes 90a100fps whene the first 0/1/4 will gif me slower fps rate on second pass from 60 to 85fps.

[Buggle]

Thnx 3 is the best number for me both passes 90a100fps whene the first 0/1/4 will gif me slower fps rate on second pass from 60 to 85fps.

Then another question: where did you get the april build?

[Hogan77]

Then another question: where did you get the april build?Try here: http://www.koepi.info/

[Buggle]

Try here: http://www.koepi.info/

Yeah, I know that, but that one's based on old code with a VAQ patch, if I understand correctly. There must have been some work done in the meantime, implying that the latest build posted in this thread is more recent than his, even though it's been stamped april. Or am I not understanding Koepi correctly and did he use the latest codebase for that build?

[Lenny_Nero]

Yep, when I looked into it the code seemed to be from some early 2006 CVS.

It would be nice to find an easy way to get the later builds, I dont have a box set up to do any M$ builds ATM, but I do want to try out the VAQ patch.

[kandrey89]

Could someone make the latest v1.2 build with VAQ patch? As I understand it, Koepi's build is 2 years old.
Thanks

[Ranguvar]

There have been VERY few changes since then... but there are builds in this thread. Look back a little.

[clsid]

Yep, last time I checked the last source code modification dated back to september 2007.

[kandrey89]

There have been VERY few changes since then... but there are builds in this thread. Look back a little.

I see other builds in this thread :helpful: , I'm not blind, but are they with VAQ??????????????
If so which one? :mad:

[LordIntruder]

Koepi included VAQ some months ago in both the official branch (1.1.3) and unofficial SMP one (1.2.127):

http://www.koepi.info/

[kandrey89]

But is v1.2.127 recent or 2 years old?
Thanks

[LordIntruder]

But is v1.2.127 recent or 2 years old?

We are in the multithreaded XviD thread. I guess you want to encode with that version of XviD because you have a multicore, right? So use the 1.2.127. Recent or not, this is the only version that is multithreaded. ;) I'm afraid you have no choice. :)

The 1.2.127 has VAQ and this function is a new improvement introduce in February 2008 by Dark Shikari, so I guess it is recent enough isn't it? ;)

Now 1.2.127 is maybe 2 years old, I didn't count, but no one except Dark Shikari recently has been working on it. It is free stuff and if no one has time or will to work on XviD, it stays as it is. ;) But don't worry, 2 years old didn't mean your encodes will be bad, XviD rocks and my best advice would be to make an encode with XviD and the same one using DivX and compare both and I'm sure you'll love the 2 years old 1.2.127 :D

[kandrey89]

We are in the multithreaded XviD thread. I guess you want to encode with that version of XviD because you have a multicore, right? So use the 1.2.127. Recent or not, this is the only version that is multithreaded. ;) I'm afraid you have no choice. :)

The 1.2.127 has VAQ and this function is a new improvement introduce in February 2008 by Dark Shikari, so I guess it is recent enough isn't it? ;)

Now 1.2.127 is maybe 2 years old, I didn't count, but no one except Dark Shikari recently has been working on it. It is free stuff and if no one has time or will to work on XviD, it stays as it is. ;) But don't worry, 2 years old didn't mean your encodes will be bad, XviD rocks and my best advice would be to make an encode with XviD and the same one using DivX and compare both and I'm sure you'll love the 2 years old 1.2.127 :D

Rofl :eek:
Just that I thought the 2 year old version had been outdated by a complete routine rewrite of the multicore processing in XviD, and as for v1.2.127 having VAQ and old or not, I would say that the compiler took old code and embeded VAQ in it, doesn't mean it's recent code if it has VAQ.

[Ranguvar]

I see other builds in this thread :helpful: , I'm not blind, but are they with VAQ??????????????
If so which one? :mad:
Check and see if they say they're with VAQ. If they don't say so, they're most likely not. In which case it's extremely simple to patch with VAQ yourself.

Read the very first post here: http://forum.doom9.org/showthread.php?t=135093

[drunken_clam]

Hi does anybody know if xvid multithreading through ffmpeg is possible yet?

I tried with "-threads n" but can't get any performance enhancements.

[Widok]

Till now, the optimal way to use Q6600 for coding in XviD requires installation:
XviD-1.2.-127-VAQ http://koepi.leffe.dnsalias.com/
+
MT (MultiThreading in avisynth) v0.7 http://www.avisynth.org/tsp/MT_07.zip

Or there is the best decision?

[DeathTheSheep]

How to compile XviD with mingw? There's no ./configure script in xvidcore/build/generic/ !!

sh: ./configure: No such file or directory
Anyone?

[Kurtnoise]

./bootstrap.sh first...

[DeathTheSheep]

Ok...
$ ./bootstrap.sh
ERROR: 'autoconf' not found

;)

[Kurtnoise]

well...https://sourceforge.net/project/showfiles.php?group_id=2435&package_id=67879&release_id=540763

[DeathTheSheep]

Oh great, now I have to install perl too. XD Are you sure the process is so ridiculously long-winded? Doesn't somebody have an old configure script they can upload for me?

[SledgeHammer_999]

Oh great, now I have to install perl too. XD Are you sure the process is so ridiculously long-winded? Doesn't somebody have an old configure script they can upload for me?

No just download and install "autoconf".

Or if you have linux installed just run the "./bootstrap.sh" command from linux and then switch to Windows.

[Kurtnoise]

Oh great, now I have to install perl too. XD Are you sure the process is so ridiculously long-winded?
there is a MsysDTK package providing all this stuff, available here (http://downloads.sourceforge.net/mingw/msysDTK-1.0.1.exe?use_mirror=)...

[DeathTheSheep]

Thanks everyone! I did end up taking sh999's advice (Linux to the rescue) and build in windows. But to be sure I'm grabbing kn13's MsysDTK which I just saw. :)

PS: To everybody who's interested, there has definitely been some improvement since the latest "CVS build" from Koepi, especially in keyframes (gradient blocking)...

It's unlikely the B-frames flickering will ever be fixed, seeing how all the developers abandoned their brainchild. There was such a nice "Possible improvements beyond 1.1" thread right here on Doom9 too. :(

[ChronoCross]

Thanks everyone! I did end up taking sh999's advice (Linux to the rescue) and build in windows. But to be sure I'm grabbing kn13's MsysDTK which I just saw. :)

PS: To everybody who's interested, there has definitely been some improvement since the latest "CVS build" from Koepi, especially in keyframes (gradient blocking)...

It's unlikely the B-frames flickering will ever be fixed, seeing how all the developers abandoned their brainchild. There was such a nice "Possible improvements beyond 1.1" thread right here on Doom9 too. :(

because h264 far surpasses any gains that could possibly be made by xvid. Better to focus time and effort for something worthwhile rather than sticking to something that has passed it's peak usefulness.

[DeathTheSheep]

Past its usefulness? That's not for you to say, my friend. :) What's no longer useful for the video archival enthusiast (such as yourself, perhaps?) may still be quite so for many other individuals who wish to glean benefits of decoding speed, HW/device compatibility, and so on. I do very much appreciate h264; however, I don't at all believe in giving up on something that still does in fact see much use. But now we're getting a bit off-topic, are we not?

[ChronoCross]

Past its usefulness? That's not for you to say, my friend. :) What's no longer useful for the video archival enthusiast (such as yourself, perhaps?) may still be quite so for many other individuals who wish to glean benefits of decoding speed, HW/device compatibility, and so on. I do very much appreciate h264; however, I don't at all believe in giving up on something that still does in fact see much use. But now we're getting a bit off-topic, are we not?

Considering there are more and more H264 capable devices everyday I think the HW/Device capability point doesn't really work.

Decoding speed is also becoming more and more of a distant thing as CoreAVC make 1080 work on even my older Single core machine. Even FFDSHOW is making leaps and bounds in the speed department.

The Quality tradeoff between the two can often be quite drastic and even if I did things other than "Archiving" I would more than likely use H264 as there is plenty of support for streaming as Dark Shikari has often done with his web based touhou encodes. Even youtube is moving in the H264 direction (while still horribly done) and I've seen a few of the youtube clone scripts adding x264 encoding functionality.

Even DIVX is moving in the h264 direction.

[IgorC]

A bit offtopic.
I think that industry pushes H.264 as a new standard. That's why all forces should be concentrated on it.
While old ASP will be improved people will still use it. Look what happens with MP3. There is already better codec like AAC. But while there will be improvements for MP3 encoders (even little ones) markets will stay with it. LC-AAC is more efficient in terms of quality and decode speed is very light. It's valid to compare Xvid vs x264 as LC-AAC vs MP3.

[alexins]

xvid 1.2-127.08.11.15-VAQ x86 (http://www.xvidvideo.ru/content/view/394/1/)

Initial SSE4 support; Noexecstack patch; NASM 2.x compatibility

[DeathTheSheep]

Interesting... so Xvid is still seeing improvement from the Russian developers' community? :) Or is this simply a new CVS compile?

[LoRd_MuldeR]

What exactly is "Initial SSE4 support", is it SSE4 Exhaustive Search ???

[MasterNobody]

What exactly is "Initial SSE4 support", is it SSE4 Exhaustive Search ???
After looking in http://cvs.xvid.org/cvs/viewvc.cgi/xvidcore/src/ it seems that "Initial SSE4 support" means only detection of SSE4 (without any use of it).

[LoRd_MuldeR]

After looking in http://cvs.xvid.org/cvs/viewvc.cgi/xvidcore/src/ it seems that "Initial SSE4 support" means only detection of SSE4 (without any use of it).

lol :D

[hajj_3]

so this wont give any speed boost over the older build of xvid 1.2?

[LoRd_MuldeR]

so this wont give any speed boost over the older build of xvid 1.2?

Definitely not. Maybe you see a message on the log that says SSE4 was detected on your machine, but that's it. (Unless MasterNobody missed something)

[olnima]

But - to think a bit more positive - isn't this "step 1" for coding routines boosting the speed?

Olnima

[LoRd_MuldeR]

But - to think a bit more positive - isn't this "step 1" for coding routines boosting the speed?

Olnima

Yes. But SSE4 is not that "magic" speed-boost for video encoding :rolleyes:

The "SSE4 Exhaustive Search" is in fact slower than the SSE2-based Exhaustive Search as implemented in x264 :p
There are some more operations in SSE4 that may be helpful, but "one has to be rather creative with it" and it's not available on Penryn.

So I wouldn't expect too much. Especially because Xvid doesn't have any active developers atm. But we'll see...

[Dark Shikari]

So I wouldn't expect too much. Especially because Xvid doesn't have any active developers atm. But we'll see...And there's far more important things to implement if you want to boost Xvid speed (SSSE3 quant, faster bitstream writer, cacheline SAD, etc...)

[clsid]

There haven't been any significant changes to the Xvid code in the past two years. So it would be kind of surprising if new optimized code is going to be added now.

[Lenny_Nero]

Considering there are more and more H264 capable devices everyday I think the HW/Device capability point doesn't really work.

Decoding speed is also becoming more and more of a distant thing as CoreAVC make 1080 work on even my older Single core machine. Even FFDSHOW is making leaps and bounds in the speed department.

The Quality tradeoff between the two can often be quite drastic and even if I did things other than "Archiving" I would more than likely use H264 as there is plenty of support for streaming as Dark Shikari has often done with his web based touhou encodes. Even youtube is moving in the H264 direction (while still horribly done) and I've seen a few of the youtube clone scripts adding x264 encoding functionality.

Even DIVX is moving in the h264 direction.
I see £20~50 Xvid enabled DVD players in almost every shop I look, I have yet to see any H264 enabled players on the high street, and online they are 10x the price.

That aside I still cant see the quality that I hear about, my hope is that all of the H264 encodes I have seen and or been given have not been done very well, but that just says that its too hard to get a good H264 encode, where as its a piece of cake to get a quality Xvid encode from a noob with something like AGK, and I can get very good results via StaxRip that can be put up against the original, give the template to someone and they can go from a off air mpeg capture to a quality Xvid that they can sit down in front of a big TV and watch in a few hours.

Or wait for 10~20 hours for an H264 encode and sit at the computer and watch, as for youtube, do people really watch that crap ?

[Dark Shikari]

I see £20~50 Xvid enabled DVD players in almost every shop I look, I have yet to see any H264 enabled players on the high street, and online they are 10x the price. That's because the H.264 players are HD and the Xvid ones aren't: there's no incentive to release new SD boxes anymore, so all the new ones are HD (and therefore more expensive). But the Popcorn hour is only $180; that's certainly not "10 times the price" (more like 2) and it plays 6 times the resolution (1080p).its too hard to get a good H264 encodeIf someone is really too dumb to use a one-click GUI to encode their videos, they really don't deserve to use a computer... it isn't as if everyone is forced to use something overcomplicated like MeGUI.where as its a piece of cake to get a quality Xvid encode from a noob with something like AGKSure, its just that your Xvid encode will have to be about half the size of the DVD to be good quality. Don't tell me you don't care about size: if you didn't, you wouldn't be re-encoding the file to begin with.

And don't tell me about 700MB DVD rips: seriously, they look awful unless you're completely blind. Even the 2xCD ones are an insult to the movie.Or wait for 10~20 hours for an H264 encode and sit at the computer and watch, as for youtube, do people really watch that crap ?x264 is only slower than Xvid if you want it to be.

[kinematic]

And don't tell me about 700MB DVD rips: seriously, they look awful unless you're completely blind. Even the 2xCD ones are an insult to the movie

The funny thing is that everybody on torrent sites think 2 cd scene rips are the dogs kahuna's even with all the fucked up downsizing the scene does. Apparently the number of bits per pixel is the only determining quality factor if you believe the scene. A prime example of the so called scene quality is the Indian Jones 4 rip by group DiAMOND, it's incredible how blurred the picture is and everybody still thinks it's great quality.

(FYI, I don't torrent, I saw that rip at a friends house along with some others)

[LoRd_MuldeR]

Who cares if some self-proclaimed "scene" groups produce crappy rips, as long as we know how to do it properly for our own legal encodes? :p

[TripleA]

If you've never seen what the original DVD, let alone HD, movie looks like, I am sure that a low-bitrate PoS will look good to you. Hence, the "scene" rules. Not applicable for most people here, that. Any for whom it is applicable will be keeping very quite about it, I am sure :D.

That said, I still use XviD exclusively for my own work. Mainly because of lack of h.264-capable standalone players in the immediate vicinity. I have no problems with using very high bitrates for what I need.

[Lenny_Nero]

Just on the single cost of Popcorn hour, over here £199 to £250, as I said I can go into many shops and get a good Xvid enabled player for £18~20 ...I will let you work that out, also I have yet to see anything like that in the hi street. £30~£50 gets you up scaling to 1080i/p.

I dont care about "scene" group rels and torrent sites, as I said I am doing this with my captures of DVB-TV and HD off the air, I dont encode to a set size, I have never seen the point I have my templates and they use as much as they need, but its rare for a 40~50 min SD prog to need more than 3-400 MB, unless its all moving outdoor stuff, its often hard to tell them from the raw mpegs. I have never had to encode a file to half a DVD size, what would be the point 600~1500 MB is often more than enuff, unless its a 3 hour film.

I have yet to do much with H264, as I said I base on stuff I get given, and so far I have been able to do Xvid encodes that look better in the same file size.

[Dark Shikari]

Just on the single cost of Popcorn hour, over here £199 to £250Then how about this (http://www.newegg.com/Product/Product.aspx?Item=N82E16822136325)?

Not my fault if your country's prices can't drop to sane levels... :p

[akiza]

And there's far more important things to implement if you want to boost Xvid speed (SSSE3 quant, faster bitstream writer, cacheline SAD, etc...)

That's all we pray for..... :)

[LoRd_MuldeR]

That's all we pray for..... :)

I somehow doubt that praying will help :p

[akiza]

I somehow doubt that praying will help :p


Hope someone can spend another "15min" ....:devil:

[Dark Shikari]

Hope someone can spend another "15min" ....:devil:But making Xvid faster just makes x264 look slower... :p

[akiza]

But making Xvid faster just makes x264 look slower... :p


When it happen, someone can spend another 15min to make X264 faster.... :devil::devil::devil:

[Dark Shikari]

When it happen, someone can spend another 15min to make X264 faster.... :devil::devil::devil:It isn't that easy when you've exhausted nearly every avenue of optimization... perhaps I can spend 15 minutes and make x264 ~0.01% faster...

[gizzin]

If someone is really too dumb to use a one-click GUI to encode their videos, they really don't deserve to use a computer... it isn't as if everyone is forced to use something overcomplicated like MeGUI.

lol

Too say that 700-1400 "scene" xvids looks like crap is overstatement. They don't look great compared to the original but they still look good. I did some encodes xvid, x264, and did some side by side comparisons. If xvid didn't look like such crap in dark areas, I would say that x264 is not much more than 10%, 15% better. Not that 80% that some people claim :)

[DeathTheSheep]

But making Xvid faster just makes x264 look slower... :p
I don't think there should rationally be a "conflict of interest." Come on, give it a shot; you might even surprise yourself. Besides, you'd have two big codecs to your name instead of just one, ya know. ;)

[prOnorama]

I don't think there should rationally be a "conflict of interest." Come on, give it a shot; you might even surprise yourself. Besides, you'd have two big codecs to your name instead of just one, ya know. ;)

Good argument ;)

For me using x264 only makes sense for HD sources at this moment. A good quality SD Xvid encode (usually >1500 Kbps or 1/3 DVD-R) will look fairly good IMO with the great added benefit I can watch them on my standalone DVD player.

Since I can't play HD content on my standalone DVD player (simply because of the fact resolutions >720 pixels width aren't supported by the chipset and I don't know any commercial DVD players that will), it makes sense encoding HD stuff with the superior x264 codec since Xvid won't be playable @ > 720 pixels width anyway.

If you look on the net x264 encodes of SD content just aren't popular probably precisely because the lack of standalone compatibility (yes I know PopCornHour but that's really a niche market)

And since SD content will still be produced for quite some time (especially the non-big budget non-Hollywood stuff) Xvid is still relevant as a codec at least until we see H.264 capable DVD players from big manufacturers sold at the average electronics store (maybe DivX Inc. can break the ice here)

Anyway (speed) improvements for Xvid would be nice of course

[Sharc]

Since I can't play HD content on my standalone DVD player (simply because of the fact resolutions >720 pixels width aren't supported by the chipset and I don't know any commercial DVD players that will), it makes sense encoding HD stuff with the superior x264 codec since Xvid won't be playable @ > 720 pixels width anyway.

... or one resizes the HD stuff to 720x576 - eventually cropping the black borders and signalling the correct PAR - and encodes with XviD or DivX to make it playable on legacy standalones, until BD players fit the budget. The results are pretty good in my experience, because one can exploit the full 720x576 resolution with the active picture.

So any improvement on XviD would be welcome.

[PatchWorKs]

So any improvement on XviD would be welcome.
Well, I loved XviD but its era is going to end....

So guyz, isn't time to switch to Theora/Dirac instead ?

They really need improvements !

http://www.theora.org/

http://www.diracvideo.org/ :helpful:

[Dark Shikari]

Well, I loved XviD but its era is going to end....

So guyz, isn't time to switch to Theora/Dirac instead ?

They really need improvements !

http://www.theora.org/

http://www.diracvideo.org/ :helpful:Wait, the "Xvid era is ending"... so you want to switch to something inferior to Xvid?! (Theora)

[DeathTheSheep]

One could argue that the so-called "Xvid era" isn't "ending" at all; it's merely becoming compartmentalized in the grand scheme of things. Thus, improvement would indeed yet benefit many.

[LoRd_MuldeR]

One could argue that the so-called "Xvid era" isn't "ending" at all; it's merely becoming compartmentalized in the grand scheme of things. Thus, improvement would indeed yet benefit many.

For what would you use Xvid/DivX today, except for stand-alone compatibility? :confused:

And stand-alone support for H.264 is spreading out these days, so even stand-alone compatibility won't be a noteworthy reason for Xvid/DivX soon...

[DeathTheSheep]

Standalones (read previous posts about price and availability points) and divx TV's and divx connected boxes, and device support (like my x51v in powersave), and support for slower systems in full res (netbooks and eee pc in powersave), widespread net support (xvid/divx files are still more widespread and entrenched than h264's), easy frame-accurate extensible virtualdub and vfw editing support, highly customizable post-processing available (look at all the PP methods, some of which are superb and highly tweakable for desired effect decoder-side), more 'official' VfW support and encoding in all capable applications (the AVI's will work everywhere thanks to a long history of divx support), a faster asp decoder native to windows 7 (the avc one is laughable to say nothing of the unsupported mkv and aac plus and embedded subtitles etc), and more...

In a nutshell, one could say speed and convenience, but that wouldn't hit the mark since AVC junkies have an arsenal of canned and superficial comebacks at the ready to convince themselves with. Sure x264 can be faster [and still be leagues better in quality] at encoding. Such a narrow definition of speed is useless for most people who won't do the darn encoding and have to put more crap on their computers and more stupid players or filters or splitters. Sure support is growing in the HD market and in funny niche things like Popcorn hour [only available in certain countries for any reasonable price anyway], but we 'geeks ahead of the game by a few years' really need to take a look at people who don't have, want, or give a crap about something they don't or really can't use for their purposes, or would be simply impractical in comparison.

It was so amazing to install Windows 7 on the class eee pcs and they play xvids out of the box in the cool new WMP12. Bring AVC into the picture and all hell breaks loose. If you like, follow this little skit below:
"It won't play right on my WMP. I want the avi files."
Too bad--I make the rules, loser. Get this and this splitter, decoder, vobsub filter.
"Now it crashed!"
That's the damn OS or your config or your file or that POS WMP's fault, get this other random awesome player.
"But I like my old one much better than this ugly one, plus all my library is on it and it worked just fine with the avi files!"
Shut up and go with it because I said it's better.
"Fine... Hey, it doesn't play right, and keeps stuttering."
Put your processor in turbo mode, dufus.
"...The battery died halfway through!"
Buy a new clunky battery if you wanna watch movies you idiot.
"I don't want to spend more money and carry more around and have to switch the ba--"
SHUT UP. Then buy CoreAVC or sign up to use some beta decoder with the DivX logo on it and in either case pray it works with all your AVCs in all the containers.
"That's still spending money and filling up my limited hard-drive with crap!"
Listen, you have to make some sacrifices and learn for the sake of technology.
"Isn't the evolution of technology supposed to make things easier, faster, and more intuitive?"
Uhm, you're just an idiot and got unlucky and your stuff just can't handle it.
"It's also supposed to be 'easier' and more accessible. Just because I'm not a video file nerd doesn't mean I have to put up with all this!"
Then just stop living in the past and get new, expensive stuff!
"These are all brand new computers and devices, and I'm not stupid enough to spend all that money for something I don't need when the avis worked fine. Now please go away."
ARGHHH!!
Now that situation is a lot more typical than you might think out here in the "real world" (replacing the "Windows 7" native support with "install this one 446K xvid.exe (http://ffdshow.faireal.net/mirror/XviD/XviD.cvs.head.MTKVAQ.exe)), and while it might not be a powerful case to get people back to working on Xvid, it at least needed to be said in light of some recent misunderstandings in this regard.

You probably don't want to hear the story about my friend's DivX supporting TV, or my pocket pc which hums along with SD XviD in powersave but can't bench 50% on VGA baseline AVC (even in max performance), or my uncle's new DivX capable DVD player, right? Or any of the multitudes of others? In light of this, I honestly can't care for some self-conceived "noteworthy reasons" being so easily thrown around; you simply don't understand that there are a vast number of people in and out of the nerd sphere who would really benefit from better Xvid--and not only for the compat/powersave/decoder/editability/etc/etc/etc stuff above. Just because you don't understand the hassles of AVC for both people and hardware (or are immune from it with your own setups), doesn't mean it's not there and you can self-righteously claim that the "Xvid era is over." I love AVC for my own purposes. I've been hacking around with some x264 code myself these last few weeks here... and XviD too, but I'm simply not really a programmer. I always knew XviD was better for most people outside of my computer, but only recently had cause to consider regularly using it for myself (I'm also getting an eee pc now along with my VGA pocket pc) and the reality hits me like a slap in the face. The need for Xvid as is strong as ever in many spheres of users.

Now I hope you can see what I was referring to regarding the "compartmentalization" I spoke of. I'm not the best at getting ideas across, but if you could look beyond my pitiful writing and try to see where I'm coming from, it would help not only me, but all the people I spoke of. So please don't just declare Xvid dead and walk away, or worse, withhold the [literally] few minutes worth of coding that comes so easily to you devs (especially DS et al) which would really make things that much better for the rest of us. Please, at least consider spending that metaphorical (or literal?) "15 minutes" making Xvid that much better, instead of spending the same on x264 for less dramatic improvement. Hack in some better B-frame detection, some sort of primitive UMH or ESA, some form of decent RD, and just maybe some basic speedups. I mention these because all of them can be found in some form or another in x264, so porting shouldn't be that hard, right? (The breathtaking legendary 15-minute VAQ comes to mind.)

[Sagekilla]

Erm, that's an awfully long list of problems and quirks.

For me it was:
AVC --> Haali Media Splitter + CoreAVC
ASP --> XviD or DivX decoder

Nothing more beyond that was needed. The other thing? My desktop runs on an Opteron 170 (2 GHz) and I tried using XviD @ 1080p once. I don't know if I was using the wrong decoder or something, but my playback stuttered unless I turned off all PP (inc. deblocking). Transcode the material over to AVC @ 1080p and coreAVC played it back perfectly with deblocking.

That's just my experience. I haven't seen an XviD decoder so far that offers similar speed to an AVC decoder for the same resolution. I wasn't making any "special cases" either by forcing certain options off on the encoder for compatibility or performance (beyond disabling PP for the ASP decoder to allow for fluid playback).

I agree that so far the hardware for AVC isn't great, but that's to be expected this early in the mainstream life cycle. Stuff like this only improves over time.

[DeathTheSheep]

A separate splitter + a paid MT program, so not quite the single 450k exe. Your results might be strange nonetheless; if Windows 7 could do it bareboned on the eee (or one xvid.exe for xp), I'd say maybe you screwed something up with all the decoders and software and settings you added/tried out? Besides, if you're going to watch 1080p, and/or have a super dual-core opteron desktop system, that's the perfect scenario for x264; you pretty much exemplify the "other audience" I speak of, the very type of person and system x264 (and the paid multithreaded decoders) are designed and optimized for. That "awfully long list of problems and quirks" manifest for systems and scenarios essentially opposite of yours. :)

[PatchWorKs]

Wait, the "Xvid era is ending"... so you want to switch to something inferior to Xvid?! (Theora)

Err... well, I'm not alone: Upcoming versions of Firefox and Opera will play natively Ogg/Theora videos with the new HTML5 element (http://news.slashdot.org/article.pl?sid=08/11/04/136220)...

Theora should be the flash replacer, but for quality encodings i would go with Dirac ! ;)

BTW, the best approach would be expand/optimize the FFMpeg multithreading, IMHO. :devil:

[LoRd_MuldeR]

A separate splitter + a paid MT program, so not quite the single 450k exe.

Not needed, ffdshow-mt is on the way:
http://forum.doom9.org/showpost.php?p=1215370&postcount=5157

[Lenny_Nero]

I am sure that all that happened when I watched H264 was that FFDshow kicked in, its what I say to people that are having problems watching H264, if that does not work most of the time their computer does not have the power to play them.

As for settings I can make MPC use 2~3% or 100% CPU and have problems unable to get over 15 fps for the same file. This seems to be more of a problem for Windows XP users and VMR7 and their vid cards having AA (anti aliasing) turned on, like most things computer its all about the settings.

As for fancy media playing HDD's and that sort of media streamer like popcornH I dont need them as I can work out how to run a cable from one of my computers to the TV, so in fact I have the ability to do everything that popcornH can for the £10ish I gave for the cable. Also the £20 quid Xvid DVD players have USB (and SD card slots) plugs on them so I might have to have a play via them. But with my quality encodes I can get a nights TV on a 4 GB USB stick no problem at all.

As for people trying to making Xvid better I could care less as I said I get very good encodes and I dont feel the need for a massive TV, but then I dont have the small body part that means some have to have big TV's, fast cars and the newest computers :)

[seggitek]

What is the reason of using threads at the codec level, if you can do it in your AviSynth script?

[clsid]

You can have a trillion threads in your AviSynth script, but if just one of those threads is doing all the resource intensive work, the performance will not scale.

[alexins]

xvid 1.2-127.08.11.27-VAQ x86 (http://www.xvidvideo.ru/content/view/436/1/)

Brightness control fix; GUI controls for SSE3/SSE4; Updated about box and messages

[squid_80]

Looking in xvid's cvs, it appears win64 support has been officially added.

Edit: Hmm doesn't look right to me - XMM6 and XMM7 aren't treated as non-volatile registers.

[seggitek]

You can have a trillion threads in your AviSynth script, but if just one of those threads is doing all the resource intensive work, the performance will not scale.

First of all thanks for the reply. But why should 1 thread do the resource intensive work. Normally the frame is split up evenly among the cores using the MT function of AviSynth.

I assume the XviD multithreading only affects the compression of the frame, right? And not how the frame is built up, because that is part of AviSynth.

So it goes like this:

1.) AviSynth creates the frame (maybe using MT or SetMTmode multithreaded)
2.) XviD compresses the resulting frames (maybe using multiple threads, but this only speeds up the work of the codec)

[clsid]

A frame is not split up. Xvid encodes whole frames.

[olnima]

Btw - any news about Syskin? Is he doing well? Maybe he can code some tweaks?

Olnima

[seggitek]

A frame is not split up. Xvid encodes whole frames.

Sure, but the work (compression) can be split up. Or what do the 4 threads I start for XviD do? Does each one write one single frame?

[Dark Shikari]

Sure, but the work (compression) can be split up. Or what do the 4 threads I start for XviD do? Does each one write one single frame?That's what they would do if XviD was multithreaded well (frame-based threading, a'la x264).

XviD itself uses a quite interesting threading model that results in the exact same output as unthreaded encoding (IIRC) but is not as efficient as full-frame threading.

[Blue_MiSfit]

A separate splitter + a paid MT program, so not quite the single 450k exe. Your results might be strange nonetheless; if Windows 7 could do it bareboned on the eee (or one xvid.exe for xp), I'd say maybe you screwed something up with all the decoders and software and settings you added/tried out? Besides, if you're going to watch 1080p, and/or have a super dual-core opteron desktop system, that's the perfect scenario for x264; you pretty much exemplify the "other audience" I speak of, the very type of person and system x264 (and the paid multithreaded decoders) are designed and optimized for. That "awfully long list of problems and quirks" manifest for systems and scenarios essentially opposite of yours. :)

I hear what you're saying about MPEG-4 ASP being very important, particularly where hardware devices and power savings are concerned.

It makes perfect sense, and if a device works well with ASP, why bother with AVC if it burns significantly more battery power?

That being said, your discussion of Windows 7 isn't really valid. It's not even an officially released operating system!

~MiSfit

[alexins]

xvid1.2-127.CVS - 08.11.28 - VAQ (http://www.xvidvideo.ru/content/view/438/1/)

Enable SSE4 GMC code;
Encraw - fix for -ssim option;
More ssim fixes;
Bugfix: prevent access violation if width/height is not multiple of 2;
Auto SMP.

[johnsonlam]

xvid1.2-127.CVS - 08.11.28 - VAQ (http://www.xvidvideo.ru/content/view/438/1/)

Enable SSE4 GMC code;
Encraw - fix for -ssim option;
More ssim fixes;
Bugfix: prevent access violation if width/height is not multiple of 2;
Auto SMP.

Wow! Thank you very much Alexins!

You're our binary savior!

[clsid]

What is the preferred build? MSVC9 or GCC?

[_xxl]

@ alexins
I have seen that you compile ffdshow's libs using MinGW GCC with -msse. If I remember correctly forcing the compiler to use SSE won't make them faster, but slower.

[alexins]

What is the preferred build? MSVC9 or GCC?
I build in MSVC9 sp1

[clsid]

Yes, Xvid already has handwritten assembly optimizations. Using -msse has little or no benefit.

[alexins]

clsid,
I compared the assembly was made in the GCC and MSVC.
Assembling the GCC - the first passage: 124.62 fps, the second pass: 52.75 fps.
Assembling MSVC - first pass: 142.04 fps, the second pass: 61.02 fps.

[olnima]

clsid,
I compared the assembly was made in the GCC and MSVC.
Assembling the GCC - the first passage: 124.62 fps, the second pass: 52.75 fps.
Assembling MSVC - first pass: 142.04 fps, the second pass: 61.02 fps.

So maybe You can compile and upload a new MSVC-bulid?

Olnima

Great to see that xvid isn't dead!

[alexins]

XviD-1.3.0 (CVS)-081129.05.22-VAQ (http://www.xvidvideo.ru/content/view/441/1/) - MSVC9-bulid

add: alternative multicore detection;
pump up HEAD version numbers;
installer is added

[olnima]

Dear alexins,
thank You very much !!

Olnima

[cweb]

Dear alexins,
thank You very much !!

Olnima
thanks! this seems like a very good build, testing it right now.

[seggitek]

Thanks for your work. Does this mean that this version should be a bit faster? :)

[Lugia25000]

When i use Megui, the framerate is wrong. Instead of 23.976 is detected 25.00. But it works with vfw.

And with Mediainfo the Version is not right:
with Dark Shikaris 1.2 Build http://img19.myimg.de/Aufnahme253a7a.jpg

with the new 1.3 Build http://img19.myimg.de/Aufnahme19614a.jpg

And with Megui, the width and height are swapped in WinXP
http://img19.myimg.de/0141762.jpg
normal:
http://img19.myimg.de/023d1a6.jpg

But I found no major errors :)

:thanks: for the new Builds and sorry for my bad english.

[avivahl]

So the new XviD-1.3.0-(CVS)-081129.05.22-VAQ build (from XvidVideo.ru) sounds quite buggy. :( Can anybody confirm?

[alexins]

Problem appears with new in xvid_encraw.exe. Old xvid_encraw.exe and new version xvidcore.dll work normally.

[avivahl]

So does that mean the DirectShow filter (of XviD-1.3.0-(CVS)-081129.05.22-VAQ) should work fine?

[Sharc]

Works fine here - so far. >85% CPU on Quadcore.
Thanks alexins.
Any plans to improve VBV / peak bitrate control? IIRC this is still an issue with Xvid for standalone compliance.

[Dark Shikari]

Works fine here - so far. >85% CPU on Quadcore.
Thanks alexins.
Any plans to improve VBV / peak bitrate control? IIRC this is still an issue with Xvid for standalone compliance.Two random thoughts on this topic from looking at Xvid ratecontrol code:

1. There's no row-based ratecontrol; be this as it will for VBV compliance (bad).
2. The 2pass algorithm has a very very very fine threshold for underflows; from what I can tell it literally says "as long as this is less than 100% of the max bitrate, its fine." This obviously fails if the prediction isn't exact--which it surely isn't. Odds are it'll perform better if the limit is 95% or 90% or something.
3. The first pass in Xvid is always run at CQ2--this is probably bad for VBV compliance that relies solely on what is described in 2), because it makes the prediction from the firstpass less accurate.

[Sharc]

Hmmm, this looks to me - as a layman - that improvements in this area would require substantial re-engineering.

[Lenchik]

Old xvid_encraw.exe and new version xvidcore.dll work normally.

Is this working version bundled with your build's "coming without installer" version?

[Amefurashi]

Hi guys, just got this mail:

Hello!

This is Xvid 1.2.0 release.

This release is Xvid 1.2.0 stable release. It is API compatible with
the previous 1.1.3 stable release.

Changes since 1.1.3:

* xvidcore library
- Complete AMD64/EM64T 64-bit support
- Added support for WIN64 platform
- Multi-threaded encoding support
- SSE3/SSE4 optimizations
- Faster and more precise mpeg intra quantization
- Fixed bug in packed pixel format colorspace conversion
- Noexec-stack security patch
- Fix for bad resync marker length
- Improved decoder robustness for broken streams containing B-frames
- Fix for potential out-of-bound access to MV bits table
- Added SSIM quality-metric plugin


* VFW frontend
- WIN64 compatibility
- Added widgets for SSE3/SSE4
- Auto-detection of available processor cores
- Minor GUI cosmetics


* DShow frontend
- WIN64 compatibility
- Minor GUI cosmetics


The files are available in the download section of Xvid.org:
http://www.xvid.org/downloads.html

-- The "Xvid Team"

Can't wait to try this out... :helpful:

[olnima]

...and Isibaar has added new code again yesterday...

Olnima

//edit: maybe Koepi will build THE official 1.2-release

[buzzqw]

yep.. i hope soon!

BHH

[totya]

Hi guys, just got this mail:
Can't wait to try this out... :helpful:

xvid is free, but the recommended compiler...not :)

MS VisualDev 6 Processor Pack 5 or MS VisualDev 7

This is slightly joke.

[squid_80]

The visual studio project files have been updated to VC8 so the freely available VC++ 2005/2008 Express Editions should work.

[alexins]

XviD-1.2.0 x86 / x64 Stable release (http://www.xvidvideo.ru/content/view/452/1/)

[LordIntruder]

I'm a bit lost.

Amefurashi tells us he just got an email about Xvid 1.2.0 release:

http://www.xvid.org/downloads.html

But on Koepi site there is already a 1.2.0 branch for SMP for months now:

http://koepi.info/

So what is the difference between them? Same? The XviD.org is a brand new one just released and better than the one on Koepi site?


alexins released XviD-1.3.0 (CVS)-081129.05.22-VAQ - MSVC9

Today he announced XviD-1.2.0 x86 / x64 Stable release for windows based on the xvid.org.

Great but again what build to use? What is the difference between 1.3.0 and the 1.2.0?

[clsid]

The 1.2.0 branch has been around for a long time. But today the final version has been released. Previous builds were just builds from current SVN repository, consider them as "work in progress". The 1.3.0 branch has been created a few days ago. I don't think that has anything new compared to 1.2.0 final. So just use the final version.

[olnima]

XviD-1.2.0 x86 / x64 Stable release (http://www.xvidvideo.ru/content/view/452/1/)

Again MSVC9 sp1 ?

Thanks anyway,
Olnima

[alexins]

Again MSVC9 sp1 ?

Thanks anyway,
Olnima

Assembling version 1.2.0 I have done in msvc8sp1, as it was conceived by developers xvid, no change in the code. In msvc9sp1 I will assemble the 1.3-dev.

[totya]

The visual studio project files have been updated to VC8 so the freely available VC++ 2005/2008 Express Editions should work.

Thanks.

[olnima]

Assembling version 1.2.0 I have done in msvc8sp1, as it was conceived by developers xvid, no change in the code. In msvc9sp1 I will assemble the 1.3-dev.

Thanks again, alexins :o

[LordIntruder]

Assembling version 1.2.0 I have done in msvc8sp1, as it was conceived by developers xvid, no change in the code. In msvc9sp1 I will assemble the 1.3-dev.

You mean 1.2.0 and 1.3.0 are exactly the same XviD but:

1.2.0 is done with msvc8sp1
1.3.0 is done with msvc9sp1

or am I wrong as usual? :D

That would mean 1.3.0 faster than 1.2.0? Sorry it may be obvious for some but I'm totally confused, I have no knowledge about what is msvc8sp1 and such stuff. It is chinese for me.

I suppose I should use 1.2.0 as clsid suggested me, this is official but maybe 1.3.0 is much faster? Alexins could you just clarify that? What 1.3.0 has than 1.2.0 has not? Thanks :)

[clsid]

1.3.0 doesn't have anything that 1.2.0 does not have. It did not even exist a few days ago.

[squid_80]

I don't know where this 1.3.0 stuff comes from at all, I can't see any 1.3.0 branch and CVS HEAD is marked as 1.2.1.

1.2.0 x64 should not be used since it has serious bugs as noted on the mailing list. Isibaar checked in a quick fix but it's untested and from looking at it there's still bugs.

[avivahl]

I don't know where this 1.3.0 stuff comes from at all, I can't see any 1.3.0 branch and CVS HEAD is marked as 1.2.1.The CVS HEAD is marked as 1.3 (since 3 days ago)... http://cvs.xvid.org/cvs/viewvc.cgi/xvidcore/src/xvid.h?view=log&sortby=date&pathrev=HEAD

The release-1_2-branch is already at 1.2.1: http://cvs.xvid.org/cvs/viewvc.cgi/xvidcore/src/xvid.h?view=log&sortby=date&pathrev=release-1_2-branch

1.2.0 x64 should not be used since it has serious bugs as noted on the mailing list. Isibaar checked in a quick fix but it's untested and from looking at it there's still bugs.
Looking at http://list.xvid.org/pipermail/xvid-devel/2008-December/005985.html
I wouldn't say "serious bugs"... They both said: "although it's possible this won't cause any problems" and "It didn't seem to cause any problems but that may be compiler-dependent and because we're not using double calculations".


@alexins, could you please compile us a [x86+x64] 1.2.1 version using VS8+sp1? (just to be on the safe side)

[olnima]

Something is wrong with the newest xvid-build (x86-build from 2.12.2008) on xvid.ru:

During installation-process, after selecting the language I get the following message:

Can not expand "pf64" constant on this version of Windows

(WinXp32 SP3)

x64-build does nor work either (as expected with my Vers. of Windows)

Olnima

[Vindarath]

I get the same error aswell with that build.
Running Vista sp1 32bit

[squid_80]

Looking at http://list.xvid.org/pipermail/xvid-devel/2008-December/005985.html
I wouldn't say "serious bugs"... They both said: "although it's possible this won't cause any problems" and "It didn't seem to cause any problems but that may be compiler-dependent and because we're not using double calculations".
Andrew = Me. :D

It's possible it won't cause any problems, but also very likely it will when xvid is used with other programs such as virtualdub, avisynth etc. The problem cannot be mitigated by using a different compiler. The latest cvs additions should fix the remaining issues.

[sneaker_ger]

Is the chroma optimizer fixed in XviD 1.2 final?

[squid_80]

Doesn't look like it.

[olnima]

What's wrong with the chroma optimizer?
Is it really buggy or could the effect be better (like f. example the old AQ)?

Olnima

[squid_80]

It's not completely broken in the sense that it's going to make a huge ugly mess of your encodes, it just doesn't work exactly as it's meant to (http://forum.doom9.org/showthread.php?p=1120914#post1120914).

Who knows, it might actually be meant to work that way. Gzarkadas said he got better compression with the fixed version though.

[alexins]

Something is wrong with the newest xvid-build (x86-build from 2.12.2008) on xvid.ru:

During installation-process, after selecting the language I get the following message:

Can not expand "pf64" constant on this version of Windows

(WinXp32 SP3)

x64-build does nor work either (as expected with my Vers. of Windows)

Olnima

I am sorry!
I made a mistake in the installer. After three hours publish an updated version of.

[Sharktooth]

any builds with VAQ yet?

[len0x]

or MTK profiles to that matter?..

[alexins]

XviD-1.3.0 (CVS)-081203.01.28-VAQ x86/x64 (http://www.xvidvideo.ru/content/view/457/1/) (MSVC9sp1)

WIN64 XMM6/XMM7 bench and asm optimization patch by Andrew Dunstan; fix installer.

or MTK profiles to that matter?..
In the nearest assemblies I will try to add MTK profiles.

[alexins]

XviD-1.3.0 (CVS)-081203.06.15-VAQ-MTK x86/x64 (http://www.xvidvideo.ru/content/view/460/1/) (MSVC9sp1)

add MTK profiles ;)

[olnima]

...thanks !

[Lugia25000]

Can you make always a x86 version without installer on www.xvidvideo.ru? and with new encraw?

I hope you work at the bugs from the new encraw version.

Thank you for all new improvements in Xvid!

[Sharc]

Thanks for the new version.
Is VAQ optimized for H.263? Does VAQ have a benefit with custom matrices or is it not recommended?
Secondly, when I select e.g.the Home Theatre Profile, some options are greyed out but remain selected (ticked), like the MPEG matrix or the Quarter Pixel. Do the greyed out parameters still apply, or are they overwritten by the profile selection?

[Gromozeka]

Alexins
Земляк, извини чт опишу на русском, с английским плохо, но не мог бы ты добавит ьв XviD также профили от DivX-а, так как это сделано у Jawor-a:
http://jawormat.republika.pl/xvid.html
А то очень удобно, приходится перескакиват ьс твоего билда на его только из-за профилей

[alexins]

Gromozeka, сделал! (did!)

XviD-1.3.0 (CVS)-081203.13.35-VAQ-MTK x86/x64 (http://www.xvidvideo.ru/content/view/463/1/) (MSVC9sp1)

add Divx profiles (Jawor's (http://jawormat.republika.pl/xvid.html))

http://s48.radikal.ru/i120/0812/55/79edd8fd69bet.jpg (http://radikal.ru/F/s48.radikal.ru/i120/0812/55/79edd8fd69be.png.html)

[Taurus]

XviD-1.3.0 (CVS)-081203.06.15-VAQ-MTK x86/x64 (http://www.xvidvideo.ru/content/view/460/1/) (MSVC9sp1)

add MTK profiles ;)

Great!

[Gromozeka]

alexins
Спасибо, родной, обрадовал то как
Спешу поделиться новостью с народом
:thanks:

[clsid]

xvid.ax depends on msvcr80.dll. Would it be possible to make a static linked build?

[Sharktooth]

yeah it would be great

[Lenchik]

when I select e.g.the Home Theatre Profile, some options are greyed out but remain selected (ticked), like the MPEG matrix or the Quarter Pixel.
I dont know if it is a bug in compile or in something else, but videos made through vfw interface and home profile (with packed bitstream greyed out (not changeable)) are using packed bitstream actually (as Gspot says). Does it supposed to be so? Alexins' build 1.2.0 used.

[len0x]

Can you make always a version without installer?


I second that as I want to rebuild the installer anyway...

[talen9]

I dont know if it is a bug in compile or in something else, but videos made through vfw interface and home profile (with packed bitstream greyed out (not changeable)) are using packed bitstream actually (as Gspot says). Does it supposed to be so? Alexins' build 1.2.0 used.

Packed bitstream is an intrinsic "feature" of home profile. The fact is that is greyed out because you can't modify it, unless if you want that the generated encodes *will not* be compatible with the profile.

That said, there was (at least in the 1.2.-127 versions) a GUI glitch, meaning that the state of the greyed out checkbox was not correctly updated: if you changed your profile to home coming from one where the checkbox was enabled, it would have been greyed out AND enabled, but it would show as disabled if coming from a profile where it was disabled ... sorry if I'm not being very clear :o

I just checked, and in the 1.2.0 alexins build this behaviour is still the same; dunno if it is something that depends on the widget or if something can actually be done in the code .... but, as I said, it's only a (very) minor glitch.

[Jawor]

Can you make always a x86 version without installer
Here (http://jawormat.republika.pl/xvid.html) is a 32-bit 1.2.0 build for those of us who don't like installers ;)

It has DivX Profiles and VAQ. There's no encraw though...

[Lugia25000]

This Build is old and has anything different with the VAQ Version from Dark Shikari.
The Results are different.

alexins builds are newer and the results with Dark Shikaris VAQ Version are the same, but alexins build is faster and has many improvements.

[Jawor]

This Build is old and has anything different with the VAQ Version from Dark Shikari.
My 1.2.0 build is just a few hours old :)

You can download a ZIP with alexins' 1.3.0 binaries here (http://jawormat.republika.pl/Unpacked.zip).

[Lugia25000]

sorry, my mistake
Then... thank you :)

You can download a ZIP with alexins' 1.3.0 binaries here (http://jawormat.republika.pl/Unpacked.zip).

Big thx. ^^

[olnima]

Packed bitstream is an intrinsic "feature" of home profile. The fact is that is greyed out because you can't modify it, unless if you want that the generated encodes *will not* be compatible with the profile.

That said, there was (at least in the 1.2.-127 versions) a GUI glitch, meaning that the state of the greyed out checkbox was not correctly updated: if you changed your profile to home coming from one where the checkbox was enabled, it would have been greyed out AND enabled, but it would show as disabled if coming from a profile where it was disabled ... sorry if I'm not being very clear :o

I just checked, and in the 1.2.0 alexins build this behaviour is still the same; dunno if it is something that depends on the widget or if something can actually be done in the code .... but, as I said, it's only a (very) minor glitch.

...but - Is it right that Home Theater Profile can NOT have more than 1 b-frame? Because this is completely not greyed out...

Olnima

[talen9]

That's a point that's not entirely clear to me too.

I think that the Divx5 certification (to whom the "home" profile should conform) asserts that "one B-frame" encodes have to be correctly reproduced; "two B-frames" encodes should anyway work on most DivX media players, in my experience, but they could actually be out-of-spec.

[kandrey89]

Dark Shikari:
So is there a v1.2.1 with VAQ patch?
Could someone compile it?

From what I remember the VAQ improved quality quite a bit!
Thank you Dark Shikari for the code.

[Sharc]

You may visit:
http://www.koepi.info/

[Jawor]

A build with VAQ and DivX profiles has just arrived on my site (http://jawormat.republika.pl/xvid.html).

I added *.reg files that delete XviD entries from the registry (there's no "real" installer/uninstaller with my builds).

[len0x]

A build with VAQ and DivX profiles has just arrived on my site (http://jawormat.republika.pl/xvid.html).


Can I ask for MTK profiles built in as well please?

[Jawor]

Sure. Where can I find the patch?

[olnima]

Can I ask for MTK profiles built in as well please?

What's wrong with Alexins Builds? He made a build with MTK and one with divx - profiles.

Olnima

[len0x]

Sure. Where can I find the patch?

Here: http://celticdruid.no-ip.com/source/xvid.diff

@olnima

Nothing wrong - I just would like to get 1.2.1 binaries without installer.

[Jawor]

Thanks, I'm looking into it ;)

[kandrey89]

thank you, earlier when I posted, koepi didn't have any v1.2.1 versions, he still had the v1.1.3 and v1.2-127, so he must have updated it within the last few hours, COOL!

[Jawor]

I just added a build with MTK profiles.

[Ninjers]

I installed Koepi's binaries but VDubMod nor VDub will detect it. What do I do now? Install 1.13 and replace the DLLs with the new ones?

[Koepi]

ninjers:

what os are you using?

I can currently only check within win xp sp3, no vista around here - my 64bits vista machine is still somewhere between the boxes from my move to a new place...

cheers
koepi

[turbojet]

koepi:
Thanks for the new build. After some testing with this (http://www.koepi.info/Xvid-1.2.1-VAQ-04122008.exe) build it appears that VAQ isn't being enabled with both my custom settings and default with adaptive quantization checked. This was checked with ffdshow OSD frame mean quantizer. Both of jawor's 1.21 builds and alexin's latest 1.30 build have working VAQ. Would you mind looking into it?

[olnima]

I installed Koepi's binaries but VDubMod nor VDub will detect it. What do I do now? Install 1.13 and replace the DLLs with the new ones?

No Problem here with vfw under XP-SP3.

Olnima

[Audionut]

No problems here on vista 64bit.

[Koepi]

@turbojet:

Will look into that this weekend. There is a trapdoor in Dark Shikari's first patch which directly returns without doing anything, and I'm sure that I didn't apply these lines. I'll try his newer version I saw in the according thread again.

Anyhow, it _does_ change something if you activate it. While in my test-encode file size / bitrate stayed the same, the md5 still changed. That might be due to indicating adaptive quantization in the bitsream headers though.

Well, anyhow, I'll look into it.

Cheers
Koepi

[Sharktooth]

did the api change between the old 1.2 builds and actual 1.2.x /1.3 versions?
if not the new xvid.dll should work with encraw without problems...

[squid_80]

Indeed it does. This is why I made xvid_encraw report the build and bitstream versions. :)

[ankurs]

can anyone please help me out here : http://forum.doom9.org/showthread.php?t=142001

i just installed koepi's latest 1.21 builds ( vaq by ds and simple one as well ) and tried , still not solved :-/

my latest log



[Information] Log
-[Information] Versions
--[NoImage] MeGUI Version : 0.3.0.3011
--[NoImage] OS : Microsoft(R) Windows(R) Server 2003, Enterprise Edition SP2 (5.2.131072.3790)
--[NoImage] Framework used : 2.0 SP1 (2.0.50727.1433)
-[Information] Hardware
--[NoImage] CPU : Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
-[Information] Log for job1 (idx, sample.VOB -> sample.d2v)
--[Information] [12/5/2008 8:05:41 AM] Started handling job
--[Information] [12/5/2008 8:05:41 AM] Preprocessing
--[NoImage] Job commandline: "C:\Program Files\megui\tools\dgindex\dgindex.exe" -SD=< -AIF=<C:\Documents and Settings\amd\Desktop\crap\sample.VOB< -OF=<C:\Documents and Settings\amd\Desktop\crap\sample< -exit -hide -OM=1 -TN=80,
--[Information] [12/5/2008 8:05:41 AM] Encoding started
--[NoImage] Standard output stream
--[NoImage] Standard error stream
--[Information] [12/5/2008 8:05:42 AM] Running auto force film
---[NoImage] Film percentage: 99.84
---[Information] [12/5/2008 8:05:42 AM] Applied force film
--[Information] [12/5/2008 8:05:42 AM] Postprocessing
--[Information] [12/5/2008 8:05:43 AM] Job completed
-[Information] Log for job1 (video, sample.avs -> )
--[Information] [12/5/2008 8:08:21 AM] Started handling job
--[Information] [12/5/2008 8:08:21 AM] Preprocessing
--[NoImage] Job commandline: "C:\Program Files\megui\tools\xvid_encraw\xvid_encraw.exe" -i "C:\Documents and Settings\amd\Desktop\crap\sample.avs" -pass1 "C:\Documents and Settings\amd\Desktop\crap\sample.stats" -bitrate 1065 -kboost 100 -chigh 30 -clow 15 -overhead 0 -vhqmode 4 -qtype 1 -closed_gop -lumimasking -max_bframes 1 -bvhq -par 1:1 -threads 4
--[Information] [12/5/2008 8:08:22 AM] Encoding started
--[NoImage] Standard output stream
---[NoImage] xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003
---[NoImage] Tot: enctime(ms) =43922.00, length(bytes) = 25038103
---[NoImage] Avg: enctime(ms) = 12.00, fps = 83.33, length(bytes) = 6841
---[NoImage] I frames: 49 frames, size = 27544/ 1349693, quants = 2 / 2.00 / 2
---[NoImage] P frames: 1819 frames, size = 10692/ 19449945, quants = 2 / 2.00 / 2
---[NoImage] B frames: 1791 frames, size = 2366/ 4238465, quants = 4 / 4.00 / 4
--[NoImage] Standard error stream
---[NoImage] Trying to retrieve width and height from input header
---[NoImage] xvid [info]: Avisynth detected
---[NoImage] xvid [info]: Input colorspace is YV12
---[NoImage] xvid [info]: Input is 576 x 416, 23.976fps (24000/1001), starting from frame 0
---[NoImage] xvid [info]: Number of frames to encode: 3659, Bitrate = 1065kbps
---[NoImage] xvid [info]: xvidcore build version: xvid-1.2.0-dev
---[NoImage] xvid [info]: Bitstream version: 1.2.-127
---[NoImage] xvid [info]: Detected CPU flags: ASM MMX MMXEXT SSE SSE2 TSC
---[NoImage] xvid [info]: Detected cpus = 4, threads requested = 3, threads in use = 3
---[NoImage] xvid [info]: Threaded input reading active
--[Information] [12/5/2008 8:09:07 AM] Postprocessing
--[Information] [12/5/2008 8:09:07 AM] Job completed
-[Information] Log for job2 (video, sample.avs -> sample.avi)
--[Information] [12/5/2008 8:09:07 AM] Started handling job
--[Information] [12/5/2008 8:09:07 AM] Preprocessing
--[NoImage] Job commandline: "C:\Program Files\megui\tools\xvid_encraw\xvid_encraw.exe" -i "C:\Documents and Settings\amd\Desktop\crap\sample.avs" -pass2 "C:\Documents and Settings\amd\Desktop\crap\sample.stats" -bitrate 1065 -kboost 100 -chigh 30 -clow 15 -overhead 0 -vhqmode 4 -qtype 1 -closed_gop -lumimasking -max_bframes 1 -bvhq -par 1:1 -threads 4 -avi "C:\Documents and Settings\amd\Desktop\crap\sample.avi"
--[Information] [12/5/2008 8:09:07 AM] Encoding started
--[NoImage] Standard output stream: xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003
--[NoImage] Standard error stream
---[NoImage] Trying to retrieve width and height from input header
---[NoImage] xvid [info]: Avisynth detected
---[NoImage] xvid [info]: Input colorspace is YV12
---[NoImage] xvid [info]: Input is 576 x 416, 23.976fps (24000/1001), starting from frame 0
---[NoImage] xvid [info]: Number of frames to encode: 3659, Bitrate = 1065kbps
---[NoImage] xvid [info]: xvidcore build version: xvid-1.2.0-dev
---[NoImage] xvid [info]: Bitstream version: 1.2.-127
---[NoImage] xvid [info]: Detected CPU flags: ASM MMX MMXEXT SSE SSE2 TSC
---[NoImage] xvid [info]: Detected cpus = 4, threads requested = 3, threads in use = 3
---[NoImage] xvid [info]: Threaded input reading active
---[NoImage] xvid [error]: Couldn't init AVI file for writing (C:\Documents and Settings\amd\Desktop\crap\sample.avi)
---[NoImage] AVIOutputFile::Init Error: Unable to open file "C:\Documents and Settings\amd\Desktop\crap\sample.avi" for write: The process cannot access the file because it is being used by another process.
--[Information] Final statistics
---[NoImage] Video Bitrate Desired: 1065 kbit/s
---[NoImage] Video Bitrate Obtained (approximate): 0 kbit/s
--[Information] [12/5/2008 8:09:08 AM] Postprocessing
--[Information] [12/5/2008 8:09:08 AM] Job completed

[Sharktooth]

AVIOutputFile::Init Error: Unable to open file "C:\Documents and Settings\amd\Desktop\crap\sample.avi" for write: The process cannot access the file because it is being used by another process.
that's why.
file in use or cant write to the output folder...
still, megui uses the xvid build that comes with its autoupdate... it IGNORES what you install.

[ankurs]

well that's the agony sharktooth ^

NOTHING WHAT SO EVER is interfereing with xvid_encraw ..

the file is'nt in use and everything can BE DONE / WORKING in that folder , for instance , i can copy / paste files to and fro from it easily ..

it is something else .. :( ?

[Vindarath]

Could anyone please compile the latest cvs source of v1.3.0 with vaq, mtk and divx profiles.
It seems that xvidvideo.ru is offline....

[olnima]

Could anyone please compile the latest cvs source of v1.3.0 with vaq, mtk and divx profiles.
It seems that xvidvideo.ru is offline....

PM me your mail-adr....

Olnima

[alexins]

Could anyone please compile the latest cvs source of v1.3.0 with vaq, mtk and divx profiles.
It seems that xvidvideo.ru is offline....

My site is not yet available, damaged optic cable currently carried out to recover it. Tentatively on Tuesday Wednesday site will be online.

[Cyber-Mav]

alexins do you have an alternative mirror up for me and others to download the 64bit version of xvid latest version?

[Jawor]

Accidentally I created a bug in my recent builds - the zone list in the VfW GUI was broken (you couldn't delete a zone or change it's settings). It's fixed now.

I had a linking problem because _WIN32_IE_ was not #defined. Instead of fixing my include/commctrl.h I "fixed" vfw/src/config.c and that created the bug. My bad.

xvidcore.dll was not affected, only xvidvfw.dll. Everything's fine with output files created with the older build.

[jethro]

Any chance for the latest and greatest xvid_encraw?

[Sharktooth]

encraw is the same. just update the xvidcore.dll ...

[jethro]

oh ok, didn't know...
Thanks, Sharktooth

[Lugia25000]

My site is not yet available, damaged optic cable currently carried out to recover it. Tentatively on Tuesday Wednesday site will be online.

www.xvidvideo.ru is back. Thanks :)

[Vindarath]

Whats the difference between v1.2.1 and v1.3.0?

[totya]

What is the speed difference between 32bit and 64bit versions?

[alexins]

XviD-1.2.1 x86 / x64 Stable release (VAQ. MTK, DivX profiles) (http://www.xvidvideo.ru/content/view/464/29/)
XviD-1.3.0 (CVS)-081213.02.23-VAQ-MTK x86/x64 (VAQ. MTK, DivX profiles) (http://www.xvidvideo.ru/content/view/465/29/)

[krosswindz]

I just updated xvid_encraw with MeGui to the latest version. I am running into an error on the script which ran fine previously. I ran the encode thrice and it crashed at exactly the same place all the three times.

Any help appreciated on this.

http://img49.imageshack.us/img49/2721/xvidencrawerrorxl5.jpg

[Kurtnoise]

did you have installed the msvc 2008 c++ runtime (http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en) ?

[avivahl]

did you have installed the msvc 2008 c++ runtime (http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en) ?
Old link! Use the SP1...
http://www.microsoft.com/downloads/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2&displaylang=en

[FuPP]

Whats the difference between v1.2.1 and v1.3.0?

+1

FuPP

[krosswindz]

did you have installed the msvc 2008 c++ runtime (http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en) ?

To the best of my knowledge I dont think I have it installed. Wouldnt it be something that MeGui/xvid_encraw list as a dependency when upgrading :confused:

I just installed it and re-running the encode. Will probably know in another 7-8 hours if I still have that error.

[Sharktooth]

uh, i used the koepi's xvidcore dll, so i guess he used VS2008 to compile xvid.

[squid_80]

If it required the runtime library, it wouldn't get halfway through the encode then crash. Where's the updated xvid_encraw come from? The one in xvid's CVS is a bit different to mine, I wouldn't recommend using it with MeGUI.

Edit: If it is a CVS build of xvid_encraw, it's probably crashing when the output size hits 2GB.

[krosswindz]

If it required the runtime library, it wouldn't get halfway through the encode then crash. Where's the updated xvid_encraw come from? The one in xvid's CVS is a bit different to mine, I wouldn't recommend using it with MeGUI.

Edit: If it is a CVS build of xvid_encraw, it's probably crashing when the output size hits 2GB.

The xvid_encraw came from megui update. I installed the VS2008 runtime and I still have issues with crashing in the same place. It is actually crashing at the first pass while creating the stats file.

edit: When I go through the frames in AVSP I dont have any issues.

[Sharktooth]

krosswindz, try to feed the .avs (created in megui) directly to xvid_encraw (grab the commandline from the megui preset config window, replace "program" with the name of the encraw executable, "input" with the avs file name, and output with the output file name - keep the quotation marks).
also, are you sure encraw can write the stats file in the output folder?

[krosswindz]

krosswindz, try to feed the .avs (created in megui) directly to xvid_encraw (grab the commandline from the megui preset config window, replace "program" with the name of the encraw executable, "input" with the avs file name, and output with the output file name - keep the quotation marks).
also, are you sure encraw can write the stats file in the output folder?

Yes it can write the stat file in the output folder. It writes close to 3.5Mb of stat file by then. Then constantly around that frame it crashes.

I am running xvid_encraw manually from command prompt copying the command line from MeGUI log file. I have redirected the output a text file. I will update with what is happening.

[krosswindz]

When I ran xvid encraw using the command line I think it completed without any issues. At least it has encoded all frames. But going through MeGUI is causing it to crash at the same place again and again :confused:


206205: key=0, time= 109, len= 628 | type=B, quant= 4, len= 628
206206: key=0, time= 16, len= 569 | type=B, quant= 4, len= 569
206207: key=0, time= 0, len= 4203 | type=P, quant= 2, len= 3917
-1: key=0, time= 16, len= 637 | type=B, quant= 4, len= 637
-1: key=0, time= 0, len= 712 | type=B, quant= 4, len= 712
-1: key=0, time= 0, len= -5 | type=P, quant= 2, len= 4203

Tot: enctime(ms) =16584698.00, length(bytes) = 2607724278
Avg: enctime(ms) = 80.43, fps = 12.43, length(bytes) = 12645
I frames: 3870 frames, size = 32094/ 124205546, quants = 2 / 2.00 / 2
P frames: 82534 frames, size = 23376/ 1929339771, quants = 2 / 2.00 / 2
B frames: 119804 frames, size = 4625/ 554178961, quants = 4 / 4.00 / 4

[alexins]

When I ran xvid encraw using the command line I think it completed without any issues. At least it has encoded all frames. But going through MeGUI is causing it to crash at the same place again and again :confused:


206205: key=0, time= 109, len= 628 | type=B, quant= 4, len= 628
206206: key=0, time= 16, len= 569 | type=B, quant= 4, len= 569
206207: key=0, time= 0, len= 4203 | type=P, quant= 2, len= 3917
-1: key=0, time= 16, len= 637 | type=B, quant= 4, len= 637
-1: key=0, time= 0, len= 712 | type=B, quant= 4, len= 712
-1: key=0, time= 0, len= -5 | type=P, quant= 2, len= 4203

Tot: enctime(ms) =16584698.00, length(bytes) = 2607724278
Avg: enctime(ms) = 80.43, fps = 12.43, length(bytes) = 12645
I frames: 3870 frames, size = 32094/ 124205546, quants = 2 / 2.00 / 2
P frames: 82534 frames, size = 23376/ 1929339771, quants = 2 / 2.00 / 2
B frames: 119804 frames, size = 4625/ 554178961, quants = 4 / 4.00 / 4


Try to do a project in which the size of the output file will be less than 2Gb. What is the profile you choose MeGUI to encode the video file?

[Lenchik]

I just updated xvid_encraw with MeGui to the latest version.

You updated xvid_encraw package actually. http://megui.org/auto/stable/xvid_encraw-2008-12-04.zip contains same xvid_encraw.exe (date of file: 2007-10-24, info from file: built at 10:22:53 on Aug 31 2007) that was in previous build of package.

[krosswindz]

You updated xvid_encraw package actually. http://megui.org/auto/stable/xvid_encraw-2008-12-04.zip contains same xvid_encraw.exe (date of file: 2007-10-24, info from file: built at 10:22:53 on Aug 31 2007) that was in previous build of package.

I think the only difference is the xvidcore.dll that has changed.

Try to do a project in which the size of the output file will be less than 2Gb. What is the profile you choose MeGUI to encode the video file?

The command line options that I used for the output that posted in my previous post.


-pass1 -bitrate 1052 -kboost 100 -overhead 0 -turbo -nopacked -vhqmode 4 -q type 1 -closed_gop -bvhq -par 1:1 -threads 4

That is the first pass and in the second pass the actual file size is well less than 2Gb but for some reason after the update I am facing this issue.

I am using a custom megui xvid profile. I have been using that profile for encoding for quite while. This is the first time I have had issues with MeGUI. I can send you the profile if you want.

Before the update I had run an encode using the same avs file and it went through fine.

The output from MeGUI log for that encode for pass 1


---[NoImage] Tot: enctime(ms) =15037890.00, length(bytes) = 2602777991
---[NoImage] Avg: enctime(ms) = 72.93, fps = 13.71, length(bytes) = 12621
---[NoImage] I frames: 3855 frames, size = 32254/ 124339953, quants = 2 / 2.00 / 2
---[NoImage] P frames: 82512 frames, size = 23343/ 1926147976, quants = 2 / 2.00 / 2
---[NoImage] B frames: 119841 frames, size = 4608/ 552290062, quants = 4 / 4.00 / 4

[Sharktooth]

You updated xvid_encraw package actually. http://megui.org/auto/stable/xvid_encraw-2008-12-04.zip contains same xvid_encraw.exe (date of file: 2007-10-24, info from file: built at 10:22:53 on Aug 31 2007) that was in previous build of package.
xvid_encraw is commandline interface (and did not get updated coz there isnt a new version and btw theres no need for an update), xvidcore.dll is the encoder (and it got updated).

@krosswindz: that behaviour is not normal. megui runs the commandline encoder more or less in the same way you do it manually.
the only difference could be megui eats up some more ram than the command prompt...
test your memory with memtest86 and do some burn-in tests to test your system in stress situations. also try encoding the same source with x264 and see if it crashes/produces corrupted frames.

[krosswindz]

@krosswindz: that behaviour is not normal. megui runs the commandline encoder more or less in the same way you do it manually.
the only difference could be megui eats up some more ram than the command prompt...
test your memory with memtest86 and do some burn-in tests to test your system in stress situations. also try encoding the same source with x264 and see if it crashes/produces corrupted frames.

memtest86 doesnt run on my m/c because of ECC ram. I checked the logs there are no ECC errors. I ran CPU burn both inside VMware and native windows. No errors appeared the system is stable as ever. I ran this tool stress http://weather.ou.edu/~apw/projects/stress/

inside linux nothing in the logs or any crashes. I will test an x264 encode and will update you.

[krosswindz]

@sharktooth I was running a 2nd pass of the same rip using xvid_encraw through command line and guess what the same error in the 2nd pass at around the same frames.

[Sharktooth]

ok, then megui is definatly ruled out.
i think a dubugging session with xvid devs or with someone who has practice with xvid codebase is needed at this point.

@squid: the encraw used by megui is yours.

[krosswindz]

^ if someone can give me a debug build I can run it and provide any further info if you want.

edit:

@sharktooth do you think I should try to replace entire xvid_encraw with http://megui.org/auto/stable/xvid_encraw-2008-05-17.zip and see if everything works fine.

[Sharktooth]

that archive has an old xvidcore.dll (1.2-127). so, if you want to try...
you can also try a different xvidcore.dll build, maybe xvidvideo.ru (http://www.xvidvideo.ru/content/category/1/34/29/) build or jawor's (http://jawormat.republika.pl/xvid.html) one (take the xvidcore.dll in those builds and replace the one in the megui/tools/xvid_encraw folder with that)

[krosswindz]

^ I am at the moment running x264 encode of the same script. once that is done I will replace xvid files from that archive and see if that helps.

[krosswindz]

@sharktooth pass1 of x264 encode hasnt crashed yet but it has stalled around the same region. I have feeling it would crash soon. I am now wondering what could be the problem. When I scan through the source using avsp around that region I have no problem. Trying to encode is causing me problems :(

[Koepi]

@SharkTooth:
I use VS6+ICL7.1 (+PlatformSDK win2003+directx9-sdk) to compile my builds. I didn't stumble over any crashes though. Maybe it's something Isibaar has to check out. Maybe you can (for testing purposes) provide a straight-from-cvs xvid_encraw.exe to rule a bug in your modifications out?

Cheers
Koepi

[Sharktooth]

it's not my modification. it's squids build of encraw.
btw, the issue seems to be of another kind: https://forum.doom9.org/showthread.php?p=1225351#post1225351

[krosswindz]

it's not my modification. it's squids build of encraw.
btw, the issue seems to be of another kind: https://forum.doom9.org/showthread.php?p=1225351#post1225351

I dont think the issue is the same as I ran the same tool in this setup and it returns successfully.

the x264 encode has been stuck around the same frame for over 16 hours. I am not sure what the problem is.

[squid_80]

The problem there is the output file can't be created, not a crash in the middle of the encode. I suspected from the start that Symantec was responsible for that bug, since the aviwriter code is taken from VirtualDub (http://www.virtualdub.org/blog/pivot/entry.php?id=51). I had aviwriter sitting around for about a year before I added it to xvid_encraw, so it was originally developed just a little bit before vdub 1.6.6 came out.

If I'm following correctly, this is what's happened so far:
- xvid_encraw worked fine with MeGUI before updating
- xvid_encraw crashes on pass1 under MeGUI
- xvid_encraw completes pass1 fine from command line
- xvid_encraw crashes on pass2 from command line
- x264 pass1 stalls around the same spot (cmdline or MeGUI?)
The easy way to rule out an xvid problem would be to replace xvidcore.dll with the old version and test.
Was xvid the only tool that was updated via MeGUI's updater recently? It vaguely sounds like an out of memory error is happening, some of the older avisynth builds had a problem on PCs with large amounts of ram (normally 8GB or more) because they would try and use 50% of the available memory for cache, and blow up when they hit 2GB since you can't get any more in a 32-bit process. Easiest way to check for it is watch the memory usage via task manager, if it's close to 2GB when it crashes add a setmemorymax(1024) (maybe lower) line to the avs script. If the x264 encode is still stuck it should be easy to check the mem usage (the VM Size column in task manager).

[krosswindz]

The problem there is the output file can't be created, not a crash in the middle of the encode. I suspected from the start that Symantec was responsible for that bug, since the aviwriter code is taken from VirtualDub (http://www.virtualdub.org/blog/pivot/entry.php?id=51). I had aviwriter sitting around for about a year before I added it to xvid_encraw, so it was originally developed just a little bit before vdub 1.6.6 came out.

If I'm following correctly, this is what's happened so far:
- xvid_encraw worked fine with MeGUI before updating
- xvid_encraw crashes on pass1 under MeGUI
- xvid_encraw completes pass1 fine from command line
- xvid_encraw crashes on pass2 from command line
- x264 pass1 stalls around the same spot (cmdline or MeGUI?)
The easy way to rule out an xvid problem would be to replace xvidcore.dll with the old version and test.
Was xvid the only tool that was updated via MeGUI's updater recently? It vaguely sounds like an out of memory error is happening, some of the older avisynth builds had a problem on PCs with large amounts of ram (normally 8GB or more) because they would try and use 50% of the available memory for cache, and blow up when they hit 2GB since you can't get any more in a 32-bit process. Easiest way to check for it is watch the memory usage via task manager, if it's close to 2GB when it crashes add a setmemorymax(1024) (maybe lower) line to the avs script. If the x264 encode is still stuck it should be easy to check the mem usage (the VM Size column in task manager).

This setup which I am using with VM doesnt have problem of writing AVI files that is a different setup. This were the steps I performed.


MeGUI and xvid_encraw were working fine.
I update MeGUI from 3011 to 3012 and the problem appears of xvid_encraw crashing at around the same time during pass 1. IIRC it replaced xvid_encraw along with MeGUI files.
I ran xvid_encraw pass 1 from the command line it completed.
Then I ran xvid_encraw pass 2 from command line it crashed around the same region.
I run x264 pass 1 from MeGUI and encode is still stalled.


The VM setup only has 1GB of ram secondly all my avs scripts have setmemorymax(512). When I checked the task manager and x264 encoder is using 470244K and MeGUI 11948K.

http://img296.imageshack.us/img296/5384/x264meguilo7.jpg

What do you think should my next step be. Either run x264 pass 1 from command line or should I replace xvidcore.dll and rerun xvid_encraw using MeGUI.

[darkfalz79]

I'm still using the package posted in this thread, as Koepi's release has broken aspect ratio on playback, and he bundles all that junk with it.

[squid_80]

I don't give up easy, but I've gotta say I'm stumped.
Sharktooth will have to confirm if any other new tools were pushed out in the 3011->3012 update. Maybe post the avs script if possible so we know what plugins are being used, it might help narrow down a suspect.
I guess you can still try replacing xvidcore.dll with the old one but it probably won't make a difference since it seems x264 is affected too.

[Sharktooth]

no. just megui core package (megui.exe + changelog + gpl) and xvid_encraw.zip package (the only change was xvidcore.dll)

[krosswindz]

@squid/sharktooth I ran the same encode again same script same x264 profile (DXVA-SD-HQ) this time with MT disabled x264 again crashed around the same region during the first pass. I am out options and the only thing that remains is probably re-installing the machine to see if it has to do something with my windows setup. :eek:

[Kurtnoise]

before to do that, I'll try with another input file...

[krosswindz]

I tried a different source I am getting the same issue. If I run pass1 through megui, pass1 crashes. pass1 from command line works. pass2 from command line is always crashing. I just dont understand what is wrong. Any help to resolve this issue is appreciated.

[krosswindz]

@squid_80/sharktooth is there anything I should try. Unfortunately I am not able to get any install image which doesnt have symantec antivirus setup by default and the techstaff plainly refuse to make an image for me which will not have symantec antivirus.

[Gromozeka]

Happy new 2009 year
People, how can add in XviD new 1vbr method from this:
http://forum.doom9.org/showthread.php?p=1230473#post1230473
Its give best quality and speed

[cweb]

Happy new 2009 year
People, how can add in XviD new 1vbr method from this:
http://forum.doom9.org/showthread.php?p=1230473#post1230473
Its give best quality and speed
trellis? XviD already has trellis... happy new year

[Gromozeka]

trellis? XviD already has trellis... happy new year
NOT! 1 passVBR (fast 2pass VBR) :)

[cweb]

trellis? XviD already has trellis... happy new year
NOT! 1 passVBR (fast 2pass VBR) :)
eh ok I see what you mean 1 pass VBR trellis then...

[alexins]

XviD-1.3.0 (CVS)-090528.06.15-VAQ-MTK x86/x64 (VAQ. MTK, DivX profiles) (not stable) (http://www.xvidvideo.ru/content/view/770/1/)

Changes:
improved precision and rounding for RGB->YV12 conversion;
attempt at fixing a RGB24 access violation;
Added Darkshikari's variance masking as an option to lumimasking;
GUI for variance masking.

Building in the Intel (R) C + + Compiler for Windows 10.1.030

[LigH]

Hail alexins! :D

Now it's our task to test it thoroughly before it can be called stable?

[hajj_3]

what exactly is "Added Darkshikari's variance masking as an option to lumimasking" ?

are there any multithreaded speed improvements with 1.3.0 over 1.2.1?

[juGGaKNot]

XviD-1.3.0 (CVS)-090528.06.15-VAQ-MTK x86/x64 (VAQ. MTK, DivX profiles) (http://www.xvidvideo.ru/content/view/770/1/)

Changes:
improved precision and rounding for RGB->YV12 conversion;
attempt at fixing a RGB24 access violation;
Added Darkshikari's variance masking as an option to lumimasking;
GUI for variance masking.

Building in the Intel (R) C + + Compiler for Windows 10.1.030

what exactly is "Added Darkshikari's variance masking as an option to lumimasking" ?

are there any multithreaded speed improvements with 1.3.0 over 1.2.1?

Is it somewhat stable ? i want to replace 1.2.1

[alexins]

XviD-1.3.0 (CVS)-090529.07.01-VAQ-MTK x86/x64 (VAQ. MTK, DivX profiles) (not stable) (http://www.xvidvideo.ru/content/view/773/1/)

Bugfix:
Added missing resync marker range check in decoder.c;
return E_FAIL instead of S_FALSE upon XVID_ERR_MEMORY error in dshow frontend

Building in the Intel (R) C + + Compiler for Windows 10.1.030

[alexins]

XviD-1.2.2 x86 / x64 Stable release (http://www.xvidvideo.ru/content/view/774/1/)

This release is Xvid 1.2.2 bugfix release. It is API compatible with the previous 1.2.1 stable release. This release contains important, security-related fixes. Update is highly recommended.

Changes since 1.2.1:

xvidcore library


Workaround for nasm bug with Mach-O/OSX target
Fix for missing resync marker range check (reported by IBM X-Force. Thanks go to John McDonald and Christopher Valasek)
Improved precision for RGB<->YUV conversions
Fix for potential RGB24 access violation
Updated compiler options for Apple PPC target
Fixed MSVC6 projects to work for path names with spaces

VFW frontend

Updated mingw makefile

DShow frontend

Bugfix for wrong handling of xvidcore XVID_ERR_MEMORY return code (reported by IBM X-Force. Thanks to John McDonald and Mark Dowd)
____________________________________
Building in the Intel (R) C + + Compiler for Windows 10.1.030

[hajj_3]

great, i'll wait for koepi to add it to his site.

*begs darksharki to improve the speed on multi-core cpu's* :P

[henryho_hk]

Oops... VAQ is not official yet....

[Lugia25000]

@alexins

I have a question about the Encraw in your builds. Its a fps rate detection from the input file possible?
The input file is 23.976 and the output file show 25.00 in Mediainfo.
And a change from the High and the Width in the output file?
Width and high are interchanged in the display from Mediainfo and Windows, but high and width are correct.

Thanks for alle improvements to Xvid.

[kypec]

@alexins

I have a question about the Encraw in your builds. Its a fps rate detection from the input file possible?
The input file is 23.976 and the output file show 25.00 in Mediainfo.
And a change from the High and the Width in the output file?
Width and high are interchanged in the display from Mediainfo and Windows, but high and width are correct.

Thanks for alle improvements to Xvid.

+1 to all these requests. :goodpost:
Alexins, you can look at the source code of xvid_encraw compiled by squid_80 (http://forum.doom9.org/member.php?u=67865), he has fixed the bug with swapped WxH values. Actually, he completely fixed the AVI output saving routines and also the calculation of encoding speed -> it shows true speed including processing of input frames/encoding/outputting instead of raw Xvid encode time spent on single frames which is very misleading for real life purposes.

@Lugia2500: you have to specify output framerate manually with -framerate switch. Otherwise it will be set to default 25fps (PAL).Rate control options:
-framerate float : target framerate (25.0)

[Barough]

I found some time to compile the new Xvid release 1.2.2. A VAQ-patched version is still missing though. Since the new version fixes two potential security vulnerabilities it is advised to install it ASAP!


http://www.koepi.info/Xvid-1.2.2-07062009.exe

[jsquare]

http://www.koepi.info/Xvid-1.2.2-07062009.exe
Why bother with Koepi's version?
Alexins builds works very well, also have the VAQ option and a bunch of profiles.

[olnima]

Why bother with Koepi's version?
Alexins builds works very well, also have the VAQ option and a bunch of profiles.

...because in my tests koepis versions were a bit faster...


Olnima (...waiting for koepis 1.22 VAQ-Version...)

[juGGaKNot]

@Lugia2500: you have to specify output framerate manually with -framerate switch. Otherwise it will be set to default 25fps (PAL).Rate control options:
-framerate float : target framerate (25.0)


Yes, i forgot to add to to the second pass but i've added it to the mux and info says original fps 25 and fps 30

Was scared for a minute there :)

[Asrial]

Can someone explain, in easier terms, what the vulnerabilities in XviD allow?

Someone could make a malicious AVI that runs code on someone's computer?

[henryho_hk]

Yes, i forgot to add to to the second pass but i've added it to the mux and info says original fps 25 and fps 30

Was scared for a minute there :)

Or use squid80's much improved version of xvid_encraw

[juGGaKNot]

Or use squid80's much improved version of xvid_encraw

I have the latest one from megui, is it not squid80's build ?

[Sharktooth]

yep. megui comes with squid's enhanced xvid_encraw.

[squid_80]

Alexins, you can look at the source code of xvid_encraw compiled by squid_80 (http://forum.doom9.org/member.php?u=67865), he has fixed the bug with swapped WxH values.
That was actually my fault in the first place, it was adopted into xvid's CVS before I found and fixed it.

[christinedawson]

WOW!
Does this technology applicable to AVC? Is it possible to make same for x264?

[buzzqw]

x264 is already SMP able, a lot able

BHH

[alexins]

XviD.1.3.0-(CVS).100814.02.44-VAQ-(MTK, DivX profiles) x86/x64 (http://www.xvidvideo.ru/xvid-video-codec/xvid-1-3-0-cvs-100814-02-44-vaq-mtk-x86-x64.html)

changes:

skip mv_bits assert in _DEBUG mode;
app-level multi-threading for xvid_encraw;
typo with sequence splitting;
fixed multithreaded AVI input (hopefully);
fixed rounding issue for app-level multi-threading;
API change: signal fourcc to xvidcore;
decoder: better distinguish between xvid and non-xvid streams.


Microsoft Visual C++ 2008 SP1, Microsoft Windows SDK for Windows 7.1, DirectX SDK v.9.29.1962, Intel® C++ Compiler Professional Edition for Windows 11.1.065

[laserfan]

XviD.1.3.0-(CVS).100814.02.44-VAQ-(MTK, DivX profiles) x86/x64 (http://www.xvidvideo.ru/xvid-video-codec/xvid-1-3-0-cvs-100814-02-44-vaq-mtk-x86-x64.html)What is the difference between the 1.3.0 in this link, and the 1.3.0 in your signature? :confused:

[Sharktooth]

none...

[Penecho]

Hey guys, i tried several Xvid builds now, but none seems to use the full CPU power...

Does any1 have a recommendation for me, which xvid build to use?

I have a core i7@3,8Ghz and running Win7 x64...


Cu



Penecho

[Sharktooth]

xvid multithreading is not optimal. your CPU will never get fully used.
you should start using x264 instead. it has a way better threading model and obviously a much better compression/quality.

[LigH]

Nevertheless - nice to see that there is still *any* development around Xvid... ;)

[Gser]

Nevertheless - nice to see that there is still *any* development around Xvid... ;)

It should be stopped. And people should stop using xvid.

[olnima]

It should be stopped. And people should stop using xvid.

???

Should any project be stopped which user 'Gser' does not need?
What about viewing videos via DVD-player? :devil: :devil: :devil:

I use xvid and I will definately continue so, as long as x264-support is not available or much more expensive in DVD-players, so please stop talking such a nonsense.

[cweb]

It should be stopped. And people should stop using xvid.

For your information, nobody can stop XviD (it's XviD by the way not xvid).
It's an open source project and anyone is free to continue it and to keep copying it.

[Didée]

(it's XviD by the way not xvid).
The spelling XviD (capital "D") is outdated. The notation has officially been changed to Xvid. Check www.xvid.org. ;)

[cweb]

The spelling XviD (capital "D") is outdated. The notation has officially been changed to Xvid. Check www.xvid.org. ;)

I see. So the thread title should be appropriately changed too.

[Gser]

???

Should any project be stopped which user 'Gser' does not need?
What about viewing videos via DVD-player? :devil: :devil: :devil:

I use xvid and I will definately continue so, as long as x264-support is not available or much more expensive in DVD-players, so please stop talking such a nonsense.

Stop using a dvd-player. The xbox360, ps3 and blu-ray players are not expensive.

[cweb]

Stop using a dvd-player. The xbox360, ps3 and blu-ray players are not expensive.
Blu-rays play xvid too..

[Sharktooth]

... blah... stop using blu-ray and use streaming.
every technology fits in its own place.
you cant just say "it should be stopped"... it will naturally die when some other tech will replace it AND when it will completely adopted.
in the meanwhile its completely legit to continue developing it, especially for bugfixing or multithreading implementation.

[Guest]

Stay on topic please. This thread is about multithreaded xvid, not whether DVD players should be abandoned. Thank you.

[LigH]

IMHO there are good uses for Xvid still - like: Backwards compatibility (not everyone is rich enough to be always able to buy most current hardware); or: ratio of encoding speed, quality and size (e.g. capturing video with a compression smaller than MJPEG and faster than AVC).

[PiPPoNe92]

I can't download latest version of xvid from xvidvideo.ru.
My antivirus detect it like a virus. So, I upped xvid_encraw to virustotal...

http://www.virustotal.com/file-scan/report.html?id=3e4c79d123bedb0a8c1867d1a8fa9c3211360d35264b3e4ad006c31e2db9218a-1283337253

[alexins]

I can't download latest version of xvid from xvidvideo.ru.
My antivirus detect it like a virus. So, I upped xvid_encraw to virustotal...

http://www.virustotal.com/file-scan/report.html?id=3e4c79d123bedb0a8c1867d1a8fa9c3211360d35264b3e4ad006c31e2db9218a-1283337253

This is a false positive.

[PiPPoNe92]

ok, thanks. Another question: when I encode with last xvid_encraw with this command line:

xvid_encraw -progress -i "TESTNNDM2 - HQ --FILM.avs" -bitrate 363 -stats -max_bframes 1 -vhqmode 4 -full1pass -pass1 "pass.stats" -bvhq -bquant_ratio 162 -bquant_offset 0 -threads 6 -type 2 -avi "First_pass.avi"


xvid_encraw -progress -i "TESTNNDM2 - HQ --FILM.avs" -bitrate 363 -stats -chigh 30 -clow 15 -max_bframes 1 -vhqmode 4 -pass2 "pass.stats" -bvhq -bquant_ratio 162 -bquant_offset 0 -threads 6 -type 2 -avi "Movie_2pass.avi"

the final .avi that I have got, has like fourCC mp4v, not XVID, why? With previous version I obtain a .avi XVID. Now not. How can I do?

[LigH]

If xvid_encraw has no undocumented switch for this purpose (at least I did not see one in the "-help" output), you can at least use the "FourCC Changer" to fix it...

But I wonder how this happened to you. The "xvid_encraw.exe" installed from "XviD.1.3.0-(CVS).100814.02.44-VAQ-MTK-icl11_x86.exe" from xvidvideo.ru (204800 bytes, not EXE-compressed) does not even contain a string "mp4v".

[PiPPoNe92]

yes, I tried to use fourcc changer, but doesn't work, because It don't recognize the fourcc mp4v.

[LigH]

Incredible ... the FourCC Changer I know ("Nic's Mini AviC FourCC changer" - included in Koepi's Xvid as well as the one from XvidVideo.RU) simply overwrites the FourCC. No matter if knows the previous FourCC.

It just makes the mistake to offer upper case FourCCs for both, although one of them should be lower case. But you can type them manually.

So - which program tells you that this AVI has a FourCC of "mp4v"?

[PiPPoNe92]

vlc...

[LigH]

Well - an AVI should have two FourCCs for the video. Looking into the AVI header of the file I just created (using a hex editor), I see "xvid" right after the "vids" chunk, and "XVID" a bit after "strf". As it should be. My VLC 1.1.4a displays "Codec: MPEG-4 Video (XVID)" in the Codec Details tab (Ctrl+J).

[PiPPoNe92]

I see with VLC 1.1.3 "Codec: MPEG-4 Video (mp4v)" in the Codec Details tab.

with smplayer I see:

Demuxer: mpeg4es
Codec: ffodivx

[LigH]

"Demuxer: mpeg4es" -- this is an MPEG-4 "Elementary Stream". So you got the "raw" video, but not embedded in an AVI container?!

Please, please, pretty please -- post a "MediaInfo" report!

[PiPPoNe92]

Mediainfo report:

General
Count : 246
Count of stream of this kind : 1
Kind of stream : General
Kind of stream : General
Stream identifier : 0
Count of video streams : 1
Video_Format_List : MPEG-4 Visual
Video_Format_WithHint_List : MPEG-4 Visual
Codecs Video : MPEG-4 Visual
File name : film
File extension : avi
Format : MPEG-4 Visual
Format : MPEG-4 Visual
Format/Extensions usually used : mp4v
Codec : MPEG-4 Visual
Codec : MPEG-4 Visual
Codec/Extensions usually used : mp4v
File size : 303534080
File size : 289 MiB
File size : 289 MiB
File size : 289 MiB
File size : 289 MiB
File size : 289.5 MiB
File creation date : UTC 2010-09-02 13:49:31.140
File last modification date : UTC 2010-09-02 17:21:27.437

Video
Count : 133
Count of stream of this kind : 1
Kind of stream : Video
Kind of stream : Video
Stream identifier : 0
Format : MPEG-4 Visual
Format profile : Streaming Video@L1
Format settings : BVOP
Format settings, BVOP : Yes
Format settings, BVOP : Yes
Format settings, QPel : No
Format settings, QPel : No
Format settings, GMC : 0
Format settings, GMC : No warppoints
Format settings, Matrix : Default
Format settings, Matrix : Default
Codec : MPEG-4V
Codec : MPEG-4 Visual
Codec/Family : MPEG-4V
Codec profile : Streaming Video@L1
Codec settings : BVOP
Codec settings, BVOP : Yes
Codec settings, QPel : No
Codec settings, GMC : 0
Codec settings, GMC : No warppoints
Codec settings, Matrix : Default
Width : 608
Width : 608 pixels
Height : 256
Height : 256 pixels
Pixel Aspect Ratio : 1.000
Display aspect ratio : 2.375
Display aspect ratio : 2.35
Frame rate : 25.000
Frame rate : 25.000 fps
Resolution : 24
Resolution : 24 bits
Colorimetry : 4:2:0
Scan type : Progressive
Scan type : Progressive
Interlacement : PPF
Interlacement : Progressive
Writing library : XviD0057
Writing library : XviD 57
Writing library/Name : XviD
Writing library/Version : 57

[hajj_3]

what kind of speed improvements are people getting on core2 cpu's with the latest versions of xvid 1.3.0 compared to 1.2.2? Is there any eta on 1.3.0 final?

[LigH]

@ PiPPoNe92:

It may have the extension ".avi", but it is a raw MPEG-4 Video stream in your case.

If it was a RIFF AVI file, MediaInfo would have reported e.g.:

...
Format : AVI
Format : AVI
Format/Info : Audio Video Interleave
Format/Extensions usually used : avi
Format_Commercial : AVI
Format profile : OpenDML
InternetMediaType : video/vnd.avi
...

So for some reason, your xvid_encraw call did not embed the result into an AVI container.

[Sharktooth]

or you renamed the xvid output to .AVI...

[LigH]

But in his reported command lines, the option "-avi" was used?! ...

[PiPPoNe92]

Yes, in my command line I have "-avi "First_pass.avi""

[Sharktooth]

some xvid_encraw builds need aviwriter.dll in the same folder as xvid_encraw or system(32) folder.

[PiPPoNe92]

aviwriter.dll already there was in same folder as xvid_encraw.

P.S. I seen with small input filesize, in output I got .avi files XVID. Only with movie I got mp4v files...

[Sharktooth]

could you please download the xvid package from here (http://megui.org/auto/xvid_encraw-2009-05-30.zip) (and eventually replace the xvidcore.dll with version 1.3.0 if you prefer), unzip it to a folder and try with that version?

[s4]

Hi guys!
Is there any way to boost xvid encoding speed on i7? Trying to encode from an 1080p AVC source with the dgavc import in avs and a simple lanzcos resize but i only got 20fps for pass1
http://i51.tinypic.com/24ys9kw.jpg

Xvid thread locked to 2, x264 running on the other 6. When im running xvid in auto threads the speed is same, using AS@L5 profile at 32bit xp system, xvid 1.2.2+virtualdub but its weird.
On a prev box which was "only" Q8200 i got more than 20fps+ while encoding so i dont understand why is this limit with i7.
Also tried xvid_encraw w/o MT filter too but it wont boost the speed.
Any idea?

[Rumbah]

If you're resizing with Avisynth try splitting your resize to
Spline16Resize(720,last.height)
Spline16Resize(last.width, 576)
with your resize filter and resolution of course. With that I get a 10% speed boost.

In addition to that try it without the x264 process. In my tests xvid gets a massive loss of speed if there are other apps running. On my quad core encoding with xvid uses only 3 cores and I get about 40 fps. If I start running a lame process using the last core the xvid encoding speed drops from 40 fps to 2-3 although it still has 3 cores to use.

[Chabb]

When I expect big FPS while encoding,
I prefer to use ffdshow decoder+resizer instead of dgavc+avisynth.
Even with 1080p source it's significantly faster.

[henryho_hk]

To maximize CPU usage, I do a 2.05-pass XviD encode with assistance of some scripts:
1) split the movie into 4 (quad-core) or 6 (hexacore) using trim()
2) run 5% compressibility tests over these parts (dun worry, it runs very quickly)
3) from the compressibility test figures, calculate the bitrate required for each part
4) do a normal 2-pass on the parts at the same time.

For my quadcore, I will split the job into four single-threaded tasks. For your hexacore, you can try running six single-threaded tasks or three dual-threaded tasks. If your harddisk is fast enough, six single-threaded tasks will be faster. Otherwise, your harddisk will be stressed and the physical disk read/write will become the bottleneck.

[srk3461]

hey guys... i was wondering is there any GUI for xvid 1.2.1 or any other versions, w/o installing the actual codec!?

[LigH]

Any application encoding to Xvid will use the Xvid codec. In one or another format. Maybe - what you want to avoid - as installed VfW codec (usual AVI editors); maybe as called encoder executable (some xvid_encraw-using GUIs like MeGUI); maybe as linked library (Avidemux).

[Selur]

also a lot of mencoder and ffmpeg builds include the Xvid libraries for encoding,.. so all GUIs that use ffmpeg/mencoder are a potential hit for you ;)