x264 codec not installed properly...

[Yashke]

Hi everyone...

I'm tryin' to encode a video with the x264 codec in Gordian Knot, but just can't access on the 1st pass and 2nd pass settings...

I installed the last ffdshow, i can play h.264 files but the settings won't start on GK.

Help... :confused:

[Dark Shikari]

That's primarily because you're not supposed to be using GK to encode with x264.

Try MeGUI.

[Spiderm@n]

A few years after this answer, can I ask the same question :).
GordianKnotnow supports x264 but I can't make it work. Non of the screens shown in the tutorial shows, I press 1st or 2nd pass button for x264 and nothing.

[MasterNobody]

Spiderm@n
GordianKnot need VfW-version of x264 (which you can find here: http://sourceforge.net/projects/x264vfw/) not the CLI-version which is used by most of GUIs (for example MeGUI)

[Spiderm@n]

Can I ask what exactly is the difference, I've read a few guides but couldn't exactly find the difference.

[e-Pawel]

Just forget about Gordian Knot and the VfW-version of x264, since it doesn't support some of the features and since you should choose .mp4 or .mkv as the container format (instead of avi).

All you need is MeGUI ;)

-> http://gillam.chris.googlepages.com/

RipBot264 works fine as well.

[Spiderm@n]

GKnot supports MKV format, and I don't like mp4, probablu because of the problems I've got with .mp4 files, mostly created from GSM cameras and crappy codecs (mine is one of them).

[talen9]

MeGUI can mux into Matroska (MKV) files too :)

Or, better, it supports the programs that mux into MKV, like mkvmerge ;)

[Spiderm@n]

Yaeh, I know. I usually use VirtualDubMod for operations with .MKV or .OGM files :).

[Blue_MiSfit]

Someone is using outdated tools..... :)

If they work for you, that's fine.

Give a newer workflow app like MeGUI or AutoMKV a try. They're a lot more up to date.

VirtualDubMod is a real dinosaur. I dont think its been updated in at least 3 years.

~MiSfit

[roozhou]

Just forget about Gordian Knot and the VfW-version of x264, since it doesn't support some of the features and since you should choose .mp4 or .mkv as the container format (instead of avi).

All you need is MeGUI ;)

-> http://gillam.chris.googlepages.com/

RipBot264 works fine as well.

I wonder which x264 features are not supported by x264vfw and avi.

[e-Pawel]

I wonder which x264 features are not supported by x264vfw and avi.

Don't exactly know which features are not supported (if you want to know it, just google ;) ). But what does it matter? Forget about wfv and .avi in connection with H264 :p If everyone advises you to use MeGUI (even the x264 developers disadvise using vfw) so why do you still want to stick to vfw? ;)

[LoRd_MuldeR]

I wonder which x264 features are not supported by x264vfw and avi.
VFW Codecs can't encode B-Frames properly, because the VFW-Interface doesn't allow the encoder to "see" any future frame.
The encoder only has access to the current source-frame. Next source-frame becomes accessible after the current frame was encoded.
Encoders work around this silly limitation (B-Frames simply didn't exist when VFW was created) by buffering a number of frames internally.
Problem with that: Encoder needs to put out "dummy" frames at the very beginning plus you get a delay!
The delay equals the number of frames buffered in the encoder, which equals the number of maximum consecutive B-Frames.
For example using two consecutive B-Frames results in a delay of two frames in the resulting video file when using a VFW-based Codec.
To make things even worse, DivX will create "packed" frames (several frames stored as one) and inserts Null-Frames to compensate...

Note: This is a limitation of VFW, it is not a limitation of the AVI container!
AVI files can be created properly (with B-Frames) using proper software (e.g. Avidemux) instead of VFW-based tools.
Nevertheless B-Frames cannot be labeled as such in AVI, since AVI only supports "key" frames (I-Frames) and "delta" frames (P-Frames).
So B-Frames will be labeled as "delta" frames (P-Frames), which some people consider a "hack".
But that's a different story and it usually has no noticeable effect on playback! Most (software) players will play those AVI's 100% fine...

[Tagert]

Much abbliged Lord Mulder, for explaining that into further detail :)

[roozhou]

Thank you Lord Mulder.
And will this delay be eliminated by remuxing?

I don't like MeGUI because it only supports avs and needs .NET framework thus making it unportable. IMO 90% of MeGUI functions would be implemented by batch files.

I prefer Mencoder & AVI_DEMUX since they don't rely on external dshow filters to decode.

[LoRd_MuldeR]

Thank you Lord Mulder.
And will this delay be eliminated by remuxing?

Don't think so! There will be a number of "dummy" frames at the very beginning of the file.
You can re-mux the stream, right. But AFAIK the Muxer won't be able distinguish between "dummy" and "real" frames.

Nevertheless the "packed bitstream" created by DivX (and optionally created by Xvid) can be unpacked in a 100% lossless way...

I don't like MeGUI because it only supports avs and needs .NET framework thus making it unportable. IMO 90% of MeGUI functions would be implemented by batch files.

MeGUI is a very powerful application, but it's more targeted for "professional" encoding tasks using Avisynth.
Also .NET is not spcific to the Windows platform! There is the Mono (http://en.wikipedia.org/wiki/Mono_(software)) project for example!

I prefer Mencoder & AVI_DEMUX since they don't rely on external dshow filters to decode.

And even more important: They don't use nasty VfW Codecs to encode :cool:

[roozhou]

MeGUI cannot run on Windows without .NET installed. It takes hours to download and install .NET+avisynth+codec packs.

[LoRd_MuldeR]

MeGUI cannot run on Windows without .NET installed. It takes hours to download and install .NET+avisynth+codec packs.

1. Download/Install Avisynth takes about 3 minutes :p
2. Codec Packs are from hell, keep away from such monstrosity !!!
3. For DirectShowSource() all you need is basically ffdshow-tryouts plus HaaliMediaSplitter, takes about 5 minutes to install ;)
4. If you use FFmpegSource() no further "Codecs" are needed, just one single Plugin-DLL in Avisyhth folder
5. Installing .NET takes some time indeed, but you'll need .NET for more and more applications anyway *sigh*
6. Since Windows Vista becomes more popular and ships with .NET, people won't need to download/install .NET manually...

[roozhou]

1. Download/Install Avisynth takes about 3 minutes :p
2. Codec Packs are from hell, keep away from such monstrosity !!!
3. For DirectShowSource() all you need is basically ffdshow-tryouts plus HaaliMediaSplitter, takes about 5 minutes to install ;)
4. If you use FFmpegSource() no further "Codecs" are needed, just one single Plugin-DLL in Avisyhth folder
5. Installing .NET takes some time indeed, but you'll need .NET for more and more applications anyway *sigh*
6. Since Windows Vista becomes more popular and ships with .NET, people won't need to download/install .NET manually...

So everything needs to be INSTALLED.
Avidemux, mplayer/mencoder and other CLI tools do not need to be installed.

[LoRd_MuldeR]

What do you call "INSTALLED" ?!?

Copying files to your HDD, copying files to a "system" folder (such as "WINDOWS\System32") or writing new entries to the Registry?

In fact installing Avisyth will copy a number of files to the Avisynth install folder plus it will copy "avisynth.dll" to your "System" folder.
That's it! And it can be undone easily. Adding new Avisynth Plugins usually means copying one single DLL file to the "Plugins" subfolder in Avisynth folder.
Installing any DirectShowFilter will NOT be needed, if you use FFmpegSource() instead of DirectShowSource() ...

Last but not least: What's so bad about "installing" as long as you keep away from crappy "Codec Packs" ???

[roozhou]

>Lord Mulder

Imagine you are encoding on your friend's computer or even worse a public computer you do not have privillege to write to registry.

I don't know why there is no other avs parser/loader than AviSynth (yes VDM has one but it also uses vfw). Why don't you write an avs parser for avidemux? Avidemux has its build-in decoders so XXXSource is not needed.

DirectShowSource can handle everything but it's slow and eats up 200MB+ memory for 720P and 350MB+ memory for 1080P.

FFmpegSource sucks since it scans the whole file before decoding, making it difficult to preview effects of other filters. And it does not decode such formats as RV30/40, VP7.

[LoRd_MuldeR]

Imagine you are encoding on your friend's computer or even worse a public computer you do not have privillege to write to registry.

Tell your friend what Avisynth does and he/she will understand that this is an essential software for everybody involved in video processing/encoding ;)

Doing an encoding project (which usually takes hours or even days) on a public machine really is a rare case...

I don't know why there is no other avs parser/loader than AviSynth (yes VDM has one but it also uses vfw). Why don't you write an avs parser for avidemux? Avidemux has its build-in decoders so XXXSource is not needed.

There is no other "AVS Parser" than Avisynth, because AVS files are "Avisynth Scripts" created for use with Avisynth :p
Applications can easily call the "avisynth.dll" in order to support Avisynth input. That's how "frameserving" works.

Creating another "AVS Parser" would mean re-writing Avisynth from the scratch.
Since Avisynth is a really complex project, was development in several years and has a huge community, nobody would do that!
Why in the world do you want to re-invent the wheel ???

And no, VirtualDub does not have it's own AVS parser. It calls Avisynth to open AVS files - like any other application does :rolleyes:
Avidemux does the same, it only puts AVS Proxy in between. That's because Avidemux is a Linux tool in first case.
Using AVS Proxy allows Avidemux to run as "native" Linux process, while AVS Proxy and Avisynth run as "Wine" processes.

DirectShowSource can handle everything but it's slow and eats up 200MB+ memory for 720P and 350MB+ memory for 1080P.

Not exactly. DirectShowSource() does not handle "everything", but everything DirectShow (or the installed DirectShow Filters to be precise) can handle.
Memory usage might be pretty high, but unless you have a better solution, you will have to live with that...

Remember: RAM is really cheap these days ;)

FFmpegSource sucks since it scans the whole file before decoding, making it difficult to preview effects of other filters. And it does not decode such formats as RV30/40, VP7.

1. Before you say that FFmpegSource "sucks", write a better source filter and release it as free software! :mad:
2. Indexing is required indeed. But that cannot be avoided if you want random frame access and if you don't want to wait years for seeking...
3. FFmpegSource can store the index file, so indexing is needed exactly once per file. Next time the existing index is used.
4. Real Video is a proprietary format! Support in free software is only possible via reverse engineering :sly:

[Myrsloik]

It's time for the BLAME GAME!

The indexing pass in ffmpegsource is because avisynth/vfw need to know the exact number of frames when a file is opened. So it's NOT MY FAULT (personally I blame society for this limitation).

It's also possible to use avisynth directly without doing any of that horrible installing stuff. The program just has to support using the avisynth dll directly like avs2yuv and several others do. You'll still need to install a copy of windows though...

[LoRd_MuldeR]

You'll still need to install a copy of windows though...

There is no Windows Live-CD yet? Damn! :p

[Spiderm@n]

Actually, there is :).
It's Windows PE (Pre-Installed Enviornment), and there are few such CDs. The bad part is that they are more usefull for prepairing your PC for reinstallation etc. then for encoding. Anyway, search for UBCD (Ultra Boot CD) or Infr@, the secound is in Russian :).

As for codec packs, absolutelly agree, I've got a few codecs downloaded some time ago, they aren't updated till today, and I've dawnloaded a few .AX (I think that was the extension) files form a sourceforge site you all know, I'm sure, and put them in one installer, because I'm a lazy bastard, I've made a codec pack by myself :). I don't like the way Haali works, make a lot of problems for me, I use the original Gabest Matroska Splitter and Muxer, works perfectly fine, and I'm fine without getting thumbnail for the MKV files :).




Iny ideas if it's possible for GordianKnot to work with VirtualDub and not VirtualDubMod? It's for DivX encoding.

[Spiderm@n]

Any sugestions for a tool, that has DivX support as well as x264?

[e-Pawel]

Any sugestions for a tool, that has DivX support as well as x264?

Yes, MeGUI :) It supports both MPEG-4 ASP (Xvid) and MPEG-4 AVC (x264). That's what you need (if you had installed MeGUI as everyone advised you, you wouldn't need to ask that question... :p)

And forget about DivX... Why the hell do you want to use Divx when there is Xvid... :p Both Divx and Xvid are MPEG-4 ASP encoders, but Xvid is the better one (and it's opensource)

[Irakli]

Any sugestions for a tool, that has DivX support as well as x264?

AutoMKV supports both x264 and DivX.

And, of course, it is worth following advice of e-Pawel if you don't have strong reasons for using DivX instead of XviD.

[Spiderm@n]

And why should I use XviD, that I kind of don't stand looking at, when there is DivX :).

Yeah, right, AutoMKV supports DivX as much as AVI Demux or MeGUI.

[Southstorm]

StaxRip supports DivX 100%

[Irakli]

And why should I use XviD, that I kind of don't stand looking at, when there is DivX :).

Yeah, right, AutoMKV supports DivX as much as AVI Demux or MeGUI.

No, not "as much as Avi Demux or MeGUI". Unlike MeGUI or AviDemux, latest beta of AutoMKV does support DivX (see here (http://forum.doom9.org/showpost.php?p=1113953&postcount=1)).

[Spiderm@n]

Oh, you meant the BETA, I usually don't use BETA versions, that's why I've downloaded 0.95. Sorry :).

[LoRd_MuldeR]

Oh, you meant the BETA, I usually don't use BETA versions, that's why I've downloaded 0.95. Sorry :).

When dealing with OpenSource software, you are far better off with the latest version available, in almost every case.
Developers usually put up new "SVN" or "Beta" releases in short intervals, because they want to share their latest fixes with the community.
"Stable" versions are rare in the OpenSource scene and usually they are outdated very soon...

If a certain "Beta" version doesn't work for you, simply go back to the previous release and/or tell the author about the problem ;)

No, not "as much as Avi Demux or MeGUI". Unlike MeGUI or AviDemux, latest beta of AutoMKV does support DivX (see here).
Avidemux does not use DivX for encoding MPEG-4 ASP video, that is right. But "Avidemux does not support DivX" is not correct!
Videos encoded by DivX are in the MPEG-4 ASP format and Avidemux does support the MPEG-4 ASP video format very well.
And yes, Avidemux uses Xvid to encode MPEG-4 ASP video. But Xvid is not behind DivX quality-wise, although some people still say so :rolleyes:
You may prefer DivX over Xvid personally, but that's it...

[Irakli]

Avidemux does not use DivX for encoding MPEG-4 ASP video, that is right. But "Avidemux does not support DivX" is not correct!
Videos encoded by DivX are in the MPEG-4 ASP format and Avidemux does support the MPEG-4 ASP video format very well.
And yes, Avidemux uses Xvid to encode MPEG-4 ASP video. But Xvid is not behind DivX quality-wise, although some people still say so :rolleyes:
You may prefer DivX over Xvid personally, but that's it...

Oh, yes, I meant that AviDemux cannot use DivX for ASP encoding. I will try to express my thoughts more clearly next time.

I use XviD for encoding, because DivX gives me too much headache due to its poor support for custom quant matrixes.