View Full Version : Weird errors in GK
davidj
2nd December 2004, 06:08
I can no longer get GK to work! This is on a brand new machine w/ XP Pro. The file size doesn't come out right! I checked the .firstpass and 2ndpass files and the bitrate given there is the correct one but the file I end up with has a different bit rate. I uninstalled everything, rebooted, reinstalled, but no help. SO I uninstalled, rebooted, installed the .32beta, but same problem. What the heck could be wrong?! Any ideas GREATLY appreciated. Thanks!
jggimi
2nd December 2004, 06:59
Hello, and welcome to the forum.
We can't tell, from what you've supplied so far, exactly what your problem is. We can only make wild guesses. Here's an example of a wild guess:It is possible to end up with a lower than requested bitrate and an undersized file, if you are using a bitrate higher than obtainable by DivX or XviD, either by skipping a compressibility test, or misinterpreting the results.But without more information, it's impossible for us to do more than make guesses.
GK produces a log file, called <movie name>_Gknot.log. You should copy and past the contents here; it will help us see if there were any procedural problems. It's such a common request, we have a Smiley for it:
:logfile:
davidj
2nd December 2004, 07:35
Here's the log file. If the bitrate that it says in the file (817) was used, the file would be the right size. But instead the file has a bitrate of 862, and the file is too big.
manono
2nd December 2004, 10:14
Hi-
Did you recently update your version of XviD? Did you completely uninstall your older version of XviD before doing so (as you should have)?
See 6.3 (http://forum.doom9.org/showthread.php?s=&threadid=72679).
davidj
2nd December 2004, 18:17
Funny thing is, this computer was brand new. I installed XviD originally from the GK codec pack, and when I tried 0.32beta I first uninstalled everything related to GK on the Remove Program list one by one, including XviD, and rebooted.
There's something strange about the MPEG2 source file. It is actually 2 hours, 2 shows, one hour each. So I ran DGIndex (or DVD2AVI) on it, first selecting show #1, then show #2. And when I ran GK on show #2 the file size was perfect. But on show #1 it was too small. I ran small tests, selecting a 90 second region of show #1, and the resulting file would have a drastically low bitrate. Then I tried .32beta on the entire show #1 and the bitrate was too big. So there is something weird about the first half of that MPEG file.
Tuning
2nd December 2004, 19:14
IS it NTSC or PAL ? :confused:
I think you messed up with correct frame count option.
davidj
2nd December 2004, 19:20
It's NTSC. I'm in the U.S., I'm doing it just like I've done tens (a hundred?) others. Like I said, the 2nd half of the MPEG file came out perfectly.
davidj
2nd December 2004, 22:36
I just ran a compressibility test for the frst time. With XviD it came out at a ridiculously low value like .04, which made my chosen resolution crazy, greater than 400%. I then ran the test for DivX and it also came out small, something like .15. These numbers are smaller than anything I have seen. So I made the output res larger, re-ran it with DivX and, voila, it came out right!
So, is there something about having a hugely compressible file which can screw up the resulting file size if the chosen res is such that the percentage of Comp Test is over 100% ? :confused:
manono
2nd December 2004, 23:52
I noticed that your resolution was pretty low, but ordinarily, if the Compress Test result is over 100%, that means that you can't reach your preferred file size, and the result will be smaller than desired. Your result was larger than you wanted. So, no, that's not it. There's something else at work here, but if it's working for you now, cross your fingers and hope it continues to work.
It's possible that Tuning had the answer for you, and you (knowingly or unknowingly) changed a setting when you did it over again.
davidj
3rd December 2004, 03:20
You're right. There IS something else wrong.
It seems that last run just happened to work. On that run I had accidentally put in the wrong file size (334 instead of 350), so I ran XviD and DivX going for 350 MB (which should have resulted in 817 kb/s according to GK). Those two runs resulted in file sizes of 220 MB for DivX and 540 MB for XviD (and kb/s of 496 and 1298).
GK has 29.970 for FPS, which is correct.
I am at a total loss as to why these results are so strange.
In the log there is a variable EnforceBitrate. Could it help to set that to 1?
The log file says "VideoSize: 334051 kbyte" but then it creates an avi with video size 520000 kbyte. Why is that?
jggimi
3rd December 2004, 14:58
I don't know what's causing the trouble, but I do notice that you're not using compressibility testing -- neither log shows the results of the test before encoding.
From your earlier post about compression tests, you say your results were skewed (.04/.15). Don't look at the bpp values, instead, look at the comparison between maximum obtainable bpp and currently selected bpp as a percentage. Its the value in the box right next to the "Load" button.
For example, in your latest encode, your bpp was .216. If your compressibility test returned .15 -- was it at that resolution? If yes, then you're attempting to reach a bitrate unobtainable at that resolution, since your max bpp possible is .15.
---
Edit: but that doesn't explain why you're getting output larger than anticipated; if max bpp is .15, that's approximately all you'll get, and the output should actually be smaller than anticipated.
There have been bitrate errors reported with XviD due to improper/incomplete codec removal prior to upgrade. This is why Manono asked about your codec installation. If I recall correctly, and I may not, there is a tool called "Bigfix" which may be able to more completely remove old XviDs than a simple uninstall.
jggimi
3rd December 2004, 15:07
Yep, a search on "Bigfix" found some 40 posts; here's the very first mention of the software tool: http://forum.doom9.org/showthread.php?s=&postid=391896&highlight=bigfix#post391896
davidj
3rd December 2004, 19:46
Alright, I figured it out! Here's what happened...
You were right that the problem stemmed from not doing a comptest before encoding. Had I done it I would have seen that in my previous attempt the divx % was 142% (and hence the file was smaller, as expected). And the xvid % was over 400. The file size was bigger than expected, but that may be because unpredictable things happen when you use extreme values.
I re-ran both divx and xvid, each w/ comptest. Initially I set the target size at 350MB. In the divx case I had to make the resolution 80% of the original (much bigger than I would have thought). In the xvid case, though, I had to not only set the output res to 100%, I had to also divide the file size by 2! So only 175 MB in the xvid case.
Both file sizes came out right. The amazing thing is xvid, at half the file size, actually looks a little better. The colors are more even and richer and the picture is more smooth.
Thanks for all your help, everybody. I've learned (and hopefully others will learn also) that it is VERY IMPORTANT to do a comptest before each encoding.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.