Having problems doing xVid encodes on 64bit computer

[EuropeanMan]

I just got this computer...that runs OEMversion of 64bit VISTA Home Premium...with 4GB/300GB.

I installed xVid codec 1.1.2; ac3, megui, netframework already here...avisynth 2.5.7

When I run the encode...only the first few frames get processed, and the rest turn up blank/black...

I tried squid80's 64bit filters - xvid, xvid encraw, dgdecode...in all combinations...still the same effect.

Any suggestions?

Also, NEXT WEEK I will put my own retail VISTA ULTIMATE on this and erase the whole drive and start over...any suggestions as to using 64bit version or 32bit version on this computer...because I have NO software that is 64bit yet...

[EuropeanMan]

bump thread

[EuropeanMan]

bumping this again

[jeffy]

Post your script, your MeGUI version,
xvid, xvid encraw, dgdecode - are you mixing the apples with the oranges? xvid encraw is not a filter, xvid is not a filter.

[EuropeanMan]

WITH ANY SCRIPT it processes the same way...

megui 2.5 as i hate 2.6...and YES, both new & old did the EXACT same thing...

xvid encraw i KNOW is NOT a filter...

[ankurs]

http://forum.doom9.org/showthread.php?t=129302&highlight=ankurs

[EuropeanMan]

i have erased the hard-drive, reinstalled a 32bit Vista Ultimate (retail)...

changed my avifil32.dll in system32 from one used in XP
xvidencraw (32bit) from squid80 (turns out its the same one when megui is installed)
installed vista codecs
installed megui (same version as above)
installed xvid 1.1.2
installed the required net framework

SIMPLE script here:

setmemorymax(2048)
DGDecode_mpeg2source("C:\DVD_movie\VIDEO_TS\VTS_01_1.d2v",cpu=2,info=3)
crop( 6, 58, -6, -58)
LanczosResize(640,272)


WHAT AM I MISSING HERE? Because I'm still only able to encode the first few minutes, then the rest is BLACK!!!

[unskinnyboy]

While I don't know the answer to your issue yet, let's see if we can narrow down the issue:

Is it only the encode which is affected? Previewing the avs script in VirtualDubMoD or AvsP looks fine?
How many frames get encoded properly? Is it a set number every time or a random one?
Have you tried encoding with another front-end than MeGUI?
Have you tried with a 32-bit Xvid VfW build? Does it behave the same way as xvid_encraw?
Can you encode fine with other codecs (Snow, x264 etc.)?

[EuropeanMan]

Is it only the encode which is affected? Yes, I believe only the encode...

Previewing the avs script in VirtualDubMoD or AvsP looks fine? Yes, preview is fine throughout...

How many frames get encoded properly? Is it a set number every time or a random one? It seems that it's a set number...here are 2 outputs (first based on 700MB total output of audio/video; 2nd based on 350MB)

1 - http://www.sendspace.com/file/wk395b
2 - Actually, it turns out EXACTLY as above sample...no matter WHAT SIZE I set in bitrate calc in MeGUI...

Have you tried encoding with another front-end than MeGUI? If you mean VDM...I haven't tried. I'm trying to remember how I used set it up...meaning, giving a set bitrate and/or set output size and other settings...

Have you tried with a 32-bit Xvid VfW build? Would you please expound on this one...where would I find it to download to replace...never even knew about this avenue...

Does it behave the same way as xvid_encraw? N/A

Can you encode fine with other codecs (Snow, x264 etc.)? I haven't tried x264 yet...will do so.

Appreciate your time & help in advance...
Thanks - Farooq

[EuropeanMan]

Am trying x264...so far, it's acting weird...started off at nearly 16fps, now down to 4fps 10% on 1st pass...will keep you updated...will go to bed now :( 9.30pm and need to wake up early.

[unskinnyboy]

Have you tried encoding with another front-end than MeGUI? If you mean VDM...I haven't tried. I'm trying to remember how I used set it up...meaning, giving a set bitrate and/or set output size and other settings...No, I meant another front-end which uses xvid_encraw - StaxRip, AutoMKV etc. VirtualDubMoD is a totally different animal.

Have you tried with a 32-bit Xvid VfW build? Would you please expound on this one...where would I find it to download to replace...never even knew about this avenue...OK, little background for you first then - back in the day (circa 2001-2005), we old farts pretty much had only one flavor of Xvid to play with - that is the build which relied on the VfW (Video for Windows) architecture for encoding and decoding. That's the flavor which you would use with VirtualDubMoD. Then came the commandline version of Xvid - xvid_encraw. This is what all the modern encoding GUIs use (MeGUI, StaxRip, AutoMKV etc.).

Since we are only testing something here, don't bother trying to configure VirtualDubMoD. Just run a test encode through AutoGK using its bundled Xvid build.

The gist of the above two points, is that I am trying to find out two things here:

Is the issue with MeGUI (the reason I asked you to try StaxRip or AutoMKV) or is the issue with xvid_encraw (the reason I want you to try AutoGK).

[EuropeanMan]

Ok...let me try AutoGK really quick...will have to download and test...be right back.

[EuropeanMan]

Ok..........wow, I set a total size of 700MB in autogk...got 672 and it works fine. {it's just the first .vob 1GB} so i understand the undersizing...

so there is NO problem with xvid+encraw...
let me try staxrip...

[unskinnyboy]

so there is NO problem with xvid+encraw...AutoGK isn't using xvid_encraw. It uses Xvid VfW. So all we know now is that the issue is with MeGUI or xvid_encraw. Once you try StaxRip/AutoMKV, then we'll know more. Another thing to try would be to replace your existing MeGUI build (after backing it up) with this (http://www.mediafire.com/?zwxwdzni1ll) experimental one and retry your encode. If that works, then we know that it was MeGUI which b0rked before.

[EuropeanMan]

running staxrip right now...also uninstalled megui. will try your experimental (by the way, i encoded on megui 2.5 version above, and also the latest 2.6 something)

crap...it errored out saying stats file, not found... :( STAXRIP that is
hmmm, i think i got this figured out...it's been years since i've used either of these programs LOL

you can remove your link above...downloaded already :) thanks

[EuropeanMan]

edited...

[EuropeanMan]

StaxRIP was successful...now will try your selection above...

[EuropeanMan]

Problem solved...thanks USB - love you man...thanks SO much :)
2.5/2.6 borked on me...whatever that means LOL

[EuropeanMan]

problem is NOT solved...now i'm trying to actually rip a movie with this script below and i get the same problem...goes up to 400+ FPS :( meaning i'll get black frames for sure, for a script that should be running around 20fps processing speeds...

setmemorymax(2048)
DGDecode_mpeg2source("C:\MPK_SCN\VIDEO_TS\VTS_01_1.d2v",cpu=2,info=3)

Load_Stdcall_Plugin("C:\program files\avisynth 2.5\plugins\yadif.dll")
Import("C:\Program Files\AviSynth 2.5\plugins\Mrestore (2).avs")

Yadif(mode=3)
MRestore(quality=2,mlimit=0.2)

crop( 12, 84, -4, -82)

DeGrainMedian(mode=3)

dull=last
sharp=limitedsharpenfaster(strength=40)
sootheMT(sharp,dull,20)

Spline36Resize(656,352)

YLevelsS(0, 1.25, 255, 0, 255).Tweak(sat=1.03,cont=1.05,hue=-2)

[jeffy]

Some questions:
- Are you using the latest versions of the MRestore script and the MaskTools plug-in?
http://forum.doom9.org/showthread.php?p=673243#post673243
- Have you tried lowering the value of SetMemoryMax?
- Are you using meGUI for the script containing MRestore? Have you tried this same script in VirtualDub/Mod?
- Isn't this source bad in itself? (Badly ripped/authored?)

[jeffy]

WITH ANY SCRIPT it processes the same way...

megui 2.5 as i hate 2.6...and YES, both new & old did the EXACT same thing...

xvid encraw i KNOW is NOT a filter...

MRestore & meGUI 2.5 & errors? Read here:
http://forum.doom9.org/showthread.php?p=1133291

[EuropeanMan]

^ that is NOT my problem...the problem is in MeGUI encoding ANYTHING properly...i keep getting BLACK frames!

[EuropeanMan]

Some questions:
- Are you using the latest versions of the MRestore script and the MaskTools plug-in?
http://forum.doom9.org/showthread.php?p=673243#post673243
- Have you tried lowering the value of SetMemoryMax?
- Are you using meGUI for the script containing MRestore? Have you tried this same script in VirtualDub/Mod?
- Isn't this source bad in itself? (Badly ripped/authored?)

source is fine, i've ripped it before
yadif & mrestore are NOT the problem here, as i #'d those lines out, and still get the black frames...

will try lowering setmem now...to 1024 (the way i used to have it on the old computer when i had 2GBram, NOW i've got 4GB - and thus the 2048)

[EuropeanMan]

As far as enjoying MeGUI 0.2.5...it's because I love the bitrate calculator MUCH more than the garbage they decided to use in 0.2.6 and again so far as I can see with this newer build 0.3 :(

[EuropeanMan]

It seems that lowering setmem to 1024 has worked!!! so far so good...

but why would THIS make a difference? i have 4gb ram...

also a side question on the xvid 30% faster profile...if threads is set at 4, what exactly would this mean? or any other number...?

[unskinnyboy]

As far as enjoying MeGUI 0.2.5...it's because I love the bitrate calculator MUCH more than the garbage they decided to use in 0.2.6 and again so far as I can see with this newer build 0.3 :(How did the bitrate calculator differ in the newer versions? Are you implying that the newer one miscalculates the bitrate?

It seems that lowering setmem to 1024 has worked!!! so far so good...

but why would THIS make a difference? i have 4gb ram...It could be that your script is resulting in a memory leak somewhere. Since you limited the memory available to Avisynth, this might have been alleviated. Now, I note (and which I previously overlooked) that you've had a SetMemoryMax(2048) in all the scripts since the beginning. Maybe this was our culprit after all...

also a side question on the xvid 30% faster profile...if threads is set at 4, what exactly would this mean? or any other number...?This means that if you have a quad-core or a quad-CPU system, Xvid will try to use 4 threads to parallelize some of the encoding, thus resulting in higher speeds. But don't expect a 4x speed increase. That won't happen.

P.S: What came out of the testing with StaxRip?

[EuropeanMan]

Actually when I ripped the ONE .vob (from which I had tested everything) last night before going to asleep, 2048 worked...with NO problem!!! it's ONLY when I decided to rip a different movie, and all of the .vobs...that I had gotten the black frames again. I ended up cancelling my rip @ 78% mark of 1st pass...speeds were constant ~ 16fps, which is what I had expected...will run this rip overnight.

re: StaxRIP, had no problem...so I firmly believe, it's an error somewhere relating to MeGUI...and that is quite odd for me. I've never had memory leaks before when ripping, except when using some older version of MRestore, but that was on the old computer system...

re: threads info :) thanks for that...

HOWEVER, I'd like to do some more testing on MeGUI so we can nail this down...can you please help me with that USB?

& as for the bitrate calculator...well, I don't know YET if it errors out somewhere - meaning incorrect file size in the end by a large enough % to matter...the BEEF I have with the 2.6 & .3 (that you gave) is that after I enter in manually the file size I want...it rounds it up, and that THROWS me off. Because I selected a total file size of 2235MB (which is 2.18GB I believe)...and after that is entered, the fieldbox says 2.2GB...so that irritates me, because I want to know EXACTLY what's going on...I don't want it to round up anything. If I use MB throughout, then I want it to DISPLAY that, not change it to GB...EVEN IF THE RESULTANT .AVI FILE (with audio muxed) is 2.18GB or nearly 2235MB! I hope you get where I am coming from...

and again, MANY thanks...

[unskinnyboy]

Actually when I ripped the ONE .vob (from which I had tested everything) last night before going to asleep, 2048 worked...with NO problem!!! it's ONLY when I decided to rip a different movie, and all of the .vobs...that I had gotten the black frames again. I ended up cancelling my rip @ 78% mark of 1st pass...speeds were constant ~ 16fps, which is what I had expected...will run this rip overnight.Memory leaks (assuming, that's what's we are dealing with here) builds up over time. When you just encoded one VOB, the duration for which that encode lasted may have been too short for the memory leak to kick in.

re: StaxRIP, had no problem...so I firmly believe, it's an error somewhere relating to MeGUI...and that is quite odd for me. I've never had memory leaks before when ripping, except when using some older version of MRestore, but that was on the old computer system...When you tried with StaxRip, did you try a full-length movie encode or just one VOB? Also, was the script used for encoding exactly the same as the one for which you got the issues in MeGUI?

HOWEVER, I'd like to do some more testing on MeGUI so we can nail this down...can you please help me with that USB?Everything else remaining the same, if lowering just the SetMemoryMax value makes everything work fine, then we know where the SPOF is. Isn't that what we have here? Did you do a full-length encode yet with SetMemoryMax(1024)?

& as for the bitrate calculator...well, I don't know YET if it errors out somewhere - meaning incorrect file size in the end by a large enough % to matter...the BEEF I have with the 2.6 & .3 (that you gave) is that after I enter in manually the file size I want...it rounds it up, and that THROWS me off. Because I selected a total file size of 2235MB (which is 2.18GB I believe)...and after that is entered, the fieldbox says 2.2GB...so that irritates me, because I want to know EXACTLY what's going on...I don't want it to round up anything. If I use MB throughout, then I want it to DISPLAY that, not change it to GB...EVEN IF THE RESULTANT .AVI FILE (with audio muxed) is 2.18GB or nearly 2235MB! I hope you get where I am coming from...I hear you. I've wondered about the same thing before. It's quite odd that MeGUI would round up 2.18 GB to 2.2 GB, but it's just a minor display annoyance, nothing more. I've gotten over it. When actually estimating the bitrate, it uses 2235 MB, and not the rounded value, and as you have noted, the resultant encode is also properly sized. This is no reason not to upgrade MeGUI.

[EuropeanMan]

1.vob rip in autogk took maybe 15 minutes? something like that, and same with staxrip...generally about the same.
and yes, i used the exact same script for all testing last nite...with 2048 in SMM. and the only reason i'm mentioning this is in reference to memory leakage...which i do NOT believe is the case...unless you know something i don't. when i began the encode on an entire movie...it started out around 30fps, then 30 seconds later...boom...went over 100, 200, and eventually around 600fps...whole rip took maybe 5 minutes? and output file size was 23MB for a set bitrate of 1309 on a movie that was 184 minutes long (different from the encode / script below)

running a full encode right now with 1024, and everything seems stable..20% done on 1st pass ~ 13.33fps right now on this script:

setmemorymax(1024)

DGDecode_mpeg2source("C:\Amar.Akbar.Anthony\VIDEO_TS\VTS_01_1.d2v",cpu=2,info=3)

crop( 2, 2, 0, 0)

degrainmedian(mode=3)
spline36Resize(656,480)

dull=last
sharp=limitedsharpenfaster(strength=60)
sootheMT(sharp,dull,24)

HDRAGC(avg_lum=5,shift_v=-40)
Tweak(sat=1.07,cont=.65)
----------------

will report back tomorrow - for now, going to sleep
:)
GO CHELSEA!!!! CL finals tomorrow...woohoo

PS...USB...a buddy of mine knows you...I was hoping IF it would be okay, to send you a PM here sometime...and ask for some advice privately on a different matter. Thanks in advance...wanted to ask your permission first.

[EuropeanMan]

it undersized by about 40MB or so...but it worked out well.

[unskinnyboy]

Glad to hear that. Hope your error doesn't come back again. So it was a memory issue, after all, and not MeGUI.

[EuropeanMan]

SetMemoryMax has worked up to 1500MB so far...it still undersizes my rips by about 1-2%

PS...usb, sent you a PM yesterday...

[EuropeanMan]

Wanted to continue this thread to help those out who are engineering the next edition of MeGUI (thanks in advance for you folks)

Problems I see...

Multi-threading is not being processed properly
SetMemoryMax limiter not functioning properly over 1500 setting (for a system that has 4GB memory)
MRestore giving more leakages for memory :(
Bitrate calculator - PLEASE PLEASE LET ME SEE THE EXACT MB SIZE I have specificied...don't give me rounded up GB numbers...I want to know EXACTLY what is going on... :)

Systems these 4 were tested on:

1) Laptop HP dv9800 series
300GB HD, 4GB (2x2gb) RAM, Nvidea 512MB video card for HD system
OS: Vista Ultimate (retail) with and without SP1...yes, tested twice - before & after

I now have SP1, just so the computer recognises that I have 4GB of ram, instead of 3070 is showed before...

2) Workstation HP
Xeon Quadcore x 2: 2.8Ghz, 16GBRAM, 2TB HD RAID0, Nvidia 1.5GB graphics
Vista x64 Ultimate OS (retail)

(what is strange that even with one of the top of the line graphics cards, fft3dgpu doesn't function at all)

------------
side note, CCE also crashes under Vista Ultimate when SMM is over 1024...it won't even let 1500 into the equation...
same goes for ProCoder... :( as I hate HCenc...one of the worst encoders ever.

[unskinnyboy]

Wanted to continue this thread to help those out who are engineering the next edition of MeGUI (thanks in advance for you folks)

Problems I see...
Apart from your gripe about the Bitrate Calculator, which is valid, but better asked and addressed in one of the MeGUI threads (and I believe you already did), what does any of the other issues got to do with MeGUI?

Multi-threading is not being processed properlyAre you referring to the multi-threading of the codec or about using the MT filter?

[ronnylov]

I think there is a maximum limit in windows of how much memory each 32-bit program can use and this limit is 2 GB at default. Maybe this is a reason why set memorymax to a lower value works better?
64-bit programs in a 64-bit operating system does not have this limit (or actually the limit is much much higher).

[EuropeanMan]

^ thanks for the explanation & it makes sense...what puzzles me is that I have NO 64-BIT apps on this computer...yet everything BUT MeGUI runs faster on this 64-bit computer WITH A 32-BIT OS!!! (vista ultimate) - why IS that? MeGUI has actually slowed down...and it's the same OS I used when I was on a 32bit computer...why does the 64-bit computer system make MeGUI run slower?

-------------------

ok side question, instead of making a new thread....

if i look at a dvd9...and i find the frame sequence to be [ A A A B B A A A B B ... ] I know this rips to 23.976...

but if the frame sequence is [ A A B A B A A B A B ] what would one use to deinterlace this source?

A = progressive frame
B = interlaced frame

Normally for the first one, I just use tfm/deci...
What about for the 2nd?

[ankurs]

^ thanks for the explanation & it makes sense...what puzzles me is that I have NO 64-BIT apps on this computer...yet everything BUT MeGUI runs faster on this 64-bit computer WITH A 32-BIT OS!!! (vista ultimate) - why IS that? MeGUI has actually slowed down...and it's the same OS I used when I was on a 32bit computer...why does the 64-bit computer system make MeGUI run slower?

-------------------

ok side question, instead of making a new thread....

if i look at a dvd9...and i find the frame sequence to be [ A A A B B A A A B B ... ] I know this rips to 23.976...

but if the frame sequence is [ A A B A B A A B A B ] what would one use to deinterlace this source?

A = progressive frame
B = interlaced frame

Normally for the first one, I just use tfm/deci...
What about for the 2nd?

can the incoming B frames you mentioned be in any way dupes or frames with ghosting ?

[EuropeanMan]

^ NO

it was so weird!!!

no dupes or ghosting...
i ended up using tfm(order=1).decimate()
and it ripped fine...i just thought PERHAPS there might have been a better way...that's why i had asked

[~bT~]

I hate HCenc...one of the worst encoders ever.

what's so bad about it? lets hear what we should look out for..

[EuropeanMan]

^ In my opinion only, after testing HC vs. low-bitrate matrices on both ProCoder & CCE...I have felt that there are matrices that do a better job of bitrate distribution than HCenc...and keep sufficient amount of details...

2 movies tested - Lagaan (columbia tristar) & K3G (Bodega & also YRF)...still trying to find a better balance

ProCoder seemed to have gotten better colour saturation as well as HCenc...but for ME personally, I care more about details & proper bitrate distribution...which I felt HCenc doesn't do sufficiently for MY OWN PERSONAL standards...for others, it MAY WORK better...that's fine. I just got too frustrated...and as I'm so extremely comfortable witih CCE, I'm adjusting my own matrices to reflect length of films as well as unpacking bitrates from CBR-encoded DVD9s, which bollywood is famous for.

[EuropeanMan]

@ USB - any idea if meGUI could be configured for 64-bit? because CCE will be going 64bit soon as well...

[EuropeanMan]

what's so bad about it? lets hear what we should look out for..

Here's another proof of HC inferiority...

HCenc below

http://maxupload.com/img/B81AB5F1.jpg


CCE below

http://maxupload.com/img/64352283.png

- and it is true, i'm better at filtering & using matrices...but still
even the original DVD9 wasn't bad...

[kypec]

Maybe you're right in your assumptions but I find it very unfair to compare two still pictures: one being ~30KB JPEG and the other lossless ~230KB PNG :eek:

[EuropeanMan]

^ no worries, i have both sources to compare. the hc is horrible...but you are right in one thing...it wasn't fair :) as i see hc may NOT be the problem for the person who encoded the top...apparently its a disease...

http://i307.photobucket.com/albums/nn281/gulsahan/vlcsnap-719958.png



http://maxupload.com/img/BDFBD0E9.png

[Taurus]

You are going off topic with your thread, EuropeanMan.
Just some words:
Here's another proof of HC inferiority...
You are comparing apples with peaches.
Your pictures show nothing. kypec gave you a hint..
They are at different color spaces and as far as I can see different frames.
Make sure you use the same matrices on all encoders and same color space.

Better switch back on topic for now.

[Irakli]

They are at different color spaces and as far as I can see different frames.
Make sure you use the same matrices on all encoders and same color space.

:goodpost:

The problem is indeed related to colorspace/matrices. This is very apparent when looking at those pictures.

[EuropeanMan]

For some reason, I've tried ripping a source and each and every time (3 so far), it keeps undersizing and I have NO idea why...