Jambo! (XviD-1.0-RC2-07022004) [Archive] - Page 4

Heini011

16th February 2004, 13:40

Hi,

@sysKin:

i have a windows me system and directx 8.2 installed. i can't select different overlay-mixers, but some user has reportet, that this makes a difference.

>Also, no related code changed beteen rc1 and rc2.

the jerky playback issue is the same here with rc1 and rc2. but the beta-versions of xvid 1.0 has not this problem !
all my xvid rc2 encodes can be played perfectly with divx5.05-decoder and ffdshow (without packed bitstream).

i had serveral tests done. as other users had reportet too, the playback is (nearly) perfect, when i use gmc AND qpel together (@ a 720x448 encode). all other encoding options have no influence on this playback-issue. but wait a minute - how can this make a difference here ? they slow down the decoding ! so i had underclocked my ahtlon xp from 1900 MHz to 900 MHz and now the encoding with gmc and qpel can't be played fluently (no wonder...) but the other encodings plays (nearly) perfect ! (maybe thats why i sould "up"grade to windows xp ?? ;-) )

this seems to be a timing problem: the xvid rc? decoder skip occasionaly single frames on motion scenes on fast computers.

i hope this observation helps a little. i can mailing a small testencode too, but i don't thing that this is necessary: just encode scrolling fonts at the end of a cinema-film and play it with xvid rc? on a fast pc.

greetings, Heini011.

---
resolution was ever mod 16: (sorry for my confusing 1.post)

remark:

nic's FourCC changer in koepis xvid rc2 build don't know DX50 and the internal bitrate calc don't know matroska (i think that will be the future...)

gotaserena

16th February 2004, 13:48

Koepi, gamr:

Like I said, I feel that the problem is in the new installer? With Koepi's build the error is:

--
Exception EAccessViolation in module setup.exe at 40DC529B
Access violation at address 411C64B7. Writing of address 00000000
--

Curiously, gamr's build installs without any problems, I'm currently using it now.

Koepi

16th February 2004, 15:08

gotasarena:

"in 0x00000000" means that an object couldn't be created. Thus this is a missing function in some dll - more specific, in your case obviously a "windows dll" from WINE.

Did you install a gamr's build based upon nsis or the new innosetup installer?

Regards
Koepi

Didée

16th February 2004, 15:16

For completeness and safety, this is a repetition of a stats-window bug report in this thread (http://forum.doom9.org/showthread.php?s=&postid=445019#post445019):

- As of RC2, when using GMC, all GMC'ed frames are counted as B-frames, not as P-frames like they should.
The bars in the graph are correct. It's the numbers in the statistical table which are wrong.

Sorry

- Didée

sysKin

16th February 2004, 15:28

Originally posted by Didée
- As of RC2, when using GMC, all GMC'ed frames are counted as B-frames, not as P-frames like they should.
The bars in the graph are correct. It's the numbers in the statistical table which are wrong.Actually, all S-VOPs were just ignored. This b0rked average quants, frame counts and graph too.

Anyway, you posted it a couple of hours after it was fixed (see my signature).

Didée

16th February 2004, 16:46

What?

RC2 MAY CONTAIN NUTS?

And I was wondering why all those black bumps appeared in my face, all of a sudden!

- Didée, /on his way to hospital :)

gamr

16th February 2004, 22:50

Koepi: Currently all my builds are still NSIS, i havnt had time to full change to IS

sdsalsero

17th February 2004, 05:29

Has anyone had to chance to confirm my post re re-sizing errors (http://forum.doom9.org/showthread.php?s=&threadid=70379&perpage=22&pagenumber=5) during playback of anamorphic material?

Koepi

17th February 2004, 11:16

Ok, took the time to setup a linux.

[koepi@koepi XviD]$ wine --version
Wine 20040213

[koepi@koepi XviD]$ ls -la
insgesamt 176
drwxr-xr-x 2 koepi koepi 4096 Feb 17 11:08 ./
drwxr-xr-x 3 koepi koepi 4096 Feb 17 11:08 ../
-rwxr-xr-x 1 koepi koepi 5632 Feb 24 2002 AviC.exe*
-rw-r--r-- 1 koepi koepi 79 Feb 8 11:55 doom9forum.url
-rw-r--r-- 1 koepi koepi 52 Feb 8 11:59 koepishomepage.url
-rwxr-xr-x 1 koepi koepi 23040 Jun 12 2002 MiniCalc.exe*
-rwxr-xr-x 1 koepi koepi 9216 Dez 26 18:26 OGMCalc.exe*
-rw-r--r-- 1 koepi koepi 862 Feb 15 20:05 releasenotes.txt
-rwxr-xr-x 1 koepi koepi 13824 Nov 24 07:28 StatsReader.exe*
-rw-r--r-- 1 koepi koepi 1496 Nov 28 18:32 statsreader.txt
-rw-r--r-- 1 koepi koepi 2355 Feb 17 11:08 unins000.dat
-rwxr-xr-x 1 koepi koepi 76751 Feb 17 11:08 unins000.exe*
-rw-r--r-- 1 koepi koepi 44 Feb 8 11:58 xvidhomepage.url
-rw-r--r-- 1 koepi koepi 2967 Dez 21 11:10 XviD_Quant_Matrices.zip

[koepi@koepi system]$ ls -la
insgesamt 960
drwxrwxrwx 2 root root 4096 Feb 17 11:08 ./
drwxrwxrwx 5 root root 4096 Feb 17 11:07 ../
-rw-r--r-- 1 koepi koepi 73728 Feb 15 20:07 xvid.ax
-rw-r--r-- 1 koepi koepi 729088 Feb 15 20:06 xvidcore.dll
-rw-r--r-- 1 koepi koepi 159744 Feb 15 20:06 xvidvfw.dll

The only thing which didn't want to work was the registration of xvid.ax - but you don't need that dshow stuff for vdub.

Regards
Koepi

mazzo

17th February 2004, 14:00

After installing Jambo, I've experienced a weird problem: The decoder jumps in and out, mostly out. When I play a XVID file, the playback becomes sluggish and coarse, and when i check in the filters section, the XVID is not there any longer.

So I'll have to reinstall Jambo. THEN it works. For some time. 'Til it's the same all over again.

Can anyone explain that? I use Win2X.

sdsalsero

17th February 2004, 16:49

Koepi, you weren't replying to me, were you?

Koepi

17th February 2004, 17:05

sdsal:

nope. that was for gotasarena.

gotaserena

17th February 2004, 22:39

Koepi: fantastic, I will try it again as soon as I get to the machine! Anything in your .wine/config I want to know?

Koepi

17th February 2004, 23:06

gotasarena:

no, nothing special - i took the sample config that shipped with the wine tarball. You can also try winex (you need to fiddle around with CVS though):

http://www.transgaming.com/showthread.php?msg=1241&forum=3&thread=1237

cvs -d:pserver:anonymous@cvs.winex.sourceforge.net:/cvsroot/winex login

...Password press ENTER

cvs -z3 -d:pserver:anonymous@cvs.winex.sourceforge.net:/cvsroot/winex co wine

than change into the wine folder...

./configure --with-x --disable-trace --enable-opengl --disable-debug

make depend && make

make install

the configfile must be in the ~/.transgaming folder and not in the ~/.wine folder ...you can do a sym link

Regards
Koepi

crusty

17th February 2004, 23:28

@mazzo:

That sounds really freaky...could you post as many details as possible?

Including at least:
-Hardware
-OS & OS patch level
-Used players
-Used Vdub(mod) version

Have you tried:
-decoding using ffdshow, xvid via ffdshow or just Xvid.
-different players
-restart after reinstall
-Solve this issue: http://forum.doom9.org/showthread.php?s=&threadid=24305

Please report back whether or not any of these solved your isssues.

mazzo

18th February 2004, 09:20

@crusty

Including at least:
-Hardware
-OS & OS patch level
-Used players
-Used Vdub(mod) version

Hardware: 1.7 GHz Pentium III
OS: Win2X - last SP
Used Players: Zoom, Media Player Classic, Crystal, BSPlayer
VDubMod: 1.5.1

Have you tried:
-decoding using ffdshow, xvid via ffdshow or just Xvid.

ffdshow libavcodec and XVid disabled in ffdshow

-different players
yes

-restart after reinstall
no

-Solve this issue: http://forum.doom9.org/showthread.php?s=&threadid=24305
no

I suspect this, though: In the left of the directory window in Win2X a miniature player window opens when you mark a media file in the directory.

If I try to drag and drop the same file to the media player, the player will disable the XViD codec.

But if I just choose "file->open" from the player, it will NOT disable the codec.

I am not sure about this.

Anyway, it only happens with XViD.

gotaserena

18th February 2004, 11:55

Koepi:

Success! It works! Yay! :)

It seems the problem was in wine, after all. My apologies and an alert for everyone else to upgrade wine before installing. Thanks a lot for your patience on this!

Koepi

18th February 2004, 12:43

...don't forget about the troble with my GF i ran into ("get to sleep now!" - "no, i've to install linux for proving that this thing works") and the time ;)

Just kidding,

I'm glad you managed to get a more recent version of WINE up and running, and that it works with vdub for you.

Regards
Koepi

ChronoReverse

18th February 2004, 17:00

Hardware: 1.7 GHz Pentium III

Are you by any chance overclocking? I don't believe there is a 1.&GHz P3. Unless you meant a P4 of course. In any case, does dev-api-4 have any problems with overclocked systems at all? I seem to recall dev-api-3 not being 100% perfect with overclocked systems.

Bluedan

18th February 2004, 22:42

I think I have to report a crash. Though I'm using latest VDM build 2424 of version 1.5.10.1 which is not advised I think the crash is clearly related to XVid code. Look as these lines:

Crash reason: Access Violation
Crash context: An out-of-bounds memory access (access violation) occurred in module 'xvidcore'...
...while compressing frame 47707 from 02fa0000 to 03860020 (VideoSequenceCompressor.cpp:406)...
...while running thread "Processing" (thread.cpp:120).

Just writing this I had the next crash. But this time without a warning.

avs script:

LoadPlugin("C:\PROGRA~1\MULTIM~1\Video\Editor\GORDIA~1\mpeg2dec3.dll")
LoadPlugin("C:\PROGRA~1\MULTIM~1\Video\Editor\GORDIA~1\undot.dll")

mpeg2source("G:\2_Türme\2tü.d2v")
crop(8,78,704,420)
TomsMoComp(1,5,1)
LanczosResize(704,288)
Undot()

XVid settings for two pass encoding:

MPEG quant type
Q-pel
max consec.B-VOP 2 | quant ratio 1,5 | quant offset 1
packed bitstream
closed GOV
full qual 1st pass
credits constant quant@15
Motion search precision 6
VHQ 2
use chroma motion
turbo OFF
max I-frame interval 300
trellis quant, apart from that quant range unaltered

I can send full crash report, bits of source video or post here again.
I don't see any "challenging" settings.
And the post RC2 fixes don't touch this issue, I think.

XP pro SP1, Barton 2500+@3200+

sysKin

18th February 2004, 22:55

Originally posted by Bluedan
I can send full crash report, bits of source video or post here again.Full crash report will be useful, but if you can extract a piece of source that allows you to reproduce the crash, it would be very very useful. If you can, please send whatever you've got to syskin AT ihug.com.au . Thanks.
XP pro SP1, Barton 2500+@3200+ Overclocked systems are not safe - if xvid crashes at random and you can't really reproduce any crash, I'd start suspecting overheating because of overclocking.

Radek

Bluedan

18th February 2004, 23:26

No overheating problem. I'm not an OC enthusiast. I'm more the hasty-shaky type. This was more a question of really saving money!
I'll never reach 60°C (CPU diode) even after hours of putting 100% load on the CPU. Cooling is essential.

I'll mail you in some moments.

Koepi

19th February 2004, 00:58

Bluedan:

don't behave like sysKin is stupid. He has a _very_ valid point. XviD stresses your CPU in very small points in the cpu very much, so all your cooling efforts might fail.

Don't o/c your system, run it within it's specifications. If you still can reproduce weird behavour, we're willing to investigate.
if you still insist on overclocking, use divx3 and blame microsoft for being buggy.

Koepi

crusty

19th February 2004, 02:47

sysKin and Koepi have a very valid point.

About eight months ago I was running my Athlon XP 1800+ juuuust a bit over spec, and Xvid encoding sessions would just crap out half way through on a regular basis. When I went back to default speed it went ok.
And this is a system that would easily run 3dMark overclocked at that speed (and higher).

I know it's hard to believe, but it can really make a difference.
XviD just stresses some part of the CPU very much, and even at small overclocks can overstress your CPU.

sysKin

19th February 2004, 06:04

Originally posted by Bluedan
No overheating problem. I'm not an OC enthusiast. I'm more the hasty-shaky type. This was more a question of really saving money!
I'll never reach 60°C (CPU diode) even after hours of putting 100% load on the CPU. Cooling is essential.

I'll mail you in some moments. Unfortunately I couldn't reproduce any problems with your source and avs script. I did first pass and five different second passes, all went well. I used your settings.

The crash info, however, does indicate overclocking problem - but not with CPU but with your NVidia card. Did you increase CPU multiplier or just FSB? FSB is directly connected to AGP.

If you would take a look at crashreport's stack trace, it indicates that your nvidia driver (ntdll.dll) entered some kind of unhandled exception right before virtualdub started to compress the frame and used some kind of debug output right before the crash. The stack trace after that is apparently corrupted - it says that exectution entered plugin_dump (this plugin is not even opened by xvidvfw.dll, it's only used for debug purposes) and then entered transfer_8to16sub_3dne(), which - again - could not happen from plugin_dump. This function crashed because it had incorrect parameters (all of them are wrong).

Do you use some unofficial nvidia drivers maybe? If not then, unfortunately, I have to blame overclocking. If there was at least other person having any kind of encoding crash I wouldn't be so sure, but unfortunately (well, fortunately) there isn't.

Radek

PS. Why TomsMoComp on progressive source?

Bluedan

19th February 2004, 08:56

@Koepi: I didn't wanna sound as if I took syskin for a novice.
It's just that I really care for overclocking/stability issues.
Even extensive gaming (my girl-friend plays prince of persia for hours !) wasn't a problem so far.
I have to run prime as the standard tool to verify.

@syskin: Thank you for your analysis! The driver stuff is weird.
It's the official one. But not the VERY latest. I only raised the FSB to 200MHz, for the multiplier is locked. It's an ASUS a78nx deluxe board. I have to look into specs again.

Will report soon. I'm currently at work.
At last I'm glad that it seems NOT the codec to be blamed, but desperate that I likely have to throttle my precious one... :eek:

Leak

19th February 2004, 10:42

Originally posted by sysKin
If you would take a look at crashreport's stack trace, it indicates that your nvidia driver (ntdll.dll) entered some kind of unhandled exception right before virtualdub started to compress the frame and used some kind of debug output right before the crash.

Errr... no. NTDLL is a Microsoft DLL, as the file's properties will show you...

File Version: 5.0.2195.6685
Description: NT Layer DLL
Copyright: Copyright (C) Microsoft Corp. 1981-1999

;)

np: Luomo - Live @ Ultrahang Fest 27.09.03 (http://uhfest.underground.hu/)

sysKin

19th February 2004, 12:43

Bluedan

19th February 2004, 13:54

:eek:

New light on stage...
How am I supposed to find out if this dll is corrupted or somehow worth being replaced, updated or whatever?
This really leaves me in a state of uncertainty.

It's easier to blame Microsoft. Maybe some aof the latest updates wasn't advised at all!!

OT: Leak, I like the music that you're swinging to!

m0rtal

19th February 2004, 14:53

recently found strange bug, but cannot repeat it...
on my last encode I saw strange artifact: in top left corner there was a "triangle" area, which "legs" were laid on the edges on the movie, while hypotenuse creates "stairs" artefact when contents of the screen moves horisontally (and sometimes vertically). Though, in few minutes I've discovered that cause of these strangeness was Quantizer offset with value of 0.75. When I changed it to "1", artifact disappeared and never happened again! No matter what I was doing, including setting Quantizer offset back to erroneous 0.75, turning B-frames off and back on... WTF?

Koepi

19th February 2004, 15:49

m0rtal:

do you o/c your fsb or something? That may have been a biterror due to some weird circumstances. If it's not repeatable it's most likely no bug.

Regards
Koepi

jhutch

19th February 2004, 18:44

Originally posted by Leak
Errr... no. NTDLL is a Microsoft DLL, as the file's properties will show you...

File Version: 5.0.2195.6685
Description: NT Layer DLL
Copyright: Copyright (C) Microsoft Corp. 1981-1999

;)

np: Luomo - Live @ Ultrahang Fest 27.09.03 (http://uhfest.underground.hu/)

I have had some crashes lately with the NTDLL as mentioned above. I finally narrowed it down to two specific rips (at first I just shrugged it off as a random crash). I'm still working on finding where in the vob it dies, so once I have that info, I'll forward it on, sysKin.

One similarity I've seen is that my machine is an AMD athlon, too. Mine is not overclocked, either. I'm also gonna try running the same encode on a different machine to see if the error is specific to the computer or to the encode. (I'm at work right now, or I'd start running the tests now).

Is there anything specific I should look for or try to help with the debugging process?

JHutch

Wilbert

19th February 2004, 22:42

I also tried XviD 1.0 rc2, but I'm going nuts :) The filesizes are way off.

Source: huffyuv 75 frames (640x480, 25 fps).
Settings: everything disabled (VHQ=0), MPEG quantization.
Bitrate: 1200 kpbs (should result in 1200*3/8 = ~440 KB).
I and P: 1-31, no b-frames

Results (vdub 1.5.10.1):
2 passes: 180 KB (average quantizer 12.44)
1 pass: 532 KB (average quantizer 5.67)

I Frames: 2.67%, P Frames: 97.33%

Am I doing something stupid?

crusty

19th February 2004, 23:59

@Wilbert:

-Try setting Quantizers in 2-31 range
-Try using a bigger clip. Maybe 3 seconds isn't long enough to properly adjust for?

BTW: where did that 3/8 come from?

Wilbert

20th February 2004, 00:47

-Try setting Quantizers in 2-31 range
Same results.

BTW: where did that 3/8 come from?
3 seconds, 8 bits = 1 byte

Leak

20th February 2004, 02:09

Originally posted by crusty
-Try using a bigger clip. Maybe 3 seconds isn't long enough to properly adjust for?

I'm pretty sure I remember Koepi saying that the rate control in 2pass is tuned to clips of about half an hour or longer; I doubt it'll work correctly with such a short clip. (It *does* work great with 24-minute episodes, I can tell you... :))

np: Monolake - Remoteable (Cinemascope)

Koepi

20th February 2004, 02:51

It's _definatly_ the 75 frames length. It's too short. Set the overflow settings to 20 and it'll more likely hit your desired size - at the prize of fluctuating quantizers (for 2pass). In 1pass, the reaction delay factor could be set to 5, that should help.

Regards
Koepi

...who wonders why someone would encode a 75 frames clip. :)

m0rtal

20th February 2004, 08:21

Originally posted by Koepi
do you o/c your fsb or something? That may have been a biterror due to some weird circumstances. If it's not repeatable it's most likely no bug.
no, no o/c, usual circumstances.
problem is that I encountered this issue for the second time, but I thought that was the broken source...
and my fellows sees that error on their computers a few times exactly in XviD encodes...
but nobody can't tell when this error appears or what turns it "on"...
anyway, there is one similarity - this issue is much more visible in fullscreen mode. dunno if it helps...

Wilbert

20th February 2004, 11:07

...who wonders why someone would encode a 75 frames clip. :)
We are working on a comparison of smoothers for analog caps. I have limited webspace :)

I will try your suggestions. Thanks!

Bluedan

22nd February 2004, 13:39

Now when all overclocking has been turned off both passes went fine one after another.
I still have to run Prime to verify.
To me astonishingly it means that no other app being in use on my oc'ed machine had the capability to stress my CPU that much to make it fail. :rolleyes:
Ok, must be related to a certain kind of calculation operations.

I still doubt that it causes heat issues, but for sure this CPU must have been labeled BARTON 2500+ for some reason within post-production testing.

battyice1847

24th February 2004, 16:34

Now when all overclocking has been turned off both passes went fine one after another.

If you would like to try and figure out exactly what is causing the problem on your machine, I highly recommend the overclocking section at http://forums.amdmb.com/ You also might want to check out the PC Hardware section on this forum.

Perhaps you need better cooling, some voltage tweaks, or different memory timings; the people on either of the forums mentioned above will certainly help you figure out your problem.

On a side note: I run an Athlon 2700xp at 200*12 with a Volcano 12, CPU die never goes over 45C even after several hours of xvid encoding :-)

Good luck getting your machine diagnosed.

-Rob

Moitah

25th February 2004, 19:21

Avery Lee posted this on the VirtualDub forum after researching a problem I was having (http://virtualdub.everwicked.com/index.php?act=ST&f=15&t=6105):looking at the source in CVS it looks like there are a couple of bugs in the XviD codec wrt format handling. One is that ICM_DECOMPRESS_GET_FORMAT returns a bogus biSizeImage that is 8 times too big, and another is that the handler for ICM_COMPRESS uses lpbiOutput->biSizeImage which is basically guaranteed to be garbage on entry.It turned out that neither VirtualDub nor XviD were at fault, but I thought you might want to know about this.

Ryokurin

26th February 2004, 00:38

Originally posted by erdie
don't know if it's the same problem, but with RC1 & RC2 I do too have stuttering playback:

* only RC1/RC2 encodes are affected
* RC1/RC2 decoder used, no ffdshow/standalone decoder
* Mplayer2 (WMP 6.4), DX 9.0, some ASUS MX 440 card
* options used for encodes: all defaults except 2 b-frames, 20 i-frame boost, all min quants set to 2

these encoded clips play fine with XviD-Dec-1.0-Beta3.exe and ffdshow using XviD-24062003-1 for decoding

postprocessing is off, CPU usage at 25-30% (Duron 1600)
clip res is 576x432, datarate about 1000kbit, no sound

I've had the same problem but its a file off of a HDTV rip 1024 rez. For the time being, ive been using ffdshow to play the file, but it somewhat not desired as it messes up the rendering often (rolling fog and all that junk) also the latest versions of FFDshow are also starting to have the same problem. Same deal with that it started with RC1

poochie2

28th February 2004, 15:54

Is it normal that (happened like after installing RC1) using the included filter do decode xvid (no BVOPs, Chroma On, VHQ2, Turbo, No Trellis or Qpel or GMC and so on) it seems that the playback is a little laggy, but if I install the XvidDecoder 1.0 Beta 3 all is fine?

sysKin

28th February 2004, 17:19

Originally posted by poochie2
Is it normal that (happened like after installing RC1) using the included filter do decode xvid (no BVOPs, Chroma On, VHQ2, Turbo, No Trellis or Qpel or GMC and so on) it seems that the playback is a little laggy, but if I install the XvidDecoder 1.0 Beta 3 all is fine? http://forum.doom9.org/showthread.php?s=&threadid=71251

:/