Gordian Knot on steroids: The agkp add-on

[Brother John]

Hi everyone!

I'd like to introduce you to an extremely useful add-on for Gordian Knot. It's called agkp and is being developed by akapuma, a member of the German Doom9/Gleitz forums (http://forum.gleitz.info).


Why should I use it?

With agkp you can continue to use Gordian Knot but you will get
encoding with x264.exe,
encoding with xvid_encraw,
proper Matroska support via MKVMerge,
more possibilities to manipulate AVS scripts (documentation only available in German).

Did you say German documentation?

Yes. Agkp is a 100% German software and does not include any English documentation. That's why I translated an article on the program written by yours truly. That tutorial should enable you to use agkp and produce those lovely native MPEG-4 matroskas while still working with good ol' GKnot. So... interested in GKnot on steroids? Then have a look at the tutorial.

>> Akapumas Gordian-Knot-Personalisierer: English tutorial << (http://encodingwissen.brother-john.net/gordianknot/agkp-english.html)

Have fun reading and encoding!



Additional Useful Notes (Read them!)

x264.exe supported versions
Agkp needs x264.exe complied by Sharktooth because the default command line uses the --aq-strength option that needs Haali’s AQ patch, that is not in the official sourcecode. As an alternative erase --aq-strength from the command lines.

Xvid_encraw
Using xvid_encraw with agkp is not officially supported but is rather a hack introduced by me. It might produce side effects or not work at all in some cases. Before posting an encraw related question please try again with x264.exe to see if the problem lies with standard agkp functionality or the encraw hack.

Agkp and AVI/OGM
Agkp should not be used with AVI or OGM. GKnot’s standard set of features is perfect for those containers.

Agkp and DivX
Using agkp with DivX requires MP4Box to clean up the VfW video stream produced by the DivX encoder.

Decoding of native MPEG-4 streams
Use ffdshow. Xvid’s native decoder can only handle VfW streams.

Gordian Knot and anamorphic encodings
This is a procedure explained in detail on my site. If you can, read the German original. Here is a short walk-through in English for DVD sources.
Note 1: If you encode to a traditional square pixel resolution the steps below and the tutorial’s whole "anamorphic encoding" section are irrelevant for you. If you usually both crop and resize (e.g. cut black bars, then resize to sth. like 640x256) you are using the traditional way.
Note 2: The term "anamorphic" here refers to the output file, not the source.
Options tab: Disable the advanced SaveAVS window
Resolution tab: Use 1:1 input pixel ar for all sources. Then crop to a mod16 resolution.
To find the DAR value you need for matroska’s aspect ratio feature (agkp’s mkvmerge AR line) temporarily set input resolution and input pixel ar according to the source’s properties (e.g. NTSC anamorphic for a widescreen NTSC disc). Then set W-modul and h-modul to 16. Make sure the two shown resolutions match: the one in the crop section and the one above the huge slider. If they don’t use the slider to match them. The value next to aspect ratio... in the Crop section is the DAR you’re looking for. Don’t forget to switch back to 1:1 afterwards.
SaveAVS window: Edit the AVS script and delete the resize line.
Use the pixelar variable like explained in the tutorial to set the MPEG-4 video stream’s PAR value. Do NOT USE this variable for a traditional square pixel resolution or set it to 1:1.

[akapuma]

Hello,

thank you, Brother John, for the translation. I will explain the pre-configured avs-Filter functions, because agkp is in german. All this functions are changeable in the agkp200.ini.

ColorYUV [aus] [autogain] [Weissabgleich] [HDRAGC]
[aus] => no operation
[autogain] => ColorYUV(autogain=true)
[Weissabgleich] (white balance) => ColorYUV(autogain=true, autowhite=true)
[HDRAGC] => hdragc()
"autogain" and "Weissabgleich" (white balance) are not very useful. "HDRAGC" is experimental.

Farbe [bunt] [schwarz-weiss]
Farbe = color
=> no operation
[schwarz-weiss] (black-white) => GreyScale()
[schwarz-weiss] (black-white) is recommended for black/white-movies

[B]Postprocessor [aus] [deblock] [deblock+dering]
[aus] => no operation
[deblock] => adds ", cpu=4" to mpeg2source
[deblock+dering] => adds ", cpu=6" to mpeg2source
Specially for DVB, I recommend "deblock".

Deinterlacer [aus] [full] [auto] [smartbob]
[aus] => no operation
[full] => TDeint(slow=2)
[auto] => TDeint(full=false, tryweave=true, MI=32, blockx=8, slow=2)
[smartbob] => TDeint(mode=2, slow=2)
"Deinterlacer" enhance the GKnot-Deinterlacer capabilities. I prefer "auto".

DeGrainMedian [aus] [leicht] [mittel] [stark]
[aus] => no operation
[leicht] (little) => DeGrainMedian(limitY=5,limitUV=5,mode=3)
[mittel] (medium) => DeGrainMedian(limitY=5,limitUV=7,mode=2)
[stark] (heavy) => DeGrainMedian(limitY=5,limitUV=7,mode=0)
For a good filtering and a good compression, I prefer [mittel] (medium).

undot [aus] [an (vorn)] [an(hinten)]
[aus] => removes undot, set by GKnot
[an (vorn)] (on, in front) => no operation
[an (hinten)] (on, behind) => moves undot to the back of the avs-skript, only for demonstration
I use the GKnot-Standard [an (vorn)].

Best regards

akapuma

[Slitheen]

Does this work with AKG? Or was this posted in the wrong forum?

[Sharktooth]

it's for GordianKnot and it's in the right forum.

[har-vas]

Hi Brother John and thank you very much for your translation! Now there is a good solution for all of us who still love GK! But unfortunately, my first tries to switch to the notorious "native mode" were dispiriting! First of all, I read carefully 3 times your webpage (by the way, I saw that you have a very interesting website which seems to be a good source of information). I hope to gradually translate more pages (especially the x264 & XviD configurations, the mkvmerge GUI settings, the PAR calculation discussion etc). Anyway, I tried both with x264 CLI (v598) and XviD_encraw (v1.2 taken from MeGUI's folder). Complete failure! First, I tried with AGKP 42 and after giving the correct paths to the ini file, setting-up the filters and pressing OK, nothing was happening. After 2 seconds the job was done (a command-line window was up for a moment). I always choose the 2-pass x264 configuration and all filters in their first value (those filters need a much better explanation although. I hope that Akapuma will help us here). I am also checking with the preview window and everything seem to be fine (this mouse support is awesome). I tried 5 times! I am going by your instructions, but I can't do anything! I have also used the pixelar variable because of a PAL 16:9 DVD I have (if I understood correctly, I have to use that variable in every DVD ripping, according to the PAR table, because every DVD has non-square pixel AR, correct)? Then I tried with the latest AGKP 44 and this time the encoding was starting and showing a command-line window with an one-line message. A slight difference but no encoding again. I have to kill the window for the job to finish. What is happening? Should I use an older x264.exe or I am doing something wrong? To be honest, I haven't tried with another DVD movie, but I think that this is not necessary. I have never had any problems with x264 VFW in the past (which is still installed of course, v573). I don't know what to say, I even tried to enclose the paths to the x264.exe and others into quotes " ", in case of any problem with spaces in the path, but that was catastrophic! In the AGKP GUI the last three lines have disappeared! Please, help if you can! Finally, I tried with XviD_encraw and I followed your instructions (I copied your lines into my .bat). The encoding at last started and I saw the program working (but I want to understand the settings of XviD. I will start German lessons immediately! Anyway, I hope that you chose the settings for the best result. These settings are 2-pass or single pass? Why should I have to untick the "Calculate frame-overhead" checkbox?). Unfortunately, after the first pass, the process freezed in the 15% of the second pass (I am not sure what this pass did, because the abr was 69 Kbps. Possibly, the ogg encode). After 30 minutes of freezing, I killed the command-line window and restarted the same encoding. I left the house and when I came back I saw that the job was done! I was very happy until the moment I open the mkv. 130 MB instead of 850 MB for a 2-hour movie. The quality was awful of course and additionally the decoding has many problems. I use the latest MPC, but what filter should I use for the proper decoding of native XviD streams? You suggest the latest ffdshow or the classic XviD filter from Koepi (I wonder if this is only for VFW). Brother John, I spend many hours on reading and testing and I came up with nothing! I am writing all these in detail, because I hope for a comprehensive answer from someone which will really help me. Again thank you for your time.

PS 1: To Akapuma: This is an excellent GK's add-on, congratulations. I understand that you are a German developer and you wrote a software for your community with a very detailed German documentation. But I think that the interface, the messages (and a brief how-to) should be in English or at least having a choice between German and English, if we take for granted that this is a piece of software which applies to the whole video community. But if your intention was to refer only to German users, then OK. I hope that this will change in the future.

PS 2: Brother John, which is the value I should give in the AGKP GUI's last line for an anamorphic case? Is this the same value with the one in the "Aspect Ratio" field of the "Output Resolution" section of GK's "Resolution" tab (eg 2.441 in my case)? In other words, is the result of width/height of the output resolution? In MKVmerge GUI, I am always using the right radio button "Display width/height" and never the "Aspect Ratio", so I am not sure for this value.

[akapuma]

Hello har-vas,

sorry for the trouble.

If you want to use the standard-x264-settings in agkp, you need the x264-builds by sharktooth (http://forum.doom9.org/showthread.php?t=89979), because the aq-patch is used.

Then I tried with the latest AGKP 44 and this time the encoding was starting and showing a command-line window with an one-line message.What was the content of the message?

To solve problems, I need the following files:
agkp.log (in the VDM-directory)
agkpmux.txt (in the movie directory).

For xvid_encraw-settings, I can say nothing. I'm using only the x264.exe.

Best regards

akapuma

[har-vas]

Hello all! Akapuma, I think that your last comment must be included in every AGKP reference. Indeed, when I replaced the x264.exe downloaded from www.x264.nl with the one downloaded from Sharktooth, my problems regarding x264 encoding were gone! Yesterday, I made my first native x264 backup! The only problem was the duration. Over 12 hours for a 2-hour movie with my HT P4@3.8 GHz (2 GB RAM) was something I couldn't even imagine (with x264 VFW I think that it would be 4-4 1/2 hours maximum with very high quality settings). Is this normal? If yes, I suppose that the codec settings are being set to the maximum quality. But anyway I think that it's too much. Additionally, I noticed that the CPU use was very low (a little above the 50-55%). When I was encoding with VFW, VirtualDubMod was stressing both my logical CPUs to the maximun (over 90%). So here is it a code or a codec issue? Finally, I would like to note that the chapters don't work. I mean that this is a GK's function which works normally when producing VFW MKVs, but the cooperation with AGKP is problematic in this field. So I have to mux the chapter file and the subtitles file into the output mkv with MKVToolnix. I think that it won't be hard this function to be added in the new version of AGKP. Akapuma, if you like, share with us your relative comments. Thanks.

PS: Brother John, it would be very kind of you, if you try to give some answers to the questions from my previous post. Thanks.

[akapuma]

Hello,

Akapuma, I think that your last comment must be included in every AGKP reference.It's included in the german reference. The english reference is by brother john.

The only problem was the duration. Over 12 hours for a 2-hour movie with my HT P4@3.8 GHz (2 GB RAM) was something I couldn't even imagine (with x264 VFW I think that it would be 4-4 1/2 hours maximum with very high quality settings). Is this normal? If yes, I suppose that the codec settings are being set to the maximum quality. But anyway I think that it's too much.My pre-settings are optimized for a small size and a good quality, not for a good speed. You can change all x264-settings in the agkpx264.bat. For the settings, I use this (http://www.flaskmpeg.info/board/thread.php?threadid=5571) german reference. To save time, I use only the 1-pass-mode (CRF).

Additionally, I noticed that the CPU use was very low (a little above the 50-55%). When I was encoding with VFW, VirtualDubMod was stressing both my logical CPUs to the maximun (over 90%). So here is it a code or a codec issue?I have an Athlon 64 3500+ with 100% cpu usage. I cant test with Intel. agkp only calls the x264.exe, so, I think, it's a codec issue. You can try to remove "--thread-input" in the agkpx264.bat or replace "--thread-input" with "--threads 2" for 2-core-systems.

Finally, I would like to note that the chapters don't work. I mean that this is a GK's function which works normally when producing VFW MKVs, but the cooperation with AGKP is problematic in this field. So I have to mux the chapter file and the subtitles file into the output mkv with MKVToolnix. I think that it won't be hard this function to be added in the new version of AGKP.I never used chapters. So, I will make some tests in the next days. SRT subtitles works fine.

Best regards

akapuma

[har-vas]

Hi Akapuma. After my first successful rip, I had two consecutive failures. The first one was a movie which seems to be normal, but 5 minutes before the end, stucks! The audio continues normally, but the video is being freezed in that damned frame! Now I had to re-encode the whole movie for the last 5 minutes (another 8 hours)! And I am not sure that it won't happen again. I don't know what is going on, but I saw that the ripped .vob file plays normally that point of the film.
In the second case, when the first pass finishes, the second pass is skipped and the job is done! In the agkpmux.txt I can read:
---
ECB: x264 [warning]: width or height not divisible by 16 (664x272), compression will
ECB: suffer.
ECB: x264 [info]: using SAR=16/11
ECB: x264 [error]: requested bitrate is too low. estimated minimum is 23283 kbps
ECB: x264 [error]: x264_encoder_open failed
---
And below:
---
MXB: Error: The file 'BOSTON~1.MKV' has unknown type. Please have a look at the suppo
MXB: rted file types ('mkvmerge --list-types') and contact the author Moritz Bunkus <
MXB: moritz@bunkus.org> if your file type is supported but not recognized properly.
---
I tried twice with this case: Same result. When the first pass is finishing, the job also finishes. Am I doing something wrong? I am selecting width and height resolutions divisible by 8. Is that OK? Can you give your explanation about those two failures? Thank you.

PS1: Is it coincidental that in both cases I had enabled the trim function? Does this feature works flawlessly with AGKP or should I have to encode the credits also?
PS2: If you want me to send you any log files, please let me know.
PS3: Your advice for the 2 threads seems to be helpful. Now the CPU usage is much higher. But I noticed that x264.exe, ntvdmod.exe and cmd.exe are all with a low priority flag. How can I change that if I want to (I mean without Task Manager)? Is it a switch in a command or is it hard-coded in AGKPV.exe?

[Brother John]

I'm back from a short holiday, but rather tired right now. Will read and answer tomorrow.

[akapuma]

Hi Akapuma. After my first successful rip, I had two consecutive failures. The first one was a movie which seems to be normal, but 5 minutes before the end, stucks! The audio continues normally, but the video is being freezed in that damned frame! Now I had to re-encode the whole movie for the last 5 minutes (another 8 hours)! And I am not sure that it won't happen again. I don't know what is going on, but I saw that the ripped .vob file plays normally that point of the film.I dont' know this problem. But you can make a test. In the movie directory, there are two files like this:
1: test.mkv
2: test_movie.mkv
The 1st file is the complete movie with audio, the 2nd file is the unmuxed movie without audio. Have you the problem with both files?

In the second case, when the first pass finishes, the second pass is skipped and the job is done! In the agkpmux.txt I can read:
---
ECB: x264 [warning]: width or height not divisible by 16 (664x272), compression will
ECB: suffer.
ECB: x264 [info]: using SAR=16/11
ECB: x264 [error]: requested bitrate is too low. estimated minimum is 23283 kbps
ECB: x264 [error]: x264_encoder_open failed
---
And below:
---
MXB: Error: The file 'BOSTON~1.MKV' has unknown type. Please have a look at the suppo
MXB: rted file types ('mkvmerge --list-types') and contact the author Moritz Bunkus <
MXB: moritz@bunkus.org> if your file type is supported but not recognized properly.
---
I tried twice with this case: Same result. When the first pass is finishing, the job also finishes. Am I doing something wrong? I am selecting width and height resolutions divisible by 8. Is that OK?
"ECB:" means encodingscreen. "ECB" should contain the x264cli-commandline like this:
ECB: c:\PROGRA~1\x264\x264.exe --crf 25 -I 300 -i 120 -r 6 --mixed-refs --no-fast-psk
ECB: ip -b 4 --b-pyramid --b-rdo --bime -w -f 1,1 -m 7 -t 1 -A all -8 --qpstep 8 --aq
ECB: -strength 0.5 --direct auto --b-bias 30 --thread-input --progress --no-psnr --n
ECB: o-ssim -o "morph_6.mkv" morph.avsCan you post this lines?
"MXB:" means muxing screen. You got muxing errors, because the encoding was not successful.
Resolutions divisible by 16 are highly recommended.

PS1: Is it coincidental that in both cases I had enabled the trim function? Does this feature works flawlessly with AGKP or should I have to encode the credits also?Did you set the trim function manually in the avs-skript? This should work, this mechanism is used in the CompCheck also. For credits, I prefer the GKnot-credits-function. With the agkp standard settings, only 10% of the normal bitrate is used for the credits.

PS3: Your advice for the 2 threads seems to be helpful. Now the CPU usage is much higher. But I noticed that x264.exe, ntvdmod.exe and cmd.exe are all with a low priority flag. How can I change that if I want to (I mean without Task Manager)? Is it a switch in a command or is it hard-coded in AGKPV.exe?The priority is not coded in agkp. While encoding, only the x264.exe needs CPU power. I don't know any way to change the priority.

Best regards

akapuma

[har-vas]

Hi Akapuma and thank you for your quick and clear-cut answers. As for the stuck movie case, I don't have the test.mkv, because I have muxed it in MKVToolnix with chapters and subtitles. So I have the "complete test.mkv", which has this problem and I also have the test_movie.mkv which also has this problem. I am sure that this problem was there for the original test.mkv too. So the problem seems to be with the encoding process, not with the muxing. What is strange though is that the test_movie.mkv has a much more oblong picture than the "complete test.mkv", despite the fact that both report to have the same resolution (672x352). I suppose that the PAR factor is being taken into account only after the final muxing. Another strange point is the duration. The test_movie.mkv is 1:29:34 and the "complete test.mkv" is 1:31:44. Possibly because of my "Movie Only" trim choice. The freeze is taken place at 1:26:32 in both files. I am confused, because I think that they should both have the same duration, 1:29:34. Am I correct? That's all for that case. I will re-try the encode and post the results.
As for the second case, here are the lines you need:
---
AWB: 11-10-2006 18:06:17
AWB: ColorYUV...aus
AWB: Farbe...bunt
AWB: Postprocessor...aus
AWB: Deinterlacer...aus
AWB: DeGrainMedian...aus
AWB: undot...aus
AWB: x264-Encoder:...2-pass
AWB: mkvmerge fourcc:...H264
AWB: mkvmerge AR:... 2.441
x264first=done
ECB: 11-10-2006 19:43:56
ECB: x264 : mb I I16..4: -6331910.4% -9568419.9% -5412057.3%
ECB: x264 [info]: mb P I16..4: 840970.3% -649402.7% 828271.4% P16..4: 58259.1% 1592
ECB: 76.9% 323866.8% -75690.7% 28829.4% skip:25673236.4%
ECB: x264 [info]: mb B I16..4: 471003.2% 1000106.6% 827424.5% B16..8: 94570.0% 4102
ECB: 46.4% 166900.5% direct:7559.3% skip:22439.4%
ECB: x264 [info]: final ratefactor: 23.85
ECB: x264 [info]: 8x8 transform intra:299.6% inter:116.2%
ECB: x264 [info]: direct mvs spatial:48.7% temporal:51.3%
ECB: x264 [info]: ref P 17.7% 17.3% 8.6% 4.5% 27.2% 24.7%
ECB: x264 [info]: ref B 23.5% 22.4% 12.4% 17.1% 14.6% 9.9%
ECB: x264 [info]: kb/s:826.0
ECB:
ECB: encoded 167213 frames, 28.56 fps, 827.09 kb/s
ECB: C:\PROGRA~1\X264NA~1\x264.exe -p 2 -B 984 -I 300 -i 120 --sar 16:11 -r 6 --mixed
ECB: -refs --no-fast-pskip -b 4 --b-pyramid --b-rdo --bime -w -f 1,1 -m 6 -t 1 -A all
ECB: -8 --qpstep 8 --aq-strength 0.5 --direct auto --b-bias 30 --zones 134356,167213
ECB: ,b=0.1 --threads 2 --progress --no-psnr --no-ssim -o "bostonnew_movie.mkv" BOSTO
ECB: N~1.AVS
ECB: avis [info]: 664x272 @ 25.00 fps (167213 frames)
ECB: x264 [warning]: width or height not divisible by 16 (664x272), compression will
ECB: suffer.
ECB: x264 [info]: using SAR=16/11
ECB: x264 [error]: requested bitrate is too low. estimated minimum is 40217 kbps
ECB: x264 [error]: x264_encoder_open failed
---
Do you understand something helpful?
You said: "[I]Resolutions divisible by 16 are highly recommended
". Can you please report one or two specific reasons for that? I don't understand that limitation, despite the fact that many people talk about it. One says that this helps the correct hardware acceleration of the movie, the other that retains the compatibility with standalones, but I am not sure about all these. I thought that a modern codec and container wouldn't have such limitations. Can you explain to me please?
As for the trim function, I have just marked the frame after which the credits are starting and then I selected the "Movie Only" radio button from the "Save & Encode" window. That's all I did, I haven't edited the avs script. Is this OK for the credits to stay away?
Finally, you said "With the agkp standard settings, only 10% of the normal bitrate is used for the credits.". Do you mean that it's possible to mark the frame after which the credits are starting and have the credits encoded with 10% of the average bitrate? The good old DivX setting "Encode credits separately" is not there for x264, so we have only "No Trim" and "Movie Only" choices. Do you know any trick to encode separately the credits and then append it in the main movie? Thanks.

[Brother John]

Hi, guys.

Finally I’m back, properly awake and ready to post. Thanks akapuma for doing all the answering so far.

The encoding at last started and I saw the program working (but I want to understand the settings of XviD
No magic involved here. Those cryptic strings are standard commandlines for x264.exe and xvid_encraw. Open a dos window and run "x264.exe -h" and "xvid_encraw.exe -help" to get en overview. You could also open MeGUI’s codec configuration, tick the "show commandline" checkbox and play with the options.

Why should I have to untick the "Calculate frame-overhead" checkbox?Xvid takes AVI overhead into account by itself. If GKnot calculates the overhead again, you’ll end up with a slightly undersized file. From my experience encraw acts the the same way. But if you’re files end up slightly oversized tick the checkbox and see if sizes become more accurate.

The audio continues normally, but the video is being freezed in that damned frame!
----------------
Is it coincidental that in both cases I had enabled the trim function?
----------------
Possibly because of my "Movie Only" trim choice.
Don’t use "movie only" if you want the complete movie (even when you encode credits with different settings). You should always select "No trim". Otherwise you’ll end up with a movie that is cut at the point where you defined credits to start. This leads to the effect of a frozen picture (because that indeed is the last picture of the video stream) and continuing sound (because "Movie only" does not automatically cut audio streams, that remain the original length).

You said: "Resolutions divisible by 16 are highly recommended". Can you please report one or two specific reasons for that?
Macroblocks have a size of 16x16 pixels. For non mod16 resolutions the codec has to deal with incomplete macroblocks, which reduces encoding efficiency and might result in playback problems with some decoders. So only deviate from the mod16 rule if you’re absolutely sure what you’re doing.

For some more info have a look at the tips I added to the first post of this thread. Especially read the notes about anamorphic encoding as you should not use the pixelar variable.

[akapuma]

ECB: x264 : mb I I16..4: -6331910.4% -9568419.9% -5412057.3%
ECB: x264 [info]: mb P I16..4: 840970.3% -649402.7% 828271.4% P16..4: 58259.1% 1592
ECB: 76.9% 323866.8% -75690.7% 28829.4% skip:25673236.4%
ECB: x264 [info]: mb B I16..4: 471003.2% 1000106.6% 827424.5% B16..8: 94570.0% 4102
ECB: 46.4% 166900.5% direct:7559.3% skip:22439.4%
....
ECB: -refs --no-fast-pskip -b 4 --b-pyramid --b-rdo --bime -w -f 1,1 -m 6 -t 1 -A all
ECB: -8 --qpstep 8 --aq-strength 0.5 --direct auto --b-bias 30 --zones 134356,167213
ECB: ,b=0.1 --threads 2 --progress --no-psnr --no-ssim -o "bostonnew_movie.mkv" BOSTO
ECB: N~1.AVS
ECB: avis [info]: 664x272 @ 25.00 fps (167213 frames)
ECB: x264 [warning]: width or height not divisible by 16 (664x272), compression will
ECB: suffer.
ECB: x264 [info]: using SAR=16/11
ECB: x264 [error]: requested bitrate is too low. estimated minimum is 40217 kbps
ECB: x264 [error]: x264_encoder_open failed
Don’t use "movie only" if you want the complete movie (even when you encode credits with different settings). You should always select "No trim". Otherwise you’ll end up with a movie that is cut at the point where you defined credits to start. This leads to the effect of a frozen picture (because that indeed is the last picture of the video stream) and continuing sound (because "Movie only" does not automatically cut audio streams, that remain the original length).There is an encoder error, because the values for the percentages are over 100%. Maybe the encoder expects 167213 frames (defined in the zones section), but your movie have not so much frames (because "Movie only" is used). Try the suggestion by brother john.

You said: "[I]Resolutions divisible by 16 are highly recommended
". Can you please report one or two specific reasons for that? I don't understand that limitation, despite the fact that many people talk about it. One says that this helps the correct hardware acceleration of the movie, the other that retains the compatibility with standalones, but I am not sure about all these. I thought that a modern codec and container wouldn't have such limitations. Can you explain to me please?Brother John explained this. If I am not sure, I ask in the german forum (http://forum.gleitz.info/showthread.php?t=26293). And there (http://forum.doom9.org/showpost.php?p=745881&postcount=45) is a quotation by sharktooth. And x264 denounced this (see your agkpmux.txt):
ECB: x264 [warning]: width or height not divisible by 16 (664x272), compression will
ECB: suffer.

Finally, you said "With the agkp standard settings, only 10% of the normal bitrate is used for the credits.". Do you mean that it's possible to mark the frame after which the credits are starting and have the credits encoded with 10% of the average bitrate?If you choose "set credits start" in GKnot, this setting will be used in agkp. The bitrate for the encoding is 10% compared without this setting, not 10% of the normal bitrate. Video quality maybe poor, but your can hear the sound.

The good old DivX setting "Encode credits separately" is not there for x264, so we have only "No Trim" and "Movie Only" choices. Do you know any trick to encode separately the credits and then append it in the main movie? Thanks.It's no separately encoding neccessary. Only use "set credits start" in GKnot.

Best regards

akapuma

[akapuma]

Additionally, I noticed that the CPU use was very low (a little above the 50-55%).I hope, I've a solution. I modified the agkpx264.bat:

before (without remarks)@ECHO OFF

if NOT "%6"=="" set agkpzones=--zones %6,%7,b=0.1

set subme=7

if not "%1"=="" goto %1
ECHO Fehler: Direktaufruf oder zu wenig Definitionen in der agkpx264.bat
pause
goto ende

:compcheck
ECHO compcheck
echo %2 -q 18 -I 300 -i 120 -r 6 --mixed-refs --no-fast-pskip -b 4 --b-pyramid --b-rdo --bime -w -f 1,1 -m %subme% -t 1 -A all -8 --direct auto --aq-strength 0.5 --b-bias 30 %agkpzones% --thread-input --progress --no-psnr --no-ssim -o %4 %5
%2 -q 18 -I 300 -i 120 -r 6 --mixed-refs --no-fast-pskip -b 4 --b-pyramid --b-rdo --bime -w -f 1,1 -m %subme% -t 1 -A all -8 --direct auto --aq-strength 0.5 --b-bias 30 %agkpzones% --thread-input --progress --no-psnr --no-ssim -o %4 %5
goto ende

after (without remarks):
@ECHO OFF
if NOT "%6"=="" set agkpzones=--zones %6,%7,b=0.1

set subme=7

set CLI=START /B /NORMAL %2

if not "%1"=="" goto %1
ECHO Fehler: Direktaufruf oder zu wenig Definitionen in der agkpx264.bat
pause
goto ende

:compcheck
ECHO compcheck
echo %CLI% -q 18 -I 300 -i 120 -r 6 --mixed-refs --no-fast-pskip -b 4 --b-pyramid --b-rdo --bime -w -f 1,1 -m %subme% -t 1 -A all -8 --direct auto --aq-strength 0.5 --b-bias 30 %agkpzones% --thread-input --progress --no-psnr --no-ssim -o %4 %5
%CLI% -q 18 -I 300 -i 120 -r 6 --mixed-refs --no-fast-pskip -b 4 --b-pyramid --b-rdo --bime -w -f 1,1 -m %subme% -t 1 -A all -8 --direct auto --aq-strength 0.5 --b-bias 30 %agkpzones% --thread-input --progress --no-psnr --no-ssim -o %4 %5
goto ende


With the new line "set CLI=START /B /NORMAL %2", you can change the priority. Instead of NORMAL, you can use the following parameters:

LOW - NORMAL - BELOWNORMAL - HIGH - ABOVENORMAL - REALTIME

Best regards

akapuma

[har-vas]

Hi to all Germans out there! Thank you all for your posts. I have many comments to make, so first I would like to answer to Brother John.
1. Could you please answer to that? If I understood correctly, I have to use that variable in every DVD ripping, according to the PAR table, because every DVD has non-square pixel AR, correct? Only in the case of content from TV capture, I think, the pixelar variable should be removed or being set to 1:1, correct?
2. And what about this? I was very happy until the moment I open the mkv. 130 MB instead of 850 MB for a 2-hour movie. The quality was awful of course Here, I want to add that this phenomenon appeared with another movie also (170 MB instead of 900). I then repeated the encoding setting the size to 1400 MB this time. Hopeless! The final output was AGAIN 170 MB. Why is that? This is actually the biggest problem with XviD_encraw encodings.
3. I have noticed that the bitrate starts from very high levels (over 3600 kbps at 0%) and gradually going lower (2200 kbps at 20%). Later is too low (138 Kbps at 39% of second pass). See my attachments (first one is from a different job I think). Maybe this has something to do with the very small output filesizes?
4. Why XviD_encraw says "Detected 0 cpus, using 0 threads"? And why the version says 1.1.2? In MeGUI says 1.2.0 and I have taken encraw from there. See my attachments.
5. Could you please answer to that? What filter should I use for the proper decoding of native XviD streams? You suggest the latest ffdshow or the classic XviD filter from Koepi (I wonder if this is only for VFW).
6. Finally, please also answer to this question: Brother John, which is the value I should give in the AGKP GUI's last line for an anamorphic case? Is this the same value with the one in the "Aspect Ratio" field of the "Output Resolution" section of GK's "Resolution" tab (eg 2.441 in my case)? In other words, is the result of width/height of the output resolution? Thanks.

[Brother John]

1. and 6.
For all the examples you provided so far, you do not need to set any AR flag. I explained this in the tips in the first post. Read them. I’ll give you an overview. Note that the term »traditional encoding« from the tips section means »square pixel output resolution«. Also »square« and »non-square« in the table refers to the shape of one pixel, not the whole frame’s shape.

Is setting AR flags necessary? I.e. is it necessary to use the pixelar variable and/or the mkvmerge AR line?
| Square | Non-Square
| Input | Input (e.g. DVD)
-----------+----------+-----------------
Square | Optional | Optional
Output | |
-----------+----------+-----------------
Non-square | Yes | Yes
Output | |
Optional means you do not need to set any AR flag. But if you do, set the pixelar variable to 1:1 and the mkvmerge AR line to (output width / output height).

2. and 3.
Always keep in mind that especially during encoding encraw’s status display sometimes is not really accurate.
I can’t see anything wrong with the commandline, so problem should not be agkp related. Try removing the -vbvmax and -vbvsize options (including their values of course) from both passes’ commandlines. Though this should not result in significant changes. If you problem stays, I’m out of ideas. Maybe the xvid_encraw thread (http://forum.doom9.org/showthread.php?t=98469) can help you. Yes, I know it’s quite long. :-|

4.
Afaik this is normal for Xvid builds without multi CPU support. Only the current 1.2 CVS builds support multiple CPUs. If you have more than one xvidcore.dll on your system – e.g. 1.1.2 in \windows\system32 and 1.2 in encraw’s folder – I’m not exactly sure which one gets chosen. Probably the one in encraw’s folder.

5.
Read the tips from the first post.

[akapuma]

For the correct AR, I'm using GKnot an agkpAR.

Best regards

akapuma

[M3n747]

Hello. Sorry for this thread necromancy, but it seems to be the best place to ask, so...

I've installed agkp and I must say I like it. However, there are two problematic things.

1. Deinterlacing works fine when I set it in GKnot's "Save & Encode" window, but when I set deinterlacer in the agkpA.exe window to anything other than "aus", it always results in CLI-Encoderfehler message. The logs then show something like this:


12:14:43: Started x264 - First Pass: H:\Kompresja\Wycinek\wycinek_15_itakniezadziala.avs
12:15:59: Finished x264 - First Pass: Duration: 1 minuta, 15 sek.
12:15:59: Trying to open Log-file.
12:15:59: Error: Could not open H:\Kompresja\Wycinek\vdenc.log
12:15:59: Error: Could not count encoded Frames.
12:15:59: Speed: 0.000 Frames per Second.
12:15:59: WARNING: Number of counted frames differs from settings!
12:15:59: WARNING: Settings: 99
12:15:59: WARNING: Counted: 0
12:15:59: WARNING: Difference: 99
12:15:59: Correcting Bitrate...
12:15:59: Original Bitrate = 1482210 k(=1000)Bits/s
12:15:59: Error: Correction impossible.
12:15:59: Now encoding at 1482210 k(=1000)Bits/s


If this is of any importance, I use x264.763.modified.exe by Sharktooth (http://forum.doom9.org/showthread.php?t=89979).

2. When I try to run the compressibility check, I get the same CLI-Encoderfehler, and then GKnot gives me the message "Log file not found. Unable to get compressability value." My guess is that both cases are connected.

I would appreciate any help you can give me.

[akapuma]

it always results in CLI-Encoderfehler message.

"CLI-Encoderfehler" means that the size of the resulting file is not longer than some hundred bytes.

Possible causes:
- scribal error in x264-parameters
- x264-parameters don't match with x264-version
- wrong avs-script

Look for a file named "agkpmux.txt". In this file, you should find the reason.

best regards

akapuma

[M3n747]

Thanks for your answer, it helped! As it turned out, the encoder couldn't load the "TDeint.dll" AviSynth Plugin - simply because it wasn't there. :) I downloaded it, copied to the AviSynthPlugins directory and now it works as it should.

As for the compressibility test, I had to choose x264vfw instead of x264-CLI and it worked too. Let's just hope that vfw's results don't differ. :D

Again, thanks for your help and thanks for the agkp! :)

[M3n747]

Hi, me again. :)

First of all, the English tutorial (http://encodingwissen.de/gordianknot/agkp-english.html) has 404ed. Too bad. :(

Secondly - I've been using the GKnot/agkp/x264 (r763 modified) combo for quite a time now and I love it. However, some time ago I wanted to try out a newer release of x264 (r1028M, then r1046M, both by Sharktooth (http://forum.doom9.org/showthread.php?t=89979)). It worked fine until the first pass ended - then, instead of starting the second pass, the encoder just displayed my favourite CLI-Encoderfehler and terminated. I checked the logs, and here's what I found:

GKnot's log:

15:25:19: EXCEPTION: 'sh' is not a valid integer value
15:25:19: EXCEPTION: Encoder Thread Terminated.


agkpmux.txt:

ECB: F:\Programy\KOMPRE~2\x264\x264.exe: unrecognised option `--b-rdo'


(If you need the full logs, they're here (http://www.zshare.net/download/5238485447f9f360/).)

So it would seem that the newer builds of x264 modified don't support some options which worked fine in the older releases. Is there a fix for this problem or should I simply stick to r763M?

[Atak_Snajpera]

Maybe you should forget about GKnot and you use my GUI. Check my signature.

[M3n747]

Thanks, but I'd rather stay with a tool I know well and which provides great results. Plus I'm not uninstalling CCCP, thank you very much.

[Atak_Snajpera]

If you really love old bugy builds without PsyRDO and AQ so ... Good luck! These two magic things are huge improvement in terms of quality!

BTW. Let me guess. You still use Win98 because you know it well ? :)

[M3n747]

Well, unlike you videophiles, I don't need to use every available piece of tomorrow's technology to make my encodes a little bit smaller. And now please kindly remove yourself so as to make space for somebody, who can actually answer my question.

[Atak_Snajpera]

Well, unlike you videophiles, I don't need to use every available piece of tomorrow's technology to make my encodes a little bit smaller.
then use MPEG-1 compression :) If you don't care about quality so why do you try to use latest x264 builds in outdated AGT???

ECB: F:\Programy\KOMPRE~2\x264\x264.exe: unrecognised option `--b-rdo'
--b-rdo was combined with --subme 7 couple weeks ago. That's why it does not exist amigo.

[Brother John]

agkp isn’t updated anymore, so the included x264 command lines don’t work with current builds. However you can always edit them in one of the .bat files. Offhand I don’t remember which one, though.

All in all Atak_Snajpera ist right. GK/agkp is outdated and has been replaced with much more capable (for todays formats) and usable programs (StaxRip, MeGUI etc.)

[M3n747]

I tried editing the agkpx264.bat file - alas, to no avail. I guess it would be simply too easy if it worked without any problems. :)

I've tried a few other programs, but none of them really worked for me. And since the GK/agkp combo works just fine, I see no point in using something else; at least not yet. Nonetheless, thanks for your suggestions, I'll keep them in mind.

[Sharktooth]

seriously, there are tons of guides and docs or howtos for the encoding GUIs supporting x264. some of them are even easier to use than GK!
x264 and GK are mutually exclusive...