lets get a new version of AutoGK out

[len0x]

First, let me say I'm still around and finally got to a point when I have a new dev environment set up and compiled current version of AutGK with it. Having not read last year+ of posts it would be good if you guys could brief me if there are any known/outstanding problems with the latest 2.48 version.

I've already updated DGIndex and filters to the latest versions and wanted to see if a new XviD version was out, so I checked out Celtic Druid's version from this spring and couldn't get it to work on my Vista64 box (can't even launch encoder configuration window) while last 12/06 version is working just fine.

I'm not actively resuming development though, but will have some time to work on it this winter.

[budwzr]

Whoo-Hoo!!!!!

[Barough]

Thats great news :)

[buzzqw]

welcome back len0x!

you will surely do a good work!

even if xvid is a little outdated...

BHH

[Sargon]

Lenox it is a pleasure to read your back . Agk will be improve definitly. There must be a lot of corrections. Since I use Agk, I always enjoy this program, easy to use, simple but so much powerful. There are no others that come close to AGK. My standalone runs always great, and the sound is beautiful and never too loud.... Again, I say thank you Lenox for what you already done in the past and for what's coming next.

[Codex0nz]

i remember using this app back before i went to megui and started annoying this forum with n00b questions :P

AutoGK is a wonderful application and i am very happy to see that the development of it is being revisited, this will surely help a lot of new people ease into the encoding scene and not kick & scream at it :D

[Taurus]

Boy, it's great to see you back on the tracks!
It was getting a little humdrum without you.
So here are the first todos:
A "new" XviD 1.2 stable just arrived.
And a so called 1.3 branch is open.
Many noobs got confused by video aspect ratios and therefore complaining.
Automatic detection is somewhat buggy.
I think older versions did a better job on this.
And you know, I'm into this since Prehistoric AutoGk..
(GordianKnotItFast4U)
Cheers

Taurus

[len0x]

And you know, I'm into this since Prehistoric AutoGk..
(GordianKnotItFast4U)


Ah, good old times :)

Anyway, I'm aware about XviD 1.2. Unfortuntely Celtic_Druid seems no longer around and I do need an MTK build of it...

And what about AR detection being buggy? Can I have some relevant threads about this? Cheers.

[CWR03]

How much trouble would it be to add support for episodic disks? I realize that different PGC's are selectable, but the output will always contain all eps in one file.

[linyx]

I know that this is not a feature request thread, but it might be a good idea to incorporate DivX 7 and its standalone profile(s) when it is released (soon, hopefully).

[len0x]

How much trouble would it be to add support for episodic disks? I realize that different PGC's are selectable, but the output will always contain all eps in one file.

That's because DGindex will load the whole vob set. We would need an option to do the cutting via CLI in it (assuming I can get the cut points from an IFO file, although I'm not really that familiar with DVD structure) which we do not have at the moment.

*EDIT* Actually we can select frame range in avisynth script, so in theory its possible even without DGIndex... I'm not clear how to find that frame range from IFO though yet...

[len0x]

I know that this is not a feature request thread, but it might be a good idea to incorporate DivX 7 and its standalone profile(s) when it is released (soon, hopefully).

I've been out of the loop with DivX7 - does that still have VfW interface?

[den78]

glad to see you back len0x :)
thanks for keeping agk alive m8.

[linyx]

I've been out of the loop with DivX7 - does that still have VfW interface?
Well, it supports avisynth, which is VfW, correct?

[Mtz]

Welcome back!
I that "old times" I asked you if you can implement "Keep interlaced". Your response was somethink like: "This is a useful feature". Now?
Regarding AR, try to make some test with a DV which was shoot in 16:9 mode. For pal is 720x576 but with 16:9 AR.
Mod 16 will be forever? At least mod 8 to have.

enjoy,
Mtz

[weaver4]

I made a comment a few months ago that I would like to be able to configure the location of the agk_tmp directory.

My reason for this is that I want the output of my encode to be on my media-server next to my TV, but I run autogk on my mainpc. So having the agk_tmp directory on my media-server over the network really slows down the encoding time and ties up my network.

[PoloZ7]

Great news, how long I have waited !

[len0x]

Well, it supports avisynth, which is VfW, correct?

Please don't me laugh :) (no pun intended)

[len0x]

I made a comment a few months ago that I would like to be able to configure the location of the agk_tmp directory.

Valid request. I'll be honest though - now that I look at the hidden options (where this option would go) it doesn't make sense to keep the kind of implemenation it is at the moment (via dot files), but rather make a proper registry entries. And this would not be the first thing I would like to do...

[len0x]

Welcome back!
I that "old times" I asked you if you can implement "Keep interlaced". Your response was somethink like: "This is a useful feature". Now?


I can only assume that should have been "This is not a useful feature", right? :) I still don't see this as a mass usage option (especially if not all the codecs support it, but I'm rusty in this department do x264/divx7 support interlaced encoding?).


Regarding AR, try to make some test with a DV which was shoot in 16:9 mode. For pal is 720x576 but with 16:9 AR.
Mod 16 will be forever? At least mod 8 to have.


This isn't AR problem, this sound more like "too much cropping" kind of problem...

[Brother John]

I've been out of the loop with DivX7 - does that still have VfW interface?
DivX 7 isn’t finished, so it’s too early to say anything final. Only betas (decoder (http://forum.doom9.org/showthread.php?t=141086), encoder (http://forum.doom9.org/showthread.php?t=137786)) are out. From what DivX Inc. has revealed so far they are going for H.264/MKV and abandoning VfW, which makes perfect sense for that codec/container choice. However nothing has been said if the DivX 7 package might include the traditional DivX ASP VfW encoder (possibly in an updated version?).

[linyx]

Please don't me laugh :) (no pun intended)

I don't know much about VfW, but AFAIK, AviSynth "outputs" its video format to VfW. Taken from wikipedia:
It stands as an intermediary between a digital video source, like an AVI or MPEG, and a VFW receiving program
That's just what i understand of it. Sorry for sounding stupid.

[len0x]

VfW is a codec interface that is being used by VirtualDubMod (and hence AutoGK) to communicate with encoding engine... Avisynth is just a video scripting environment that does processing before video even comes to VDubMod. So ability of a codec to support VfW interface means easier integration into AutoGK (and for example for x264 CLI version I would have to completelety rewrite the way AutoGK encodes video because its not VfW way of doing things).

[MasterNobody]

May be you can think about adding x264vfw (http://sourceforge.net/projects/x264vfw/) support to AutoGK (but you must be prepared that a lot of Doom9 members would start to blame you talking that MPEG-4 AVC unsuitable for AVI even though MPEG-4 ASP have the same limitations and this doesn't stop it using with AVI).

[linyx]

VfW is a codec interface that is being used by VirtualDubMod (and hence AutoGK) to communicate with encoding engine... Avisynth is just a video scripting environment that does processing before video even comes to VDubMod. So ability of a codec to support VfW interface means easier integration into AutoGK (and for example for x264 CLI version I would have to completelety rewrite the way AutoGK encodes video because its not VfW way of doing things).
Good explanation, thank you.:goodpost:

[den78]

May be you can think about adding x264vfw (http://sourceforge.net/projects/x264vfw/) support to AutoGK (but you must be prepared that a lot of Doom9 members would start to blame you talking that MPEG-4 AVC unsuitable for AVI even though MPEG-4 ASP have the same limitations and this doesn't stop it using with AVI).

vfw x264 sounds good to me ...& integrating mkv container in agk shouldn't be a problem, right?

[AMED]

I was wondering if it was at all possible to intergrate MeGUI or AutoMKV's auto deinterlacing into AutoGK?

[buzzqw]

autogk deinterlacing's routines is good
it was the base of megui and automkv works on auto detecting routines (thanks to IanB)

the only suggestion i can give is to update the deinterlacing filters

BHH

[len0x]

Deinterlacing filter AutoGk is using - LeakKernelDeint. Is there a new version out ?

[AMED]

I'm not sure that LeakKernelDeint is the best for all deinterlacing scenarios.

AutoGK and MeGUI analyze the video and based off the results choose the best deinterlacer.

e.g.
Yadif
TDeint
TDeint+EDI
Tomsmocomp
Fielddeinterlace
Fielddeinterlace (no blend)

Buzzqw has implemented it into Automkv so hopefully he can tell you more how it works.

[yetanotherid]

I made a comment a few months ago that I would like to be able to configure the location of the agk_tmp directory.

My reason for this is that I want the output of my encode to be on my media-server next to my TV, but I run autogk on my mainpc. So having the agk_tmp directory on my media-server over the network really slows down the encoding time and ties up my network.

I guess it can't hurt to have it configurable, but I like it defaulting to the output location for the reason you don't. I usually put the source file on one RAID volume and the output file on another. That way they seem to share the work and I can keep using the PC without hard drive activity seeming to slow it down much.

One thing AutoGK really could use is the ability to pause it and the ability to save jobs between sessions would be nice.
Being able to run the compressibility test and have AutoGK then tell you what resolution and quality you'll get for a chosen file size would be great. I find myself guessing as to the file size then having to run the compressibility test several times until I get it right.
It'd be handy to have the ability to re-use an already demuxed or encoded audio file or a previous compressibility test when re-encoding rather than have to start the process from scratch, and along those lines....
AutoGK clears it's temp folder before each job (if the output files are in the same directory). A separate temp folder for each job would mean that if you encode a batch of videos, then decide you want to re-encode a couple of them, you'd already have the demuxed, converted audio track to add manually later rather than AutoGK needing to convert it again.

Oh and given the proliferation of h.264 video in one container or another, if AutoGK could handle the appropriate file/video/audio formats to enable it to re-encode them to XviD.... I find myself more and more downloading an MP4 or sorts, but wanting video which will play on my standalone player I have to go through a convoluted process to convert it. Preferring to use AutoGK for the job, I'm often having to use another program to convert the MP4 to an AVI containing uncompressed video and audio, then using AutoGK to convert that to XviD. :-(

[Haubi]

Good news, len0x is back! :D

Here a few suggestions from the old topic "Auto Gordian Knot: current version 2.48 beta":

infiniter wrote:

- when opening an IFO with multiple PGCs and selecting one of them, the demuxer and the audio encoder process the whole VOB, not only the selected PGC. This consumes unnecessary time, because both tools are not able to transcode a multi-PGC VOB into single files. For every PGC and file, the complete VOB audio will be encoded, which stretches the audio encoding time to 6x if there are 6 PGCs.

- Audio encoding is done BEFORE video encoding (which seems illogical), though the picture is the most important item. Audio encoding mostly runs smooth without problems, while video encoding often results in bad quality (to blurry) or wrong resolution (if "Auto" is used). It would be better to encode a test sample of video from the source and show it to the user (as an option). Then the user can decide to take the settings and continue, to change them (and restart test encoding) or to discard. I know, this is intended to be automated because its "Auto"-GK, not the normal GK. But the normal GK is too complicated for occasional users.

- the preview mode has no relevance to the resulting picture quality and is thus useless

- VD still does not take advantage from multi-core processors

- no test encoding with preview

- if a transcoding session is aborted by any reason (error or by user) and the settings were not changed before it is started again, the whole demuxing/encoding thingy starts from the very beginning, instead of re-using the present files. This can be very annoying and extremely time consuming

- audio encoding is slooooooow! Only up to 8x on a Pentium D with 2.8GHz. Compared to old audio ripping tools like EAC, which would rip and encode a whole CD to MP3 in some minutes which results in 20x or higher, LAME or the other libs are medievally lame. (Uhm, err, I guess that's where LAME's got its name...)

- multi-core processors could easily encode audio and video at the same time - this is not used

[len0x]

vfw x264 sounds good to me ...

Is that actively developed alongside regular x264? I also have a general problem with x264 that (unlike XviD/DivX for example) it doesn't have a concept of a release. So lots of time could be spent just making sure bundled version is more stable than all the revisions that are getting out. After all, I take bugs in the tools I'm using personally :)

[len0x]

AutoGK and MeGUI analyze the video and based off the results choose the best deinterlacer.
e.g.
Yadif
TDeint
TDeint+EDI
Tomsmocomp
Fielddeinterlace
Fielddeinterlace (no blend)


There is one big difference from AutoGK to all those tools - you can always override automatic way of things with lots of manual options in them. So unless it can be proven that automatic deinterlacing is acceptable in 99% cases (and I haven't heard anyone complaning about deinterlacing in AutoGK in a while) I just don't see a reason for doing so (and frankly I prefer others copying me rather me copying them :) )

[buzzqw]

I haven't anything to teach to Len0x! always kudos the Master!

this was a little old (i no more use bautodeint, but my own routine based on bautodeint) but you can check this
http://forum.doom9.org/showthread.php?p=937978#post937978

BHH

[Barough]

It would be gr8 if u would add support for the official Xvid 1.2.1 using Koepi's builds.

[len0x]

I have built it (with 1.2.1) but ESS option isn't working there, so I don't know what to do with that yet...

[den78]

Is that actively developed alongside regular x264? I also have a general problem with x264 that (unlike XviD/DivX for example) it doesn't have a concept of a release. So lots of time could be spent just making sure bundled version is more stable than all the revisions that are getting out. After all, I take bugs in the tools I'm using personally :)
don't know 'bout active development m8, maybe it's because i don't use it that much, but it sounds good, cause no matter if it's vfw or cli, what matters is that it's x264 & hopefully it would be a part of next agk :)

I have built it (with 1.2.1) but ESS option isn't working there, so I don't know what to do with that yet...
1.3.0 cvs works ok with ess (xp sp2) ...i mean the final size is correct :)

[Carraway]

Welcome back, len0x. I'd like to throw my hat in the ring for x264/MP4 support. It's the next standard. Adding additional features to Xvid/AVI is fine, but realistically AutoGK has been rock solid for years and not a lot of developments have been made in that arena.

H.264 inside MP4 on the other hand is now the standard in every iPod, in Flash video, Quicktime, etc. It might be worth rewriting the encoding engine to support CLI. If an AutoGK-like program existed for X264 it would be a killer app; right now all we have is MeGUI, Stax and AutoMKV, all of which are more complicated and less stable than AutoGK in its current state (not to mention the first two are mired in .NET hell).

Thanks again for all your great work with AutoGK, it's saved me probably days or weeks of encoding work over the past several years.

[Sharktooth]

@lenox: just FYI, jawor made some xvid 1.2.1 builds with MTK and DivX profiles. check this: http://jawormat.republika.pl/xvid.html
oh... and welcome back :)

[len0x]

I was using Jawor's builds already and they do have problems with ESS option. I finally managed to build XviD from head myself though and my first test gave me spot on size with 2.48 which is promising, but I need to do more testing.

[Sharktooth]

right now all we have is MeGUI, Stax and AutoMKV, all of which are more complicated and less stable than AutoGK in its current state (not to mention the first two are mired in .NET hell).
+ ripbot264, autoff, bencos, avidemux... etc.
also, what's the problem with .NET? if you have problems with .NET then your system is misconfigured... and i guess you never tried the OneClick Encoder in megui...
btw, this is about autogk and i agree, x264 support would be great.

[Carraway]

+ ripbot264, autoff, bencos, avidemux... etc.
also, what's the problem with .NET? if you have problems with .NET then your system is misconfigured... and i guess you never tried the OneClick Encoder in megui...

This was a worthless derail. My system configuration is fine, and I've used the One Click Encoder about six-hundred thousand times, so I think I'm pretty well-versed in what I'm talking about. None of the programs you listed are anywhere near as simple, stable and intuitive as AutoGK is. If they were, I wouldn't bother asking len0x for x264 support.

[len0x]

I'm glad AutoGK still serves its purpose as simple and robust tool (in fact I don't consider it a tool, but rather a product) after all these years :)

My first priority atm is to get next stable version out with all the updated tools and only after that I can start doing something new like x264 (MKV support would probably have to be added first though). I was struggling with latest XviD for a while, but it looks like my own build is working correctly but I still have to test different platforms.

[len0x]

OK, so I got 2.50 alpha out. It contains 1.3.0 build of XviD and lots of updated tools.

[TheTooleMan]

Just downloaded 2.50 alpha and looking forward to trying it out.

I've been trying lots of conversion software and tools and find AutoGK gives great results more consistently than any other software I've used.

The one thing I would like to add to AutoGK is being able to turn on greyscale encoding for DivX and Xvid output. When encoding captures from DVD's made from B&W VHS tapes, quite often the output is green or bluish or has colored areas. True greyscale is much nicer to view. There's a greyscale checkbox in the hidden advanced options, but it only applies to Xvid and only to credits (or did I miss something).

Oh yeah, while you're at it, it would be nice to be able to mux an audio file while rendering DivX or Xvid in AutoGK.

Thanks for all your work! Glad to see this product hasn't been abandoned. ;-)

[buzzqw]

and now waiting for x264.exe , mp4, and mkv support!!!

(you can mutuate some profiles from megui/ripbot/automkv)

BHH

[len0x]

well, its not a stable version :) (well unless everything magically works)

I was hoping to build x64 binaries of XviD to bundle with the installer, but can't seem to use them yet (weird range check errors, which mean its not installed properly, I'm guessing x64 dll registartion is different from 32 bit...). Also I will need to check out that VAQ patch...

[Barough]

@ len0x

Is there a special reason why you don't use the latest stable release of Xvid instead of the v1.3.0 CVS?

[Sharktooth]

@lenox: VAQ for Xvid is good, not as good as in x264 though (due to the MPEG4 ASP quantizers distribution).
However avoid using it on hardsubbed sources or toons (actual/detailed anime are ok) since it will produce visible ringing around very hard edges.