Auto Gordian Knot: current version 2.55

[BigDid]

Originally posted by len0x
Aha, but what's the problem with that? I thought VBV takes care of it anyway...
...... speechless

/Edited: Searching ... /

Did

[Wesmosis]

You rock! :P:):O:(

[ukb007]

Your encode is as good as to be expected, given your source. And the link (http://forum.doom9.org/showthread.php?s=&threadid=77780) you quote is not relevant to your situation. A width of 608 and acceptable AR is pretty good, I'd say.

After finding source directory, AGK makes the primary report of AR from the stream info file, which, in turn, takes the info from the .IFO file in the DVD. The streaminfo file does not contain the running time, or AGK would have reported it, too.

Regards.

[Taurus]

Originally posted by len0x
Aha, but what's the problem with that? I thought VBV takes care of it anyway...
So I'm a little confused by now.
In my understanding if i enable "respect vbv buffer" straight curve scaling, this should act as a hard knee limiter (in audio terms) to make sure sudden bitrate bumps will not saturate the buffer on SAP's
or slow PCs. As Sharktooth figured out this might happen at 7000 kbs (same as Divx?).For compatibility reasons this was implanted.

So on my own tests I took a source with sudden sharp short motional I frame changes. Encoded it with and without "respect vbv buffer".
I know DRF Analyzer is sometimes not good on Xvid, but what makes me wonder: Both encodes show exactly the same height (in numbers) on the highest peaks graph. So no limiting at all (in comparision). But there was an influence to the average bitrate.

Of course Koepi 1.1.
Average bitrate at about 2000kbs.

Maybe some nice soul might explain this to me?

Cheers

Taurus

[len0x]

I'm not really an expert on the feature (XviD forum would be more appropriate place to ask about it) but I might speculate about it:

VBV buffer limit defines not a single frame limit but a window of frames, so if it just one frame with a large spike (that is to be corrected not because of buffer overflow but because of the curve) then if 7000kbit limit is allowed surrounding frames might get large bitrate to smooth the curve instead of reducing bitrate of the spike. (so average bitrate should be higher for such window). Only if VBV buffer is already maxed out then bitrate will be reduced.

I might be totally wrong though, so feel free to correct me in that case.

@Taurus

Do you have any single frames with >7000kbit size in that encode?

[BigDid]

Originally posted by Taurus
How did you get this thing working:


Hi Taurus,

2nd post on the subject, I have edited my tests (page 160), now 3 tests the third being with Xvid 1.02, same machine, same conditions, output to DRF analyser + 3 snapshots related on a B frame.

At the moment,no time to compare; if you can ,please do so or anybody feel free to.

Did

/Edited: Sorry, I was really in a hurry, asap I will take the time to compare -what I can- compare./

[richarddd]

Originally posted by Taurus
How did you get this thing working:

http://img123.exs.cx/img123/564/11defaults.png



http://img123.exs.cx/img123/3423/AutoGk.png

First picture is Xvid 1.1 defaults.
Second picture is AutoGk setting.
So, no use inside AutoGk.

Cheers

Taurus

Are you saying checking VBV won't matter in AGK because AGK changes 10-1-20 to 0-1-0?

From the thread for the latest xvid build in the xvid forum:

Posted by Koepi on 4th November 2004 10:51:

VBV works with hardcoded values currently, no matter what you enter as profile. I / we should adopt that of course. Don't forget this is a test build. We were wondering if VBV compliancy works as expected at all - which it seems to do. So now it's time to extend that.

[len0x]

Originally posted by richarddd
Are you saying checking VBV won't matter in AGK because AGK changes 10-1-20 to 0-1-0?

No, C'mon ppl :)
VBV is checked before writing output mpeg stream to ensure VBV compliance while all other 2-pass adjustemens are done before that! (otherwise VBV check box would not make sense).

P.S. Taurus, its your fault :)

[richarddd]

@len0x

It is Taurus's fault :)

I was trying to figure out what he meant, as I don't understand why there should be a relation between the 3 values and VBV. The Koepi quote in my edit shows that VBV works anyway.

[Mouse]

len0x,

I have discovred since version 1.79, that when doing "1min samples" from a MPEG2 (dvd) stream, and using the method to stop DGIndex and doing a so called "range-copy", the sound is taken from the beggining of the stream and not from where you "marked" in DGIndex.

I does not happen allways, but most randomly it seems.

Not a big issue really, just for your info.

[len0x]

its not >=1.79 specific issue, but just DGIndex behaves badly :)

[Taurus]

Originally posted by len0x
P.S. Taurus, its your fault :)
Nag,Nag!
Shame on me.
My interpretation was wrong.
From my job, I work a lot with audio tools called compressors and limiters.
Normally you would insert a limiter at the first part of the chain.
so the following stages will not be overdriven(is this correct english?)
My understanding on video compressing is not that good, so thank you len0x
for clearing up the sky for me :D
Anyway, I will do some testclips with real high voltage and feed it into my SAP, with and without vbv, with and without AGK's settings for intra frames tuning.
Stay tuned and if I'm right the Nag,Nag will be on you ;)

Cheers

Taurus

[BigDid]

Hi everybody,

I do not have access to my computer atm (motherboard ooo) and I cannot post the complete summary I wanted to share. This subject being still in process (no stable Xvid 1.1 released), I will re-make a short summary using the details of the 3 tests I made (page 160) here :
http://forum.doom9.org/showthread.php?threadid=64266&perpage=20&pagenumber=160

First of all THE TESTS ARE NOT RELEVANT. The actual AGK is not using the Xvid 1.1 beta (Koepi gui build) in a normal way (see Taurus posts on the subject). I have no idea and no information about the degradation that it may generate except the diferences in the DRF results and the snapshots (see below).

Summary about the tests :

I - Speed :
1/Xvid 1.1 defaults (strict curve+VBV) = 33’04 total time
2/Xvid 1.02 defaults = 33’21
3/Vxid 1.1 +VHQ for B-frames = 34’44
This was the initial purpose of the test, Len0x wanting to know how slow is VHQ for B-frames in Xvid 1.1

II – Quality
1/Xvid 1.02 = 4,46 average DRF
2/Xvid 1.1 defaults = 4,58
3/Xvid 1.1 +VHQ = 4,64
This seems to point out the abnormal results of the test. To my understanding, Xvid 1.1 should have better quality than 1,02, and 1.1+VHQ for B-frames should have better (overall) quality than 1.1 defaults. I may be wrong or not accurate on this point so please confirm or infirm.
Beside DRF analyser, another way to test the quality is to compare the snapshots. What I see (use x2 magnification to see the differences) is more blocks/shaggyness in the downleft corner in the 1.1 & 1.1+VHQ compared to the 1.02.

3/ VBV buffer ( a useful(expected) new feature to reduce spikes and/or high bitrates in SAP)
Considering the quality issue, I will not make any conclusion concerning the new VBV buffer feature. But if you look at the graphs from DRF analyser it seems clear the VBV feature is doing (part of ?) the job. Look specially at the I-frame (black bar) in the middle left part and see the difference between the 1.02 and the 1.1 build.

Conclusion
No conclusion except that I am willing to re-do the tests as soon as there is a AGK beta-build working well with a Xvid1.1 beta-build.

Did

P.S. Len0x & AGK do not support the Xvid 1.1beta actually and I am no Xvid specialist, I just use AGK.

[Sharktooth]

1.1+strict CS = better AVERAGE quality (that means better OVERALL PSNR)...
If you want to do a frame by frame comparison use LOOSE CS...

[len0x]

Originally posted by Sharktooth
1.1+strict CS = better AVERAGE quality (that means better OVERALL PSNR)...
If you want to do a frame by frame comparison use LOOSE CS...

what does this mean? That some of the frames may look worse and some better, so you cannot do comparasion directly with 1.02?

[Sharktooth]

Exactly. Strict CS encodings has better "low quality frames" and worse "high quality frames" than loose CS encodings.
The average quality is about the same but it produces a more "constant" encode (that's not always better...).

[len0x]

as I expected. Now the tough choice what should we do about it in AutoGK :)

[Sharktooth]

I did some tests and i found i like Strict CS only in low motion sources (they looks more like a constant Q encode) and sometimes with anime but i dont like it for action movies or in cases where there is mix of high and low motion scenes.
Loose CS is always good for every kind of sources.

[richarddd]

@Did

How do these look when you play the files on your SAP? Does VBV eliminate the stutter problem?

[BigDid]

Originally posted by richarddd
@Did

How do these look when you play the files on your SAP? Does VBV eliminate the stutter problem?

Yes.
This is the movie (LOTR3) that made my SAP freezes with a 2gb size, now with the VBV I can make the encode at 2.24Gb (1/2DVD). That makes, for that movie a 12% improvment. This is also my goal: make an encode with DVD or very near DVD quality and still use only 1/2 DVD; the blanks DVD are very expensive here :mad:
I believe more can be done with the VBV and maybe the high scene degradation: around 15 to 20% but no relevant tests done and no more possible atm.

By the way, I used loose curve+VBV for this LOTR3 encode for a little speed gain,see my very first tests( N°4=12.27fps versus N°3=11.84fps) here:
http://forum.doom9.org/showthread.php?s=&threadid=64266&perpage=20&pagenumber=154

The DRF graphs are also available and the peak differences without VBV are visible. /Edited: you can see also the differences in frame distribution between the 4 clips, even between strict curve and loose curve, with or without VBV/

I have still no info about the degradation impact, just read Sharktooth post about loose curve... Question: could this small quality difference (DRF average 4.46 to 4.58) be caused not by the Xvid 1.1 but by the 1.1 strict curve compared to 1.02 ? ( I did not made a 1.1 loose curve test) Sorry no more tests possible so I cannot answer my question.

Did

PS. The 2.24gb file is split in 2 with VDmod; if not my SAP just don't play that over 2gb size file.

[Sharktooth]

Originally posted by BigDid
Question: could this small quality difference (DRF average 4.46 to 4.58) be caused not by the Xvid 1.1 but by the 1.1 strict curve compared to 1.02 ? ( I did not made a 1.1 loose curve test) Sorry no more tests possible so I cannot answer my question.
Yes.

[len0x]

What change log doesn't mention is that its actually XviD 1.1 ready. I would not recommend using it yet that is why its not announced in public. The option to control bitrate spikes uses DivX home theatre profile and XviD VBV. Loose curve is forced in AutoGK as well now.

P.S. Let this info stay in this forum please :)

[richarddd]

Originally posted by BigDid
Yes.
This is the movie (LOTR3) that made my SAP freezes with a 2gb size, now with the VBV I can make the encode at 2.24Gb (1/2DVD). That makes, for that movie a 12% improvment. This is also my goal: make an encode with DVD or very near DVD quality and still use only 1/2 DVD; the blanks DVD are very expensive here :mad:

Excellent!

I may have to re-encode a number of movies using VBV. At least DVD blanks are not overly expensive here (on sale, you can get a 50 pc spindle for $20)

[richarddd]

Originally posted by len0x
What change log doesn't mention is that its actually XviD 1.1 ready. I would not recommend using it yet that is why its not announced in public. The option to control bitrate spikes uses DivX home theatre profile and XviD VBV. Loose curve is forced in AutoGK as well now.

P.S. Let this info stay in this forum please :)

Why wouldn't you recommend using it yet?

Will xvid 1.1 with 1.81 beta be worse than 1.1 with earlier betas?

P.S. I won't tell :)

[BigDid]

@Len0x, thanks for the 1.81.
I will have to negociate with my wife to install and use it on her computer, may takes some time...

@Sharktooth, thanks for the answer and the info.

Originally posted by richarddd
Excellent!

I may have to re-encode a number of movies using VBV. At least DVD blanks are not overly expensive here (on sale, you can get a 50 pc spindle for $20)
@ Richarddd,

May I advise you to be careful and make tests on DVD/RW first. Your SAP may not have the same threshold as mine. As Taurus as said experiment with different audio that may also influence on SAP processing (and stutter).

An exemple, I could not have a 2Gb encode (even with 1.1 & VBV) for the Tina TURNER in Wembley DVD-concert. Using the 2ch AC3 the max I could do without stutters (not freezing) is 1,850Gb. The video quality is so-so (not so bad, not so good)
This is why I am asking for even more SAP compatibility. If not, I will consider recoding (with recode or DVD-shrink) the DVD-concerts (and only them) and make use of the menus.

Concerning the blank DVD-R prices, the best I can do (until the stock is out) is around 20$ for 25 pieces(leaddata 4x), but usually the good brands are about 10 pieces for 50$ cough & recough. :eek:

Did

[len0x]

Originally posted by richarddd
Why wouldn't you recommend using it yet?


Not specifically to all the readers of this forum, just to the general public: I do not want promote beta versions of XviD, because AutoGK is being used by a _lot_ of ppl that expect production quality components in it :)

Originally posted by richarddd
Will xvid 1.1 with 1.81 beta be worse than 1.1 with earlier betas?


no, what gave you that idea ?

[richarddd]

@Did

test burns are always a good idea :)

I don't have a DVD burner yet, but hope to have one by the end of the week

@len0x

no, what gave you that idea ?

just checking.

thanks for the new version :cool:

[gudjong]

Like this tool alot for I do not need all the fetures in gk. What I mainly do with this is to avi files from my Dreambox. Files are often 2.5 to 3GB so I'ts nice to be able to shrink them on 1 cd.

What I miss however is the abilety to select 1pass encoding for faster decoding.

Thanks.

[len0x]

Originally posted by gudjong
What I miss however is the abilety to select 1pass encoding for faster decoding.


Target quality based encoding = 1 pass encoding in AutoGK. 1 pass CBR is not gonna be an option...

[gudjong]

Originally posted by len0x
Target quality based encoding = 1 pass encoding in AutoGK. 1 pass CBR is not gonna be an option...

Ok thank's for explaning this m8.

:)

[Carraway]

I might as well mention this -- if it's been hashed out before, feel free to ignore.

I was encoding some DVD extras yesterday, some of which were only a couple minutes in length, and the compressibility tests were taking nearly as long as the first pass itself. I looked at the avs files and I was getting numbers like this, e.g.:

For a 1:30 second clip, comp test frames: 2059; total clip frames: 2196.
For a :55 second clip, comp test frames: 1320; total clip frames: 1320 (heh).
For a 3:10 second clip, comp test frames: 2025; total clip frames: 4573.

I don't really know the comptest algorithm for how it decides what % to use, but this seems like overkill for short clips. Is there a reason it does this? Is it a secondary effect of a minimum # of comptest frames? If there is a limit, would it be possible to somehow reduce the comptest frames for clips where the total number of frames is less than the comptest limit? Or something? Just curious.

[bourtzovlakas]

@carraway
From the changelog of version 1.50 beta:
comp test and analysis step have now lower limit of 2000 frames for better accuracy on short sources

[len0x]

Originally posted by Carraway
I If there is a limit, would it be possible to somehow reduce the comptest frames for clips where the total number of frames is less than the comptest limit? Or something? Just curious.

On very short sources even 10% comp test can be upto 40-50% wrong...
So instead of redoing first pass its better to have more accurate info to start with.

[superdump]

I've been running AutoGK 1.81b on some episodes of 24. I left everything as auto and set it to use XviD. On installation I checked neither of the standalone compatibility options. I set the target filesize to be 250MB. Every time it has produced an oversized file (ranging from 309MB to 313MB) and every time it has rerun the first pass. From consulting the log files the size calculations of Video size = 250MB - Audio size - Overhead have been correct. Any ideas why the files are coming out incorrectly sized?

[len0x]

Originally posted by superdump
Any ideas why the files are coming out incorrectly sized?

Only episodes of 24? Can you try anything else?
And also - always provide log files...

[weiqj]

According to Doom9 news:
Nero Recode 2.2 is out, and it contains the new MPEG-4 AVC codec developed by ateme.

Any plan to support it?

[Sharktooth]

You cant use Ateme H.264 encoder from outside Nero Recode 2...

[ydobon]

I just tried to do my first 1.81b encode and I got a "EXCEPTION: Unable to set codec settings in registry." error message. Any idea about the problem?

I've uninstalled AGK and I'm trying again. Meanwhile, log is as follows:

[04/12/2004 20:45:59] AutoGK 1.81b
[04/12/2004 20:45:59] OS: WinXP (5.1.2600).2
[04/12/2004 20:45:59] Job started.
[04/12/2004 20:45:59] Input file: movie_1.ts
[04/12/2004 20:45:59] Output file: C:\dreambox\movie_1.avi
[04/12/2004 20:45:59] Audio: MPEG2 Audio on PID 0x55
[04/12/2004 20:45:59] Audio2: MPEG2 Audio on PID 0x54
[04/12/2004 20:45:59] Subtitles: none
[04/12/2004 20:45:59] Codec: XviD
[04/12/2004 20:45:59] Target size: 1493Mb
[04/12/2004 20:45:59] Custom audio settings: CBR MP3 with bitrate: 128Kbps
[04/12/2004 20:45:59] Started encoding.
[04/12/2004 20:45:59] Demuxing and indexing.
[04/12/2004 20:52:54] Processing file: C:\dreambox\movie_1.ts
[04/12/2004 20:52:55] Processing file: C:\dreambox\movie_2.ts
[04/12/2004 20:52:55] Processing file: C:\dreambox\movie_3.ts
[04/12/2004 20:52:55] Processing file: C:\dreambox\movie_4.ts
[04/12/2004 20:52:55] Source aspect ratio: 4:3
[04/12/2004 20:52:55] Source resolution: 528x576
[04/12/2004 20:52:55] Found PAL source.
[04/12/2004 20:52:55] Analyzing source.
[04/12/2004 21:02:45] Source has percentage of interlacing in motion areas: 0,11
[04/12/2004 21:02:45] Source is considered to be progressive.
[04/12/2004 21:02:46] Found 184456 frames
[04/12/2004 21:02:46] Encoding audio.
[04/12/2004 21:15:31] Encoding second audio.
[04/12/2004 21:28:49] Audio size: 118,053,248 bytes (112.58 Mb)
[04/12/2004 21:28:49] Audio 2 size: 118,052,480 bytes (112.58 Mb)
[04/12/2004 21:28:49] Overhead: 4,380,928 bytes (4.18 Mb)
[04/12/2004 21:28:49] Video size: 1,325,037,312 bytes (1263.65 Mb)
[04/12/2004 21:28:49] Running compressibility test.
[04/12/2004 21:28:49] Writing the following script to C:\dreambox\agk_tmp\movie_1_comptest.avs
===========================================================
LoadPlugin("C:\PROGRA~1\AutoGK\DGMPGDec\DGDecode.dll")
LoadPlugin("C:\PROGRA~1\AutoGK\filters\autocrop.dll")

movie = mpeg2source("C:\dreambox\agk_tmp\movie_1.d2v")
cropclip = autocrop(movie,mode=0,wmultof=4,hmultof=4,samples=10,aspect=0,threshold=34,samplestartframe=0)
fixed_aspect = 1.45454545454545
c_width = width(cropclip)
c_height = round(height(cropclip) / fixed_aspect)
input_par = float(c_width)/float(c_height)
input_par = input_par > 1.4 ? input_par : (4.0/3.0)
out_width = 704
out_height = round(float(out_width) / input_par)
hmod = out_height - (floor(out_height / 16 ) * 16)
out_height = (hmod > 4) ? (out_height + (16 - hmod)) : (out_height - hmod)
new_aspect = (float(out_width) / float(out_height)) / fixed_aspect
autocrop(movie,mode=0,wmultof=4,hmultof=4,samples=10,aspect=new_aspect,threshold=34,samplestartframe=0)
LanczosResize(out_width,out_height)
SelectRangeEvery(300,15)
===========================================================
*************************************
EXCEPTION: Unable to set codec settings in registry.
*************************************
[04/12/2004 21:28:49] Job finished.

[len0x]

Originally posted by ydobon
I just tried to do my first 1.81b encode and I got a "EXCEPTION: Unable to set codec settings in registry." error message. Any idea about the problem?


Interesting... I've implemented a check if AutoGK can actually write a registry. What account (admin, limited etc) are you running AutoGK under?

P.S. was it your first run after you installed XviD by any chance ?

[ydobon]

Hi,

Originally posted by len0x
Interesting... I've implemented a check if AutoGK can actually write a registry. What account (admin, limited etc) are you running AutoGK under?
Admin, so it should not have problems with that.

Also posted by len0x
P.S. was it your first run after you installed XviD by any chance ?
Yes, it was. Damn DivX keep stealing XviD's FourCC and I tried the brute force approach (after failing that, I found the DivX checkbox *blush*).
Can it be that the problem?

uninstalled everything, rebooted, reinstalled again and same error :(

I went back to AGK 1.80b and now it works as expected


Regards,

[len0x]

Originally posted by ydobon
Yes, it was. Damn DivX keep stealing XviD's FourCC and I tried the brute force approach (after failing that, I found the DivX checkbox *blush*).
Can it be that the problem?


Yes, I check if I can write the registry key, but it fails if the key is not there (XviD deletes registry settings on install). I fixed that already, but to make it work with 1.81 you need to display XviD config window at least once befoe starting AutoGK.

[len0x]

Originally posted by ydobon
uninstalled everything, rebooted, reinstalled again and same error :(


try 1.82 with the same scenario

[BigDid]

Originally posted by len0x
P.S. Let this info stay in this forum please :)
Hi Len0x,

I have a Working PC again (same mobo with a XP2400 instead of a 2800Barton), just tried to redo the same tests with AGK 1.81 and I have the same problem, AGK changes the 2nd pass Intra-frames tuning from 10/1/20 to 0/1/0
Still have no info on the possible degradation, but what I see is Xvid 1.02 seems better than 1.1 used by AGK (defaults beeing: loose curve scaling, VHQ for B-frames, no VBV buffer)

Do you mind if I post in the Xvid 1.1 thread quoting this thread to have more info on the subject?

Did

[len0x]

Originally posted by BigDid
AGK changes the 2nd pass Intra-frames tuning from 10/1/20 to 0/1/0


Again, what is wrong with that? (we seem to be runing in circles here)

[BigDid]

Originally posted by len0x
Again, what is wrong with that? (we seem to be runing in circles here)

Quoting my post: "... but what I see is Xvid 1.02 seems better than 1.1 used by AGK (defaults beeing: loose curve scaling, VHQ for B-frames, no VBV buffer)"
Don't have atm access to the new tests but it is still the (small) difference in the DRF, something like:
1.02->DRF 4.46
1.1 -> DRF 4.54 /Edited: confirmed/
I take your answer as a no

Did

PS: I will edit the DRF results with the exact values asap

[len0x]

I might be reading you wrong, but I thought that what actually bothers you is AutoGK's second pass setting that were to blame and not quality of 1.02 vs 1.1 (and that I do not understand).

So as far as I can see its no longer about AutoGK, but just XviD and indeed folks over at XviD forum should be able to answer your question there.

P.S. DRF doesn't tell you that much - do you see real difference in quality?

[ydobon]

Hi, Len0x.

Originally posted by len0x
try 1.82 with the same scenario
Done. It worked flawlessly. Thanks.

[richarddd]

Shouldn't xvid with VBV have marginally worse quality than without VBV, as VBV prevents it from distributing bytes most efficiently.

I share len0x's view that DRF doesn't tell you a lot, especially small DRF differences. I'd rather rely on visual inspection.

For me, being able to limit the maximum bitrate, to deal with standalone stutters, is more important than minor quality differences. I can always increase the size of the encode to add quality, so long as it doesn't exacerbate playback issues. Alas, I don't know which settings are best for that. We may have to wait for a newer xvid 1.1 in which they let you set maximum bitrate.

EDIT: I found this by Sharktooth in the xvid forum. Does AutoGK behave as described?

...do not use ultra-high bitrates (at least until xvid 1.1 with VBV buffer), do not use QPEL, do not use GMC, use MP3 (suggested choice) or AC3 (only if you know HOW to mux it) audio and AVI container, do not use custom quantization matrices with INTER frame matrix that have values, or at least that start (the value in the upper left corner) with a value, lower than "16".
...if you're going to use 1 max cons. Bframe (suggested choice) select packet bitstream. If you're going to use 2 max cons. Bframes uncheck packet bitstream... in any case do not use more than 2 max cons. Bframes.

[len0x]

Originally posted by richarddd
EDIT: I found this by Sharktooth in the xvid forum. Does AutoGK behave as described?


with ESS option and XviD 1.1 it does (well apart from packed stream option that is always off)

[Carraway]

Hey, I've got a mystery bug. Maybe this has been discussed before, but I can't figure it out:

I have an ATI HDTV Wonder (for the time being), and it records video to generic mpeg-2 files (I think). Anyway, I load a clip into AutoGK and press start -- DGIndex pops up, and then...nothing happens.

It basically opens the clip in DGIndex and then it just sits there. It doesn't lock up or anything -- I can hit F5 and it runs preview just fine, but F4 (or File -> Save Project) simply DOES NOT WORK. As far as I can tell, this is the only thing that doesn't work. It functions as though I had opened the clip in DGIndex normally, except that I can't save. So I'm forced to close DGIndex (prompting the "Can't find D2V" error, obviously) or terminate the process through AutoGK.

The weird thing is, if I run DGIndex from the AutoGK folder, then I can open the clip and save it as a project just fine. When I first load it, I get a "Warning, Opening GOP is not closed" warning, but that's it. So this problem only happens through AutoGK.

Len0x -- do you use some obscure setting when launching DGIndex that might cause this?

--

Reference stuff:

Media Player Classic lists these streams when I open the file, maybe it'll give you some kind of hint:

Video(0000,e0,00)
Audio(0000,bd,80)
Subtitle(0000,00,00)

And since there aren't really any logs that can show what's going on, here is a sample clip (http://home.cinci.rr.com/mike45069/WWHO-GG.mpg) from an HDTV broadcast of Gilmore Girls. It's only like half a second long, since I have a 5mb disk space limit, but it still gives me the problem. If you can't reproduce the bug, then I'll be quiet. :)