ffdshow tryouts project: Discussion & Development

[LoRd_MuldeR]

Just make a diff and you will see the diferenced from x264 and ff_x264. Also for latest ff_x264 you need to compile ffdshow.ax. I'll test later if I have time. Thanks!

Do you want me to make a diff between the the binaries or the sources?

I can tell you that the latest working libx264.dll that shipped with Avidemux was 438 KB in size, while the latest ff_x264.dll from ffdshow-tryouts is 707 KB in size :confused:

[_xxl]

I have compiled latest ff_x264. Tested with winxp and Amd XP and X2, both work fine. SSE2 is disabled, because MinGW or MSVC can't properly compile x264. Libavcodec had that same issue, but we added some custom code that fixed that crash. Libmpeg2 when SSE2 is used it crashes, so I disabled it.

[Dark Shikari]

I have compiled latest ff_x264. Tested with winxp and Amd XP and X2, both work fine. SSE2 is disabled, because MinGW or MSVC can't properly compile x264. Libavcodec had that same issue, but we added some custom code that fixed that crash. Libmpeg2 when SSE2 is used it crashes, so I disabled it.Why not just disable the specific problematic functions that your compiler can't handle? Slashing overall performance by 20-40% on a wide variety of popular CPUs is not exactly a good method of solving the problem...

[_xxl]

I know, but safety comes before speed.

[clsid]

Can't the problem be solved for MinGW GCC by adding the appropriate alignment attributes (from GCC 4.2+) to the crashing functions? Supporting MSVC is not important.
How do the regular x264 builds for Windows handle this problem?

[Dark Shikari]

How do the regular x264 builds for Windows handle this problem?There is no such problem in the regular builds; they work on everything from GCC 2.95 all the way up to 4.4 with no issues (as far as I've heard). This is why I have always suspected there must be some user error going on here because I have never seen any of these problems in any of the following:

1. Windows 32-bit executables
2. *nix 32-bit executables
3. *nix 64-bit executables
4. *nix 32-bit libraries, without PIC
5. *nix 32-bit libraries, with PIC
4. *nix 64-bit libraries, without PIC
5. *nix 64-bit libraries, with PIC

[_xxl]

Fix crash on PC's with SSE2 support from x264 vfw
http://x264vfw.svn.sourceforge.net/viewvc/x264vfw/trunk/codec.c?r1=7&r2=6&pathrev=7
or from ffdshow's libavcodec encoder:
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/trunk/src/ffmpeg/libavcodec/dsputil.c?r1=1214&r2=1213&pathrev=1214

[clsid]

That's libavcodec. But x264 isn't part of that. So similar fix should be added to TvideoCodecX264.cpp. Although that normally gets compiled with MSVC, so some kind of wrapper might be needed.

Are there many people (percentage wise) that encode with ffdshow? I vote for completely removing encoding support from ffdshow.

[_xxl]

I vote for completely removing encoding support from ffdshow.
All encoding support, ffdshow only for decoding?
Vfw is anyway outdated.

@clsid start a new svn branch with no encoding support?

[Dark Shikari]

All encoding support, ffdshow only for decoding?
Vfw is anyway outdated.

@clsid start a new svn branch with no encoding support?I would disagree; I find FFDshow's VfW encoders extremely useful; not the ones like x264, but rather the ones like FFVHUFF or FFV1, for which otherwise there is no VfW or DirectShow encoding interface.

[clsid]

There also is a DirectShow version of the encoder in ffdshow. I suggested removing encoding in the past, mainly since it is old, a bit buggy, and not maintained. There are plenty of alternatives for it imho. But there were a few people against it because they still used it. But on the other hand, those that wish to use this 'outdated' functionality can always stick to current/past versions.

I am curious as to how many people use it. Having a poll would probably not give a realistic representation though.

How do FFVHUFF and FFV1 compare to HuffYUV (for which a standalone codec exists)?

[LoRd_MuldeR]

Why kill the entire encoding support, just because one of the encoders currently has a problem?
You can simply disable the problematic decoder until the bug has been fixed. This way people can still use the working encoders :)

Also if x264 cannot be compiled as a DLL anymore, this is a serious problem! It would exclude all applications that use libx264.dll from future updates :(

[Shinigami-Sama]

I've used it about 4 times
mostly just to play with it

maybe just cut out the encoding part and leave it as a separate part of the project so anyone that wants to use it or fix it can?

then again I guess they could do that with the old version's source as well..

[Dark Shikari]

How do FFVHUFF and FFV1 compare to HuffYUV (for which a standalone codec exists)?FFVHUFF is both faster and better compression than HuffYUV, plus it has YV12 support.

FFV1 has no standalone comparable codec; while slower than Lagarith or HuffYUV it completely smokes them in compression ratio.

There are other useful codecs there too, such as MJPEG. VfW isn't inherently evil, especially with intra-frame-only codecs...

[clsid]

Why kill the entire encoding support, just because one of the encoders currently has a problem?That was never the reason for the suggestion. Everything currently works, with SSE2 disabled. The idea was to remove stuff that nobody uses or should use (because of better alternatives). But Dark Shikari has given some strong arguments for just keeping things the way they are :)

Although, in the case of H.264 encoding, there are plenty of alternatives for ffdshow.

Having SSE2 disabled for libmpeg2 is bad. So if no solution can be found for that, I suggest reverting to the older fully working code.

[Dark Shikari]

That was never the reason for the suggestion. Everything currently works, with SSE2 disabled. The idea was to remove stuff that nobody uses or should use (because of better alternatives). But Dark Shikari has given some strong arguments for just keeping things the way they are :)I would agree with removing x264 though, because it would be a great way to encourage people to stop using x264-in-AVI... :p

[_xxl]

First we should try to fix that bug and if no other solution is found remove encoders support.

[_xxl]

Having SSE2 disabled for libmpeg2 is bad. So if no solution can be found for that, I suggest reverting to the older fully working code.
That wasn't fully working:
1. No MinGW GCC with SSE2 support.
2. No x64 just plain C and couldn't be compiled by MinGW 64.
3. Wasn't updated to latest.

[Episode]

Ooh, almost 2000 revisions already. Keep up the good work guys!

[obieobieobie]

By any chance do you use Haali Media Splitter or ffdshow it's direct connected ?

Yes, I use haali but only for MKV and MP4, so when in WMP11, the file is played back using the default AVI splitter, VMR9 renderer and ffdshow decoder and ac3filter for the audio.

[georgevalkov]

My vote is to keep the encoding capabilities in ffdshow, and also to keep the H264 encoder. If the developers are too busy to update it, leave as it is or disable SSE2 for it, perhaps make it configurable if possible? but please don't remove it!


First we should try to fix that bug and if no other solution is found remove encoders support.

@_xxl
Count me on the test team. I'll help You with whatever I can to keep this feature. I have Visual Studio 2008 and WinDBG in hand. You can find me on this address:
the(underscore)boss(underscore)gfc(at)m s n(dot)com


I would agree with removing x264 though, because it would be a great way to encourage people to stop using x264-in-AVI... :p

@Dark Shikari
Please have a look at the attached images! The H264 stream encoded by ffdshow has two major ways to get a compatible container.
1. First is to connect ffdshow filter's output pin to another DirectShow filter like Haali Matroska Muxer that will add a compatible container MKV or MP4. Any DirectShow application encoding to MP4 or MKV can take advantage of this.
2. The second is to output the frames to a RAW stream file.264 and then add a compatible container for it. This can be done by MP4box.exe; mkvmerge.exe; meGUI or another tool.

I have been using both of the ways for a long time; encoded hundreds of H264/MP4 files, most of which by the second method, because I like using VirtualDubMod.

My capture program records in MPEG-2 format. I do understand that I can also use avisynth script+meGUI+x264.exe. Here are the cons: The MPEG-2 file has to be indexed first. After avisynth, every frame is a key-frame, the application (meGUI) will not be able to fast seek to the original key-frames. Decoding the mid-frames is extremely slow. So if I need to cut the advertising, I will waste a lot of time in seeking. After that the life is good. x264.exe will produce a bit smaller files than ffdshow, but will consume more CPU time.

This is why I use VirtualDubMod+ffdshow+MP4 container. And the dummy AVI that is created (is full of dropped frames when the output pin is disabled), well that's just a dummy AVI, so I delete it.

Another advantage of ffdshow is the built-in filtering. I can attach ffdshow filtering on the playback chain; then configure the desired filtering for the source file during a live playback. Finally copy the filtering configuration to the encoder's filtering page. This makes ffdshow the most powerful encoder. This makes it the desired encoder for many people. On the other hand, the logical choice for video format is H264, because it produces the best compression and high quality picture.

On my computer there are only Haali Matroska Splitter and ffdshow. No other codecs. I can play any format in any file and I can encode to any format I wish. MPEG-2 to H264/MP4 transcoding with filtering in a single pass. Its is the best all in one solution. Please don't remove this functions!



[Shell Extensions for RAW H264 steam files :: adds MP4 container]
264.reg.txt
1. Edit the text file to fix the path to MP4box.exe
2. rename to .reg (registry file) and add to the registry.

[Shell Extensions for RAW audio steam files :: encodes to AAC in MP4 container]
raw.reg.txt
1. Edit the text file to fix the path to faac.exe
2. rename to .reg (registry file) and add to the registry.

:thanks: Thanks for taking time to read my long posting! I understand that ffdshow consumes a large piece from Your time. That's simply because it is a great project. :)
George Valkov

[Mercury_22]

Yes, I use haali but only for MKV and MP4, so when in WMP11, the file is played back using the default AVI splitter, VMR9 renderer and ffdshow decoder and ac3filter for the audio.

I wasn't talking about VMR9, which it's working for me too
I can't play this mpeg4 (DX50) (http://www.dump.ro/download.php?file=Testmpeg4.avi&id=MzBmNzhiNzhlYjZiOGQ3ZGU5OGJiZjkzODMxMTk2MmI=&download=true) (OR Try this server (http://rapidshare.com/files/121074851/Mpeg4Test.avi.html)) ........it's working only with VMR9 !
Any idea what's wrong ? :helpful:

My OS Vista Ultimate x64 SP1

Let's say I wasn't clear so once again : VMR9 it's working, EVR it's NOT working with ffdshow but EVR it's working with DivX for the above file !

Clear now ? Can you test this please ? :thanks:

[LoRd_MuldeR]

My vote is to keep the encoding capabilities in ffdshow, and also to keep the H264 encoder. If the developers are too busy to update it, leave as it is or disable SSE2 for it, perhaps make it configurable if possible? but please don't remove it!

That's my position too. Better have an outdated/limited feature that might be updated at a later time than not having that feature at all.

Also it seems the SSE2 problem for the DLL has been found and a fix has been suggested:
http://forum.doom9.org/showpost.php?p=1148167&postcount=10

As far as I understand, the problem was that code outside of the DLL does not align the stack to 16...

[CiNcH]

Hey guys,

does anybody have the input format ffdshow expects in case of H.264 and VC-1? If you feed it with VC-1 and/or H.264 Elementary Stream, ffdshow outputs some weird colors and may crash.
Haali seems to serve ffdshow right by adding some special header.

Here is what RadScorpion said about it:

00 00 00 01 are special start codes that are used under the
ISO/IEC 14496-10 - Annex B (AVC/H.264) standard in several
situations like PES packet transmission. After the start code a single
NAL unit follows. The size of the NAL unit is then the difference
between two successive start codes.

MP4/AVC files use different way of storing the
NAL units. There is an avcC box that tells e.g. how many bytes
are used to signal NAL unit size. MP4 also does not
store SPS and PPS in the data itself but stores them separately.

[_xxl]

Also it seems the SSE2 problem for the DLL has been found and a fix has been suggested:
http://forum.doom9.org/showpost.php?...7&postcount=10
As far as I understand, the problem was that code outside of the DLL does not align the stack to 16...

I work to fix it, for libmpeg2 seems to work but more testing is required.
X264 still crashes, ffdshow is compiled by MSVC not GCC, so that fix can't be used outside x264.

[LoRd_MuldeR]

X264 still crashes, ffdshow is compiled by MSVC not GCC, so that fix can't be used outside x264.

Maybe a wrapper can be used?

[georgevalkov]

@CiNcH
This is what graphedit indicates on the property pages.
I am on my first steps in DirectShow programming, so my answer may not be correct, but I think that the source filter has to set this parameters in the Major Type+Sub Type+(maybe also Format), so that ffdshow knows that it should use the H264 decoder. If it tries to use another decoder, it is pretty normal to crush, since the decoder is fed with invalid data.

Major Type: Video

Sub Type:
{31435641-0000-0010-8000-00AA00389B71}
Format: avc1 704x576, 24 bits,
Aspect Ratio: 4x3
Interlace format: Frames
rcSrc=(0,0,0,0)
rcDst=(0,0,0,0)
CtrlFlags=00000000
^ The source filter is Haali Matroska splitter; H264 stream in MP4 container; video is PAL 704x576 25 fps interlaced.



@Mercury_22

Let's say I wasn't clear so once again : VMR9 it's working, EVR it's NOT working with ffdshow but EVR it's working with DivX for the above file !

Clear now ? Can you test this please ? :thanks:

I made a few tests for You. Results:
Plays with any of this renders: [EVR; VMR9; Default Video Render (overlay); Default Video Render (GDI); Haali Video Renderer]
I used revision 1971, May 23 2008, icl 10, x86, unicode, clsid
on Windows 2003 Server x86 with SP2 and .NET framework 3.5. I think that EVR on Win2003 came with this version of .NET. For Vista you don't need to install the .NET framework. I don't have a 64 bit machine to test it. I don't have DivX or any other codecs, because ffdshow alone is pretty much enough to decode anything.

PS: just to add a proof that it works, see the two screen-shots:
Jack-and-Jill-sample-EVR-render.png (http://www.mediafire.com/?tlwmrjmjdc3)
Jack-and-Jill-sample-info.png (http://www.mediafire.com/?dmgzx8qmdut)

[Mercury_22]

@CiNcH
This is what graphedit indicates on the property pages.
I am on my first steps in DirectShow programming, so my answer may not be correct, but I think that the source filter has to set this parameters in the Major Type+Sub Type+(maybe also Format), so that ffdshow knows that it should use the H264 decoder. If it tries to use another decoder, it is pretty normal to crush, since the decoder is fed with invalid data.

Major Type: Video

Sub Type:
{31435641-0000-0010-8000-00AA00389B71}
Format: avc1 704x576, 24 bits,
Aspect Ratio: 4x3
Interlace format: Frames
rcSrc=(0,0,0,0)
rcDst=(0,0,0,0)
CtrlFlags=00000000
^ The source filter is Haali Matroska splitter; H264 stream in MP4 container; video is PAL 704x576 25 fps interlaced.



@Mercury_22


I made a few tests for You. Results:
Plays with any of this renders: [EVR; VMR9; Default Video Render (overlay); Default Video Render (GDI); Haali Video Renderer]
I used revision 1971, May 23 2008, icl 10, x86, unicode, clsid
on Windows 2003 Server x86 with SP2 and .NET framework 3.5. I think that EVR on Win2003 came with this version of .NET. For Vista you don't need to install the .NET framework. I don't have a 64 bit machine to test it. I don't have DivX or any other codecs, because ffdshow alone is pretty much enough to decode anything.

PS: just to add a proof that it works, see the two screen-shots:
Jack-and-Jill-sample-EVR-render.png (http://www.mediafire.com/?tlwmrjmjdc3)
Jack-and-Jill-sample-info.png (http://www.mediafire.com/?dmgzx8qmdut)

A big Thanks :thanks: but for me it's not working -> must be my Video Intel G35 :(

[clsid]

A new build (rev. 2000) is now available at the sourceforge project page. The recent issues with libmpeg2/x264 updates should be pretty much resolved now, I hope.

Everyone please test the following:
* MPEG-2 decoding with libmpeg2, specially if performance is on par with older builds.
* Theora decoding, idem for performance.
* Theora encoding.
* x264 encoding.

If all is well, then a new beta will is likely to be released sometime at the end of the month.

[LoRd_MuldeR]

A new build (rev. 2000) is now available at the sourceforge project page. The recent issues with libmpeg2/x264 updates should be pretty much resolved now, I hope.

I'd like to test that file, but apparently none of the SourceForge mirrors can provide it :confused:


[EDIT]

Never mind, works now.

Everyone please test the following:
* MPEG-2 decoding with libmpeg2, specially if performance is on par with older builds.
* Theora decoding, idem for performance.
* Theora encoding.
* x264 encoding.

Yes, they all work fine here on my SSE2 capable processor :)

[_xxl]

Everyone please test the following:
* MPEG-2 decoding with libmpeg2, specially if performance is on par with older builds.
* Theora decoding, idem for performance.
* Theora encoding.
* x264 encoding.

Libmpeg2 will have SSE2 mc added soon.
Theora, libmpeg2 and x264 should only be compiled by MinGW GCC 4.2.x.

[georgevalkov]

A new build (rev. 2000) is now available at the sourceforge project page. The recent issues with libmpeg2/x264 updates should be pretty much resolved now, I hope.

Everyone please test the following:
* MPEG-2 decoding with libmpeg2, specially if performance is on par with older builds.
* Theora decoding, idem for performance.
* Theora encoding.
* x264 encoding.

If all is well, then a new beta will is likely to be released sometime at the end of the month.


PC1:AMD 32-bit [SSE:yes] [SSE2:no ] Athlon XP 1700+ overclocked to 1.89 GHz
results on PC1 are measured by process explorer and are accurate.
timing relays on CPU:total time.

PC2:AMD 64-bit [SSE:yes] [SSE2:yes] Sempron 3100+
PC2 was in use during this benchmarks; timing results may not be accurate;
timing relays on the log from VirtualDubMod.jobs file [end time - start time]

[MPEG-2 progressive file playback: PAL 720x576, 20 Mbit/s, length: 265 s]
s. ms
86.406 PC1 ffdshow-rev1971_20080523_clsid_sse_icl10, YV12 [faster]
88.171 PC1 ffdshow_rev2000_20080612_clsid, YV12
117.812 PC1 ffdshow-rev1971_20080523_clsid_sse_icl10, YUY2 [faster]
118.828 PC1 ffdshow_rev2000_20080612_clsid, YUY2
N/A PC2 is remote

[Theora progressive file playback: PAL 704x576, length: 60 s, PC1-2000-theora.avi]
s. ms
34.812 PC1 ffdshow-rev1971_20080523_clsid_sse_icl10, YV12 [faster]
33.296 PC1 ffdshow_rev2000_20080612_clsid, YV12
41.484 PC1 ffdshow-rev1971_20080523_clsid_sse_icl10, YUY2 [faster]
40.359 PC1 ffdshow_rev2000_20080612_clsid, YUY2
N/A PC2 is remote


[VirtualDubMod encode 1500 frames (1 minute) PAL 720x576 to 704x576 H264,
crop 16px from right to 704x576; one pass - quality 52; force RGB24]
s. ms
232.000 PC1 ffdshow-rev1971_20080523_clsid_sse_icl10
result.264: 17 804 575 bytes
228.625 PC1 ffdshow_rev2000_20080612_clsid
result.264: 17 481 900 bytes [best compression; faster]
363.078 PC2 ffdshow_rev2000_20080612_clsid, computer is in use!
result.264: 17 633 037 bytes
245.594 PC2 ffdshow_rev1975_20080526_x64_xxl, computer is in use!
result.264: 17 947 672 bytes

[VirtualDubMod encode 1500 frames (1 minute) PAL 720x576 to 704x576 Theora,
crop 16px from right to 704x576; one pass - quality 52; force RGB24]
s. ms
165.781 PC1 ffdshow-rev1971_20080523_clsid_sse_icl10
result.avi: 22 530 048 bytes [faster]
187.375 PC1 ffdshow_rev2000_20080612_clsid
result.avi: 21 864 448 bytes
N/A PC2 ffdshow_rev2000_20080612_clsid, computer is heavy use! /gaming/
result.avi: 21 895 168 bytes [best compression]
N/A PC2 ffdshow_rev1975_20080526_x64_xxl, computer is in use!
result.avi: 21 895 168 bytes [best compression]

[Liisachan]

wow the millenium build :cool: ~ ffdshow_rev2000_20080612_clsid.exe

[clsid]

Summarizing georgevalkov results:
MPEG-2/Theora decoding performance is pretty similar. Small differences might be due to ICL10 vs Normal build.
Theora is slower. That is probably due to algorithmic changes, since output sizes are also different.
x264 is faster. That is likely due to code improvements.

So altogether it is good news.

[leeperry]

is there any filter in ffdshow than can improve the motion blur ?
or should I mess around with AVS scripts again ? :D

the LSF avs script looks so good, I'm really impressed :eek:

[Episode]

@clsid, could you please compile icl10 version of rev 2000?

[Momber]

Hi!

I'm having a problem with bass management in the ffdshow audio decoder.

When enabling "LFE Crossover", all audio that is already present in the discreet LFE channel of a DD5.1 ac3 signal is muted. Hence the ".1 channel" is completely lost!
Correct would be to maintain the LFE signal and simply add the bass from the other 5 channels to it.

I'm using a standard 5.1 setup (3/0/2 + LFE) and have been able to reproduce this flaw using rev1971_20080523_clsid_sse_icl10 and rev1990_20080608_xxl.

Should I try a different build?
Is this a known problem or should I open a bug tracker for it?

Thanks,
S.

[iron2000]

Wow ffdshow-tryouts now breaking into 2000, feels like some big achievement to me.
Good job guys!

[MythCreator]

Just a question: How to compile it by use VS2008 under Windows Server 2008?

[Px]

I vote for completely removing encoding support from ffdshow.
I disagree, I've using ffvfw huffyuv for compressing raw video before processing in vurtualdubmod. Space saving in compare to single huffyuv is near 10 Gigs on 60 GB file....

[leeperry]

is there a way to convert BT.709 to 601 in ffdshow ? so I can output YUY2 to HR ? its BT709 coeffs are screwed up :(

I've tried the "picture properties" filter but it's not accurate enough.

and I'm still getting the frame rate randomly in Reclock when the Avisynth section of ffdshow is enabled.

sometimes Reclock says "no video stream found", I close the video/open it again and it's fine

if I disable the Avisynth script in ffdshow, it never happens.

[georgevalkov]

Yesterday I had desktop assess to the AMD64/XP64+SP1 computer so I made a few tests.

H264 encoding of a football match (length 1h38m), using VirtualDubMod (32 bit) and ffdshow_rev2004_20080613_clsid_sse_icl10 (32 bit) went okay.
I noticed that when encoding a football match in one pass quality mode, the AQ Strength should be set to 100. That way most of the details on the grass terrain are preserved and the file size is 20% smaller compared to the default value for AQ Strength=30, where most of the terrain's details are lost.


Then I installed the 64 bit version of VirtualDub 1.8 + ffdshow 64 bit (I tried both versions):
ffdshow_rev1975_20080526_x64 :: by _xxl
ffdshow_rev1975_20080525_clsid_x64
both don't have VFW component. Otherwise the ffvdub VirtualDub filter is in the list and I can add and configure it, I didn't test it though, because I wasn't prepared.

Then I installed the 64 bit versions of graphedt64.exe:
I was able to add ffdshow's DirectShow encoder to the graph; I noticed that some of the encoders are not available in the 64 bit build, including the H264. All the other (ffdshow filters Video and Audio decoders and procesors) returned an error and cannot be added to the graph:
The filter could not be created. Resources used by this filter may already be in use.
No such interface supported (Return code: 0x80004002)
(see the screen-shot:ffdshow64_rev1975 DS-filters not working.png) (http://www.mediafire.com/?uocngaiy0uw)

Anyway I don't care much for the 64 bit version. The most important thing is that the current 32 bit version is fixed and can encode H264 on processors that support SSE2.

[Momber]

The LFE Crossover bug is also present in rev. 2004 icl BTW. Just tried it.

[clsid]

The older 64-bit versions didn't include x264. Next build will have it.

Edit: found bug in installer that broke VFW on x64, now fixed.

[Dark Shikari]

The older 64-bit versions didn't include x264. Next build will have it.How? x264 doesn't support Windows 64-bit.

[clsid]

I thought that xxl somehow managed to make it compile on x64 at some point, but I may be wrong. Current revision doesn't compile.

[Dark Shikari]

I thought that xxl somehow managed to make it compile on x64 at some point, but I may be wrong. Current revision doesn't compile.x264 hasn't worked on 64-bit since sometime in 2005 (if ever), and even then it was probably just incidental.

You can get it working on 64-bit now if you munge a few of the #defines and completely disable all assembly optimizations :p

[LoRd_MuldeR]

Why does the assembler code in x264 depend on a specific OS? Since assembler code uses CPU instructions it's specific to a certain CPU architecture, that's for sure. But where does the OS interfere with the assembler code? As long as the assembler code runs on a suitable CPU it shouldn't have to care about the OS. Well, except for system calls maybe. So what is the difference between Win64 and Linux64 that makes x264 not work? And is there a chance it will ever be fixed? (and no, I'm currently not willing to pay akupenguin for that ^^ I just want to understand...)

[Dark Shikari]

Why does the assembler code in x264 depend on a specific OS? Since assembler code uses CPU instructions it's specific to a certain CPU architecture, that's for sure. But where does the OS interfere with the assembler code? As long as the assembler code runs on a suitable CPU it shouldn't have to care about the OS. Well, except for system calls maybe. So what is the difference between Win64 and Linux64 that makes x264 not work? And is there a chance it will ever be fixed? (and no, I'm currently not willing to pay akupenguin for that ^^ I just want to understand...)Because every operating system except Windows uses a certain 64-bit calling convention... while Windows uses a totally different one. And Akupenguin doesn't want to maintain the Windows 64-bit version of the calling code.

Fortunately, making it work on Windows 64-bit is much easier than with most programs because of x264's calling convention abstraction code, but it still requires someone with detailed knowledge of assembly and the Windows calling convention, along with a few hours spent poring over the current code and adding %ifdefs in some corner cases.

[Px]

Maybe because it's not assembler code, but intrinsic functions...