Gordian Knot with x264 support is here (v 0.34.8 beta)

[len0x]

Something for the public to play with. :) Head off to sourceforge to get latest beta that supports x264 codec (I used latest build from celtic_druid here: http://celticdruid.no-ip.com/xvid/ Note that x264 doesn't include decoder atm, so to be able to play its files you need to install latest ffdshow from the link above).

please note that x264 is still in alpha developemnt stage

Upgrade instructions:
always uninstall x264 before installing new revision, then always delete
- default_x264_firstpass.settings
- default_x264_secondpass.settings
in GK folder after upgrade of both GK and x264

0.34.8 beta

- fixed comp test for x264 on advanced SaveAVS window
- MPEG2 decoding library setting is removed (GK always uses DGDecode.dll from where DGIndex.exe resides)
- DGMPGDec updated to version 1.2.0 RC3

0.34.6

- fixed loading of "don't check" check boxes on the path tab
- fixed first comp test script upon startup of GK
- DGIndex is updated to version 1.2.0RC2

0.34.5

- fixed opening of AVI files (any kind that has proper VFW decoder installed can be opened now)
- DGIndex updated to version 1.2.0b6 (1.1.0 was not recommended for usage)
- filters xml definitions are updated

0.34.4

- Frame overhead is always checked for x264
- comp test startegy is changed for x264 (now its discarding first and last frames for non bframes encode and first two/last two frames with bframes encode)
- XviD AVI dev-api3 can be opened again
- deinterlacing section is moved before crop to avoid green line problem
- added logo for x264 (my lame variation on XviD theme ;) )
- DGMPGDec is updated to version 1.1.0
- ColorMatrix filter is included with its xml description (read about its usage here: http://forum.doom9.org/showthread.php?s=&threadid=82217 )

0.34.3

- bitrate propagation for x264 fixed again

0.34.2

- now only support rev 107 and up of x264
- fixed bitrate propagation for x264

0.34.1

- comp test changed to use common strategy as was used for b-frames.
- min&max key frame distance is swapped in rev 103, so GK was changed to compensate for that

initial version 0.34 and comp test:

- quant 18 single pass encoding is used
- snip size of 20 frames is used (as well as min-key interval=20)
- without b-frames algorithm's using all frames for comp test (works within 5% in all my tests so far)
- with b-frames algorithm's discarding starting and ending 3 frames (doesn't really work in 100% of cases - much more work to be done here).
- you should still aim at about 70% quality

Enjoy.

[len0x]

Wrong time for the forum to be down :)

Anyway version 0.34.1 should work with rev 103 until x264 developers will fix keyframe settings, then I will need to update GK back...

[niamh]

Ha, I managed to get 0.34 yesterday morning, haven't tried 0.34.1 yet.

Thank you very much for the New Year surprise len0x, it's very much appreciated :)
I will try 0.34.1 asap

[len0x]

Note that rev 105 of x264 that is out may not work as they introduced stats file parameter. I'll wait until min/max keyframe issue is fixed and then release 0.34.2 with support of later revisions.

[The Edge]

Thanks alot for your continued work len0x :)

[Bluedan]

GordianKnot is still the one application in the centre of my video encoding activities.
I like it very much.

Thank you for this update!

[Koti]

A wonderfull unexpected addition to one of my favorite toys - :thanks:

[b0b0b0b]

Hi len0x, thanks very much for your work on gk and autogk

[netchris]

Revision 106 is up
Fixes : registry values for min/max keyint were mixed up

[niamh]

Well I got a 129 mb file instead of 221 with rev 105 :D so it seems it does not work
Is it a case of the codec is developping faster than the app? ;)

By the way the bitrate was slightly off when I tried an encode in 0.34(with whichever rev, an older one), and notwithstanding the big error in the filesize this time, the bitrate sent to vdub seems to be off again .I explain, in the GK window it gives me a bitrate of 1373 kbps(it's the correct one), and the rate sent to vdub was 1346 . (same deal first time, where I got a 218 mb file instead of 221)

[len0x]

Originally posted by netchris
Revision 106 is up
Fixes : registry values for min/max keyint were mixed up

I don't see binaries yet...

[len0x]

Originally posted by niamh
Is it a case of the codec is developping faster than the app? ;)


So far its codec developing faster then QA can be done and therefore last two revisions do not work properly (at least with GK) at all...

Originally posted by niamh
I explain, in the GK window it gives me a bitrate of 1373 kbps(it's the correct one), and the rate sent to vdub was 1346.

This seems to be a 1024 vs 1000 bytes in 1Kb problem: DivX 3.11 is using 1000 bytes notion, while the others are using 1024. I will change that in GK.

[niamh]

I got twice a 129 mb file, that corresponds exactly to a 800kbps CBR, as discussed in the x264 thread. It's consistent :)

[len0x]

not sure what you meant...

[niamh]

but second time codec resets itself to CBR mode (although registry settings are correct!).
hhmm, that, unless I got confused :)

[len0x]

ah :)

We found the problem (well, virus found it) - we are chatting live on IRC...

[niamh]

any chance to get the addy so I can get in, sit and learn? ;) (or get a headache)

[len0x]

#x264 on freenode network.

[niamh]

Thank you, I got pounced on and served with a bugfix release ;) Going to test as soon as vdub is free.

[len0x]

So it should be ok to use for testing purposes now. Please leave feedback about problems with encoding itself in x264 development thread here: http://forum.doom9.org/showthread.php?s=&threadid=80910

P.S. Latest revisions of x264 can be found also here: http://www.iti.uni-stuttgart.de/~bergmats/video_mirror/videotools/

[Dragon Shenron]

Just tried the 0.34.2 beta with CD's rev. 107, and what I got is a green (about 2 cm thick) line on the right side and a thin dot-like line on the left side of my encode. First thought was ffdshow or x264, but after doing a test encode with XviD (to compare the encodes) the lines were still there. XviD is decoded with XviD decoder, and other encodes done with 0.33.1 don't have this problem so I suspect it's a bug in GK.
Using XviD 1.1 beta from Koepi.
Any ideas?
:confused:

[Dragon Shenron]

Traced the bug to "Kernel Deinterlace" filter (I don't use it often).
Sorry for wasting your time.

[len0x]

x264 doesn't like non mod16 resolutions at the moment, btw

[digidragon]

The encoding seems fine, but when muxing I get a VideoSourceAVI error "the source image format is not acceptable (error code -2)". When trying to manually multiplex the movie only avi with the mp3, virtualdubmod complains that "the decompression codec cannot decompress to an RGB format".

exe version 0.34.2.1892 (although the info panel reports 0.33.2)

x264 version 26 January 2005, 04:15:01

[len0x]

ah, true...
VDub(Mod) doesn't support muxing unless you have VFW x264 decoder installed (afaik there is only one available from mpegable and it requires different 4cc). Bummer...

[digidragon]

Thanks for the explanation. In the meantime, what can I use to mux the video and audio streams? I have the videosoft h.264 directshow codec.

[Koti]

GK is muxing audio for me fine thru virtualdubmod

I do get the warnings if I open the video in vdubmod "Couldn't locate decompressor for format 'x264'(unknown)
VirtualDub requires a Video for Windows(VFW) compatible codec to decompress video.
'Direct stream copy' is available for this video."

Also just tested vbr and cbr with x264 .avi in GK 34.2 Both suceeded

[len0x]

Correct, direct stream copy obviously works.
(for the moment I though that when opening vcf script VDubMod throws this error before direct stream copy is set. I only tested video part myself).

P.S. How's target size?

[niamh]

I'll tell you, I have so many tests files in my folder, I'm having to use search to find them ;)
After fighting with the codec, and losing and having to do a full registry clean-up, I can confirm that it seems to work fine (now), and VDM will mux ac3, cbr-vbr mp3 and vorbis in avi /mkv ( accordingly), as it should since even if you don't have the decoder, you still have direct stream copy available :)
I haven't checked the 1024 issue, I only encoded bits of 200 frames, I will set up something more consistent tonight

Btw, doing a compressibility test with a mod4 file will at best make GK vanish, at worst, crash very badly (It doesn't mind mod8, it seems)

@Len0x, being in charge must be terribly stressful, you've gone a bit green and scaley looking there ;)

edit: must refresh before posting :D @len0x, x264 threw an error every time I tried to set up an mp3 audio job, so I haven't got the chance to test size yet, I needed to figure that one out first

[len0x]

Originally posted by niamh
Btw, doing a compressibility test with a mod4 file will at best make GK vanish, at worst, crash very badly (It doesn't mind mod8, it seems)


Very probably. You should report it in the x264 development thread.

Originally posted by niamh
x264 threw an error every time I tried to set up an mp3 audio job

Can you elaborate on that?

Originally posted by niamh
@Len0x, being in charge must be terribly stressful, you've gone a bit green and scaley looking there ;)


tell me about it :)

[niamh]

Can you elaborate on that?

Well I'm not sure it's interesting, x264 refused to encode a 2nd pass on every single job I set up involving mp3 vbr and cbr, as well as vorbis and worked fine when no audio/ac3 was selected, which was really strange, since what has 2nd pass encoding to do with any audio setting (Xvid worked btw)? Anyway, after an hour or two, and 15 test files trying to pinpoint the issue(this is OT, but VDM threw an assertion failure when trying to mux in maually vbr mp3 with a x264 avi), nothing would get encoded anymore at all, even through VDM, so off I went to the registry, got rid of everything, reinstalled rev 107, and all the errors went away(and you would think I would have thought of it straight away ;)). So it had nothing to do with GK, I should think, but x264, or rather me, who didn't uninstall one build or other thoroughly enough apparently.(There were warnings in the x264 thread, so it's my fault entirely)

PS: the output sizes look like they're a bit short, can somebody confirm this? I haven't encoded more than 2000 frames for now, so I can't say for sure, though they're all undersized a bit (22mb >> 21.6)

[digidragon]

I can't get VDM to mux even if I set it direct stream copy. Any idea how I can get it to work?

I still get this error when trying to save the new avi:

[E] Error: VideoSourceAVI error: The source image format is not acceptable. (error code -2)

[Koti]

Target size still running a little under for me.
40mb > 39.3mb file (no audio in file) 10,000 frames
30mb > 29.4mb file (with audio)<- ran 4 times, same each time with different audio (vbr and cbr .mp3). at least it's consistant ;)
I will do a full 700mb soon.

[loni_blues]

len0x,
Is compressibility check working now? Should we consider 70% a good choice as in xvid?
Regards.

[digidragon]

I uninstalled the codec and gknot, and reinstalled them, but am still getting the error when vdubmod tries to mux the mp3. What can I do, if anything, to get this to work?

[len0x]

Yes, its not as accuarte as for XviD though (most of the time +-5%, but sometimes +-10%), hovewer you won't notice the difference as AVC looks much better that ASP already (b-frames can be blocky at the moment in x264 though).

[len0x]

Originally posted by digidragon
I uninstalled the codec and gknot, and reinstalled them, but am still getting the error when vdubmod tries to mux the mp3. What can I do, if anything, to get this to work?

http://forum.doom9.org/showthread.php?s=&threadid=51906

[digidragon]

Originally posted by len0x
http://forum.doom9.org/showthread.php?s=&threadid=51906
The error is specific to the muxing of the H.264 encoded video with the mp3, XviD is fine, so that thread is of no use to my particular problem.

Anyway, in the meantime, I found AVI-Mux GUI, which seems to work fine.

[Koti]

Originally posted by len0x
P.S. How's target size?

Ran 2 encodes with x264 using GK 34.2 last night. Both came up short by 10 mb (700 desired - 690 results)

Dont know if this can be any help, before x264 was added in GK I used GK as a bitrate calculator for x264 multiple times. I was calculating using the 'Divx5' codec setting, adding a pre created mp3 to 'Audio A Size', Selecting audio type cbr-mp3 or vbr-mp3 (with cbr-mp3 set 'Frames Interval') I plan to use, Selecting 'Calculate Frame-Overhead' (as DivX5 has selected by default) , take the average bitrate calculated and set up x264 in vdubmod using that rate, mux audio in vdubmod (at the frame interval I selected if cbr-mp3) , Results were within 1Mb on avi or mkv (700 calculated - 700-701 results)

Aside from the size issue I have its working flawlessly :)

Any thoughts ?

[len0x]

hm... by selecting "calculate frame overhead" we reduce bitrate and therefore there will be more undersize... apart from that current GK does the same as you do manually (you can try manual encoding and it should be the same...)

P.S. rev 108 is out that produces better results!

[Koti]

Somehow it seems that the bitrate sent to x264 is not what GK says.
I understand that frame overhead will further reduce in this issue as well , but if I take the non overhead compensated rate to VDubmod myself for encoding it runs over target , thats how I came to use it this way. :)

I do have a full gk log file if you want it

[niamh]

22 mb in avi produces 21.6 mb
221 mb in mkv produces 216 mb.

Oh well, I'm running behind anyway :D .Will give ogm a go with rev 108 :)

[len0x]

Originally posted by Koti
Somehow it seems that the bitrate sent to x264 is not what GK says.


Can you check that by opening x264 confuguration in VDubMod after you're done an encode and see if bitrate is set exactly to what GK shows you?

[Koti]

Just reinstalled 108 - ran a encode and GK calculated 710 for rate to be sent. Went to vdubmod right after done , in x264gui is is reported 693
bitrate for 2nd pass. At the help of a friend the 1.024 idea was brought up. 710/1.024=693 <---- Aha !!! there it is. Now if 710 was sent tho we would have a oversized file, in my experiments the way I have calculated with frame overhead 703 would be right. So it seems 2 errors - no overhead calculation. Seems to me x264 needs it .Then a 1.024 calc error. I really hope this makes sense :)
Thanks

[len0x]

I found the problem. Bitrate was set OK in the registry files (1024) upon job start. But as you know GK does bitrate recalculation after first pass where those settings got overwritten...

[len0x]

Please test undersizing now.

[Koti]

Tested 34.3 on a 5 min music video with cbr-mp3
requested size 50.0mb

Results without frame overhead selected - 50.3 final
Results with frame overhead selected - 50.1 final

Much Much Closer :)

(edit)
Full movie x264 with audio, overhead selected.
Selected size700MB (716,800KB)
Resulting size was 700MB (717,224KB)

[niamh]

80 mb output
no frame overhead:80.2 mb
frame overhead: 80.0 mb

40 mb output
no frame overhead:40.2 mb
frame overhead:40.0 mb

rev 108 and GK 0.34.3

(added: ) 221 mb output:220.8 mb.Reliable it seems.

[len0x]

Good, I'll check overhead option automatically then.

[niamh]

I'm having serious issues with x264 settings not being remembered in the encoding window from the options tab. It's kind of random too, sometimes they get changed real time (as they should) , sometimes nothing gets changed, sometimes only the first pass, or the second pass does, or even parts of either pass get changed while others don't. In the end I am never sure of the settings I encode with ..Today it refused to change B frames options in 2nd pass, so I have 1 b frame in first pass and 0 b frames in the second one, and it took 3 trials for it to be remembered, but I still have cabac and deblocking enabled in options, and disabled in the encoding window. So I don't even know which supercedes the other.

Yesterday it worked fine all day, and it's random, so I haven't reported it yet, but today it's stubborn, so I thought it needed a post :)

[len0x]

It works like this:

- when you add the job settings are copied from defaults if you don't specify them explicitely
- if you specify them by launching codec settings from Encode window then
-- first time they are loaded from defaults
-- all consequent times they are loaded from the file in the output directory
-- even if you load them first time then they might be loaded from jobname_firstpass.settings in the output dir if it exists (so make sure to delete all *.settings from output folder).

[niamh]

I see, thanks for the clarification. I cleaned up my testing folder yesterday indeed, today is a mess of files again. I'm glad to learn about that little quirk.

(That was it indeed, now it all makes sense and works as well)

[niamh]

I'm not able to open a dev-api-3 xvid avi through the open d2v button... It makes GK simply vanish into thin air. (All builds of Xvid 1.x seem to open fine, as well as the x264 ones, may I say)

[len0x]

Well, I did that for 0.33.2 - previously you could open pre 1.0 AVIs OK, but not dev-api4. Now it happens vice versa (they are mutually exclusive it seems) - I think it makes more sense to have as now as dev-api-3 is obsolete.

[niamh]

It sure does indeed. I wonder what's so special about xvid, since all the other codecs seem to play nice in this case..

[len0x]

Its coz M$ avifil32.dll library cannot properly work with XviD. If you right click on xvid file in windows you'll see very weird info about it being 12 bit, that screws things when you try to access video frames...

[Mtz]

I think the latest v 0.34.3 beta is not working with miniDV input transfered via firewire. :(

enjoy,
Mtz

[len0x]

Afaik it was never supposed to work (i.e. dv/huffyv/mjpeg)

[killingspree]

hi,

yesterday i did my first encodes with x264 and gknot and i have to say, i'm impressed at how fast this was implemented so well...

anyway, for some comparisons i encoded a couple of chapters of LOTR SEE at a high res with a rather low bitrate (645kbit, 704x288) - still an acceptable bitrate, but definitely not overkill ;) - and encoded it with xvid and x264 (no noise reduction, lanczos resize); as expected, overall xvid fared a little worse, although on easy two encode scenes, there was hardly any difference.

what i had noticed though, was the fact that in some areas, it seemed to me the xvid still preserved more details, whereas x264 presented a little smearing. on the other hand, xvid had scenes where it was blocks and nothing but, and x264 still had watchable results...

anyway, that probably belongs to the x264 dev thread. bottom line, encoding with x264 in gknot works fine so far, thx len0x, just now i'm doing a 700MB encode to see if there's any surprises...

oh and btw, the file sizes are still marginally off, no matter if i use calculate frame overhead or not

steVe
PS: if anybody wants some screenshots, just drop a message here, i've got quite a few...

[len0x]

Originally posted by killingspree
what i had noticed though, was the fact that in some areas, it seemed to me the xvid still preserved more details, whereas x264 presented a little smearing. on the other hand, xvid had scenes where it was blocks and nothing but, and x264 still had watchable results...


It is possible that XviD preserve more details sometime (especially if you use custom matrixes). Also x264 looks much better to me without usage of b-frames atm (plus reference frames has to be increased from default 1 to at least 5).

Originally posted by killingspree
oh and btw, the file sizes are still marginally off, no matter if i use calculate frame overhead or not


you're the only one having such problems it seems...

[len0x]

I consider first stage of x264 integration as completed. I did more tests and tuned comp test result according to that.

*Edit* also I was able to do two types of loading for AVI files that should be ok for both types of XviD.

P.S. plz have a go with ColorMatrix filter - should be interesting to see the results (those who complained about encodes being too dark might be happy with this filter).

[killingspree]

Originally posted by len0x

you're the only one having such problems it seems...

hmmm... well i'm going to run a couple more tests asap using the new beta and i'll see if they persist...

[len0x]

Make sure you have x264 properly installed (i.e. uninstall any old version you might have).

[Koti]

Small bug in color matrix .xml or my system
"Rec.601->Rec.709" and "Rec.709->Rec.601" are entered in quotes " in the string presets which results in the final entry being double quoted.
ColorMatrix(""Rec.709->Rec.601"",true) in the avs file.

All the rest is great , even a x264 logo :) .
Thanks

[Hesse]

I am having some problems with updates after GK 0.33.1. I am trying to reencode some AVI files of very large size, ~16GB. GK 0.33.1 can open the file and process it like a charm. However, any version after just quits when I select the file to open. I also tested a 2GB file and it does the same thing, simply just quits, no errors or anything.

Any chance this could be looked at?

Thanks,

Jesse

[jsprogg]

i am testing the GK 0.34.4 beta and all is well except for the file load option for avi, it loads divx5 and div3 fine but trying to load xvid avi's the app just shuts down.
i have tried several xvid files and get the same problem with all of them.

[thewonderer]

It seems as though there are problems with the download links for the 1.89 beta of autogk. i've noticed this before with previous versions.

Access denied/no permission...

Please fix

Thanks

[len0x]

Please don't ask questions about AutoGK in this thread! (and read FAQ Q 0)

[len0x]

Originally posted by jsprogg
i am testing the GK 0.34.4 beta and all is well except for the file load option for avi, it loads divx5 and div3 fine but trying to load xvid avi's the app just shuts down.


Did you have the same problem with 0.33.1 and 0.33.2 ?

[len0x]

Originally posted by Hesse
I am having some problems with updates after GK 0.33.1.


Version 0.33.1 had original old code. Then I modified it to be able to open new XviDs in 0.33.2. Now in 0.34.4 I've put old code back but in case it fails I'm trying new code second time. So 0.34.4 should not behave any worse than 0.33.1.

[len0x]

Originally posted by Koti
Small bug in color matrix .xml or my system
"Rec.601->Rec.709" and "Rec.709->Rec.601" are entered in quotes " in the string presets which results in the final entry being double quoted.
ColorMatrix(""Rec.709->Rec.601"",true) in the avs file.


Indeed on line 17 you should remove "quot;" twice (along with ampersand) from the string if you want to fix it yourself.

[niamh]

So 0.34.4 should not behave any worse than 0.33.1.
As a matter of fact, it behaves the exact same :D
Fat chance of M$ fixing their dll, so we'll have to live with it :)

[len0x]

Originally posted by niamh
As a matter of fact, it behaves the exact same :D


Not really - 0.33.1 couldn't open dev-api4 XviDs while 0.34.4 can...

[niamh]

Woops, I was thinking 0.34.3 ;)

[jsprogg]

Did you have the same problem with 0.33.1 and 0.33.2 ?

To be honest Lennox , I don't recall trying it with xvid in 0.33.1 or 0.33.2 , reading back on this thread I guess that it is intentional and that my test files are simply older xvid versions.

[len0x]

I have no problems opening any kind of XviD files with 0.34.4.
Can you make available a small sample of what you can't open with current version?

[jsprogg]

ok I re-installed GK 0.34.4 and can now open xvids fine, i still have one problem file although i can't seem to detect just why it's a problem,i checked it in v-dub and it doesn't seem to have any errors or be corrupt.I did split a little off the file but the sample opens fine in GK ..lol
so I am hoping that this file has a unique problem.

[niamh]

@len0x:Well I've just reformatted, and I still can't open dev api 3 xvid. You can get a little sample of one of my reluctant files here (http://c.1asphost.com/niaomalley/dev-api-3.sample.7z). Not that it matters greatly really, but you asked :)

[len0x]

Well I never said that if you were not able to open some XviDs of dev-api3 with 0.33.1 that you will now. All I said that all XviDs that you were able to open with 0.33.1 you should still be able to open with 0.34.4 plus dev-api4 files can be opened as well.

P.S. I wonder if that's QPEL that makes it impossible to open, btw.
(All samples that I have of dev-api3 are without QPEL and work just fine, but yours is with QPEL and gives us the troubles).

[niamh]

I'm not sure I tried that file in 0.33.1, but I can't recall one that didn't open( I kinda test the same ones, and this one I know has Qpel, so usually it goes first).I've binned it, so I can't try to reinstall it. Thing is, none of my dev-api-3 open, that's what I was trying to say. It seems to be me only though, so no bother ;)

(edit:I'm on 56k, and it'd take an hour to get the whole pack back, I might try another day when I have time online)

[len0x]

I tried your sample in 0.33.1 - didn't work...

[niamh]

Thanks for trying :)
Can we revert situations and somebody send me a little sample of a dev-api-3 that opens for them? because I can't get a single one to open, I'm being curious.

[sillKotscha]

I don't know if my question is answered here somewhere - if so, link me ;)

... starting with version 0.34.4, for me it is not possible anymore to open an(y) *avs script.

going back to v0.33.2 everything works as expected :)

and somehow opening captured huffyuv files > 2GB let GK work and work and work and than crash...

huffyuv version used is: Huffyuv v2.1.1 CEESP-Patch v0.2.5

I didn't tried versions below. This does happen with both mentioned GK versions but as I said, with v0.33.2 I'm at least able to open huffyuv files > 2GB via avisynth

what else do you need to know?

cheers Sill

[len0x]

After reading specs for AVI files, WinAPI docs and analysing a bunch of files last night I sorted all the problems for opening AVI files (haven't tried AVS yet). Its not about the codec its about AVI structure that is very different for different files (and just happen to be different for different codecs). Now I'm able to open everything that has proper VFW decocer installed (i.e. can be opened in VDub). I tried xvid/divx/huffyuv/mjpeg - all went fine. I only had problem with DV source (dvsd) that I was decoding via ffdshow_vfw (I kept getting access violation in module ff_vfw.dll).

*Edit* AVS works as well

[len0x]

Should fix all you AVI problems :)

[The Edge]

Cheers for your continued efforts len0x ;)

[niamh]

Everything opens, I'm very impressed. Being in charge suits you Len0x :D
:thanks:

Hi Edge :) (OT: Did you manage to get tickets? ;) )

[sillKotscha]

hey len0x,

how nice :)

thank you... !!!!

that was really quick.

Sill

[The Edge]

Originally posted by niamh
Hi Edge :) (OT: Did you manage to get tickets? ;) )

Nope! :(

PM sent! :)

[digidragon]

I'm using the core 14 build of x264, and am getting an error in vdubmod: "Cannot start video compression - maybe corrupt data (error code -100)" when it tries to encode the avs generated by gk. However, if I just encode the mpg (the original source in the avs) then I don't get an error.

Any ideas please?

[niamh]

This is yet another x264 error, it doesn't like for example certain resolutions, you must take it to the x264 dev thread :)

[len0x]

Originally posted by digidragon
I'm using the core 14 build of x264

Is it rev 114? There were some errors fixed in rev 115 and you can try it. If doesn't help, then report it in the x264 development thread.

[digidragon]

It's rev 115.

After a bit of playing it's the crop and resize functions (either of them) that cause the error.

Using gk's auto crop, these are the two lines in the avs file:

crop(6,16,712,548)
LanczosResize(712,376)

[len0x]

Yeah, they might. What if you try to stick to mod16 resolutions?

[digidragon]

Thanks for the suggestion.

I posted in the X264 thread and they suggested that too. And it worked. I also mentioned that the codec properties don't mention any restrictions on resolution, as some others do.

Is it normally a good idea to stick to mod16 in xvid too?

[Dester]

I'm here to thank you for all the work, bu especially for this fix:

- deinterlacing section is moved before crop to avoid green line problem

I wrote on this forums many months ago for this problem and I thought my post was lost :))))

Many thanks again, wow !
Dester.

[killingspree]

Originally posted by digidragon

Is it normally a good idea to stick to mod16 in xvid too?

yes, definitely... some people even suggest mod 32 resolutions...

kr
steVe

[len0x]

Mod32 was needed for proper playback on old graphics cards. I don't think its a problem nowadays (for instance AutoGK uses mod16 for ages and nobody complained).

[hpn]

Well, any forced modXX is evil, unless you don't mind either cropping your valued video content or producing encodes with some aspect error. But since codecs, supporting mod16, are much easier to program (it plagues even new encoders like x264, which other than that is a very promising encoder), we have to comply with it in the next decade or so. Just like when ages ago some guys decided that interlaced footage was much easier to produce. Hopefully when HD resolutons such as 2,880x1,440 become omnipresent in about 10 years, any ModXX issues will be solved, cause simply no one will record anything less than 1,280x720. But it's definately not the case now when you try to recode some weird 200x300 clip.

p.s. Len0x, GK is great, keep up the good work.

[Esc]

Looks like I have found a bug.
I have path for vStrip intentionally left blank. Now I want to set it. I press Locate button right to it, select vStrip_gui.exe and nothing happens at all. Other buttons seem to work fine.

[len0x]

Indeed its a bug, but not where you would think - try clicking on "don't check" checkbox and you'll see what I mean :)

*Edit* Actually it was implemented that way for all checkboxes (their state is remembered but not visually updated on the next start of GK)

[MacAddict]

Haven't seen this mentioned anywhere but what is the reasoning for a full first pass to do a 5% compression test via XviD? I obviously noticed the "SelectRangeEvery(0,0)" in the script no matter what codec is selected. I must be missing something here:confused:

[len0x]

SelectRangeEvery(0,0) in the script is not used - its overwritten when actual comp test starts (you can veify that by looking at LastCompCheck.avs). And after first comp test is done you'll see proper values in the script window as well (basically snip_size is not initialized before first comp test is started as i was thinking of dynamic snip size depending on codec properties).

[niamh]

I just tried and for me the first comp test runs the full movie, not the 5%. After aborting it, it behaves normally, until I close GK and re-open it.

[MacAddict]

Originally posted by niamh
I just tried and for me the first comp test runs the full movie, not the 5%. After aborting it, it behaves normally, until I close GK and re-open it. Actually I can verify this also. I let it run through about 20,000 frames and canceled Vdub, GK then updated the compression ratio percentage. Requesting different percentage values for the compression tests doesnt seem to have an effect, the entire movie is encoding for some reason.

@len0x
Thanks again for your contributions to this invaluable tool!

[Arlong]

Same problem here. In the AVS SelectRangeEvery is always set to (0,0) even if I try to run a 5% comp test. Actually it needs to be edited manually [SelectRangeEvery(280, 14)]. Odd, CT worked the first two times I ran it. ;)

Many thanks for the development of GK, len0x... I just love it! :)

[len0x]

Fixed a couple of bugs and new DGIndex is bundled. Beware that all d2v projects have to be rebuilt.

[sillKotscha]

nice :)

I've noticed one thing:

- the "calculate Frame-overhead" isn't remembered if you switch between the codecs... not fully true, this only concerns xvid.

[len0x]

Its supposed to be always _unchecked_ for XviD.

[sillKotscha]

it's supposed to be the way it is??

point??

[niamh]

XviD has the feature built-in, so to speak, so it's supposed to be unchecked in GK, _always_ ;) (And it's been this way since forever too)

[len0x]

Because XviD takes target size instead of target bitrate its able to calculate frame overhead directly in the codec.

[sillKotscha]

Originally posted by niamh
(And it's been this way since forever too)

I've started (re-) using GKnot since it support x264... that's why I stumbled over this behaviour for the first time...

[loni_blues]

len0x,

I cannot open a d2v file just made with DGIndex RC2 with latest GK 0.34.6.
What's wrong?

[mongoosesRawesome]

I also can no longer open d2v files with the new version of GK (0.34.6). Using the new version of DGIndex (1.2.0 RC2).

[len0x]

You have to redo your projects with correct version of DGIndex, old ones will not work.

I (and lot of others it seems) do not have any problems opening new d2v files.

[loni_blues]

len0x,

I was only describing a problem with d2v files made with the new DGIndex RC2 when trying to open them with the new GK 0.34.6. I have tried once more, with Forced Film, without it. With different idct algorithms. I have uninstalled GK, reinstalled it. I always get the "File is not a valid...". mongoosesRawesome seems to be having the same problem.
Perhaps there is some other thing we're overlooking. Would very much appreciate you looking into the issue.
Hopeless,
Kind Regards,
loni_blues

[len0x]

I'd be happy to if I was able to reproduce it...
Can you attach d2v file please?

[len0x]

Btw, what kind of CPU do you guys have? (those with d2v problem)

[loni_blues]

But of course, I should post the d2v file.
My CPU is AMD Athlon 1.20 GHz. The OS is Windows XP SP1.
I am posting a couple of them, one with FF.
Thanks a lot

[loni_blues]

Here is another d2v.

[len0x]

Nothing wrong with it. Some ppl reported that DGDecode 1.2RC2 is no longer working for them so I guess it might be the same problem. You can try opening d2v manually through AVS in vdubmod and see if there are any errors.

[niamh]

I've an Athlon too and XP SP1, and it works(thought I'd mention)

[loni_blues]

Well, well. I cannot open the d2v in Vdubmod through Avisynth. So it's not a Gk problem after all.
I'm gonna check the Dvd2avi forum.
Regards.

[len0x]

make sure DGDecode.dll is the same in both DGMPGDec dir and your avisynth plugin dir, coz if you have custom avisynth plugin dir then GK's installer will not be able to write there.

[loni_blues]

len0x,
Thanks a lot!
I mixed up things quite a bit with installing from your installer, installing RC1 with the installer of GK 0.34.5 and reinstalling RC2 directly from the zip file by DG.

Now things are like this: With no Forced Film the d2v can be opened both in Gk and Vdubmod. But with FF applied it fails in both programs.
Back to Dvd2avi forum!

[mongoosesRawesome]

It looks like RC3 of DGIndex fixed everything for me (I had the force film problem). Just remember to replace the file DGDecode.dll in your avisynth plugins directory (lenox said this earlier).

[TripleA]

One question before I try this new GK: is there any spyware in it? If so, how should I go about disabling it/them?

[len0x]

ppl are getting too paranoid... there is no adware/spyware in GK and never will be.

[TripleA]

Thanks for clearing that. But I do believe there are grounds for my paranoia in this particular case: no one was told of the addition of spyware to AutoGK. It sets a precedence, you know...

Now let's see if the new GK can eat the new D2Vs...

[Edit: Works, of course. But the old one could have worked as well, for all I know: I had moved my AVISynth plugin directory and forgotten to accordingly update the batch file that "propagates" DGDecode.dll]

[len0x]

Now I'm waiting for DGIndex 1.2.0 to be released and will do full repack of GK as 0.35 stable :)

[Subwars]

hi i don't believe this is a feature as yet not that i've seen in any options anyway but to be able to have a set default processor priority thruout the entire rip process is this an option that can be built in??

[len0x]

why not change default priority option in VDubMod instead?

[Subwars]

:rolleyes:
:stupid:
:thanks:

[len0x]

Bundled with latest DGMPGDec and its no longer possible to change name of the mpeg2 decoding library (to avoid all the confusion when upgrading).

[mongoosesRawesome]

Are there any changes besides supporting RC3 of DGIndex?

[len0x]

As you can see from the history only one (x264 comp test related).

[niamh]

version 0.34.8 beta is out

Where did 0.34.7 go? :p

[len0x]

it was up for 10 min and then I discovered x264 comp test bug :)

[niamh]

I have a feature request (/ducks)....add the possibility to hardcode text subs, as well as idx/sub in the avs window....
This entails
- ability to browse for text subs in the avs window
- replacing vobsub(filename) by textsub(filename.extension) in the pre-made avs in that case (and probably half a million lines of code :D)

Reasons I'm asking:
I) I've had to explain the manual procedure at least 4 or 5 times over in the subtitles forum (never mind outside of doom9)
II) I know the advanced avs caters for it, but
a)not many people seem to use it yet
b)it's bewildering for basic users, as it's so complete, so then we're back to I)


If it wasn't too much of a hassle, it would be a really nice feature IMO (personally I'd rather burn alive than hardcode any subs, but there you are, lots of people like it that way)
If it is hard to implement, well I've asked at least :)

[iradic]

hi,

first - thanks for your great work...

second - feature request (i saw the one before so :) ) ... if it is possible do add something like "LOCK HEIGHT" checkbox (or similar) so when changing AR gknot changes width ...

thanks and bye...

[len0x]

I'm not taking feature requests atm :)

But TextSub stuff is pretty easy to do though (ini files have to be updated to allow different filtering in open dialogs).

[niamh]

Originally posted by len0x
[B]I'm not taking feature requests atm :)

Is why I ducked ;)

[len0x]

try this: http://www.autogk.me.uk/gk.zip
Does it work?

[niamh]

Sorry for the delay, I just had an interesting issue with my graphics card drivers, that turned every character on screen into chinese(with assorted pink cubes) :D. had to look into that first

It nearly works :) all that's missing is the extension in the textsub line (vobsub() doesn't require it, textsub() does)

[BruceL]

@len0x
As always, thank you for your terrific work! :)

[len0x]

Should be working now. Same link.

[niamh]

yup, works great now :) thanks :)

[OMINUS]

i installed the latest gknot 0.34.8 and i am trying to use it with my captured avi-but there is a problem
when i try to make a comp test i get the error:
avisynth open failure:
fielddeinterlance:yv12 or yuy2 data only etc

i know that the problem is with the colourspace because
the above error happens only with my asv2 captured avi (colorspace YCbCr ) whereas with my mjpeg captured avi (yv12 colorpsace) i have absolutely no problem and i can encode perfectly with gk

so is there any command i have to put in the avs script generated from gk in order to bypass this error?i am a little novice concerning avs ;) so i need your help here

anyway thanx in advance

[killingspree]

converttoyv12() would probably be a good idea... but you could also try converttoyuv2()

kr
steVe

[OMINUS]

yep it works thank you very much
one last question
because it seems that gk cant give correct compr test results with avi files should i use this part from the doom9 capture guide? -<http://www.doom9.org/capture/postprocessing_gknot.html-

its a little hard work to do it every time but if its the only way to get correct comp test from gk well no problemo ;)

[killingspree]

the proceture actually looks way more complicated than it really is. after doing it a couple of times you'll know it by heart and it will probably not take you more than a minute or two to do the extra steps... in addition you will notice that, after some time, you will actually get a feeling for how compressible a source is. i for example don't do a comp check in about 60% of the cases. ;)

kr
steVe

[len0x]

Originally posted by OMINUS
because it seems that gk cant give correct compr test results with avi files

why is that?

[OMINUS]

Originally posted by len0x
why is that?

well i used a 2hour captured avi file and the comp test showed me that with 70mb xvid output the quality i can get is at least maximum! ;)
i dont know what causes it - maybe its the xvid codec or the asv2 captured file - i will try and make some more tests with other avi although i am a little pessimistic with the final results :I

[Tima]

When saving script through 'advanced AVS Save window', loading of decomb.dll never gets commented.
I haven't tried to check this in simple save window..

[len0x]

I can't reproduce that - script tab always behaves properly for me...

[Tima]

The bug disappeared after I selected 'none' in 'field operations'. This was my first selection on a fresh install of GK, so the problem may lay there..

There is another strange thing: when I click EXACTLY on radiobuttons in 'field operations', everything os OK. But when I click on LABELS near them, the type of operation changes (and the script too), but buttons don't change their states..

Also a note about first bug: in that case loading of decomb.dll was not commented, but NO strings in the script actually used it.

P.s.: also there are always TWO strins: '# DENOISING: choose one combination (or none)' in the script.

[len0x]

Everything's fixed apart from denoising business that seems to be a feature (header is always printed out twice because there are two places where denoising can go).

[MetalMusicAddict]

Ive been gettin a weird bug in the past couple of betas of GK. Basically everything goes fine for a while into Vdub encoding. But I noticed somtimes the file its making, Whatever_Movie stays at 16 megs. Doesnt get bigger. Then, a little while later my PC will reset for no reason I can see. Cant figure it out. I like the new fearures ant dont wanna go back to the old "stable". Any ideas?

[len0x]

Originally posted by MetalMusicAddict
But I noticed sometimes the file its making, Whatever_Movie stays at 16 megs. Doesnt get bigger.

VDubMod writes output in 16Mb chunks. During first pass there is no output, so it will stay like this until second pass reaches the point when more than 16Mb is needed (ir will increase to 32Mb).

Originally posted by MetalMusicAddict
Then, a little while later my PC will reset for no reason I can see.

Nothing to do with GK (in the end it doesn't encode itself). Usual hardware reasons - overheating, overclocking, memory problems.

[MetalMusicAddict]

Originally posted by len0x
VDubMod writes output in 16Mb chunks. During first pass there is no output, so it will stay like this until second pass reaches the point when more than 16Mb is needed (ir will increase to 32Mb).

I was actually thinkin somthing like this.

Nothing to do with GK (in the end it doesn't encode itself). Usual hardware reasons - overheating, overclocking, memory problems.
As far as I can see with heat Im cool. :) Ill look further into this though. Thank you for the awesome app and support.

[OMINUS]

len0x i am sorry for your time but i would like your opinion about the process i use to encode avis with gknot

i create an avs (capture.avs) with the code:
SegmentedAviSource("capture.avi")
Trim(*.*)
ConverttoYV12()
KillAudio()

i open the avs with gk-i make the usual stuff,cropping,resizing etc etc,i set the bitrate,(always at 2000kbs-the comp test never work well with my avis dont know why yet)i set the xvid settings and i save the job

then i edit the saved avs from gknot and i change the line
avisource("capture.avs")
into the code:
SegmentedAviSource("capture.avi")
Trim(*.*)
ConverttoYV12()
KillAudio()

i save and then start the encoding from gknot
when the xvid is ready i rip the wav from the original captured avi
i encode it into mp3 and merge it with the xvid using for the whole process virtualdubmod

with this method i get excellent xvid from my captured avis
i just wanted to know if there is any other easier way than the one i use

anyway thats all thanx again

[len0x]

I'm not doing much capture encodings. Why don't you feed WAV file directly to GK as a part of a job?

[len0x]

Closed as GK 0.35 stable is released.