Xvid 1.1.3 Released [Archive]

Pages : [1] 2

ChronoCross

28th June 2007, 19:14

This release is Xvid 1.1.3 bugfix release. It fixes and replaces previous Xvid 1.1.2 release. This release fixes a potential security problem and update is recommended.

Changes since 1.1.2:
xvidcore library

* Fixed a potential vulnerability in mbcoding.c reported by Trixter Jack at Secunia

Changes since 1.1.1:
xvidcore library

* Fixed typo in xvid.c
* Updated bitstream.h to fix the previous faulty non-aligned bitstream buffers fix

plugh

28th June 2007, 19:53

Does it include the motion_inlines.h d_mv_bits() / r_mvtab array bounds fix?

Koepi

28th June 2007, 20:14

As usual, you can find a new build at my site. Time to upgrade since it resolves a potential security issue...

Cheers
Koepi

buzzqw

28th June 2007, 21:34

as usually :thanks: for your build Koepi!

BHH

Cyber-Mav

29th June 2007, 01:18

is this xvid build smp enabled?

celtic_druid

29th June 2007, 02:01

No. You need a 1.2.x build for that. The 1.2.x branch also got the above mentioned security fix though, so I guess wait for a new build.

Hard Core Rikki

29th June 2007, 03:29

Is it me, or is the changelog really skinny after a year ?

Isnt the 1.2 production-ready ?

How about a word on AVC XVID, fellas ?

fight2win

29th June 2007, 10:06

avc xvid wud be friggin' cool...

708145

29th June 2007, 10:51

Does it include the motion_inlines.h d_mv_bits() / r_mvtab array bounds fix?

I wonder the same thing. Does it have a performance penalty like the previous DEBUG mode or not? Since I don't use xvid to decode I'd stay with 1.1.2 if it affects speed ;)

SealTooGreat

29th June 2007, 17:15

@celtic_druid
When I install your MTK build, what should I do with xvidcore builds - should I copy appropriate xvidcore build (for my cpu) to "c:\windows\system32"?

celtic_druid

29th June 2007, 17:32

If you are using the installer, then you shouldn't need to copy anything. If you want to use the gcc build, then yeah, just copy the dll.

ect5150

30th June 2007, 03:09

Hey guys. First post here (hope its not too bad, but I couldn't find my answer in the search).

If the new XviD is out, what about xvid_encraw? I pretty much just use the CLI, and not the VFW. Is that updated with it as well? Or do I need to replace the DLL (xvidcore.dll) that exists in the same directory as my xvid_encraw.exe file? (those two files are in the same directory thanks to the tools of MeGUI). Thanks in advance.

sysKin

30th June 2007, 09:29

The difference is in decoder module only, so I don 't think there's much point building encraw.

Anyway, 1.2.x is better than 1.1.3 isn't it ~

plugh

30th June 2007, 14:10

Anyway, 1.2.x is better than 1.1.3 isn't it ~

I'm not trying to be cute - this is a serious question...

Is 1.2.x 'better' ?

I know 1.2 has smp support, and some 'callout' enhancements (lambda stuff, ssim calcs, etc), and I assume some bugfixes(?) not backported to 1.1, but are there any actual encoder enhancements?

If so, what are they? Inquiring minds want to know ;)

Thanks!

clsid

1st July 2007, 12:08

Another interesting question:

Are there any known problems/bugs in Xvid 1.2.x (latest SVN revision)?

sysKin

2nd July 2007, 05:14

are there any actual encoder enhancements?

Lol guess what, I don't remember ;)
I remember I improved trellis a bit and I remember I disabled one VHQ flag that was decreasing SSIM (while increasing PSNR).
I also think Skal's fdct is finally active, or at least should be, or at least someone had the idea it should be.

Other than this, well, I consider SMP to be quite an improvement ;) and btw this reminded me there were some other SMP improvements proposed, which I need to check out.

Thanks![/QUOTE]

Are there any known problems/bugs in Xvid 1.2.x (latest SVN revision)?

I *think* the mv_table bug was not backported. I totally forgot about it, otherwise I'd push it in before 1.0.3....

AVmaniac

5th July 2007, 08:23

PING...

... for AVS-support in XVID. (aka XVID 2.0)

would be nice to see how it compares to x264.

Kurtnoise

5th July 2007, 10:55

You mean AVC, right ? not avs...

AVmaniac

5th July 2007, 23:27

You mean AVC, right ? not avs...

indeed i did .. sorry

martino

6th July 2007, 13:23

I have a question, though it's not necessarily related to the 1.1.3 release, but I just thought that it'd be better than creating a thread for it;
Is there a way to add more presets to the XviD VfW encoder (Koepi's build in this case), that is to have more than the three available in the drop-down box (I know, you can use MeGUI, and then that bat utility for more presets, but I wanted to know whether it can be done with the VfW encoder).

Thanks

nullstuff

6th July 2007, 17:30

Is there a way to add more presets to the XviD VfW encoder
...an easy way to do so is dump the HKEY_USERS\S-1-5-21-1202660629-1275210071-682003330-1003\Software\GNU\XviD registry-key to a .REG file (this key refers to XviD 1.2 but I guess is the same for 1.1.x) --- example: config codec via VirtualDub(Mod), open regedit, dump key to profile1.REG; repeat for each profiles you need; to load a "custom" profile double-click a .REG file.

-- nullstuff

celtic_druid

6th July 2007, 17:32

From recollection they are hard coded. Not to say that you can't add more, but you would need to add them to the code.

TheRyuu

6th July 2007, 17:40

celtic_druid

6th July 2007, 18:58

Well you can't just use your regular installed binutils and gcc. Did you compile binutils and gcc with the mingw target? You also need mingw-runtime, etc.

TheRyuu

6th July 2007, 20:11

Ok.
So I need to reinstall GCC/binutils on my Linux partition with the --target=i686-mingw32?

So does that also mean every time I want to change the target machine (say back to Linux) that I need to reconfigure and reinstall gcc/binutils?

Seems kind of time consuming, but I'll get it a shot.
I'm currently reinstalling my Linux partition, so once thats up and running I'll try it.

TheRyuu

6th July 2007, 23:25

Got it to compile.
Figured it was kinda pointless to compile something for windows on linux and decided just to use cygwin instead. Worked the first time once I got all the right stuff installed.

Just one thing though. I'm not getting a 1.23mb file from compiling the latest CVS like the latest builds online are (that I think celtic_druid built).

Wrong CFLAGS maybe? :) Or is it that the 1.23mb file is made using the icl9 compiler?

BTW, :thanks:

cc979

7th July 2007, 00:13

I'm trying to cross compile xvid (on Linux system to cross compile to Windows).

Having a tad bit of trouble though.

It compile with --host=i686-pc-linux-gnu just fine. However when I switch that to --host=i686-mingw32 I get a "unrecognized command line option -mno-cygwin".

I get it with this 1.1.3, and I've also tried the latest CVS too. Maybe there's some compiler option I didn't install yet?

Thanks.

Edit:
Could it have something to do with binutils?

you will need the correct cross tool-chain

*** build
this is *always* the platform on which you are running the build process; since we are building on Linux, this is unequivocally going to specify `linux', with the canonical form being `i686-pc-linux-gnu'.

*** host
this is a tricky one: it specifies the platform on which whatever we are building is going to be run; for the cross-compiler itself, that's also `i686-pc-linux-gnu', but when we get to the stage of building the runtime support libraries to go with that cross-compiler, they must contain code which will run on the `i686-pc-mingw32' host, so the `host' specification should change to this, for the `runtime' and `w32api' stages of the build.

*** target
this is probably the one which causes the most confusion; it is only relevant when building a cross-compiler, and it specifies where the code which is built by that cross-compiler itself will ultimately run; it should not need to be specified at all, for the `runtime' or `w32api', since these are already targetted to `i686-pc-mingw32' by a correct `host' specification.

TheRyuu

7th July 2007, 00:21

Thanks.
I just gave up on trying the cross-compile it although I might have eventually gotten it.

Instead I'm using Cygwin and it worked the first time. :)

celtic_druid

7th July 2007, 04:57

If you do go back to it, don't overwrite your default binutils/gcc. Install separate copies, then use cross-make/cross-configure.sh scripts when cross compiling.

Sharro

17th July 2007, 10:38

Is it just for me or Koepi's site is down ?

Sharro

kypec

17th July 2007, 10:54

Is it just for me or Koepi's site is down ?

Sharro

I can't access it either right now :mad:

trodas

17th July 2007, 16:02

Site is obviously down... Now where to get it elsewhere...

Brother John

17th July 2007, 16:06

celtic_druid's site (http://celticdruid.no-ip.com/xvid/) for example.

celtic_druid

17th July 2007, 17:43

Well that depends on what people mean by "it" if they mean Xvid v1.1.3, then sure. If they mean Koepi's compile, then no. Usually places mirror Koepi's though.

http://www.free-codecs.com/Koepi_XviD_download.htm

weaver4

18th July 2007, 15:28

Zach

19th July 2007, 01:19

http://www.free-codecs.com/Koepi_XviD_download.htm

Koepi's domain seems to have gone defunct. :( For two days I've been getting a "Server not found" error.

So a quick question: The 1.1.3 xvid package of his mirrored above is safe, right? (I've never downloaded anything from free-codecs.com, so I don't know if it's a reputable site or not, hence my query.) :)

buzzqw

19th July 2007, 09:19

should be save
anyway you can direct download from my mirror

http://www.64k.it/andres/data/x/XviD-1.1.3-28062007.exe

or browse my xvid build mirror site

http://www.64k.it/andres/dettaglio.php?sez=x

BHH

Didée

19th July 2007, 10:20

Just a quick note. If you are using the quality setting to do a single pass encode the filesizes are very much different between XviD 1.2 and 1.1.3 using the same quality setting. I have found that 1.1.3 can be 25% larger even though the quality appears to be the same. No idea why.
I vaguely remember that at some time a bug was discovered that made coded intra blocks much bigger than they should be. Could be the fix is in v1.2, but not in v1.1.3. (not sure about that, though.)

Zach

19th July 2007, 12:18

should be save
anyway you can direct download from my mirror

http://www.64k.it/andres/data/x/XviD-1.1.3-28062007.exe

Doing a file compare, yours is identical to the one on free-codecs.com (or whatever).

Cool. Thanks!!!

Subwars

19th July 2007, 13:05

i havn't made any avi files for quite some time now... i was just going to use auto gordian knot to make it simple... but obviously that pack is a bit outdated with the current xvid versions... can i just install this version over the top and it will work ok... or should i be looking at other programs now to do it

buzzqw

19th July 2007, 13:42

autogk is prefect with the build of xvid bundled

installing other builds could broken encoding or done incorrect encoding

BHH

celtic_druid

19th July 2007, 16:23

AutoGK is running 1.2.x, so if you update it should be a newer 1.2 build, not a 1.1.x build. The issue really is just with the VfW front end and different profile names which are used for MTK and ESS modes. Basically you have the EXTRA_PROFILES that aren't defined by default and the MTK profiles which I added.

trodas

22nd July 2007, 20:50

celtic_druid - the xvidcore.amd64.7z you have on your site can be used with the 1.1.3 Xvid? And it is faster (or it should be) on AMD64?

celtic_druid

23rd July 2007, 06:13

gcc compiled for AMD64's (32bit). Faster than ICL10? No idea. Would be a 1.2.x build that you refer to I think, so I don't see much point using it with 1.1.3 VfW.

Cunhambebe

29th July 2007, 13:11

I was just wondering what happened to Koepi's development site. It is offline for a few days. I hope everything is OK. Thanks in advance.

TheRyuu

29th July 2007, 16:12

gcc compiled for AMD64's (32bit). Faster than ICL10? No idea. Would be a 1.2.x build that you refer to I think, so I don't see much point using it with 1.1.3 VfW.

I ran a few quick tests.
I gather the MTK build was compiled with ICL since the dll file is so big.

I don't have any numbers, but a simple gcc config with -O3 and -march=k8 (along with -ffast-math, -fomit-frame-pointer, safe stuff) is faster, at least for me, then the ICL build.

I lied, I do have numbers :)
This is all rough, so they may not be totally accurate, and the difference really isn't all that great. And also I had -msse3 on since my DC Opty supports it.
The difference between the two comes down to 6 seconds. A whole 6 seconds. Probably would be slightly more on a longer encode, but I'll take my 6 seconds.
(MTK was celtic_druid's build on 6-29-07, I gather it used the ICL right?)

GCC- 2:39
MTK (ICL)- 2:45

I think it's probably faster because the of the size of it. It was about half the size of the MTK one from celtic_druid (about ~690kb, compared to ~1.44mb). Probably means it can fit in the 1mb L2 cache of the AMD64's making it slightly faster I guess. Or it could just be that Intel optimized code isn't AMD optimized code (no 3dnow?).

Honestly, I couldn't tell you why it's faster. ICL "should" be faster, but it's not. Wonder how it fairs on an Intel CPU. :)

HeadBangeR77

31st July 2007, 17:36

I've just finished a long 2-pass rip, packed with Didee's magic scripts, using the latest Koepi's 1.1.3 stable build. Now I'm repeating the same encode using the latest Celtic Druid's 1.2 build form the 25th of July plus AthlonXP optimized xvidcore.dll. I've got an impression it's running a bit faster than the previous one.

Now to the point:
According to this change log (http://www.videohelp.com/tools/XviD_Codec?changelog=190)

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

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

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

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

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

there was a patch for P/B frames applied, apart form the already mentioned in this thread trellis improvement. Has anyone got any idea what kind of changes did it bring into the project?

Also, I assume the latest CVS head MTK has all the fixes from the stable branch applied, doesn't it?

cheers,
HDBR77

PS. Ooops, I've just marked I had set the number of threads to 1, instead of 0. Doesn't seem to affect speed though. Is "0" some kind of automatic setting?

halsboss

4th August 2007, 03:18

I was just wondering what happened to Koepi's development site. It is offline for a few days. I hope everything is OK. Thanks in advance.
Yes, me too ? Tried just now and "Firefox can't find the server at www.koepi.org".

TheRyuu

4th August 2007, 07:03

I've uploaded Koepi's build here. (http://www.esnips.com/doc/adfcb421-0224-4898-9349-c0bfb3791947/XviD-1.1.3-28062007-Koepi)
(if anyone wants it)

Alternatively, you can download it (different 1.1.3 build) from celtic_druid's site here. (http://ffdshow.faireal.net/mirror/XviD/) (or the newer 1.2.x builds if you want)

HeadBangeR77

4th August 2007, 22:09

Are my eyes cheated somehow or am I getting consecutive I-frames with 1.2-127 based builds? I can't remember such a thing with Koepi's stable releases. Can anyone reproduce such a behaviour?

thx in advance, experience sharing much appreciated :)

EDIT: Not only do I really get some consecutive I-frames with the latest CVS Head, what is a waste of bitrate imho, but I've also got some difficulties with reaching the desired file size in two pass mode, and that with exactly the same settings as with Koepi's 1.1.2 and 1.1.3 builds. It tends to oversize, so I can't get DVD-5 or half a DVD-5 files. Might it be because of 3-4 zones I usually implement while encoding or perhaps because of the overflow settings I've been using for a long time (0/8/4). The latter had not caused any problems before, and improved B-frames quality in some scenes. All the threads I've found on the overflow control are rather old, and might be a bit outdated to some extent.

any help would be much appreciated ;)