Log in

View Full Version : Selam! (XviD-1.0-Beta3-26122003)


Pages : 1 2 3 [4] 5 6 7 8

drebel
30th December 2003, 13:14
@iago

You should also try adaptive quantization (old lumamasking).I think you 'll be pleasantly surprised there ;) I know I did.The gain is not that big but in cases which every bit counts...
I'm adressing to you as the "expert" in this old prob.It would be nice to know that Xvid made the use of lumafilter() obsolete, even though it never slowed down the encoding proccess much.

Certain posts mentioned "not that stable walls".Qpel or not?Does catoon mode help finally in this matter?

I ' ve been playing around with the "Usual suspects" movie R1 version : 2cds,ac3 5.1.I 've tried almost every setting available in small tests , even a whole encoding with the method which uses quant 3 for the first pass.I might say I liked a couple of things (IMHO):

- I grasped by the fact (mentioned in the forum by bond IIRC) that the human eye spots more details in vertical axis ,so I resized anamorphically (I tried to avoid resizing at all but I could fit the movie to my target with Andreas matrix).Zoom player does a fine job when Custom AR is selected (2.5:1).The only prob was that when I cropped from inside Avisynth ,there was a frame mismatch (overlapping ?) or something that created strange shadows from previous frames.So , I cropped from DVD2AVI3.

- The method with quant3 in first pass gave me a second pass larger than the first but I liked the quality or the traditional way better (less blocky for my eyes).

Nice first pass speed & quality boost(2nd pass) ,guys.

kadajawi
30th December 2003, 13:15
@MajinMarc: I believe the wannabe thing is done, no need to talk about it over and over again.

About your problem: I haven't experienced a speed up since Beta 2, except the fast first pass (twice as fast as the second pass). But as you say that the addition of cartoon mode was the only thing you changed, maybe try without. You don't have to run through the whole encode again, just a few minutes would be enough. 1-2 fps is indeed slow, try Isibaar's suggestions too :) Btw, what CPU do you have?

mikeson
30th December 2003, 14:14
@GolovachLena:
It rather sucks...
Probably we should gather some money to help Koepi buy some P-4 in order to debug SSE2 optimization code... at last!
Please learn how to behave on this forum or do not post at all. In your post you are insulting not only Koepi but whole XviD dev team. Furthermore your post has ZERO value as a bugreport.

Take your time, read Koepi's and Teegedeck's posts on previous pages about OpenSource and XviD and think first before you post or do not post.

GolovachLena
30th December 2003, 14:56
Take your time, read Koepi's and Teegedeck's posts on previous pages about OpenSource and XviD and think first before you post or do not post.

Forgive me for my bad language, i didn't want to insult anybody, it's merely misunderstanding. I'll read about OpenSource, but how this reading can help me to complain that SSE2 optimization obviously is NOT working? I have a P4 and i'm getting top performance only when i turn SSE2 off and turn on MMX and possibly integer SSE. What kind of bugreport can i provide except of empirical testing? Xvid doesn't crash or somewhat, it just works slower than it can.

mikeson
30th December 2003, 15:06
@GolovachLena:
I have a P4 and i'm getting top performance only when i turn SSE2 off and turn on MMX and possibly integer SSE
For this reason there is option in GUI to specify exactly which optimizations do you want to use.

If you are geting poor performance, disable CPU consuming features like Chroma motion, VHQ4, GMC a/o Qpel (although I wouldn't recommend disabling them), but this was already discussed here...

XviD is still evolving and in the first place there is stability and image quality, speed comes next.

Read here (http://forum.doom9.org/showthread.php?s=&threadid=24924) how to post bugreports.

Mole
30th December 2003, 15:41
Does the "Turbo Mode" has any impact on file size or quality?

Koepi
30th December 2003, 15:45
Mole:
yes, it has a small impact, quality may be a little lower, size a little bigger. But not much noticable.

Regards
Koepi

dimzon
30th December 2003, 15:50
Originally posted by Koepi
Mole:
yes, it has a small impact, quality may be a little lower, size a little bigger. But not much noticable.

What does it mean: not much noticable?

Koepi
30th December 2003, 15:52
dimzon:

just test it on a 1000 frames sample you like for yourself - once with turbo, once without. You need to judge for yourself.

Regards
Koepi

N-Bomb
30th December 2003, 16:59
What might be another bug with FFDShow and the new beta (don't see anyone else mentioning it)

I disabled packed bitstream and it seems that with this latest test encode, it starts the video with a few (looks like 2) frames from the end of the file, before moving on to the episode proper.

Actually, maybe not a bug with FFDShow, tho it goes away when using the XviD Dshow... in Virtualdub, those two frames from the end are there. This is very wierd. Anyone have a similar problem, or a solution?

Thanks!

assa69
31st December 2003, 01:32
hello everyone one

i just downloaed this build and i am using virtualdubmod version 1.5.10.1 but i started to have probelms like some of the clips i encoded using beta 2 apearing upside down and what is worst virdubmod stoped encoding now totally i mean when i hit the button to start encoding virdubmod crashs same thing is happing with virtualdub too why this happing

was there a bug in beta 2 and did i lost all the clips i encoded using beta 2.?

i am new to this all i started encdoing 2 weeks ago so i am sorry if this was obivious this thing to ask

thanks

Stux
31st December 2003, 06:53
Originally posted by Isibaar
Unfortunately that's not true. I implemented the 132 inter MB refresh period as well as all the other additional requirements to IEEE 1180 that are specified in the MPEG-4 standard. But: it didn't help. To avoid visible mismatch between simple idct and walken idct (which are both perfectly compliant btw) you'd need a refresh interval of about 20 inter MBs. However this would mean a huge loss in compression performance.

So the situation is like this: It was a huge mistake to leave the idct implementation unspecified in the MPEG-4 standard. The requirements that were specified are absolutely insufficient. Autodetecting the idct that was used for encoding (if possible at all) is a rather weak and limited approach to cure idct mismatches. I've already posted some more info about the idct issue here on the forum: http://forum.doom9.org/showthread.php?s=&threadid=56190&perpage=20&pagenumber=6


Yes, its a serious problem, and qpel just makes it worse

assa69
31st December 2003, 09:33
Stux


Do you have the same probelm .....???

MajinMarc
31st December 2003, 10:02
@all who responded to my last post.
Yeah I did notice that GMC decreases speed. but I did notice better quality with qpel. Fast first pass actually hasn't done anything for me. I have seen a 1fps increase in most of my AVs scripts. but even if I run a base encode with no filter, no cropping, no resizing I max out at 11fps...which I find strange seeing as how I get 25fps with divx...I don't like divx which is the reason I use Xvid. my current PC stats are as follows.
Dell inspiron 4100
P3 1.3 Ghz
256MB DDR
32MB Video Card.

This works fairly well I know it's a little weak but when I encode I do so with almost nothing running in the background. I have seen a system that is only 200mhz stronger than mine pull almost 12fps faster. If I remember correctly the Xvid codec is athlon optimized maybe this could be part of the reason. Is there any chance that the Xvid team will be making a Intel Optimized version...cause after referring with my friend a few seconds ago actually he has a dual p4 2.3HT and he only gets double the framerate and nowhere near the speed of the doom9 codec comparrisons 32fps.

Thanks for the input.

Teegedeck
31st December 2003, 10:07
Welcome, assa96.

First of all, please use proper punctuation, your post is hard to read.

Stux didn't comment on your problem, not even on an XviD-problem; he's talking about a flaw of MPEG4 standards.

My guess would be that you've accidentally entered non-existing values in the zones, or don't point to the correct .stats-file in 2nd pass. If this ain't the case: Does encoding with other codecs still work? Give us some details about your setup.

Mr_G_123
31st December 2003, 10:21
will nic or umaniac release some of their own version/modifactions to xvid 1.0 binary?
or (the mighty :D) koepi will do all the job (what a wonderfu job:D ).

Koepi
31st December 2003, 11:53
Nic will compile builds soon, too. He hasn't found the time recently due to his job, rejig,...

uManiac seems to have left for nearly a year now :-(

Regards
Koepi

assa69
31st December 2003, 13:52
Teegedeck

thanks for your concern and i am sorry for the misunderstanding

to makes things clear

i use single pass bite rate at max.

mothion search at 6

vhq at 4

and quantization type h263

now the porbelm is

some of the clips (not all) that I encoded using xvid build beta 2 are starting to apear up side down

about the crsah probelm i reinstalled xivd build beta 3 and virtualdub stoped crahsing now but the probelm of the clip apearing upside down is still exist

i didnt try to encode anythin using this build yet but i only encoded one of the clips that were apearing up side down again using build 3 hoping that it would correct the probelm but it didnt work the new result stil apears up side down

i also noticed (but thats not now but some time a goand has nothing to do with my probelm) that the clips you encode using xvid compression still can be played after you uninstall xvid from you computer but the player see the clips as divx file is this normal or what.?

mikeson
31st December 2003, 14:04
@assa69:

Have you read whole thread? I guess not because Koepi explains this in this very thread. So please read it from the beginning (and especially page 3) and next time use Search function more intensively.

Assault
31st December 2003, 14:11
@ assa96

In addition to mikeson's reply: you should stop posting all your questions twice. You already posted both your VDub/upside down problem and your observation that xvid files can be played back by the divx decoder in that thread (http://forum.doom9.org/showthread.php?s=&threadid=67563).

Assault

dbzgundam
31st December 2003, 19:07
I don't get it, how is everyone getting such high speeds with all those settings turned on?!!!

I'm using VHQ1, Motion 6, Chroma on/off = same speed, HVS good/H.263, Qpel, No GMC, Bvops, and two pass mode.

On both passes it runs at maybe 4 fps.

My filters are:

AVIsource(...)
LanczosResize(800, 600)
Awarpsharp(depth=20)
tweak(bright = -1, cont = 1)
textsub(...)
textsub(...)

Those filters shouldn't be too demanding...and why would they cut the speed down so much. I'm running a 1.3GHz Athlon (unclocked from 1.7GHz...I don't wanna bother explaining why)

vinetu
31st December 2003, 20:32
I don't get it, how is everyone getting such high speeds with all those settings turned on?!!!


dbzgundam

Your resolution is 800x600 - its near HDTV :)

dbzgundam
31st December 2003, 21:39
even when it's left at 640x480..not an increase.

K-Dash
1st January 2004, 01:27
Well, it kinda depends on your hardware.
Like I have XP2500+ Barton OCED @ 10x218FSB with Twinmos Winbound PC3200 2-2-2-11 and WD80GB with 25-26fps w/o filters or
XP2500+ Barton OCED @ 10x200FSB with Twinmos Winbound PC3200 2-2-2-11 and WD80GB with 18-20fps.

Tested on "Good times, bed times."
Unrestricted Profile
Single Pass
Target Bitrate 1000
Standard options
Chroma Motion, Chroma Optimizer
I/P/B Settings normal

vio
1st January 2004, 04:26
eh, just a cosmetic thing here, would it be possible to move the "Load Defaults..." button away from "OK"?

I just set up the codec and went to hit ok, missed.

Testing the codec on Jurassic Park, not doing so good. But then again neither did divx5, I'll play with it some more.

MajinMarc
1st January 2004, 06:08
@dbzgundam and others.
Well I just got done with another test and even when I use the default codec setup I'm surprised to say that the speed definitely crashes in the second pass even when turbo is off I have noticed that the speed drops dramatically in speed in comparrison to the last unstable build of Xvid. Usually I base my AVS script at 6-8fps in both passes on the dev-api-3 build. The same avs on the current build of xvid produces slower and sometimes uglier results. With that said I thinkt here are some minor errors I have found with my own encodes. Using it on Dragonball Red ribbon Saga Episodes I have managed to find an interesting "film Reel" image showing up in the upper left hand corner of the image when tried with Xvid 1 Beta 1 2 or 3. All testing is done with the exact same AVS and same settings for the codec. I haven;t been able to determine the problem as I have tried changing settings, using a basic crop and resize only script, changed Resolutions. Left off cropping and still the same result. If anyone knows of a good capture program I would like to take some Screenshots so I can post them as an example.

MajinMarc
1st January 2004, 10:10
Hello Fellow Xvid users. I know this may not be the best place to put this but I thought it'd be best to wish everyone on the development team(this basically includes everyone who posts on this board because everyone who posts has some sort of contribution to id errors or experiences that help make Xvid better) a very Happy New year. With this new year comes a promise of better encoding methods, codec improvements and lots more feedback. Good luck to everyone and once again have a happy new Year.

cweb
1st January 2004, 12:09
Happy New Year to everyone.

I'm testing the Selam build by Koepi (thanks!) and I'm happy to say that this build doesn't cause (or effect) a crash with TMPGENC after it encodes an MPEG1 using Avisynth (the previous build was doing this, I had posted earlier about it). So whatever it was it's been solved, and thanks again.

cweb
1st January 2004, 12:17
Originally posted by riggits
@wannabe:

there's a fairly clear disclaimer on the official xvid page explaining that backward compatibility isn't on the agenda, and that xvid is an alpha or beta status project designed to implement the mpeg4 specs. in other words, it's not perfect, and older movies just might not work. too bad 4 u. no need to be a dink about it, esp. since it's clearly stated on xvid's website.

In fact when I encode something using XviD and put it on a CD, I always put the corresponding codec for possible future use..

cweb
1st January 2004, 12:21
Originally posted by kadajawi
yes, smells. But it is not a proof, for sure there are legal encodes using XviD which are freely distributed on the internet.

For instance I have put my footage (I own it) from the local EU referendum celebrations from last year, encoded using XviD, freely available for download (but not redistribution obviously).

cretin
1st January 2004, 15:48
Yeah and what about commercials and free short films by indy filmmakers ? Some short films can have AC3 sound, today everybody can make AC3 athome, you cant strike down somebody because you think he is "suspicous", you are not God you know.

Heh Heh, so it turned out that you have no real proof against him but he had to be banned from the forum by some unfair moderator. And after all the last few pages are discussing the project that he brought up, and it turned out to be pretty serious. Nice job, next time ppl will think twice before they bring up a serious problem
in the fear of that they get suspended from forum just to quiet them.
Happy New Year.

temporance
1st January 2004, 19:14
Originally posted by cweb
Originally posted by kadajawi
yes, smells. But it is not a proof, for sure there are legal encodes using XviD which are freely distributed on the internet. For instance I have put my footage (I own it) from the local EU referendum celebrations from last year, encoded using XviD, freely available for download (but not redistribution obviously).For instance I have put my footage (I own it) from the local EU referendum celebrations from last year, encoded using XviD, freely available for download (but not redistribution obviously). "Legal encode using xvid" is an oxymoron. AFAIK, no-one has yet found a way of using xvid that doesn't either
(a) violate GPL, or
(b) infringe the MPEG-4 patents.
Most xvid users are doing (b) which in practice is probably OK for individuals that don't publish their encodings. If you publish something encoded using xvid it could be used as proof that you used an unlicensed encoder.
IANAL

jang0
1st January 2004, 21:52
:confused: :confused:

I thought Xvid is legal outside the USA and Japan !?

btw: What about DXN? Do they pay royalties for MPEG4?

bond
1st January 2004, 22:16
i doubt that you infringe any patents or licenses when you only encode using any mpeg-4 codec (if it were so every divx5 or 3ivx user would have to pay for using these 100% legal codecs, what definitely isnt the case)...
afaik not the users have to pay to the patent holders for a codec that uses these patents but the codec manufacturers have to (as xvid is only for educational purpose they dont have to pay for spreading the source code)

what you are not allowed to do as a user would be to spread these encodes afaik (independantly if you own the rights on the video source), but i am not sure if this also is the case if you dont charge anything for them...

Stux
1st January 2004, 23:06
Originally posted by bond
i doubt that you infringe any patents or licenses when you only encode using any mpeg-4 codec (if it were so every divx5 or 3ivx user would have to pay for using these 100% legal codecs, what definitely isnt the case)...
afaik not the users have to pay to the patent holders for a codec that uses these patents but the codec manufacturers have to (as xvid is only for educational purpose they dont have to pay for spreading the source code)

what you are not allowed to do as a user would be to spread these encodes afaik (independantly if you own the rights on the video source), but i am not sure if this also is the case if you dont charge anything for them...

There are MPEG "use" fees in some situations, most normal users probably wouldn't qualify.

It essentially comes down to is the use "for profit" and not "promotion"

IANALE, consult your assigned MPEG-LA representative ;)

seewen
1st January 2004, 23:41
I already told it with Beta 1, but I re-write it again:

You should let user define the MAX bitrate.

Beta 3 is unusable with KISS DP-450.
(In fact 99% of the movie is ok, but the player freeze when bitrate > ~4'000).

I really don't understand why devloppers (who made a great/huge job, that's not the point) doesn't listen to user swho ask for this feature since few month.

Bye, and thanks for all other features ;)

Doom9
2nd January 2004, 00:54
@seewen: I can't locate it right now but I know that bitrate caps have been mentioned before and the answer was: not for XviD 1.0. It's not as simple as you think.. you also have to take care of VBV buffering requirements for the various MPEG-4 profiles. A simple bitrate cap wouldn't help your standalone much.

Chainmax
2nd January 2004, 01:20
I get less than 1fps when encoding a DVD rip with the following AVS script:

mpeg2source("C:\MPEG-4\La Naranja Mecánica\ClckWrkOr.d2v")
Crop(0,48,720,380)
SeparateFields()
VagueDenoiser(threshold=2,method=1,nsteps=4,chroma=true)
Weave()
Telecide(order=1,guide=1,post=1,hints=true)
KernelDeint(order=1,sharp=true)
Decimate(cycle=5,quality=3)
Undot()
MipSmooth(preset="movieHQ")

And the following XviD settings: VHQ1, MSP 6, b-frames @ 2/1.50/1.00, Trellis, adaptive quant and turbo mode.

On an 850Mhz Athlon with 160Mb PC100 ram. With similar settings, devapi3 usually yielded me 3 to 6 fps. So, is this behaviour normal? Are there any further speed optimizations planned for the future or will I just have to upgrade my PC :(?

Blue_MiSfit
2nd January 2004, 02:14
@Chainmax -

Yeah I think your hardware is to blame. That is a wicked avisynth script, and I am not surprised at all that you are only getting 1fps. I average 12-20 or so on secondpass with beta3 on my system (see below) which is probably several orders of magnitude faster than yours ;) Not to mention, I only use undot in my scripts in addition to crop and resize.

I think its time to upgrade. You would be amazed, its a lot cheaper than you think (nforce2 board, 2500+, 512mb ddr400 ram for less than $250 at newegg.com ;))

good luck.

Blue_MiSfit
2nd January 2004, 02:19
also, about the stupid fool who didnt know how to deal with the audio track...

It is possible (however unlikely) that he got the file in a legitimate manor. However - suppose the following scenario.

What does the average AOLamer do after he downloads a rip off kazaa, and discovers he cant play the audio? Well he yells at his computer because "ITS AVI!!! UR SUPPOSED TO KNOW HOW TO PLAY AVI!!!! ALL MY OTHER AVIS WORK FINE!!!" then he starts googling around for DVD ripping, and surely enough he finds (the finest in the business to be sure) doom9. So he comes in here and starts asking questions.

Anyways... Sort of a rant against n00bs... but yeah I think he was a little kazaa-downloading bastard and banning him was a very good move ;)

~misfit

cretin
2nd January 2004, 02:28
He did not say that he got it on kazaa, and its filename was dvdrip.illegalgroup, and unless he would say so, u cant ban him, because you have no proof. BTW the one who complained about the AC3 did not get banned just thread closed.

sysKin
2nd January 2004, 02:55
Originally posted by seewen
I really don't understand why devloppers (who made a great/huge job, that's not the point) doesn't listen to user swho ask for this feature since few month.You do understand thsat your question can be rephased as "I asked for VBV ratecontrol but developers didn't drop out of school/work and didn't spend all the weeks they had to implement it"?

In other words: if you know how to do that, do that. I don't.

Radek

cretin
2nd January 2004, 03:20
Well the KISS DP-450 is not DivX Certified at Home Theater level (up to 10000 kbps max bitrate) so dont get surprised if it doesnt work. But i would be really pleased if someone would let us know if the new beta plays on the KiSS DP-500 or some other Home Theater standalone because thats the real goal.

MajinMarc
2nd January 2004, 11:44
Well since it seems this board has become a place to complain I'm gonna respond to all the people who complain about other users getting banned, as well as the people who said that Xvid developers aren't paying attention......F%ck you. Stop your god damn whining and ask some real questions or give comments about the codec in terms of how it can be improved....aka suggestions are always looked at but not always implemented. if you want a specific feature make it yourself. So if you can't do that stop complaining about it. Now if you find a bug or you think something is wrong make sure you describe your situation. Everything from your AVS to all the Xvid settings your using...yes they know there are still some bugs in it...yes they are trying to fix the major ones first....yse they know about alot of the problems already....aka look at syskin's posts and he has a giant ass list of complaints and problems that they are already aware of. Remember that these guys do this stuff in their free time and if you don't like the progress I'm gonna once again tell you to Make your own version of Xvid...then see how "easy" it is before you complain about something. Thank you and all you guys have a happy New year.

Sincerely,
A disgruntled poster who has seen like 4 pages of just random shit that has nothing to do with the codec other than complaining about something that is irrelevant

Xndo
2nd January 2004, 12:08
I'm going to agree with marc on this, I've read about 5 pages of mindless dribble over "this is what should be in there" and blah blah blah, i think i read the same post by 5 people so far, and its just crap. Give them some time folks, they can only work as fast as they can. I also remember seeing posts over "turbo". Personaly its a nice idea, but losing quality to gain speed isn't a good idea, who cares if something takes longer to encode at least you know the quality is there, so just chill out and let the xvid team work on "real issues". I thank all of the Xvid Team for putting so much work into this. So give them a break and stop whining about every little thing.

Gaia
2nd January 2004, 12:16
Originally posted by cretin
Well the KISS DP-450 is not DivX Certified at Home Theater level (up to 10000 kbps max bitrate) so dont get surprised if it doesnt work. But i would be really pleased if someone would let us know if the new beta plays on the KiSS DP-500 or some other Home Theater standalone because thats the real goal.

Just try it yourself.

Only thing i can say is i have DP-1000 and i don't have any problems with latest XviD 1.0 beta. In normal encodes bitrate never goes as high as 10000 kbs. Only problem is that bitrate might rise too fast. That usually happens only in 2 cd rips. Packed bitstream seems to work too.

Few days ago i tried to play few movies encoded with early XviD builds and i didn't have any problems.

cweb
2nd January 2004, 15:04
Originally posted by temporance
"Legal encode using xvid" is an oxymoron. AFAIK, no-one has yet found a way of using xvid that doesn't either
(a) violate GPL, or
(b) infringe the MPEG-4 patents.
Most xvid users are doing (b) which in practice is probably OK for individuals that don't publish their encodings. If you publish something encoded using xvid it could be used as proof that you used an unlicensed encoder.
IANAL

In any case as far as I'm aware there's no local law which applies to the above (using encoders is not covered), plus it's not for commercial use (call it educational if it helps people get to use and experiment with XviD).

cretin
2nd January 2004, 18:53
MajinMarc: Ok you can stop asskissing now, i doubt that the xvid devs would need that, but thank you for your efforts anyways.

Arcon
2nd January 2004, 23:51
i just encoded a file with beta3 with these settings:

quant: mpeg
adaptive quantization
motion search: 6
vhq: 1
chroma motion
trellis
rest of the settings are default.

target size 1116616k

the output is 1108952k (the first time ever that xvid undesized by more than a few 100k). i did the 2nd pass a second time with a target size of 1124616 and the result was 1116892k, so there seems to be room to reach this size with these settings but somehow xvid undersizes by ~8mb. this is the avs i used:
LoadPlugin("mpeg2dec3.dll")
LoadPlugin("FluxSmooth.dll")
mpeg2source("my.d2v")
crop(10,2,706,476)
FluxSmooth(6,7)
LanczosResize(640,352)

don't know if you need any additional info (or even know what causes this and will have it fixed with the next release).

Koepi
3rd January 2004, 01:40
Arcon,

can you retest the 2nd pass with setting iframe boost to 5 (or 10) percent and report back?

Thank you,

Regards
Koepi