View Full Version : Selam! (XviD-1.0-Beta3-26122003)
Pages :
1
2
3
4
5
6
[
7]
8
chemmajik
14th January 2004, 04:26
Well let me ask this is there any code that does change priority's within the beta builds?
Also is XVid still compilable under Visual C 6 Pro?
Aktan
14th January 2004, 08:15
@mikeson
Thx for the reply, and sorry for not looking for the answer more :)
Koepi
14th January 2004, 10:25
chemmajik:
no. it's the encoding application which sets priorities, a codec _can't_ do that.
syskin:
if he used a build of mine i can't think of any condition where a sprintf would cause that, the buffers(in the stats DebugOutput) are sufficient. It would have happened to more people if that would be the problem - i'm very confident.
Regards
Koepi
sysKin
14th January 2004, 13:11
Originally posted by Koepi
syskin:
if he used a build of mine i can't think of any condition where a sprintf would cause that, the buffers(in the stats DebugOutput) are sufficient. It would have happened to more people if that would be the problem - i'm very confident.Yes it's definitely not sprintf() here - I just meant that lame bug will also make application disapear into void ;)
Radek
PS Koepi where are you:confused:
homersapien
14th January 2004, 18:46
Originally posted by Koepi
If a program vanishes into nothing - without error report - this is sure a memory problem. Either your memory is broken or you use too aggressive memory timing settings. Seen this myself on some overclocked computers, and it always helped to _not_ overclock the system.
Regards
Koepi
In my case, it has nothing to do with the computers, it is a problem with the 1.0 builds. Or maybe the combination of 1.0 and vdub/mod, because it only happens when I try to run jobs using the Job Control. All non-Beta 1 Xvids I've tried have been fine.
Prettz
14th January 2004, 19:16
What ever happened to the "Payback Proportionally" and "Payback with Bias" options?
edit: a second question: syskin's sig says that weight zones with different weights don't work in beta3. Did they used to work in beta2? Because I've done 1 encode using different weights with beta2 (haven't tried beta3 yet due to no internet access) and it seems to have done what I wanted it to.
Soulhunter
14th January 2004, 19:28
Originally posted by homersapien
Or maybe the combination of 1.0 and vdub/mod, because it only happens when I try to run jobs using the Job Control...
Same for me !!!
But I thought its VDubMod's fault... :confused:
Bye
Koepi
14th January 2004, 20:05
A, you use jobcontrol. Don't do that with certain vdub(mod) versions, it's broken there, this is true. It works correctly for me, but I still use vdubmod 1.5.4.1(build 2066) and an older avisynth version.
Thanks for adding the missing information to track down your problem :)
Regards
Koepi
vip
14th January 2004, 20:18
Got excatly the same problem as homersapien described before. All 1.0 beta branch crashes vdubmod when using job control. But it happens only on my home PC (Athlon XP2200+/256Mb/KT266A, not overclocked), on my new office PC (Celeron 2.4GHz/256Mb/i845PE, not overclocked also) it works like a charm (thanks to developers and Koepi for excelent work)... All systems has WinXP Pro and DirectX 9b installed, versions of xvid codec (beta3 build by Koepi) and vdubmod (1.5.10.1 build 2366) are the same on both machines. Had a total clean up on my home pc and reinstalled codecs - didnt help...
Koepi
14th January 2004, 20:26
Vip:
please try that vdubmod version I use on your athlon - I have an athlonXP here, too. Can you report back if it works correctly then?
Regards
Koepi
mikeX
14th January 2004, 23:41
is it me or are all the crashes reported here happening on Athlons??
i think 1.5.4.1 2066 crashed with beta 3 on me once too
most recent crash (vdubmod 1.5.10.1(2407)):
An out-of-bounds memory access (access violation) occurred in module 'xvid'...
...while compressing frame 34765 from 032b0000 to 03bf0020 (VideoSequenceCompressor.cpp:406)...
...while running thread "Processing" (thread.cpp:120).
trying the same pass right now with 1.5.4.1 ...
Danzel
15th January 2004, 01:24
@chemmajik
Yes, Xvid still compiles with VC6, i did it myself just the other day ;)
I followed the guide at http://www.discdude.net/xvid/compile.html
but, the one problem i had was that nasm wouldnt work, just use the latest nasm for win32 off the nasm page and you wont have this problem
(I used the one that the guide links to down in the faq section, which wouldnt work for me at all)
Danzel.
mikeX
15th January 2004, 11:56
trying the same pass right now with 1.5.4.1 ...
OK :D
chemmajik
15th January 2004, 11:56
Thanks Koepi(had a feeling it was the application, prob need to email VirtualVCR author then) & Danzel(cool VC6 compiler help) responses... I'll be glad when the gui gets finally finalized so we can get first pass hiquality back to working as easy & good as prior stable builds with default settings. The beta's are so much different then prior builds, but I understand why it was implemented thru the various profiles, even thou there maybe needs of adding a couple like 480x480 or 640x480 & 480x240-479 modes profiles.
seany
15th January 2004, 20:09
Hi there,
I've just a simple question: where to turn on deblocking/deringing? I can't find it... (using WinXP). Well I found out that with the "old" media player you can turn it on in the options of the file you're playing - but isn't there another way to get to these options????
Thanks a lot!
seany
Asrial
15th January 2004, 22:27
Koepi, can you create an option to output the frame information (the section that shows during encoding) to a text file so that it can be reviewed later?
I want to check what quants my encode is doing but I keep forgetting to check before I close vdub.
communist
16th January 2004, 01:31
Originally posted by seany
Hi there,
I've just a simple question: where to turn on deblocking/deringing? I can't find it... (using WinXP). Well I found out that with the "old" media player you can turn it on in the options of the file you're playing - but isn't there another way to get to these options????
Thanks a lot!
seany
WMP 7 or higher doesnt allow or have the feature to control codec.
My advise use a real media player like Media Player Classic :)
m0rtal
16th January 2004, 12:04
recently I've tested b-frames on 1cd encode
settings was
max consecutive bvops: 20
bvop sensivity (for movie): 3
bvop sensivity (for credits): 5
result was amazing :)
codec often inserts all 20 b-frames in a row, and it doesn't affect quality! I should consider to increase "max consecutive bvops" to 30 ;)
symonjfox
16th January 2004, 12:42
Originally posted by m0rtal
recently I've tested b-frames on 1cd encode
settings was
max consecutive bvops: 20
bvop sensivity (for movie): 3
bvop sensivity (for credits): 5
result was amazing :)
codec often inserts all 20 b-frames in a row, and it doesn't affect quality! I should consider to increase "max consecutive bvops" to 30 ;) Me too. It's a good thing.
The bad things I think are 2:
1- Maybe the processing power needed for decode 20 b frames is greater that decode mixed b and p frames, I think.
To the other side, these frames are smaller (lower bitrate) and should take less power to decode ... I don't know. Maybe someone more technical than me could answer.
2- Maybe there should be any problems with standalones, they sometimes have trouble with more than 1 b frame, with 20 they get crazy :D
If someone cold try on standalone, I'd be glad. Until I'll have more feedback about 20 bframes, I won't use more than 5.
Micro
16th January 2004, 12:44
Originally posted by mikeX
is it me or are all the crashes reported here happening on Athlons??
i think 1.5.4.1 2066 crashed with beta 3 on me once too
most recent crash (vdubmod 1.5.10.1(2407)):
An out-of-bounds memory access (access violation) occurred in module 'xvid'...
...while compressing frame 34765 from 032b0000 to 03bf0020 (VideoSequenceCompressor.cpp:406)...
...while running thread "Processing" (thread.cpp:120).
trying the same pass right now with 1.5.4.1 ...
I had two crashes with XviD 1.0 beta3 and Vdubmod 1.5.10.1 job control. Cashes happened always during second pass. Running second pass again without VD job control - no crashes.
Running WinXP on P4 2.4 @3.06GHz.
All other applications were stable so far (more than 6 months)
m0rtal
16th January 2004, 12:47
Originally posted by symonjfox
The bad things I think are 2:
1- Maybe the processing power needed for decode 20 b frames is greater that decode mixed b and p frames, I think.
To the other side, these frames are smaller (lower bitrate) and should take less power to decode ... I don't know. Maybe someone more technical than me could answer.
I think in our new millenium it's not so important anymore :)
2- Maybe there should be any problems with standalones, they sometimes have trouble with more than 1 b frame, with 20 they get crazy
is don't bother me much - I'm using matroska container, which is currently not supported by standalones, so I don't care :)
Manao
16th January 2004, 13:09
@micro : I would say VDubMod 1.5.10 is guilty. It is highly unstable. I now use VDubMod 1.5.4 for compressing, and 1.5.10 for muxing into ogm / mkv.
symonjfox
16th January 2004, 19:22
Originally posted by m0rtal I think in our new millenium it's not so important anymore :) Instead I think it's important, because much people still have an old computer, and some standalones have not enough power to decode some kind of streams.is don't bother me much - I'm using matroska container, which is currently not supported by standalones, so I don't care :) First or later I really think that everyone of us will have a standalone. IMO it's important create streams playable NOW, in the FUTURE, and EVERYWHERE!
Maybe not all have my targets of life, and use Xvid for the reasons I use it. But I cooperate to grow all togheter.
Heini011
16th January 2004, 19:37
hi,
my problem with virtualdubmod 1.5.4.1 crash was NOT xvid's fault! i had used to many filter instances in my avisynth script.
i have done 2 large 2-pass conversions in batch mode now without any problem.
greetings, heini011.
mikeX
17th January 2004, 02:17
nice to see a P4 crash come in to play :devil:
i had crashes without job control iirc (i'm not really sure)
anyway things so far indicate it's not xvid related :)
btw how does everybody run such overclocked systems??? i try raising my FSB a few Hz and i can't even get into windows, does my cooler suck that bad?... :(
Blue_MiSfit
17th January 2004, 02:55
btw how does everybody run such overclocked systems??? i try raising my FSB a few Hz and i can't even get into windows, does my cooler suck that bad?...
a little OT, but a brief explanation
your ram probably sucks. If (for example) you are running a palomino core athlon XP (anything before the 2500+), it rides a 266mhz DDR bus. In this situation, your ram is likely DDR266(pc2100), which runs at a clock frequency of 133mhz (266ddr). Most DDR266 doesnt tolerate overclocking very well, especially at low latencies. I run DDR400 memory, and my Barton core athlon xp, which operates at at 333mhz ddr bus by default can run at 200mhz perfectly.
It all depends on how good your CPU, cooler, motherboard, and RAM are.
If you have an athlonXP, try boosting your clock multiplier a bit, as this doesnt affect your fsb speeds at all, but rather the resultant clock frequency of your cpu.
sorry about being OT, but any scent of overclocking leaves me aroused lol...
peace
~misfit
alexnoe
17th January 2004, 10:21
Blue_MiSfit:
The Kingston DDR266 CL2 memory I used some time ago tolerated 152 MHz (b0rks at 153), and the Infineon DDR333 memory I know have tolerates 188 MHz (did not test more). So you are even more right with 'it depends on the memory you have'
kadajawi
17th January 2004, 13:38
My Infineon PC2700 doesn't take very much... as soon as I raise the FSB I get problems with memtest86 in one test after a few hours... how many errors and how long it takes depends on the OC (well, other than that its stable... up to 400 MHz (didn't test more). I can raise the RAM voltage for a bit of stability.
Anyway, my 1700+ CPU runs at 2600+. Could do 2700+, but I would need to raise voltage quite a bit. Well, it really depends on your cooling, your CPU (every CPU is different) and your other hardware, mainly board and RAM.
But I agree this is the wrong place to discuss about overclocking :D
kadajawi
17th January 2004, 21:46
I noticed that while playback using Windows Media Player or Zoom Player XviD a video gets much brighter. The same video in huffyuv looks much darker, even if the video is encoded using quant 1 etc. So I tried loading it into VirtualDubMod, and voila, it looks as dark and detailed as it should. I've tried XviD and ffdshow, no difference. Any idea?
Doing side by side comparison of the XviD video (using default settings and "check everything you can" ;) setting) and huffyuv using VDM I also noticed that the video got a greenish tint, a bit muddy, a bit darker. But really not very much...
Koepi
17th January 2004, 21:55
Search for your overlay colour controls and you'll see that the drivers set the brightness to a higher value.
Koepi
kadajawi
17th January 2004, 23:03
That solved it. Though I never changed that. But I noticed that default with the latest NVidia is 114%. Strange.
vip
18th January 2004, 14:15
Koepi,
i've tried vdubmod 1.5.4.1 as you suggested before and it crashes too, regular vdub crashes as well... After flushing avisynth plugin folder as Wilbert suggested in this thread (http://forum.doom9.org/showthread.php?threadid=69008) and leaving there only mpeg2dec3, undot and convolution3d vdubmod dont crash anymore... This is a bit weird 'cos i have used them all the time so they couldnt be the real reason of vdubmod crashes...
Flipin
18th January 2004, 16:29
kadajawi,
The nvidia overlay "problem" is far stranger than 114%. With both of my nvidia cards (GF3, GF4), the image is actually darker than the original when everything is set to 100%. It's a sort of a level cut-off so everything dark is even darker, if not black. Also the colours are a bit pinkish/bluish. As far as I can tell, the defaults are trying to emulate the TV colour spectrum when using the default 6500/9300 colour temperatures on your CRT.
That's fine as long you use the defaults, but I'm using custom colour settings that makes even 9300k look greenish warm. So in my case, nvidia's settings will do more harm than good.
Some ways of fixing this: use Zoomplayer and use the "Use color control interface" and reset the colours.. It'll give you the original colours. Another way of fixing it is by using VMR9. I've heard some ppl. complaining that it's crappy quality but that's only because it doesn't support I420, YV12,YUY2,UYVY or RGB output properly (bad conversion?). They all give various degrees of green or pink for some reason. It only works perfectly is when using YVYU output (slow) in ffdshow. This of course probably depends on your GFX and it's texture rendering capabilities but even now I'm using this on my GF4 and Radeon7000 on another comp. without problems.
The resize quality is slightly better with VMR9 than on nvidia overlay, that being the only difference between using zoomplayer's colour adjustments and VMR9. (+ some bugs with multiple monitors when using nvidia overlay, as zoomplayer crashes)
Hope this helps,
Flipin
begu
19th January 2004, 10:02
Originally posted by m0rtal
recently I've tested b-frames on 1cd encode
settings was
max consecutive bvops: 20
bvop sensivity (for movie): 3
bvop sensivity (for credits): 5
result was amazing :)
codec often inserts all 20 b-frames in a row, and it doesn't affect quality! I should consider to increase "max consecutive bvops" to 30 ;)
Well what values can be used in bvop sensitivity. I tried 20 and it did cause more bframes. I tried even 60 and maybe got few more. Is there any trick to do the b-frame positioning in the stream in the same way than ffvfw? It places frames like this (when using 3 bframes):
i p bbb p bbb p bbb p bbb ...
But I have found that xvid chooses not always use 3 consecutive, like this:
i p bb p bbb p bbb p bb p bb p b p bbb ...
I have not tested if I use 100 for sensitivity, maybe then it will place always 3 b-frames in row.
Are the sensitivities in different zones somehow dependant from each other, like m0rtal used 3 and 5 ?
m0rtal
19th January 2004, 10:11
Originally posted by begu
Well what values can be used in bvop sensitivity. I tried 20 and it did cause more bframes. I tried even 60 and maybe got few more. Is there any trick to do the b-frame positioning in the stream in the same way than ffvfw? It places frames like this (when using 3 bframes):
i p bbb p bbb p bbb p bbb ...
But I have found that xvid chooses not always use 3 consecutive, like this:
i p bb p bbb p bbb p bb p bb p b p bbb ...
I have not tested if I use 100 for sensitivity, maybe then it will place always 3 b-frames in row.
Are the sensitivities in different zones somehow dependant from each other, like m0rtal used 3 and 5 ?
well, it's almost useless to have 3 consecutive b-frames and sensivity @ 20 or 60 - you can't get more than 3 frames in a row, so why bother? if you want to have more b-frames, you should try increasing "max consecutive" value.
and about b-frames in zones... why not? credits are less important to me, that's why I increase sensitivity... and got more b-frames comparing to main movie.
begu
19th January 2004, 13:53
Well, actually I meant that if I set max consecutive b-frames to 3, in the result I get something between 1-3 consecutive b-frames.
Like previous post:
i p bb p bbb p b p b p bb p bbb p bbb .. so on.
I get smooth results using ffvfw and 3 b-frames, and I get:
i p bbb p bbb p bbb p bbb .. so on.
See, there isn't always 3 consecutive b-frames using xvid.
But maybe it is not harmful always having 3 b-frames in a row. The encoder seems to make good decisions, if using a b frame or not.
The behaviour between the codes just made me to think is there possible the xvid to produce always 3 (or more) b-frames in a row. I just then compare the result and see, if there is any difference. Just trust Your own eyes :)
m0rtal
19th January 2004, 14:02
begu
I think that codec makes it's own decisions regarding b-frames, thus inserting from 1 to n b-frames standing upon it's own algorythm.
but I think that it is possible to enforce codec to always insert as much b-frames as user want... good proposal for developers!
Koepi
19th January 2004, 14:43
If you want to have "constant bframes" in a row you just need to set the bframe sensitivity to i.e. 100 or more - the codec will then be forced to nearly always use the IPBBBPBBB scheme.
(This isn't good for quality and/or compressability though.)
Regards
Koepi
begu
20th January 2004, 10:07
Thanks Koepi, that was just the idea, I was looking.
Now, there is one question more.
If I want better quality out of b-frames, I must lower their quantizers. I did a test, where I did set the quantizer ratio to 1.00 and the offset to 0.
In the result I got always the same quantizer for the b-frame than for the p-frame. The result did have better quality compared to default 1.50 / 1.00. And the frame size in kb was still lower in b- than p-frame. And ofcourse the above will happen.
But the question is, how does the b-frame image quality compare to the p-frame if their quantizers are the same? Like quantizer 3 for both. The b-frame uses little less kb, but will it contain as much quality as p-frame?
I ask this because in default setting the b-frame contains less image quality than p-frame (due to the quantizer difference). And I need as much image quality as possible. So using the same image quality for b- and p-frames would be the optimal thing. So should the quantizer of the b-frame be the same or maybe one notch higher than the quantizer of p-frame to obtain the same quality? Or maybe the b-frame should be quantizer of one notch lower than p-frame. That would be overkill I think, right? (also maybe it is not possible, it would need smaller than 1.00 for ratio, maybe it works, hmm) [sorry for bad english]
I have noticed, that if I use the default 1.50 / 1.00 together with 2 or 3 consecutive b-frames, the quality slightly pumps up and down in the cycle of p- and b-frames. I need to get smooth quality, and it seems that using same quantizer will improve it.
So in the end, I may have answered to my own question. But maybe someone more professional could give an aspect too. :)
Selur
20th January 2004, 10:38
just wondering did anyone try a quantizer ratio of 0.75 for bframes ?
Cu Selur
m0rtal
20th January 2004, 10:42
Originally posted by Selur
just wondering did anyone try a quantizer ratio of 0.75 for bframes?
quantizer ratio or offset?
I've tried offset 0.75, works just fine!
Selur
20th January 2004, 11:51
quantizer ratio or offset?
like I wrote, I ment ratio :)
m0rtal
20th January 2004, 11:53
Originally posted by Selur
like I wrote, I ment ratio :)
then my answer will be "NO" :(
Soulhunter
20th January 2004, 18:16
I think I do a small PSNR test for tomorrow...
Fixed qunat2 with no BVOP's -VS- Fixed qunat2 with quant2 BVOP's
PS: Has somebody allready tested how cartoon-mode works with real movies ???
Bye
Koepi
20th January 2004, 20:21
Yes. A year ago (or even longer) sysKin invented a small glitch he called TOO_SMALL_LIMIT.
Overall reaction was:
- Booo! Where are my details?
- Boo! You suck!
and so on.
It's cartoon mode. What do you expect?!?! It won't help quality on "real life footage".
Koepi
The Link
20th January 2004, 22:22
- Booo! Where are my details?
- Boo! You suck!
Should one be frightened of an avatar with such a strong personality as yours? ;)
(Sorry for being off topic!)
mikeX
21st January 2004, 03:35
talking about avatars and being completely OT i would like to say Teegedeck stole my idea for an avatar :devil:
oh well :rolleyes:
i guess i'll look for a picture of Harpo :D
b00zed
21st January 2004, 08:49
Originally posted by Blue_MiSfit
a palomino core athlon XP (anything before the 2500+)
Actually the palominos topped out at 2100+, and all palomino speed grades were eventually replaced by thoroughbreds anyway.
I hope this line of discussion hasn't become so OT that it gets removed...
Koepi
21st January 2004, 09:25
Further o/c or hardware discussion can take place in our PC Hard & Software Forum (http://forum.doom9.org/forumdisplay.php?s=&forumid=16) - thanks for not further polluting this thread.
Regards
Koepi
begu
21st January 2004, 09:32
Well what about my post considering the quality of the b-frames, when using the same quantizer for p- and b-frame? Anyone else tried this?
I did not yet try lower quantizer for b-frame, but when using the same, the quality is nice. Also it takes little less space than using only p-frames, when trying to get best possible quality. I will do tests more soon.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.