DeathTheSheep United: x264 Guide and VfW Builds

[Dark Shikari]

Originally Posted by MasterNobody

There is no need in this because compiled binaries would be identical except dates (at least my builds that I make for Win32 with gcc 3.4.5 (mingw special) were).

My point was that r745 may crash. Therefore, one should avoid using anything before this diff but after my SSE2 intra pred commit patch.

[MasterNobody]

Dark Shikari
Today I test them at work (my home PC doesn't support SSE2) and they really crash. But the problem is that latest version from git also crashes. I think it is the problem with compiler. I try to compile with GCC 3.4.5 (mingw special) and GCC 4.2.1-sjlj (mingw32-2) and both crash (x264.exe compiled with 4.2.1-sjlj doesn't crash but codec crash). So now I am searching for new GCC compiler for MinGW (binaries, not sources) which will compile it correctly.

[clsid]

See this topic for a binary of GCC 4.2.3 for mingw:
http://forum.doom9.org/showthread.php?t=108215


GCC 4.2.x has a special attribute for forcing alignment of function arguments:
__attribute__((force_align_arg_pointer))

I dunno if that is useful for the case you guys are talking about. Just FYI.

[Mr VacBob]

If it crashes in predict_8x8_ddl_ssse3 (or something like that), you need a new yasm. gcc is probably fine.

[MasterNobody]

Versions 7_747bm_12304 and 7_747bm_AQ_0.48_12304 of x264vfw
Changes:
- x264 core updated to svn-747 (in fact git-HEAD)
- ffh264 core updated to revision 12304
- GCC updated to 4.2.3 (TDM-1 for MinGW)
- Fixed crash on PC's with SSE2 support

[Gromozeka]

BugMaster
8_757bm_12490[/b] и 8_757bm_AQ_0.48_12490 in x264vfw

Changes:
x264 core updated to revision 757 (git-4d9499b)
ffh264 core updated to revision 12490
Minor changes

[MasterNobody]

9_763bm_12490 and 9_763bm_AQ_0.48_12490 of x264vfw

Changes:
- x264 core updated to revision 763 (git-0949975)
- Increased compatibility with some buggy applications (nsvate/nsvcap)

[jult]

Originally Posted by Sharktooth

However latest revisions of x264CLI are more powerfull (new options, more output formats, avisynth support, etc.) and even new GUIs appeared (look above) so encoding with CLI is easier and results may be better than VFW.

This sentence on this forum causes a lot of misunderstandings about versions of x264vfw. You should change the way this is put. I mean really, the delay for vfw is minimal, if it is there at all. "may be better" is nonsense.

x264vfw is alive and well: http://sourceforge.net/projects/x264vfw/

[Sharktooth]

Please stop posting or commenting on this thread. VFW is NONSENSE since there's no longer OFFICIAL support.
And FYI, yes, x264 CLI produces higher quality encodes than VFW, since AVI is an unoptimal container that doesnt even support h.264 and has a lot of overhead.

[MasterNobody]

Originally Posted by Sharktooth

Please stop posting or commenting on this thread. VFW is NONSENSE since there's no longer OFFICIAL support.
And FYI, yes, x264 CLI produces higher quality encodes than VFW, since AVI is an unoptimal container that doesnt even support h.264 and has a lot of overhead.

Sorry, but I would disagree with you. Yes, it is not supported by x264 developers team, but this doesn't mean that it is unsupported at all (At least for now it is supported my me [official admin of x264vfw project]. Why you couldn't call this OFFICIAL support? And what is the meaning of OFFICIAL support for you?). About higher quality I also disagree because VfW version generates the same bitstream as CLI version and the overhead is not the quality characteristic (Also who say about AVI? You may use VfW encoder and mux the bitstream in matroska). The only real disadvantage of VfW is problems with encoder delay due to B-frames and mutithreading, which couldn't be fixed without hacks (agreements between codec and encoding application, such as used in VirtualDub for fixing this problem).

[Dark Shikari]

Originally Posted by MasterNobody

And what is the meaning of OFFICIAL support for you?

If it isn't supported by one of the main developers (currently Loren Merritt and me) or someone tasked with the job of supporting it by one of the main developers, the support isn't "official."

[Inventive Software]

Let VFW die already, and stop building and breaking the new optimisations that DS brings. CLI is the new VFW, especially since x264 has native AVS support.

[MasterNobody]

Originally Posted by Dark Shikari

If it isn't supported by one of the main developers (currently Loren Merritt and me) or someone tasked with the job of supporting it by one of the main developers, the support isn't "official."

But if we would use such logic than such applications as AviDemux (and other GUIs that use x264 library) also don't have "official" support but this doesn't mean that this applications are bad and there use is NONSENSE.

Originally Posted by Inventive Software

Let VFW die already, and stop building and breaking the new optimisations that DS brings.

I don't understand how VFW breaking the new optimizations that DS brings? All his optimizations also exist in my VFW-version. Or you mean by DS not Dark Shikari but DirectShow?

[Dark Shikari]

Originally Posted by MasterNobody

But if we would use such logic than such applications as AviDemux (and other GUIs that use x264 library) also don't have "official" support but this doesn't mean that this applications are bad and there use is NONSENSE.

You are connecting two unrelated concepts here. "Not official" means that its a third-party application, and we aren't responsible for any of it. That doesn't make it inherently bad; it just means that we are not going to help you with it because it isn't our responsibility; its the responsibility of the people who maintain it.

[Gromozeka]

x264 vfw forever
x264 vfw work with graphstudio (http://forum.doom9.org/showthread.php?t=133928&page=6) andh264 stream can put in mkv with ogg and aac, but cli version can not work with graph (directshow), with other video programs and must have avisynth

[MasterNobody]

Originally Posted by Dark Shikari

You are connecting two unrelated concepts here. "Not official" means that its a third-party application, and we aren't responsible for any of it. That doesn't make it inherently bad; it just means that we are not going to help you with it because it isn't our responsibility; its the responsibility of the people who maintain it.

I understand this (and my post want show that x264 and x264vfw is separate projects which has different developers, and so saying that it not supported by one team doesn't mean it is not supported by another). But the first who connect them here is Sharktooth by

Originally Posted by Sharktooth

VFW is NONSENSE since there's no longer OFFICIAL support.

[ChronoCross]

Originally Posted by MasterNobody

I understand this (and my post want show that x264 and x264vfw is separate projects which has different developers, and so saying that it not supported by one team doesn't mean it is not supported by another). But the first who connect them here is Sharktooth by

Anything that requires workarounds to use the x264 library shouldn't be encouraged. I'd be immensely happy if they could find a way to make it so that x264 in vfw is impossible.

honestly if your using x264vfw in your project name it's deceiving to the general public. If you really want to be considered your own project you should change it to h264vfw, or AVCvfw. That would prevent vfw users from thinking that it's something that is officially supported by the real developers of x264.

x264 vfw forever
x264 vfw work with graphstudio (http://forum.doom9.org/showthread.php?t=133928&page=6) andh264 stream can put in mkv with ogg and aac, but cli version can not work with graph (directshow), with other video programs and must have avisynth

How about learning good tools rather than muxing something using a graph. To say that vfw is better because you can add ogg and aac using something that is not needed (as mkvtoolnix supports EVERY format that mkv does and is much easier I might add) is rather stupid and not a real reason to say that vfw is good. Graphedit is only useful for discovering decoder pins as there are much better tools for muxing.

But if you enjoy doing things the hard way then more power to you.

[GodofaGap]

Originally Posted by ChronoCross

Anything that requires workarounds to use the x264 library shouldn't be encouraged. I'd be immensely happy if they could find a way to make it so that x264 in vfw is impossible.

You'd be happy to take away freedom from people?

honestly if your using x264vfw in your project name it's deceiving to the general public. If you really want to be considered your own project you should change it to h264vfw, or AVCvfw. That would prevent vfw users from thinking that it's something that is officially supported by the real developers of x264.

It's not deceiving. It's a VFW front-end for the x264 encoder. It is exactly what it says.

[Shinigami-Sama]

Originally Posted by GodofaGap

You'd be happy to take away freedom from people?


It's not deceiving. It's a VFW front-end for the x264 encoder. It is exactly what it says.

you're missing the point the REAL x264 doesn't want their name to be sullied by a non-official project that no sane person would use

[GodofaGap]

Originally Posted by Shinigami-Sama

you're missing the point the REAL x264 doesn't want their name to be sullied by a non-official project that no sane person would use

What they want is completely irrelevant. If they don't want their code to be re-used they should not use the current license.