TMPGEnc crash when doing VBR

[SatStorm]

W2K +SP4 @AthlonXP2600+ and directx 8.1 = Never had a simply problem

Of course, I do something almost anyone seems that likes to skip: I frameserve my source to TMPGenc plus 2.5. I never load any kind of file direct to the encoder....

[drak23]

Seems to be DirectX 9 on W2K that has an issue with TMPGEnc 2.5. I'll be interested in the results of DRPs rebuild. I'm planning a W2K rebuild myself so this thread will be very helpful in establishing the last working configuration.

I'd upgrade to TMPGEnc 3.0 but the web site says it requires a P4 1GHz or higher. I won't be upgrading my aging 700MHz for a few more months. Can't wait.

D

[seventhseal]

I've had this problem, and I've been on WinXP. Of course, I have DirectX 9, too. And I suppose there's no way to turn the clock back on DirectX.

[marvel2020]

I don't think this has been suggested, but if it has then please ignore.

Are you encoding the video and audio without demuxing the avi to seperate video and audio. If so, this could probably be where the problem lies as well.

Especially when doing Xvids and Dix.511.

[DRP]

W2K +SP4 @AthlonXP2600+ and directx 8.1 = Never had a simply problem

Of course, I do something almost anyone seems that likes to skip: I frameserve my source to TMPGenc plus 2.5. I never load any kind of file direct to the encoder....

I have not noticed frameserving being an issue at all either. I have had the problem both when frameserving and direct to the encoder - it doesn't matter which you do. I frameserve with VDub, AVISynth & DVD2AVI as well as input files directly to the encoder. I have seen the error on every single variation, so frameserving has got nothing to do with it.

[DRP]

Seems to be DirectX 9 on W2K that has an issue with TMPGEnc 2.5. I'll be interested in the results of DRPs rebuild. I'm planning a W2K rebuild myself so this thread will be very helpful in establishing the last working configuration.

I'd upgrade to TMPGEnc 3.0 but the web site says it requires a P4 1GHz or higher. I won't be upgrading my aging 700MHz for a few more months. Can't wait.

D

I have reinstalled W2K SP4 on my Duron 800 now but haven't got around to reinstalling TMPGEnc just yet. I'll post here the results when I do. The computer is being used by another person for work in the office, so I've gotta get it working with essential apps first before I can hijack it for video encoding, but I'll test it soon. I'm gonna be very careful what I install on it to try and narrow down the problem as much as possible. The only 3rd party codecs on it will be XviD and tooLAME for the audio initially. It already has all the Windoze updates and DirectX 8.1 from oldversion.com.

AFA TMPGEnc 3.0 Express is concerned, you know you can install it and have it running side by side with v2.5 if you want don't you? If you just wanna try it out without upsetting whatever already works, then this is what to do. I did this but I don't like v3.0. It won't let you crop odd values from the image and there are some other annoying aspects about it. It also seems very buggy to me. There are many file types it won't accept that 2.5 will such as bog standard XviDs.

[DRP]

I've had this problem, and I've been on WinXP. Of course, I have DirectX 9, too. And I suppose there's no way to turn the clock back on DirectX.

There is... but only with ME & XP. Both those OS's have something called a "system restore" feature which allows you to take a snapshot of the current configuration which you can then restore at a future date. Of course, no-one actually uses this feature and you would only use it anyway if you were about to install a piece of software you had great reservations about that you didn't seriously expect was going to work.

Seeing as how DirectX comes from the official M$ website and is a recommended update by M$ from M$'s Winblows Update site, it is hard to imagine anyone not expecting DirectX update to work flawlessly.

Other than using that feature in ME or XP there is no way to uninstall DirectX nor to install an earlier version over a later one.

If I'm right about DirectX being the problem (and that's a big IF as I haven't tested my theory yet) then the only solution is a HDD reformat and complete Windows reinstall.

[FOO]

What happens at 50% is a seek to zero. There have been some
codecs that didn't like to do that.

[DRP]

I don't think this has been suggested, but if it has then please ignore.

Are you encoding the video and audio without demuxing the avi to seperate video and audio. If so, this could probably be where the problem lies as well.

Especially when doing Xvids and Dix.511.

Consider it ignored. Thanks for reading the thread and making a suggestion though. I'll take all the help I can get in finding a solution to this very difficult problem

[DRP]

What happens at 50% is a seek to zero. There have been some
codecs that didn't like to do that.

Fair enough, but to get *really* specific about the nature of the problem, the encoding doesn't actually fail at *exactly* 50%. The encoding process does in fact begin. Usually I get around 37 frames encoded before the "Illegal floating decimal point calculation error", so it would appear that seeking back to frame 0 again is not the problem.

[DRP]

It works!

I'm 90% sure the problem is DirectX 9 as I suspected. I say 90% only because I haven't yet formatted my other computer - the celeron 2GHz - and put DirectX 8.1 on it yet to convince me 100% yet, but it certainly works on the duron 800. No doubt about that.

I guess I *could* satisfy myself with 100% certainty by installing DirectX 9 on the duron now and seeing if it instantly makes TMPGEnc fail again but the hassle of having to reformat to go back to 8.1 again means I won't be doing that. 90% certainty I've found the problem is good enough for me.

Here's a summary of my tests:

Duron800 + W2K SP3 + DirectX 8.1 = okay
Duron800 + W2K SP4 + DirectX 8.1 = okay
Duron800 + W2K SP3 + DirectX 9.0b = Illegal floating decimal point calculation order
Celeron2000 + W2K SP4 + DirectX 9.0b = Illegal floating decimal point calculation order

M$ makes reference to versions of DirectX 8.1 called "8.1", "8.1a" and "8.1b". I don't know which one I have. All I can say is that I'm using the redistributable archive from oldversion.com if anyone wants to try it out.

It might be a good idea if a VideoHelp mod could be convinced to have a read of this thread and perhaps add this finding to the list of "common TMPGEnc errors" list if anyone knows how to get that to happen?

HTH someone

[Roderz]

Strange - no probs here with 2.5, w2k sp4 dx9b
but i always dot the audio separately.
but preffer Mainconcept for speed.

[DRP]

Strange - no probs here with 2.5, w2k sp4 dx9b
but i always dot the audio separately.
but preffer Mainconcept for speed.

That is strange yes, I agree. Maybe the CPU type can aggravate problems as well. I am using chips which are known to not be particularly efficient at encoding, so perhaps I am 'closer' to having problems than a normal punter with a fully fledged Intel Pentium IV processor, who knows?

[deckard8]

I had this problem and it turned out to be Fddshow that was the culprit. I uninstalled it and used the proper Xvid and Divx Codecs and my problems disappeared.

[Vanster]

I have had problems with TMPGE from time to time also. Sometimes it works and then I install a new program of some sort, and then it doesn't work. Mysteriously, a month or two later it works again.

One method I have used to get through these periods of not working is this; I use DVD2SVCD to convert my AVI files. Start out by using this guide: https://www.videohelp.com/forum/userguides/220351.php

I let DVD2SVCD strip/encode the audio to WAV. Then I let it creat an AVIsynth script file. It also creates some other files that I don't need or understand.

Once TMPGE opens and starts encoding the video (it encodes the video separately) I shut TMPGE down and then shut down DVD2SVCD.

Then I take the AVIsynth Script file that was created and load that into TMPGE as the video source. I take the WAV file that was created and load that as the audio source. Set up my settings the way I want them and hit encode.

For some reason this bypasses whatever is causing my problem and I am able to convert my AVI's into DVD compliant MPEGs. I don't know why and I don't care. I realize this doesn't solve the problem but at least I am able to complete my projects until I do figure out what the real problem is.

Hope this helps.

Vanster

[DRP]

Yes there are no doubt a few dodgy work arounds which sometimes work, but they are unreliable and quite frankly a pain in the arse to have to do each time. I must admit though, the one you've detailed here is just about the most complicated one I've ever heard of. I shudder to think how on earth you managed to discover that this worked

I also found that copying the CurrentCfg.tpr file from a working installation of TMPGEnc on another computer to a computer with a problematic installation would solve the issue as well, but it would only do so once meaning that I had to repeat the procedure for every single encode I planned to do and of course that meant that batch encoding was not possible at all.

[drak23]

Re all the dodgy workarounds: weird.

If the weekend works out as planned I'll get my W2K partition rebuilt and see if I can confirm DRP's results. If I can get back to a stable working configuration I'll consider the weekend a success.

[gerardhvisser]

Well.... another weird solution: I've found a small free prog that converts your dv1 to dv2. (The file may be not longer then about 4 Gb because of a weakness in this program with the audio: hissing after that boundary so be warned. ) This dv2 seems to be happily eaten in TMPGenc in 2 pass VBR where it did not eat dv1 (after three .dv1 files, who WERE happily coded???) It's of course also possible that just the pointing to a new map may have done the trick... I remember the same error in previous versions of DVDlab. They are related partners - maybe they should talk :P

[aamir12345678]

- This problem came from nowhere for me. I've been encoding VCD's, SVCD's using TMPGEnc with Windows 98 for sure, and I think also with XP. Around a few months ago, when I started to try encoding DVD's, anything I tried to encode with 2-pass vbr, TMPGEnc Plus would either give the "Illegal Floating..." etc. error or produce a video that had a lower avg bitrate than what I asked for. I have only the latest codecs installed, no codec packs or such. It seems to actually encode, but if I ask for 1150, it gives me about 1140. If I ask for 2300, it gives me 2250. My guess is, based in part on you'll's directx experiments, that it was having these same errors before with XP, but I didn't notice it because the error was almost negligent. Now that I am trying to encode DVD's, if I ask for 7300, it gives me 5800!!!!! That's not negligent!!! It's possible that it never truly worked properly with XP, but I didn't notice it till recently when I started to do DVD's.

- I've formatted, reinstalled XP, etc. and then tried encoding: I got the same problems. I've checked my CPU for cooling problems, etc, but I can't seem to find any. It seems to be in tip-top shape. Does anyone know of a good cpu monitoring, details program for XP? I have a Thunderbird (Athlon) 1.33 GHz. This way, I can confirm that it's not my CPU acting up. After all, encoding is a CPU-intensive task.

- I've tried TMPGEnc 3.0 Xpress, and it had the same problem with 2-pass vbr. I tried CCE Basic, and it WORKED flawlessly. I tried Mainconcept, and it also WORKED flawlessly. If it truly is a hardware error, then why is it just with TMPGEnc? If it is a software error, then what is the conflict? DRP said that DirectX 9 conflicts with TMPGEnc on Win2000 but DirectX 8 doesn't. WinXP starts out with DirectX 8. Why didn't it work when I formatted & re-installed XP? Well, it could have been that I installed DirectX 9 and then tried encoding; I can't remember at this point. I also tried to revert to Windows 98. However, again, I can't remember whether I installed Directx 9 or not before I tried to encode, same problem same result. At any rate, I'm not about to reformat unless I can be sure it will work this time, or unless I can be sure that it is Directx 9 that is causing the problems. As you guys might have mentioned earlier, CQ & CBR work flawlessly. All of you say that your TMPGEnc exits out silently. Do any of you have the same problem I'm having with the avg bitrate being lower than you specify?

- I have tried frameserving, etc. Nothing seems to work. Using CQ is a guess game when you have a target size. Only 2-Pass VBR can do it right. As far as encoders go, I like TMPGEnc's results and have spent much time learning it, etc. I have checked source files for errors, tried ripping some of my DVD's then encoding, same result. I've even tried reencoding VCD's that I made with Nero, same result; same problem: either a "Illegal..." error or it gives a lower avg bitrate than what I ask for. Furthermore, DRP, your tests were with Win2000; have you tried this stuff with XP? If it has nothing to do with XP or DirectX, then is it possible that my hard drive has some conflict with TMPGEnc???!!!!!????? I know that TMPGEnc is programmed differently than other encoders, but how is it possible that it can conflict with hardware while other encoders don't.

[gerardhvisser]

aamir, I think you may as well stop looking for "wrongs" any other then TMPGenc. Because PC, micProc, or XP, directX, etc. are not the wrong things in this matter in my vision. I've not much experience with TMPGenc but tried to make 2VB Mpegs for DVD's -and with succes- on 2 XP PC's, on some occasions it crashed on the "50%", or as someone else on this forum wrote: after a few frames coding. The files on which it crashed were AVI's in PAL resolution. I converted the dv type of these avi's (see earlier contibution of me) and TMPGenc did a good 2VB on them (i've NOT checked the resulting average bitrate - how can I do that? but the resulting DVD was much better then the same one produced with Ulead's DVDmoviefactory 3 ). So I think it it's just something with TMPGenc and the material it must work on.... Also because these PC's do AKOP (All Kind Of Programs) for example the quite heavy Pinnacle Edition DV500 without any problem whatsoever!

[aamir12345678]

gerardhvisser, in all likeliness, there is a CONFLICT that TMPGEnc has with something. I don't know what it is but it has to be something installed. I know that TMPGEnc Plus only supports uncompressed AVI & MS-DV Type2 format AVI, but as probably a million people on this site can bear witness to, it can encode many other formats using CBR, CQ, or 2-pass VBR if you have the right codec. There is definitely something that is conflicting with TMPGEnc doing 2-Pass VBR properly of the format. There's obviously nothing wrong with XP, DirectX, or the like, but TMPGEnc uses these things and whatever required codecs to read the files. The fact that it can open the.avi files and read them and encode them properly with CBR & CQ but gives "Illegal Floating..." error or Lower Avg Bitrate than requested for with 2-Pass VBR shows that it definitely is having some conflict with some configuration. If the codec you download is official & the latest release, then there is only one thing left to blame: DirectShow. TMPGEnc's site & support request emails constantly say that if you want some format to work, then have the latest WMPlayer & DirectX and the proper codec installed and change the DirectShow Plug-in priority to the highest.

"Where did this stupid error come from?" I couldn't tell you. This thing frustrates me. IS THERE ANYONE HERE WHO HAS WINDOWS XP, WMPLAYER 9, AND DIRECTX 9 THAT USES TMPGENC'S 2-PASS VBR TO ENCODE SOMETHING OTHER THAN UNCOMPRESSED AVI OR MS-DV TYPE2 FORMAT AVI TO DVD BITRATES AND GETS EXACTLY WHAT THEY WANT? This will help clear things up for me.

[jimmalenko]

IS THERE ANYONE HERE WHO HAS WINDOWS XP, WMPLAYER 9, AND DIRECTX 9 THAT USES TMPGENC'S 2-PASS VBR TO ENCODE SOMETHING OTHER THAN UNCOMPRESSED AVI OR MS-DV TYPE2 FORMAT AVI TO DVD BITRATES AND GETS EXACTLY WHAT THEY WANT?

Yep. DivX, XviD, Canopus DV... you name it, job's right for me.

[DRP]

Do any of you have the same problem I'm having with the avg bitrate being lower than you specify?

Yes I do occasionally, but to be honest I don't consider it a "problem" as such. I mostly do conversions of AVI files and other such already heavily compressed formats, so it is not surprising that the MPEG encoder can't get up to the bitrate asked for in encoding. It just means that many bits aren't required to encode the source material. The source video just isn't that complicated I guess. It mostly happens with very anamorphic wide screen video where up to almost 1/2 of the screen is unchanging black bar. Obviously the encoder doesn't need many bits to describe unchanging black bar so there are even more bits available for the remaining 1/2 screen of real video. Just because the average bitrate doesn't come up to where you wanted it to be doesn't necessarily mean you're losing quality as a result of that.

Furthermore, DRP, your tests were with Win2000; have you tried this stuff with XP?

No I haven't. I don't use XP on any machines I have here, so this isn't easy for me to test. My brother uses XP though and he hasn't seen the same errors I've previously reported, so I assume the issue I've described is specific to W2K.

[DRP]

I am now absolutely 100% convinced the problem for me using W2K SP4 is due to having DirectX 9.0b installed. It has taken me too long to get enough HDD space free to do a reformat to be able to go back to DX 8.1, so instead I have found this

http://www.softpedia.com/public/cat/14/4/14-4-48.shtml

nice little free utility to safely uninstall DirectX 9.0 under windows.

I have used it and gone back to DirectX 8.1 without all the reformatting C: trauma. It works and more importantly I can tell you that TMPGEnc has no problems doing 2-pass VBR encodes anymore whatsoever. This is in fact the first time I've ever seen TMPGEnc do a VBR encode on this computer successfully since I bought it about 6 months ago! It's no coincidence that this is also the first time it's had DirectX 8.1 on it as well.

[aamir12345678]

-I tried that little utility and went back to DirectX 8.1, but it didn't work. However, I'm pretty sure 2-pass vbr worked before for even high bitrates with these same exact files. So, what is conflicting for me? I wouldn't know. I just know that it was working but it all of the sudden stopped. There are a few others who have XP and the same stuff that I do and have this problem. I'll try a format one last time later. Let you know if it works.

-As far as encoders lowering the bitrate because the source file doesn't require it, how come other encoders (like CCE & Mainconcept) can handle these same exact files with 2-pass vbr and give the exact avg bitrate you ask for? CQ is the encode method which is primarily concerned with the quality of the source file. 2-Pass VBR is supposed to give you the desired file size. It analyzes required quality in the first pass but is still supposed to provide an exact file size (bitrate). Maybe TMPGEnc does 2-Pass VBR differently??? At any rate, slight straying from the avg bitrate, I don't care about, like it does with VCD & SVCD bitrates; but when you ask for 7400, and it gives you 5500, this is not acceptable. I would use CQ, but it's too hard to control the file size.

[DRP]

-I tried that little utility and went back to DirectX 8.1, but it didn't work. However, I'm pretty sure 2-pass vbr worked before for even high bitrates with these same exact files. So, what is conflicting for me? I wouldn't know. I just know that it was working but it all of the sudden stopped. There are a few others who have XP and the same stuff that I do and have this problem. I'll try a format one last time later. Let you know if it works.

Sorry I can't help with problems connected with XP. I don't use it and by the sounds of it I don't want to either.

As far as encoders lowering the bitrate because the source file doesn't require it, how come other encoders (like CCE & Mainconcept) can handle these same exact files with 2-pass vbr and give the exact avg bitrate you ask for?

I can't answer that one since I've never used either, but TMPGEnc Plus 2.5 is quite old now as it hasn't been updated in a long time. Perhaps the others you mention are much younger and do a better job in that regard.

Maybe TMPGEnc does 2-Pass VBR differently??? At any rate, slight straying from the avg bitrate, I don't care about, like it does with VCD & SVCD bitrates; but when you ask for 7400, and it gives you 5500, this is not acceptable.

That would depend on the source surely? If you're talking about MPEG-4 kind of sources then obviously a bitrate of 7400 is complete and utter overkill. The encoder would surely detect this during the analysing pass and realise that there is going to be no gain in quality whatsoever by lifting the bitrate to such a level - so it doesn't. Perhaps the other encoders you mention don't intelligently make this distinction?

It would be like using twice as much paint than necessary to paint a picture - two coats if you like when one is perfectly adequate. The end result is exactly the same, you just use twice as much paint with one method.

I would use CQ, but it's too hard to control the file size.

Agreed.

[aamir12345678]

Not sure I agree. When I use a CBR of 7400, it looks better than the [.m2v] that the 2-Pass VBR of 5500 produced. Furthermore, if I choose a 2-Pass VBR of 5500, it'll give me one of significantly less value. This way, there is no way to control the size of a VBR encode because there is no real pattern to how much it degrades the bitrate. The only pattern that exists is that if you do a file with the same exact settings, you get the same amount of degradation. That's the real problem. Well, anyways, as I said before, I'll reformat once more and proceed with extreme caution with everything that I install. Thanks for the help.

[aamir12345678]

I just got Windows XP Service Pack 2. When I encode 2-Pass VBR now, it works fine. Any bitrate I ask for, it does correctly. I don't really know what that means, but I guess it's working now, so just forget about the whole thing...right?

[jimmalenko]

Thank god for that. AFAIK DirectX 9.0C is in SP2, so it may have been DirectX all along.

[DRP]

I also had a copy of DirectX 9.0c ripped out from the SP2 pack before it was released proper, however I never bothered to actually install it since I figured 9.0c wouldn't be *that* much of a difference over 9.0a or 9.0b.

Glad to hear however that it may be just the fix that is needed for TMPGEnc to function properly again. Thanks for the info.