AutoGK encode freezes (livelock?)

[fearofmimes]

Using AutoGK (first 1.96, then 2.12b), my encoding process is freezing at 52% during the "Analyzing source" stage. When I look at the log in VirtualDubMod, there are livelock messages. I tried converting the same movie the hard with straight GordianKnot, but it would freeze up whenever I tried to use Auto Crop. This leads me to believe that there is a problem with the video, but I gave DivX Creator a try and was successful. I'm curious about what might be causing the problem with AutoGK. I have tried this on two separate machines, one running an Athlon 64 3500+ and the other a Pentium 4M 2.0GHz. Both machines have 1GB RAM and had nothing going on ohter than the encoding project. Neither machine is overclocked. I have read through other threads with similar problems and most issues seemed to involve faulty hardware, but I don't believe that is the case here.

The log follows:

[7/14/2005 10:48:11 PM] AutoGK 2.12b
[7/14/2005 10:48:11 PM] OS: WinXP (5.1.2600).2
[7/14/2005 10:48:11 PM] Job started.
[7/14/2005 10:48:11 PM] Input dir: C:\WORK\VTS_01\PGC 1
[7/14/2005 10:48:11 PM] Output file: C:\WORK\VTS_01\PGC 1.avi
[7/14/2005 10:48:11 PM] Output codec: XviD
[7/14/2005 10:48:11 PM] Audio1: English AC3 6ch
[7/14/2005 10:48:11 PM] Subtitles: none
[7/14/2005 10:48:11 PM] Format: .AVI
[7/14/2005 10:48:11 PM] Target quality: 75%
[7/14/2005 10:48:11 PM] Started encoding.
[7/14/2005 10:48:11 PM] Demuxing and indexing.
[7/14/2005 10:51:56 PM] Processing file: C:\WORK\VTS_01\PGC 1\VTS_01_PGC_01_1.VOB
[7/14/2005 10:51:56 PM] Processing file: C:\WORK\VTS_01\PGC 1\VTS_01_PGC_01_2.VOB
[7/14/2005 10:51:56 PM] Processing file: C:\WORK\VTS_01\PGC 1\VTS_01_PGC_01_3.VOB
[7/14/2005 10:51:56 PM] Processing file: C:\WORK\VTS_01\PGC 1\VTS_01_PGC_01_4.VOB
[7/14/2005 10:51:56 PM] Processing file: C:\WORK\VTS_01\PGC 1\VTS_01_PGC_01_5.VOB
[7/14/2005 10:51:56 PM] Source resolution: 720x480
[7/14/2005 10:51:56 PM] Found NTSC source.
[7/14/2005 10:51:56 PM] Source aspect ratio: 4:3
[7/14/2005 10:51:57 PM] Analyzing source.

The analysis is getting stuck at frame 7866/14881 according to VirtualDubMod. Is this a bad frame? If so, what is the best way to address this issue?

[fearofmimes]

I'm still working this problem, but I can't figure out how to work around it. I have tried an updated version of VirtualDubMod (1.5.10.1), but that did not change anything. I was also suspecting that it might be related to determining the width since regular GordianKnot froze when trying to Auto Crop, so I have been playing with some of the hidden options to see if I could get it to skip the analysis but nothing seems to work so far.

What is being determined by analysis and is there a way to get it to skip it?

[niann]

Try ripping the DVD to your hard drive, and see if you can load the VOBs into DVD2AVI and create a project file. If you can do this your source should be ok.

As for skipping the analysis part of Auto GK there I am not sure.

Cheers!

[fearofmimes]

I searched around for info on DVD2AVI and it looks like it is now DGMPGDec. Is this correct? Anyway, I got that installed and had no problem saving a project in DGIndex. Since AutoGK uses DGIndex as well, this really isn't that extraordinary since AutoGK has not had problems with DGIndex. It is only during one of the analytical runs of VirtualDubMod that the freeze occurs.

I have fiddled some with settings for an AVISynth script and was able to get the video to stream with the main sound stream that I want. Now I want to figure out what is being accomplished with the analytical run in VirtualDubMod that causes the freeze so that I can figure out what is causing it and how to work around it. Is there anyone out there who has this information?

[fearofmimes]

Getting to know DVD2AVI was helpful since it allowed me to learn a little more of what is going on behind the scenes in AutoGK. Now, when I look in the agk_tmp directory, I think I am looking at what AutoGK was doing when it froze. The lastjob.vcf has the following:

VirtualDub.Open("C:\\WORK\\VTS_01\\agk_tmp\\_.avs",0,0);
VirtualDub.RemoveInputStreams();
VirtualDub.video.SetDepth(24,24);
VirtualDub.video.SetMode(0);
VirtualDub.video.SetFrameRate(0,1);
VirtualDub.video.SetIVTC(0,0,-1,0);
VirtualDub.video.SetCompression();
VirtualDub.video.filters.Clear();
VirtualDub.subset.Delete();
VirtualDub.SaveAVI("C:\\WORK\\VTS_01\\agk_tmp\\_.avi");

The _.avi file was definitely created and had a size of about 16MB, so I'm assuming that lastjob.vcf ran to completion. The _.avs script has the following:

LoadPlugin("C:\PROGRA~1\AutoGK\DGMPGDec\DGDecode.dll")
LoadPlugin("C:\PROGRA~1\AutoGK\filters\decomb.dll")
file="C:\WORK\VTS_01\agk_tmp\interlace.log"
global sep="-"
function IsMoving() {
global b = (diff < 1.0) ? false : true}
mpeg2source("C:\WORK\VTS_01\agk_tmp\PGC 1.d2v")
c = SelectRangeEvery(180,18)
global clip = c
c = WriteFile(c, file, "a", "sep", "b")
c = FrameEvaluate(c, "global a = IsCombed(clip, 32)")
c = FrameEvaluate(c, "IsMoving")
c = FrameEvaluate(c,"global diff = 0.50*YDifferenceFromPrevious(clip) + 0.25*UDifferenceFromPrevious(clip) + 0.25*VDifferenceFromPrevious(clip)")
crop(c,0,0,4,4)

I guess I need to dig into AVISynth to figure out what is going on here. It is writing to a log file called interlace.log that will most likely be an input to a future step. Can I assume that the freeze was occurring while it was writing to the interface.log file? Is there anything I should be looking for in there? Is there any way to infer the results from the log file and then kick into the next step to see if I can get around the freeze-up?

[fearofmimes]

I decided to take another crack at this with AutoGK 2.17b, but I got the same results.

I'm interested in finding out what AutoGK is trying to do when "Analyzing source" and processing the _.avs file in VirtualDubMod. Here is the script it is using:

LoadPlugin("C:\PROGRA~1\AutoGK\DGMPGDec\DGDecode.dll")
LoadPlugin("C:\PROGRA~1\AutoGK\filters\decomb.dll")
file="C:\CITYLIGHT_FILM\VTS_01\agk_tmp\interlace.log"
global sep="-"
function IsMoving() {
global b = (diff < 1.0) ? false : true}
mpeg2source("C:\CITYLIGHT_FILM\VTS_01\agk_tmp\PGC 1 (2ch).d2v")
c = SelectRangeEvery(180,18)
global clip = c
c = WriteFile(c, file, "a", "sep", "b")
c = FrameEvaluate(c, "global a = IsCombed(clip, 32)")
c = FrameEvaluate(c, "IsMoving")
c = FrameEvaluate(c, "global diff = 0.50*YDifferenceFromPrevious(clip) + 0.25*UDifferenceFromPrevious(clip) + 0.25*VDifferenceFromPrevious(clip)")
crop(c,0,0,4,4)

This is writing to the file interlace.log and showing a mixture of "false" and "true" combinations.

I guess I'm wondering (1) if it is possible to know why this is happening or (2) if it is possible to bypass this troublesome test to see if I can get this encoded using AutoGK. As I said previously, I was successful with this same title when using Dr.DivX for the same source material, but I prefer using AutoGK and I'm trying to figure out more how it works and how I can solve problems that I might encounter.

[len0x]

I had this once and my conclusion was - its combination of source plus avisynth/vdubmod that has problems. Once I cut off offending portion of video (it was very beginning in my case) everything went ok. If your freeze is in the middle of analysis step then you can just abort VDubMod and it should continue to work ok.

P.S. you can try latest RC of avisynth or VDubMod 1.5.10.2...

[fearofmimes]

I went ahead and killed VirtualDubMod after it got stuck and AutoGK went ahead and did the rest of the encoding. If the test that got stuck made it through 52% of the file, I'm assuming that there is not much of a chance that the failure to evaluate the rest of the file had much (if any) of an effect on the finished product. Would this be a valid assumption. I watched some of the resulting file on my computer and it looked alright, although the file was a little larger than I expected--but it is an old film and I seem to get larger file sizes with older films probably because of the film artifacts.

The problem I was having previously was that my attempts to abort VDubMod had failed and I never bothered killing the task via Windows Task Manager.

I plan to try different versions of avisynth and VDubMod in further testing to see if I can isolate the problem, but I feel good that just killing VDubMod allowed me to skip the rest of the test and continue with the encoding; that is exactly what I wanted to do.

Thanks!

[tkmops]

:confused: The above method(aborting VirtualDubMod) worked on 3 of the 12 VOB files that
I'm trying to convert to AVI. The other 9 hang at XX% 'analyzing source',
(livelock errors) then continue on after clicking the 'abort' button, than hang
at XX% 'compressibility test'(livelock errors). The abort button at this point
does nothing, it does not end VirtualDubMod, it just sits there, and I have to
end it via CNTL-ATL-DEL 'end program', which kills the entire process,
and ends the conversion.

I noticed that VirtualDubMod had an update available, so I upgraded from 1.5.4.1
1.5.10.2, and the same things happened. I then upgraded my AutoGK from 1.96 to
2.27, but found that this 'new' version doesn't have the option of inputting
VOB files. The old version offered a choice of DVD input or File input, this new
one doesn't seem to offer that. How can I input a VOB file? I went back to my old
1.5.4.1 version of AutoGK and downloaded the build2542 of VirtualDubMod.
Same thing as in my first paragraph.

Two questions:how can input VOB files into the new 2.27 version of AutoGK, and
how can get around these 'livelock' errors that I've been having?

Any ideas, anyone? Thanks!