Auto GK 2.55 New Problem

[New-User]

Hey Im New Around Here
I Was Using Auto GK 2.55 And I Updated The Components
Manual I Just Replaced Files
Any Way I Was Able To make Auto gk 2.55 Work With
Virtualdubmod 1.5.10.3 & Some Newer Dll Files & The Results Were Awesome

After Updating My Codec Pack K-Lite Codec Pack
Virtual Dub Cant Analyze & Create frames.log File
I Tried As Hard As I Could But I Still Cant Remember How I Did It LOL
Any Ideas?
Is It Something In Codec Install Option?
I Cant Even Remember The Codec Pack Version I Think It Was 7.1.0 Not Sure

And Here Prove:

General
Complete name : E:\English\Video Clip\Cocktail\Faithless We Come One.avi
Format : AVI
Format/Info : Audio Video Interleave
File size : 29.9 MiB
Duration : 4mn 1s
Overall bit rate : 1 040 Kbps
Writing application : VirtualDubMod 1.5.10.3 | www.virtualdub-fr.org || (build 2550/release)
Writing library : VirtualDubMod build 2550/release

Video
ID : 0
Format : MPEG-4 Visual
Format profile : Advanced Simple@L5
Format settings, BVOP : 1
Format settings, QPel : No
Format settings, GMC : No warppoints
Format settings, Matrix : Custom
Codec ID : XVID
Codec ID/Hint : XviD
Duration : 4mn 1s
Bit rate : 871 Kbps
Width : 608 pixels
Height : 336 pixels
Display aspect ratio : 16:9
Frame rate : 29.970 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.142
Stream size : 25.1 MiB (84%)
Writing library : XviD 58

Audio
ID : 1
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Mode : Joint stereo
Codec ID : 55
Codec ID/Hint : MP3
Duration : 4mn 1s
Bit rate mode : Constant
Bit rate : 160 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 4.61 MiB (15%)
Alignment : Aligned on interleaves
Interleave, duration : 67 ms (2.00 video frames)
Interleave, preload duration : 504 ms
Writing library : LAME3.98r
Encoding settings : -m j -V 4 -q 2 -lowpass 17.5 -b 160

[hello_hello]

Are you trying to encode an AVI or are you trying to encode a DVD etc? Which operating system are you using?

Personally I'm not big on codec packs. I'd try uninstalling K-Lite and installing ffdshow tryouts. I use ffdshow for decoding when re-encoding AVIs fairly regularly.

I doubt updating VirtualDubMod would be the cause of the problem. I've done the same thing myself. I've also updated the LAME MP3 encoder and MPC, which AutoGK uses for previews. If you download MPC-HC, rename the mpc-hc.exe to mplayerc.exe and use it to replace the version in the AutoGK/mpc folder, it works fine. Once I've done that I run it and select the options to "open a new media player for each file" and also the option to "store settings to ini file". That way you can also put MPC-HC somewhere else on the PC and the copy AutoGK uses won't interfere with the second installation.

I've done all of the above on two XP PCs and AutoGK works fine.

Does AutoGK offer an error message when it fails to analyze? If so, what does it say?

[kalehrl]

Did you by any chance replace MediaInfo.dll with the latest one?
After doing so I wasn't able to use avi files as input because mediainfo reported 0 frames.
When I put back the original MediaInfo.dll, it was business as usual. :)

[hello_hello]

No I didn't..... until now. I just tried it using the latest MediaInfo dll (0.7.53) and while at least with the AVI file I tried it didn't stop AutoGK from analyzing, it no longer displayed any info regarding the contents of the original AVI file.

Edit: It did however abort after the analysis saying no frames were found.

I also tried replacing both the MediaInfo dll and MediaInfo exe, but that caused MediaInfo to open and freeze whenever I tried to open an AVI file using AutoGK. I guess sticking to the version AutoGK installs is the best idea.

[hello_hello]

Mmmmmm..... you have given me some ideas to try. I didn't know MediaInfo could effect AutoGK's functionality that way.

At one stage, many moons ago, I could re-encode MP4 and MKV files to AVI simply by changing their extension to AVI and opening them with AutoGK. Only encoding the video worked. Leaving the audio selected would stop the process pretty quickly because VDM couldn't demux it.

Then after a reformat, the ability to encode MKV files by changing their extension to AVI stopped working. I can still do the same thing with MP4s, just not MKVs. I've never been able to work out exactly what changed after the reformat, and AutoGK would have installed the same version of MediaInfo each time, but I might play around with some older MediaInfo versions to see what happens.

If you'd actually like to test it yourself.... changing an MKV/MP4 file's extension to AVI to see if AutoGK will then encode it, let me know if it works.....

[New-User]

Sorry I Was Busy For While Well I Use Auto GK 2.55 TO Encode Dvd Files (Vob) to AVI
I Will Try That And Tell You What The Result I Use Widows Xp SP3 Updated Original From Microsoft.com
You Said That Auto GK 2.55 Works Fine With Updated Files?
The Error Log Say:
[25/01/2012 09:47:42 م] AutoGK 2.55
[25/01/2012 09:47:42 م] OS: WinXP (5.1.2600).2
[25/01/2012 09:47:42 م] Job started.
[25/01/2012 09:47:42 م] Input file: D:\New Folder (8)\Sean Paule - Temprature.vob
[25/01/2012 09:47:42 م] Output file: D:\New Folder (8)\Sean Paule - Temprature.avi
[25/01/2012 09:47:42 م] Output codec: XviD
[25/01/2012 09:47:42 م] Audio 1: Audio Stream 0 PCM
[25/01/2012 09:47:42 م] Subtitles: none
[25/01/2012 09:47:42 م] Format: AVI
[25/01/2012 09:47:42 م] Target size: 40Mb
[25/01/2012 09:47:42 م] Audio 1 settings: CBR MP3 with bitrate: 160Kbps
[25/01/2012 09:47:42 م] Started encoding.
[25/01/2012 09:47:42 م] Demuxing and indexing.
[25/01/2012 09:48:00 م] Processing file: D:\New Folder (8)\Sean Paule - Temprature.vob
[25/01/2012 09:48:00 م] Source resolution: 720x480
[25/01/2012 09:48:00 م] Found NTSC source.
[25/01/2012 09:48:00 م] Source aspect ratio: 4:3
[25/01/2012 09:48:00 م] Analyzing source.
[25/01/2012 09:48:03 م] Source is considered to be progressive.
[25/01/2012 09:48:03 م] Output will contain 6487 frames
[25/01/2012 09:48:03 م] Normalizing audio.
[25/01/2012 09:48:08 م] Encoding audio.
[25/01/2012 09:49:33 م] Using VAQ in XviD
[25/01/2012 09:49:33 م] Audio1 size: 4,330,560 bytes (4.13 Mb)
[25/01/2012 09:49:35 م] Overhead: 77,056 bytes (0.07 Mb)
[25/01/2012 09:49:35 م] Video size: 37,535,424 bytes (35.80 Mb)
[25/01/2012 09:49:35 م] Running compressibility test.
[25/01/2012 09:49:39 م] Duration was: 3 seconds
[25/01/2012 09:49:39 م] Speed was: 538.56 fps.
*************************************
EXCEPTION: Cannot open file "D:\New Folder (8)\agk_tmp\frames.log". The system cannot find the file specified
*************************************
[25/01/2012 09:49:39 م] Job finished. Total time: 1 minute, 57 seconds
====================================================

I Told You Virtual Dub Mod Updated Version Cant Analyze Source File & Create Log File?
SO I Back To Old Version It Works Fine But I Have Question Can I Put Updates Without I Face This Problem I Did It Once As You See Above But I Cant Remember How :(

[kalehrl]

changing an MKV/MP4 file's extension to AVI to see if AutoGK will then encode it, let me know if it works.....
It doesn't work.
It says no frames found.

[hello_hello]

It doesn't work.
It says no frames found.

It's not going to work yet as you have the same problem converting DVDs, so something's wrong. I'm fairly sure the new version of VirtualDubMod is not the problem. I've used it for quite a while with AutoGK on two different PCs running XP.
Are you saying if you revert back to the old version of VurtualDub the problem goes away? If so (as I still think it's not VDM), try upgrading it again and running an encode again.

You originally said that AutoGK couldn't analyze the file, but according to your log file it is. It's not only completing an analysis it's running the compression test. Where it's failing is after the compression test when it attempts to open the frames.log file in the temporary folder it creates.

Maybe the file in question (or maybe the whole temp folder) is locked for some reason.
If you haven't already, try rebooting and then deleting the entire "agk_tmp" temp folder on your D drive. Actually before you do, if you open the folder I'm fairly sure you'll find the frames.log inside. The problem is not that it's not there, but that after the compression test AutoGK can't open it. It's just a text file though and nothing VirtualDub uses directly.

If the above doesn't help, try putting the output file in a different location. If you still can't get it to work post back and I'll do some searching on the forum to see if I can come up with any clever ideas.

[hello_hello]

Here you go. Try re-installing AVIsynth. Or re-installing AutoGK which should re-install AVIsynth for you.
http://forum.doom9.org/showthread.php?t=85656&highlight=autogk+exception+open+file

[kalehrl]

You seem to have confused me with @New-User.

[hello_hello]

You seem to have confused me with @New-User.

So I have. Sorry about that.
I forgot when I last posted..... if I recall correctly in order to get the "changing of MP4 and MKV extensions" trick to work, the Haali Splitter needs to be installed, and I don't know if it'll work with other codecs, but it definitely works with ffdshow doing the coding.

Well it still works with MP4s for me (as long as you deselect the audio). I'm 100% sure at one stage it worked for MKVs as well, but I've not been able to discover why after the last format it no longer does.

I have come up with a workaround which involves using an AVIsyth script wrapped in an AVI which AutoGK can then open and encode, but it's slower than encoding the file directly.

[kalehrl]

I tried renaming mkvs into avis and encoding them with AutoGK but it doesn't work for me either.
Mp4s work fine.

[hello_hello]

Thanks for trying. I'll have to work on it.....

[New-User]

That What Im trying To Tell You I Already Tried All solutions
within this forum & other forums nothing worked
this problem started after i updated my codec pack k-lite
anyway i will try to change some codecs and i see what will happen
hey also i notice something

Here Is A Sample Of The Media Information

video encoded before i updated my codec:
Writing library : XviD 58

video encoded after i updated my codec
Writing library : XviD 1.2.1 (UTC 2008-12-04)

Now Thats Weird Because It Should Be 1.3.2 The Latest Version Of XVID Codec Included In K-Lite
Well I Will try to Change Stuff About Codec To Figure It Out

Well I Finished I Have Serious Problem In Here
I Made Uninstall And I Tried To use Virtual Dub
I Found Writing Library Is Writing library : XviD 1.2.1 (UTC 2008-12-04)
This Xvid Version Is Sticky How That Possible I Uninstall It And Virtual Dub Still Using It?
I Check Registry And System32 Folder No Trace For Xvid Files That’s Totally Weird? Any Ideas

[New-User]

Okay I Figured It Out
K-lite Work Just Fine But It Needs Expert User
I Just Made Registry Clean & Started New Installation Everything Back Fine

[hello_hello]

Okay I Figured It Out
K-lite Work Just Fine But It Needs Expert User

Sounds like the K-Lite codec pack must have been messing up AutoGK's installation of the Xvid encoder. Admittedly, as a non-codec pack user, I didn't think about that possibility. Probably another reason not to use codec packs. As far as I know AutoGK 2.55 instals Xvid version 1.2.1

Unless you really know what you're doing I wouldn't use any version of Xvid with AutoGK other than the one AutoGK installs. If you don't there's a good chance you'll have issues with trying to achieve a target file size, and I don't know if VAQ is enabled differently in different versions of XviD. For that matter, I don't know if AutoGK would be able to configure just any version of Xvid properly.

Now that AutoGK is working, there's probably no reason why you can't update VirtualDubMod again.

[New-User]

Sounds like the K-Lite codec pack must have been messing up AutoGK's installation of the Xvid encoder. Admittedly, as a non-codec pack user, I didn't think about that possibility. Probably another reason not to use codec packs. As far as I know AutoGK 2.55 instals Xvid version 1.2.1

Unless you really know what you're doing I wouldn't use any version of Xvid with AutoGK other than the one AutoGK installs. If you don't there's a good chance you'll have issues with trying to achieve a target file size, and I don't know if VAQ is enabled differently in different versions of XviD. For that matter, I don't know if AutoGK would be able to configure just any version of Xvid properly.

Now that AutoGK is working, there's probably no reason why you can't update VirtualDubMod again.

I Dont Use Auto Gk 2.55 Xvid Encoder v1.2.1
k-lite is best but it have a lot of options
that what crashed the xvid encoder also
this codec pack contain the most needed codecs for any pc packed as 3rd party softwares from the official web sites of these codecs
and they all updated i think that VAQ Supported In The New official xvid too on contrary
xvid v1.2.1 crashed my codec pack so badly i was have to clean registry manually
now virtualdub use xvid v1.3.2 so i figured that auto gk will work so i updated all auto gk components its work like magic its better than ever [target size - quality - speed] all improved :) and im happy after all i solved this problem
one my own ;) & I Gained More Knowledge

len0x You Rule’s Man
Too Bad That Auto Gk Project Was Stopped :(

Anyway Thanx Hello_Hello I Really Appreciate Your Help Well That Was Good For Both Of Us
We Exchanged Knowledge :)

[hello_hello]

Well there's a good chance AutoGK won't be able to enable VAQ in Xvid, so as long as you don't mind that.
K-lite must obviously be best even though it crashed the Xvid encoder. I'll assume you've never heard of, or never used, ffdshow?
Target size, quality and speed are all improved? To be honest, I have my doubts.

Yes it probably would be nice if AutoGK development had continued and it was updated to use the x264 encoder, given Xvid is somewhat obsolete.

[New-User]

Well there's a good chance AutoGK won't be able to enable VAQ in Xvid, so as long as you don't mind that.
K-lite must obviously be best even though it crashed the Xvid encoder. I'll assume you've never heard of, or never used, ffdshow?
Target size, quality and speed are all improved? To be honest, I have my doubts.

Yes it probably would be nice if AutoGK development had continued and it was updated to use the x264 encoder, given Xvid is somewhat obsolete.

That What Im Trying To Tell You
I Used FFdshow but i found it its just decoder and it doesnt have any encoders k-lite use lav & ffdshow & xvid as well its optional
i was mean by improved that it become more compatibility and k-lite crashed xvid because of duplicated
versions the updated one and the old that auto gk use and the options of k-lite as well can crash xvid if you dont choose it correctly

[hello_hello]

My apologies, I didn't realize the K-lite codec pack included ffdshow, which by the way does have some encoders.

I don't think you appreciate why you can't just upgrade something like Xvid and have it work correctly with an older program such as AutoGK, but as long as you're happy. Personally I just manually install a fraction of what the K-lite codec pack installs and it covers all my audio/video playback and encoding needs and I don't have to worry about competing codecs or software breaking when a codec pack tries to upgrade something as happened to you, but each to their own.....

[kalehrl]

I also use the jawor's xvid 1.3.2 build with autogk and everything is fine.
You just have to select ESS compatibility options in advanced settings otherwise size will not be good.
Since I always used ESS, this is no problem for me.
I compared files done with 1.3.2 and default autogk xvid and they are basically the same.

[hello_hello]

Well there's one example of a different build not working properly with AutoGK. You're forced to use the standard matrix (which I also use myself) rather than the mpeg or custom matrix or VBV control doesn't work properly.
I wonder if VAQ is actually working? For a given file size, does AutoGK report the same quality using both versions?

What you're saying is in contrast to New-User's claim that target size and quality are improved. I wonder if sooner or later New-User will start a new thread trying to work out why he's not achieving the desired target file size?


I compared files done with 1.3.2 and default autogk xvid and they are basically the same.

I'll bite then. What's the advantage of of upgrading it?

[New-User]

I wonder if sooner or later New-User will start a new thread trying to work out why he's not achieving the desired target file size?

I'll bite then. What's the advantage of of upgrading it?

Well Im Not Just Say I Tested It myself target file size Is Fine
Also Im Forced To Use Codec Pack Because I Told You Xvid + FFDSHOW Not Handle All Codecs
Look General
Complete name : E:\English\Video Clip\Cocktail\Sean Paule - Temprature.avi
Format : AVI
Format/Info : Audio Video Interleave
File size : 40.0 MiB
Duration : 3mn 36s
Overall bit rate : 1 552 Kbps
Writing application : VirtualDubMod 1.5.10.3 | www.virtualdub-fr.org || (build 2550/release)
Writing library : VirtualDubMod build 2550/release

Video
ID : 0
Format : MPEG-4 Visual
Format profile : Advanced Simple@L5
Format settings, BVOP : 1
Format settings, QPel : No
Format settings, GMC : No warppoints
Format settings, Matrix : Custom
Codec ID : XVID
Codec ID/Hint : XviD
Duration : 3mn 36s
Bit rate : 1 384 Kbps
Width : 512 pixels
Height : 384 pixels
Display aspect ratio : 4:3
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.294
Stream size : 35.7 MiB (89%)
Writing library : XviD 58

Audio
ID : 1
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Mode : Joint stereo
Mode extension : MS Stereo
Codec ID : 55
Codec ID/Hint : MP3
Duration : 3mn 36s
Bit rate mode : Constant
Bit rate : 160 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 4.13 MiB (10%)
Alignment : Aligned on interleaves
Interleave, duration : 84 ms (2.00 video frames)
Interleave, preload duration : 504 ms
Writing library : LAME3.99r
Encoding settings : -m j -V 4 -q 2 -lowpass 17.5 -b 160


The Writing Library Is Kind Strange But The Xvid Installed version Is 1.3.2

[kalehrl]

I'll bite then. What's the advantage of of upgrading it?
I think the new xvid is quicker than the "old" one.
Search my posts and you will find my comparison between xvid_encraw 1.2.2 and xvid_encraw 1.3.2.
Latest encraw is 30% faster and I think the same applies to installed xvid.
Old xvid must be uninstalled before installing the new one.
That's the key to having the new version work fine with AutoGK.
The Writing Library Is Kind Strange But The Xvid Installed version Is 1.3.2
That's strange! Writing library should read XviD 64.
I don't think you properly uninstalled old xvid before installing new one.

[hello_hello]

Well Im Not Just Say I Tested It myself target file size Is Fine

That's good. Your MediaInfo file seems to indicate you're not using the ESS hardware compatibility option (it specifies a custom matrix has been used), so either you're using a different version of xvid to kalehrl, or one of you is wrong about the circumstances under which achieving a desired target file size works correctly. Maybe the two of you need to debate that subject. ;)

Also Im Forced To Use Codec Pack Because I Told You Xvid + FFDSHOW Not Handle All Codecs

I'd be curious to know which codecs you need that aren't covered by using xvid and ffdshow. Nobody is forced to use a codec pack, it's not rocket science to install extra codecs manually, but if using a codec pack is what you prefer, then who am I to tell you not to?

I don't know what your MediaInfo file is supposed to indicate, as it's looks perfectly normal to me. The same as one without a codec pack installed.

[hello_hello]

I think the new xvid is quicker than the "old" one.
Search my posts and you will find my comparison between xvid_encraw 1.2.2 and xvid_encraw 1.3.2.
Latest encraw is 30% faster and I think the same applies to installed xvid.
Old xvid must be uninstalled before installing the new one.
That's the key to having the new version work fine with AutoGK.

Well if it's faster I might test it out myself later. I'm sure I read a discussion recently where someone was inquiring as to whether newer versions of Xvid would work correctly with AutoGK because a mobile profile was being selected in Xvid rather than one of the Home Theatre profiles (was it you, or have you checked as to which Xvid profiles AutoGK is using?) and I think one of the reasons for not upgrading Xvid was the newer versions activate VAQ differently so it wouldn't be used when encoding with AutoGK. Maybe that's not correct, but if I try the version you're using I'll test it myself. The way I understand it VAQ should reduce the file size by about 10% without reducing the quality to any noticeable degree, so it shouldn't be hard to run some comparison encodes if I can't tell by looking at the Xvid configuration while AutoGK is running an encode.

Actually before I do run any speed tests, what sort of files were you re-encoding to obtain your results? DVDs? I just want to make sure I'm comparing your apples with my apples. What sort of CPU were you using? Dual or quad core etc...

PS Did you ever work out why Xivd 1.3.2 is slower than 1.2.2 when using MeGUI?

[hello_hello]

That's strange! Writing library should read XviD 64.
I don't think you properly uninstalled old xvid before installing new one.
Maybe you are using different versions of Xvid after-all?

[kalehrl]

Yes, it was me who was inquiring about the profile.
Mobile profile was selected but obviously it wasn't used:

http://i43.tinypic.com/kccw0g.pnghttp://i41.tinypic.com/fdedlh.pnghttp://i39.tinypic.com/30bp549.png

Resolution definitely wasn't respected and probably the buffer.
I used Avinaptic and compared the video encoded with 1.3.2 and 1.2.2 and didn't find any significant differences. VHQ was probably used because it was selected. Pay attention to 'packed bitstream' because it is unchecked but it was used. So if something is selected it doesn't necessarily mean it was used or vice versa.
I was also skeptical about Adaptive Quantization because I read there were some changes in 1.3.2 so I thought it wouldn't work. I asked for some advice how to identify it and checked and it was used! I mostly encode DVB captures and I'm in Europe (PAL) thank God! :D

Media info of the file:

General
CompleteName : G:\BackupWinD\Films\Sjećaš li se, Dolly Bell\Sjećaš li se, Dolly Bell.avi
Format : AVI
Format/Info : Audio Video Interleave
FileSize/String : 700 MiB
Duration/String : 1h 45mn
OverallBitRate/String : 931 Kbps
Encoded_Application : VirtualDubMod 1.5.10.2 (build 2542/release)
Encoded_Library/String : VirtualDubMod build 2542/release

Video
ID/String : 0
Format : MPEG-4 Visual
Format_Profile : Advanced Simple@L5
Format_Settings_BVOP/String : 1
Format_Settings_QPel/String : No
Format_Settings_GMC/String : No warppoints
Format_Settings_Matrix/String : Default (H.263)
MuxingMode : Packed bitstream
CodecID : XVID
CodecID/Hint : XviD
Duration/String : 1h 45mn
BitRate/String : 796 Kbps
Width/String : 640 pixels
Height/String : 368 pixels
DisplayAspectRatio/String : 16:9
FrameRate/String : 25.000 fps
ColorSpace : YUV
ChromaSubsampling : 4:2:0
BitDepth/String : 8 bits
ScanType/String : Progressive
Compression_Mode/String : Lossy
Bits-(Pixel*Frame) : 0.135
StreamSize/String : 598 MiB (85%)
Encoded_Library/String : XviD 64

Audio
ID/String : 1
Format : MPEG Audio
Format_Version : Version 1
Format_Profile : Layer 2
CodecID : 50
Duration/String : 1h 45mn
BitRate_Mode/String : Constant
BitRate/String : 128 Kbps
Channel(s)/String : 2 channels
SamplingRate/String : 48.0 KHz
Compression_Mode/String : Lossy
StreamSize/String : 96.2 MiB (14%)
Alignment/String : Aligned on interleaves
Interleave_Duration/String : 80 ms (2.00 video frames)
Interleave_Preload/String : 504 ms

What sort of CPU were you using? Dual or quad core etc...

PS Did you ever work out why Xivd 1.3.2 is slower than 1.2.2 when using MeGUI?

I'm using a fairly old Athlon II x2 240 with 2 cores.
It is definitely MeGUI problem because it was optimized for 1.2.2 xvid_encore. Zathor doesn't want to change anything because it won't write files over 2GB. On one hand you have 30% increase in speed and on the other ability to write files >2GB. I would always choose 30% increase but each to his own. :(

[New-User]

I Just Say That New Updates For Auto GK 2.55 Was Useful To Me
I Updated .dll Files and lame encoder & DGIndex & Xvid
You Should Try It Guys You Will See The Difference
Any Way Im Happy We Exchanged Thoughts & My Problem Was Gone :)

[hello_hello]

Yes, it was me who was inquiring about the profile.
Mobile profile was selected but obviously it wasn't used.

Resolution definitely wasn't respected and probably the buffer.


The "probably" part would worry me. As you can see from your screenshot Xvid doesn't force you to respect the resolution settings but as the buffer settings are greyed out I'd be inclined to think there's no reason why they aren't enforced otherwise what's the point of having them? Of course it only applies to two pass encoding anyway as Xvid can't control the VBV buffer when running single pass encoding like x264 can (which is why AutoGK offers the warning that some hardware compatibility settings will be ignored when selecting single pass encoding). When running 2 pass encodes I very much suspect you're reducing the max buffer size from 3145729 to 1048576 and the maximum bitrate from 4854 to 1334. Not something which might effect every encode but it'd certainly effect some of them.

VHQ was probably used because it was selected.

I was referring to VAQ, but yes it looks like it's being used. Does your version of Xvid include Dark Shikari's VAQ mod?
http://forum.doom9.org/showthread.php?t=135093

Pay attention to 'packed bitstream' because it is unchecked but it was used. So if something is selected it doesn't necessarily mean it was used or vice versa.

Kind of makes you wonder what the point of being able to select an option might be if it has no relationship to whether it's used or not. I wouldn't say it's not selected though, it's actually greyed out because packed bitstream is enforced when using certain profiles. You can easily confirm it by selecting an unrestricted profile. Then you have the ability to choose whether or not to use a packed bitstream (assuming B-VOPs is also selected).
So it's actually kind of the opposite to what you're saying. Yes it's selected automatically by using a profile (even though the GUI doesn't indicate it's use), and yes selecting a profile ensures a packet bitstream is used.... probably just like the VBV settings.

I was also skeptical about Adaptive Quantization because I read there were some changes in 1.3.2 so I thought it wouldn't work. I asked for some advice how to identify it and checked and it was used! I mostly encode DVB captures and I'm in Europe (PAL) thank God! :D

How do you check it was used? I'd be interested to know.

I'm using a fairly old Athlon II x2 240 with 2 cores.
It is definitely MeGUI problem because it was optimized for 1.2.2 xvid_encore. Zathor doesn't want to change anything because it won't write files over 2GB. On one hand you have 30% increase in speed and on the other ability to write files >2GB. I would always choose 30% increase but each to his own. :(

I can see Zathor's reasoning. Writing files over 2GB is probably an important consideration. I suspect when it comes to novice MeGUI users he'd be more worried about the plethora of "why won't it write files over 2GB" questions than inquiries about speed when most users wouldn't know there's a potentially faster version anyway.

After seeing your screenshots I don't imagine I'll bother upgrading Xvid and running tests using AutoGK. The incorrect selection of a profile and consequent incorrect VBV settings would be a deal breaker for me.

Edit 1: Thinking about it, I wonder whether those VBV settings would be helping to increase encoding speed given they have the potential to reduce the bitrate quite considerably in places. Do you generally run single pass or 2 pass encodes?

Edit 2: The version of Xvid which AutoGK installs has separate profiles for MTK chipsets. The main difference is the MTK profile allows the use of a custom matrix whereas the standard Home Theater profile enforces the use of the h263 matrix (that's the one AutoGK uses for the ESS option). I think (I'd have to run encodes to verify it) selecting "always use sharp matrix" in AutoGK's hidden options gets it to switch to using the MTK profile which then lets it use the mpeg matrix, but all the other Xvid settings remain the same. Selecting the MTK option in hidden settings of course uses an MTK profile but AutoGK also then uses a custom matrix, which I think varies according to the target file size and/or compression test. You'd have to experiment with the various hardware compatibility options and look to see what the Xvid encoder configurations look like as a result, but if with the ESS option enabled it's using the Xvid Mobile profile, who knows what sort of mess might be created when using the MTK option, or no hardware compatibility option at all. It probably explains the target file size issue when not using the ESS option though....

Edit 3: And one other thought....
AutoGK, with the version of Xvid it installs, uses at least four different Xvid profiles. "Home Theater PAL", "Home Theater NTSC", "MTK PAL" and "MTK NTSC". For one encode you've shown with the newer version of Xvid it uses the Xvid Mobile profile instead. What's it use in place of the other three profiles it'd normally use?

[hello_hello]

I Just Say That New Updates For Auto GK 2.55 Was Useful To Me
I Updated .dll Files and lame encoder & DGIndex & Xvid
You Should Try It Guys You Will See The Difference
Any Way Im Happy We Exchanged Thoughts & My Problem Was Gone :)

What difference? I've updated VirtualDubMod and Lame myself. I don't think I'd touch DGIndex in case anything has changed and it effects AutoGK's analysis of video, but what differences should I be looking for in my encodes compared to not updating those programs?

Are you going to enlighten us as to which codecs you use which aren't convered by Xvid and ffdshow, forcing you to use a codec pack? I'm still curious.

[kalehrl]

When running 2 pass encodes I very much suspect you're reducing the max buffer size from 3145729 to 1048576 and the maximum bitrate from 4854 to 1334. Not something which might effect every encode but it'd certainly effect some of them.
As I wrote before, I compared the Avinaptic analysis of the movie I made with 1.3.2 and 1.2.2 and the buffers were almost the same.
They differed a little of course because the films were different.

Does your version of Xvid include Dark Shikari's VAQ mod?
Yes, of course:
http://jawormat.republika.pl/compfaq.html

Yes it's selected automatically by using a profile (even though the GUI doesn't indicate it's use), and yes selecting a profile ensures a packet bitstream is used.... probably just like the VBV settings.
http://i42.tinypic.com/e5l44m.png
These are defaults and yes it is enforced by the profile but it should be greyed out and selected but obviously not when AutoGK encodes which is different from default autogk xvid behavior.

How do you check it was used? I'd be interested to know.
http://forum.doom9.org/showpost.php?p=1547146&postcount=281

After seeing your screenshots I don't imagine I'll bother upgrading Xvid and running tests using AutoGK. The incorrect selection of a profile and consequent incorrect VBV settings would be a deal breaker for me.
I would like to see someone else more experienced play and test the new xvid. I will certainly continue using it although I haven't encoded much since its installation but so far I have seen no side effects.

Edit 1: Thinking about it, I wonder whether those VBV settings would be helping to increase encoding speed given they have the potential to reduce the bitrate quite considerably in places. Do you generally run single pass or 2 pass encodes?
2 passes usually. The film above was created using 2 pass encoding.

What's it use in place of the other three profiles it'd normally use?
I don't know. It doesn't make sense to me either. Mobile profile is listed first in the list.

[hello_hello]

As I wrote before, I compared the Avinaptic analysis of the movie I made with 1.3.2 and 1.2.2 and the buffers were almost the same.
They differed a little of course because the films were different.

Well ignoring the "films were different" part as it left me fairly speechless, unless there's buffer undeflows Avinaptic only reports the minimum buffer fill, which it seems is going to be pretty similar for most video. Unless it actually reports buffer underflows for the profile you select in Aviaptic's preferences, which it's especially unlikely to do with VBV settings way more restricted than what's required, I doubt Avinaptec is really telling you anything useful there.


These are defaults and yes it is enforced by the profile but it should be greyed out and selected but obviously not when AutoGK encodes which is different from default autogk xvid behavior.

Try selecting an unrestricted profile manually, tick the packed bitstream checkbox, then select the Home Theater profile. The box should stay checked because that's how you left it but it's greyed out because now the option is being enforced by a profile. Now do the same thing again, but with the unrestricted profile selected, uncheck packed bitstream. Now select the Home Theater profile again. The packet bitstream box remains unchecked but becomes greyed out again.
The profile either enforces a packed bitstream or it doesn't. The profile's behavior didn't change between selecting it the first time and selecting it the second time. That's just how the GUI works and it works the same way whether AutoGK is setting up Xvid or you're doing it manually. AutoGK probably doesn't try to change the packet bitstream option because it doesn't have to. The profile enforces it.
At least, that's the way the version of Xvid which AutoGK installs seems to work.

I would like to see someone else more experienced play and test the new xvid. I will certainly continue using it although I haven't encoded much since its installation but so far I have seen no side effects.

You probably won't see any side effects, unless you encode a video which has it's bitrate overly limited in places due to VBV settings being unnecessarily enthusiastic. When someone with more experience tests the new Xvid with AutoGK, I'd be curious to know what would you'd need them to tell you in order to believe Xvid isn't being setup correctly.

I don't know. It doesn't make sense to me either. Mobile profile is listed first in the list.

Well if it were me I'd be running a few different types of encodes and having a look. As long as you're only encoding either PAL or NTSC and never changing the hardware compatibility option it'd probably safe to assume you're at least only restricting yourself to the mobile VBV settings, but it might be disappointing to check after running a few encodes of different types of video to find it's sometimes switching to a handheld profile and using even more restricted VBV settings or even to an unrestricted profile and not using any at all.

There's also some second pass settings which AutoGK uses which are different from Xvid's defaults. The default I-frame settings are:
I-frame boost%: 10
I-frame closer than: 1
are reduced by%: 20

AutoGK chages them to 0, 1 and 0 respectively.

AutoGK doesn't use the default Min and Max frame quantizers either. The defaults are all min 1 and max 31. AutoGK changes them according to the results of the compression test. If memory serves me correctly for a compression test of 75% and above it uses a min value of 2 and a max value of 3.

Just for fun, it might pay to check while running an encode to see if AutoGK is still able to change them all as it normally would. As I think they factor into the quality calculations, if AutoGK can't change the quantizer values as it normally would then the quality it reports mightn't be the same as it otherwise would be.

[kalehrl]

Unless it actually reports buffer underflows for the profile you select in Aviaptic's preferences, which it's especially unlikely to do with VBV settings way more restricted than what's required, I doubt Avinaptec is really telling you anything useful there.
If you know a way to check it, tell me and I'll give it a try.

AutoGK chages them to 0, 1 and 0 respectively.

AutoGK doesn't use the default Min and Max frame quantizers either. The defaults are all min 1 and max 31. AutoGK changes them according to the results of the compression test. If memory serves me correctly for a compression test of 75% and above it uses a min value of 2 and a max value of 3.
All that is changed properly in the 1.3.2 by AutoGK.

[hello_hello]

If you know a way to check it, tell me and I'll give it a try.

I started writing a post about having to make comparison encodes using each version of Xvid, then in the middle of it I had an idea.....

If you open Avinaptic and make sure the Home Theater profile is set in preferences, then use it to open a video which you know was encoding using AutoGK, the old version of Xvid and the ESS option, then analyze it, in theory there should be no buffer underflows reported. If you go back into preferences and then change the profile to DivX mobile, you'll probably find Avinaptic reports buffer underflows for days (the last one might even say "error, too many violations").

Now do the same thing again with an encode using the new version of Xvid. Avinaptic definitely shouldn't report any buffer underflows with the Home Theater profile selected, and if it still doesn't report any with the DivX mobile profile selected (which I strongly suspect is what will happen) then the video most likely will have been encoded using the Mobile profile's VBV settings instead of the Home Theater profiles ones.

I'll be interested to find out what results you get.

[kalehrl]

I get some complaints with xvid 1.3.2 about not complying with Xvid Mobile but much less than with default xvid.
1.3.2:

[ About file ]

Name: Sjećaš li se, Dolly Bell.avi
Date: Mon, 19 Dec 2011 20:46:50 +0100
Size: 733,966,336 bytes (699.965 MiB)

[ Magic ]

Tipo file: RIFF (little-endian) data, AVI, 640 x 368, 25.00 fps, video: XviD, audio: MPEG-1 Layer 1 or 2 (stereo, 48000 Hz)

[ Generic infos ]

Duration: 01:45:05 (6304.72 s)
Container: AVI OpenDML
AVI has index: Yes
Total tracks: 2
Track nr. 0: video
Track nr. 1: audio
ISFT: VirtualDubMod 1.5.10.2 (build 2542/release)
Junk: VirtualDubMod build 2542/release

[ Relevant data ]

Resolution: 640 x 368
Width: multiple of 32
Height: multiple of 16
Average DRF: 3.806
Standard deviation: 1.065
Std. dev. weighted mean: 0.738

[ Video track ]

FourCC: xvid/XVID
Resolution: 640 x 368
Frame aspect ratio: 40:23 = 1.739
Pixel aspect ratio: 1:1 = 1
Display aspect ratio: 40:23 = 1.739
Framerate: 25 fps
Total frames: 157,618
Stream size: 627,364,978 bytes (598.302 MiB)
Bitrate: 796.058 kbps
Qf: 0.135
Key frames: 984 (0; 250; 269; 519; 598; ... 157605)
Null frames: 0
Min key int: 1
Max key int: 250
Avg key int: 160.181
Delay: 0 ms

[ Audio track ]

Audio tag: 0x50 (MPEG (MP1/MP2))
Channels: 2
Chunks: 78,804
Stream size: 100,875,648 bytes (96.203 MiB)
Bitstream type (bs): MPEG-1 Layer II
Frames (bs): 262,697
Duration (bs): 01:45:05 (6304.728 s)
Chunk-aligned (bs): Yes
Bitrate (bs): 128 kbps CBR
Sampling frequency (bs): 48000 Hz
Mode (bs): stereo
Padding (bs): No
Emphasis (bs): none
Preload: 504 ms
Max A/V diff: 560 ms
Delay: 0 ms

[ Video bitstream ]

Bitstream type: MPEG-4 Part 2
User data: DivX503b1393p
User data: XviD0064
Packed bitstream: Yes
QPel: No
GMC: No
Interlaced: No
Aspect ratio: Square pixels
Quant type: H.263
Total frames: 157,618
Drop/delay frames: 0
Corrupt frames: 0

I-VOPs: 984 ( 0.624 %)
P-VOPs: 78769 ( 49.975 %) ##########
B-VOPs: 77865 ( 49.401 %) ##########
S-VOPs: 0 ( 0.000 %)
N-VOPs: 0 ( 0.000 %)

Max consecutive B-VOPs: 1

[ DRF analysis ]

average DRF: 3.806
standard deviation: 1.065
max DRF: 7

DRF<2: 0 ( 0.000 %)
DRF=2: 18268 ( 11.590 %) ##
DRF=3: 41569 ( 26.373 %) #####
DRF=4: 58632 ( 37.199 %) #######
DRF=5: 33683 ( 21.370 %) ####
DRF=6: 2591 ( 1.644 %)
DRF=7: 2875 ( 1.824 %)
DRF>7: 0 ( 0.000 %)

I-VOPs average DRF: 3.021
I-VOPs std. deviation: 0.779
I-VOPs max DRF: 6

P-VOPs average DRF: 3.049
P-VOPs std. deviation: 0.764
P-VOPs max DRF: 6

B-VOPs average DRF: 4.582
B-VOPs std. deviation: 0.711
B-VOPs max DRF: 7

[ Profile compliancy ]

Selected profile: Xvid Mobile
Resolution: 640 x 368 > 320 x 240
Framerate: 25 <> 30
Buffer underflow: 00:03:52 (frame 5802)
Buffer underflow: 00:45:05 (frame 67630)
Buffer underflow: 01:39:42 (frame 149540)
Buffer underflow: 01:39:43 (frame 149580)

This report was created by AVInaptic (22-11-2011) on 29-01-2012 21:34:36

1.2.2:

[ About file ]

Name: The Bridge on the River Kwai.avi
Date: Fri, 29 Apr 2011 09:26:29 +0100
Size: 943,104,000 bytes (899.414 MiB)

[ Magic ]

Tipo file: RIFF (little-endian) data, AVI, 640 x 256, 25.00 fps, video: XviD, audio: MPEG-1 Layer 3 (stereo, 48000 Hz)

[ Generic infos ]

Duration: 02:34:48 (9288.44 s)
Container: AVI OpenDML
AVI has index: Yes
Total tracks: 2
Track nr. 0: video
Track nr. 1: audio
ISFT: VirtualDubMod 1.5.4.1 (build 2178/release)
Junk: VirtualDubMod build 2178/release

[ Relevant data ]

Resolution: 640 x 256
Width: multiple of 32
Height: multiple of 32
Average DRF: 4.789
Standard deviation: 1.341
Std. dev. weighted mean: 1.021

[ Video track ]

FourCC: xvid/XVID
Resolution: 640 x 256
Frame aspect ratio: 5:2 = 2.5
Pixel aspect ratio: 1:1 = 1
Display aspect ratio: 5:2 = 2.5
Framerate: 25 fps
Total frames: 232,211
Stream size: 804,829,973 bytes (767.546 MiB)
Bitrate: 693.188 kbps
Qf: 0.169
Key frames: 1,337 (0; 250; 401; 588; 838; ... 232148)
Null frames: 0
Min key int: 4
Max key int: 250
Avg key int: 173.681
Delay: 0 ms

[ Audio track ]

Audio tag: 0x55 (MP3)
Channels: 2
Bitrate: 106.232 kbps VBR
Chunks: 387,018
Stream size: 123,341,712 bytes (117.628 MiB)
Bitstream type (bs): MPEG-1 Layer III
Encoder (bs): LAME3.98r
Frames (bs): 387,018
Duration (bs): 02:34:48 (9288.432 s)
Chunk-aligned (bs): Yes
Bitrate (bs): 106.233 kbps VBR
Sampling frequency (bs): 48000 Hz
Mode (bs): joint stereo
Padding (bs): No
Emphasis (bs): none
Preload: 504 ms
Max A/V diff: 520 ms
Delay: 0 ms

[ Video bitstream ]

Bitstream type: MPEG-4 Part 2
User data: DivX503b1393p
User data: XviD0050
Packed bitstream: Yes
QPel: No
GMC: No
Interlaced: No
Aspect ratio: Square pixels
Quant type: H.263
Total frames: 232,211
Drop/delay frames: 0
Corrupt frames: 0

I-VOPs: 1337 ( 0.576 %)
P-VOPs: 116675 ( 50.245 %) ##########
B-VOPs: 114199 ( 49.179 %) ##########
S-VOPs: 0 ( 0.000 %)
N-VOPs: 0 ( 0.000 %)

Max consecutive B-VOPs: 1

[ DRF analysis ]

average DRF: 4.789
standard deviation: 1.341
max DRF: 8

DRF<2: 0 ( 0.000 %)
DRF=2: 2922 ( 1.258 %)
DRF=3: 38571 ( 16.610 %) ###
DRF=4: 71307 ( 30.708 %) ######
DRF=5: 44920 ( 19.344 %) ####
DRF=6: 40889 ( 17.609 %) ####
DRF=7: 33431 ( 14.397 %) ###
DRF=8: 171 ( 0.074 %)
DRF>8: 0 ( 0.000 %)

I-VOPs average DRF: 4.486
I-VOPs std. deviation: 0.892
I-VOPs max DRF: 7

P-VOPs average DRF: 3.931
P-VOPs std. deviation: 0.967
P-VOPs max DRF: 7

B-VOPs average DRF: 5.67
B-VOPs std. deviation: 1.079
B-VOPs max DRF: 8

[ Profile compliancy ]

Selected profile: Xvid Mobile
Resolution: 640 x 256 > 320 x 240
Framerate: 25 <> 30
Buffer underflow: 00:00:28 (frame 711)
Buffer underflow: 00:00:30 (frame 761)
Buffer underflow: 00:00:32 (frame 803)
Buffer underflow: 00:00:33 (frame 829)
Buffer underflow: 00:00:34 (frame 847)
Buffer underflow: 00:00:35 (frame 871)
Buffer underflow: 00:00:36 (frame 905)
Buffer underflow: 00:00:38 (frame 943)
Buffer underflow: 00:00:41 (frame 1013)
Buffer underflow: 00:00:43 (frame 1065)
Buffer underflow: 00:00:44 (frame 1095)
Buffer underflow: 00:00:45 (frame 1137)
Buffer underflow: 00:00:49 (frame 1215)
Buffer underflow: 00:01:25 (frame 2113)
Buffer underflow: 00:01:26 (frame 2161)
Buffer underflow: 00:01:29 (frame 2231)
Buffer underflow: 00:01:31 (frame 2269)
Buffer underflow: 00:01:32 (frame 2300)
Buffer underflow: 00:01:34 (frame 2345)
Buffer underflow: 00:01:36 (frame 2393)
Error: Too many violations

This report was created by AVInaptic (22-11-2011) on 29-01-2012 21:38:27

[hello_hello]

I thought the default Xvid was 1.2.1? Not that it probably matters....

I just tried checking another AVI which I know was encoded using AutoGK (I picked a sci-fi movie with lots of action) and when setting the Home Theater profile in Avinaptic it reported two buffer underflows (40 minutes apart), so I guess Xvid's buffer control mightn't be perfect, but I'd also guess the odd one now and again probably wouldn't bother the majority of players. Once you start getting lots in a row though......

Anyway if the difference in the results you posted between the two Xvid versions are fairly consistent when setting the Mobile profile in Avinaptic, I'd be pretty confident the Mobile profile's VBV settings are the ones being used by the new Xvid version.

Do you actually have to worry about hardware compatibility or is hitting a specific file size accurately important to you? If not you could probably just disable AutoGK's hardware compatibility to see if you get lucky and it causes AutoGK to select an unrestricted profile in Xvid as it should. Or try the MTK option to see which profile Xvid uses then. Unfortunately though either might still cause Xvid to use the wrong one.

The main reason I stick with the ESS option these days isn't because of hardware compatibility so much but because if you don't AutoGK uses custom Xvid matrices and I prefer the h263 default.

[New-User]

Are you going to enlighten us as to which codecs you use which aren't convered by Xvid and ffdshow, forcing you to use a codec pack? I'm still curious.

I Already Told You Now Your Part To Test Things Yourself
To Gain More Knowledge As I Did :)

[hello_hello]

I Already Told You Now Your Part To Test Things Yourself

No you didn't. What should I be testing anyway? I know which I codecs I install and use. How do I test which codecs you need to use?

[kalehrl]

I thought the default Xvid was 1.2.1? Not that it probably matters....
Yes, that's the one. I believe megui xvid_encraw is 1.2.2 so I confused those two.
I'd be pretty confident the Mobile profile's VBV settings are the ones being used by the new Xvid version.
You are right. I now think that Mobile profile was definitely used.
Maybe I can ask Jawor to compile xvid 1.3.2 without mobile profile but I'm not that bold.
Do you actually have to worry about hardware compatibility or is hitting a specific file size accurately important to you?
I've got a wonderful Philips dvp 3260 dvd player with MTK chipset and with a custom fw (http://hdforall.freehostia.com/dvp3260_12.php) and it plays all xvid files no matter what matrix but I prefer h263. I do like nice, round sizes so I almost always use 2 pass encoding.

[hello_hello]

You are right. I now think that Mobile profile was definitely used.
Maybe I can ask Jawor to compile xvid 1.3.2 without mobile profile but I'm not that bold.

Well at least you haven't done a lot of encoding with the new Xvid and we both learned a bit along the way to working it out.

I don't know how AutoGK actually sets up Xvid, or if it does it via the script it writes for VirtualDubMod, but it does seem a pity the profiles aren't consistent between the Xvid versions.... at least in the way an external program would select them.

[kalehrl]

I tried encoding without compatibility option selected and the autogk did use unrestricted profile.
The matrix used was Jawor's 1cd matrix. The size was spot on.
Then I tried using MTK compatibility option and the size was also spot on.
The matrix was the same.
So what I wrote before about incorrect sizes using MTK option was not correct.
Too bad I can't make autogk use h263 matrix. :(

[hello_hello]

I think with some Xvid builds hitting a target size was broken when using any VBV settings and for some it was when using a custom matrix, or maybe it's been a combination of both.

As the latest Xvid seems to work as advertised maybe it's time to say goodbye to AutoGK?