a bug with Xvid-1.2.1-04122008 ?

[betaking]

Today,I Installer Xvid-1.2.1-04122008! But all media player in my computer can not use xvid Decoder! you can see picture1!

and I Replace xvid.ax form Xvid-1.2.0-02122008 all media player can use xvid Decoder! you can see picture2!

Sorry to my english!

[Koepi]

I don't know if that is due to my DirectX9-SDK. VS98 doesn't work with newer DirectX-SDKs (Microsoft's decision), so that might be the problem.

Since it is no problem to use a different xvid.ax as the API stayed the same, just stick with the version from 1.2.0.

Cheers
Koepi

[clsid]

Why not use an older version of the SDK? August 2007 is the last one that works with older versions of VS.

[dwrbudr]

I found 1.2.1 VAQ also a bit buggy in decoding.
I use Crystal Player and when you fast forward with 1.2.1 installed - a black frame is shown and after that the frame which should be shown. I uninstalled 1.2.1 and installed 1.1.3 VAQ - no black frame. Its not a serious bug, but it is annoying

[prOnorama]

Funny you should mention decoding issues as Xvid 1.2.1 (Koepi) results in frame drops and out of sync audio/video when playing Xvid/DivX files for me.

When I uninstall 1.2.1 and re-install Xvid-1.1.3-27042008 everything plays perfectly fine again (as usual)

Note: I am on a slow PC (Celeron 900 Mhz) so could it be that for whatever reason Xvid 1.2.1 requires a lot more CPU power for decoding Xvid/DivX than 1.1.3?

[rseiler]

I found 1.2.1 VAQ also a bit buggy in decoding.
Which brings up a point of clarification: Is the VAQ build any different than the non-VAQ one for decoding-only purposes?

In other words, does one need the VAQ build to see the improvement in VAQ-created content, or will the "regular" version do?

[Koepi]

VAQ is a change on the _encoding_. The resulting bitstream is perfect mpeg4-compliant. The decoder doesn't know about VAQ (and doesn't need to).

@clsid:
August 2007... will look into that. I had trouble already in 2005 with newer DirectShowSDKs.

[clsid]

Else it would be the October 2004 one if I remember correctly. That is for even older versions of VS.

[seba5618]

yeah seems I've got a similar problem. XviD decoder doesn't pop up on its own when playing videos, it tries to use Nero decoder and the whole thing fails.

I was able to use XviD again by setting ffdshow to use XviD when reading (alas) XviD videos.

[clsid]

The DirectShow filter seems to be broken. Decoding will work if xvid.ax is replaced with an older build.

[HymnToLife]

And for those who don't want to reinstall 1.1.3, copy xvid.ax away, reinstall 1.2.1 and copy it back, I've put it up here (http://itsuki.fkraiem.org/stuff/xvid.ax) (EDIT: taken from XviD-1.1.3-28062007.exe).

[prOnorama]

Thanks HymnToLife, I've replaced the xvid.ax file from 1.2.1 with yours following the instructions here:

http://www.free-codecs.com/guides/How_to_install_uninstall_DLL_and_AX_files.htm

and now decoding works again (I use ZoomPlayer which I guess uses DirectShow)

[juanchu]

I've got too this problem. Fortunately, I've replaced xvid.ax, so I've got again 1.1.3 version (thanks to HymnToLife), and I can use again correctly Xvid Decoder with all Xvid encoded videos.

I hope that Xvid Team fixes this problem as soon as posible.

[henryho_hk]

I think most XviD developers are using ffdshow. lol

[user60015893]

Koepi,

The last SDKs that are officially supported and work without any hacking with VS6 are:

DirectX 9.0 SDK Update - (Summer 2003) (http://download.microsoft.com/download/d/5/d/d5dd3f5e-9d8e-4f6f-914d-98e2fb34629d/dx90updatesdk.exe)

Platform SDK for Windows Server 2003 - February 2003 (http://www.microsoft.com/msdownload/platformsdk/sdkupdate/psdk-full.htm)

xvid 1.2.1 builds and xvid.ax works with the above.

You should also be able to use VS2008 (express is free) with the later SDKs. Did you find VS2008 to be worse on some way?

Do you plan on fixing your 1.2.1 release?

Thanks

[juanchu]

Finally, here is a Xvid 1.2.1 release which works:

http://www.xvidvideo.ru/content/view/464/29/

However, I hope that Koepi fixes his own version.

[Koepi]

Ouch. I broke the .def-file of the directshow project, that's why the filter didn't work. I silently updated the installers, please download the new build!

Sorry for the mess!

Cheers
Koepi

[betaking]

Ouch. I broke the .def-file of the directshow project, that's why the filter didn't work. I silently updated the installers, please download the new build!

Sorry for the mess!

Cheers
Koepi

Last build work! thanks you work!;)

[Koepi]

You should also be able to use VS2008 (express is free) with the later SDKs. Did you find VS2008 to be worse on some way?


Hello user<longnumber>,

VS2008 is very heavy on ressources compared to 'good ole VS98'. You need all those .Net-thingies for it.

I have to admit that I'm extrapolating from VS2005 which is the last version I tried. For my taste it was barely usable.

Cheers,
Koepi

[prOnorama]

The technical stuff is beyond me, I just want to confirm that the latest (updated) Koepi build works fine now here for DirectShow decoding on a n00b's PC :)

Thanks Koepi

[olnima]

Thanks to all our "compilers" :)

Alexins last 1.3 x86-build also works without any problems here.

Olnima

[juanchu]

Thank you so much, Koepi! Now I can use Xvid 1.2.1 without a problem.

[user60015893]

VS2008 is very heavy on ressources compared to 'good ole VS98'. You need all those .Net-thingies for it.

Out of curiosity I compared the encoding speed of my own vs2008sp1 and vs98sp5 xvid1.2.1 builds and 2008 turned out to be ~5% slower.

In a sense we are lucky, ten years is a lot of time, they could have screwed it up much worse.

[alexins]

Out of curiosity I compared the encoding speed of my own vs2008sp1 and vs98sp5 xvid1.2.1 builds and 2008 turned out to be ~5% slower.

In a sense we are lucky, ten years is a lot of time, they could have screwed it up much worse.

I did the same comparison, and I have completely different results, assembly made VS6.0 giving way to speed assembly made vs2008sp1. For comparison, I start encoding video files on the command line, xvid_encraw.exe + xvidcore.dll+avs script. Coding was conducted in two passes, for more accurate results, we have implemented three cycles of coding.

An example command line for xvid_encraw:
pass 1
"C:\7\xvid_encraw.exe" -i "D:\10\test2\test2.avs" -pass1 "D:\10\test2\test2.stats" -framerate 23.976 -bitrate 1650 -kboost 100 -chigh 30 -clow 15 -overhead 0 -turbo -max_key_interval 250 -nopacked -vhqmode 4 -qpel -closed_gop -lumimasking -notrellis -imin 1 -pmin 1 -max_bframes 1 -bvhq -bquant_ratio 162 -bquant_offset 0 -bmin 1 -par 1:1 -progress -threads 4

pass2
"C:\7\xvid_encraw.exe" -i "D:\10\test2\test2.avs" -pass2 "D:\10\test2\test2.stats" -framerate 23.976 -bitrate 1650 -kboost 100 -chigh 30 -clow 15 -overhead 0 -max_key_interval 250 -nopacked -vhqmode 4 -qpel -closed_gop -lumimasking -notrellis -imin 1 -pmin 1 -max_bframes 1 -bvhq -bquant_ratio 162 -bquant_offset 0 -bmin 1 -par 1:1 -progress -threads 4 -avi "D:\10\test2\test2_nx.avi"
avs script:
DGDecode_mpeg2source("D:\10\test2\VTS_02_1.d2v")
#deinterlace
crop( 0, 60, 0, -64)

LanczosResize(704,288) # Lanczos (Sharp)
Undot() # Minimal Noise

Results coding for the assembly VS6.0:
1. Pass 1: 157.94 fps, Pass 2: 54.62 fps - The required time to encode the video file length of 90 minutes – 3326s (55min).
2. Pass1: 158.11 fps, Pass 2: 55.59 fps - The required time to encode the video file length of 90 minutes – 3282,33s (55min).
3. Pass1: 158.46 fps, Pass2: 54.72 fps - The required time to encode the video file length of 90 minutes – 3318,33s (55min).

Results coding for the assembly VS2008sp1:
1. Pass 1: 157.18 fps, Pass 2: 60.65 fps - The required time to encode the video file length of 90 minutes – 3084,77s (51min).
2. Pass1: 156.27 fps, Pass 2: 62.40 fps - The required time to encode the video file length of 90 minutes – 3027,35s (50min).
3. Pass1: 157.78 fps, Pass2: 61.94 fps - The required time to encode the video file length of 90 minutes – 3035,14s (50min).
Assembling VS6.0 given way to speed assembly VS2008sp1.

[Koepi]

I should mention that I use ICL 7.1 - that's one of intel's compilers that doesn't cheat by sending AMD processors through more loops...

Cheers
Koepi

[clsid]

Newer versions of ICL can be patched, so AMD and Intel processors are handled equally.

[Ranguvar]

There is also a patch for the compiled EXEs.