Multithreaded XviD - official thread

[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.

[neuron2]

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