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 :)