FFMS2 (The Fabulous FM Source 2)

[Chikuzen]

ok, I tested.

avisynth version : 2.60 official alpha3 and SEt MT(2011-07-19)

script:
LoadCPlugin("ffms2_new_csp_support.dll")
Import("ffms2.avsi")
FFMPEGSource2("input.xxx", atrack=-1)
#SWScale(colorspace="YV24")
#SWScale(colorspace="YV16")
#SWScale(colorspace="YV411")
#SWScale(colorspace="Y8")
Info()

results:
FFV1(YUV444p)+MP3.avi --- FINE(output csp is YV24)
FFV1(YUV422p)+MP3.avi --- FINE(output csp is YV16)
FFV1(YUV411p)+MP3.avi --- FINE(output csp is YV411)
H.264(4:4:4)+aac.mp4 --- FINE(output csp is YV24)

colorspace conversion --- ALL FINE

Great work

[Chikuzen]

second report

avisynth version : official 2.58

script:
same as first report

results:
FFV1(YUV444p)+MP3.avi --- FINE(output csp is YV12)
FFV1(YUV422p)+MP3.avi --- FINE(output csp is YUY2)
FFV1(YUV411p)+MP3.avi --- FINE(output csp is YUY2)
H.264(4:4:4)+aac.mp4 --- FINE(output csp is YV12)

colorspace conversion --- ALL FINE(error message "Invalid colorspace specified")

[ophiuchus18]

The so called ffmpegsource-2.15_src.7z from dev site is outdated trash (v2.13.1?)

Description:    Source code for FFmpegSource 2.15.
SHA1 Checksum:     176725473a883b0bb807986b4b397e2eded69cc5 What's this?

ffmpegsource-2.15_src.7z   308 KB

It's impossible to compile and build this source pack because
the actual ffmpeg pack don't have such file as libavutil/sha1.h
(there is only libavutil/sha.h in the actual ffmpeg pack)

Code: [Select]

################################################################################
cd C:/ffmpegsource-2.15_src
./configure
-----------
# ffms2.pc.  Generated from ffms2.pc.in by configure.

prefix=/usr/local
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: ffms2
Description: The Fabulous FM Library 2
Requires: libavformat libavcodec libswscale libpostproc libavutil
Version: 2.13.1
Libs: -L${libdir} -lffms2  -lz
Cflags: -I${includedir}

################################################################################
make
----

$ make
  CXX   src/core/indexing.o
src/core/indexing.cpp:30:28: fatal error: libavutil/sha1.h: No such file or dire
ctory
compilation terminated.
make: *** [src/core/indexing.lo] Error 1

################################################################################

I tried also to compile the svn.ffms2.15.Revision509.src. The same problem:
compilation conflict between:
\src\core\indexing.cpp (svn.ffms2.15.Revision509.src)
and
\libavutil\sha.h (Version: 51.11.0)

What outdated ffmpeg libavutil use this "Fabulous" site (with the toilet paper logo  ) to compile ffms2.15.Revision509.src?

P,.S.- I know my reply is not at the subject but here is the only maintained topic about "The Fabulous FM Source 2" and the developers linked this topic to their site.

[Myrsloik]

Look for when FFmpeg renamed sha1.h to sha.h. That's the answer to your question. Or just use the source from svn which has been updated for that change.

[kemuri-_9]

How to determine that the output is properly being handled?

good question!

Code: [Select]

LoadCPlugin()
FFVideoSource()
Info()

is probably the most reliable as it'll indicate the csp that avisynth sees it before the other utilities detect/interpret it.
e.g. all the new 2.6 colorspaces are actually detected as YV12 with the 2.5 interface (i mean when using the actual avisynth interface directly, and not when using the vfw interface).

I'd guess it wouldn't really matter what compression format the loaded files use, so long as it's in one of the desired colorspaces?  Uncompressed is as good as any other format is, or would different formats need specific testing?

correct, the compression format does not particularly matter - the csps themselves matter.
uncompressed would work, granted i had the ability to remember whether ffms2 supports them or not... so i guess they'll either A) work correctly, B) throw an error, or C) crash?

some things to make sure that are checked are
* specifying the output csp with ffvideosource should output as that csp
* not specifying the output csp with ffvideosource should have it pick the most compatible option - e.g. in 2.5, YV16 should go to YUY2 by default, YV24 similarly isn't YV24; in 2.6 they should be exactly YV16 and YV24
* SWScale works for both accepting and outputting the new csps when using 2.6; giving an error instead when using 2.5 and trying to use a 2.6 csp


from the reports insofar, i'm actually a bit surprised that something isn't wrong, i wasn't expecting it to go so well off the bat.

[ophiuchus18]

Look for when FFmpeg renamed sha1.h to sha.h. That's the answer to your question. Or just use the source from svn which has been updated for that change.

Let's presume I'll build ffms2.v15.Revision509, tricked with an older version of ffmpeg libav libs and everything is ok. But there are conflicts with many other actual libav libs headers not only with "sha.h/sha1.h" change. It seems like ffmpeg and ffms are going now in different directions. I think ffms must update its code to the actual ffmpeg libav libs.

The latest stable ffmpeg:

Code: [Select]

ffmpeg.exe --version
ffmpeg version 0.8.1, Copyright (c) 2000-2011 the FFmpeg developers
  built on Jul 29 2011 14:19:34 with gcc 4.5.2
  configuration:
  libavutil    51.  9. 1 / 51.  9. 1
  libavcodec   53.  7. 0 / 53.  7. 0
  libavformat  53.  4. 0 / 53.  4. 0
  libavdevice  53.  1. 1 / 53.  1. 1
  libavfilter   2. 23. 0 /  2. 23. 0
  libswscale    2.  0. 0 /  2.  0. 0

Now it's become clear why x264 built with ffmpeg support from the actual stable v0.8.1 and with ffms support from ffms2.v15.Revision509 (built with some older ffmpeg libav libs) crash unexpectedly in some situations: maybe because the ffms/libav libs conflicts, I don't have a detailed view about this. 

In this situation the only safely solution for run x264 without fear of crash is to use only the avisynth support with its own plugins or those imported from virtualdub.

Another x264 external support problem: ffmpeg dropped the libpostproc from its v.0.8.1 and x264 need libpostproc/postprocess.h and libpostproc.a for build the executable with lavf support. I see there are developers which work on both projects, ffmpeg and x264. What's their opinion?

[Myrsloik]

Try not contradicting yourself or actually locating these poor starving developers you mention. Also, do I really have to tell you to compile ffms2 without postprocessing support when you can't even be arsed to install the library? What did you expect would happen?

[TheFluff]

Oh boy, so much dumb.

The so called ffmpegsource-2.15_src.7z from dev site is outdated trash (v2.13.1?)

The API version is not the same as the user-friendly release version.

It's impossible to compile and build this source pack because
the actual ffmpeg pack don't have such file as libavutil/sha1.h
(there is only libavutil/sha.h in the actual ffmpeg pack)

Your FFmpeg is too new. If you want to build an old FFMS2 you should use an old FFmpeg too.

I tried also to compile the svn.ffms2.15.Revision509.src. The same problem:
compilation conflict between:
\src\core\indexing.cpp (svn.ffms2.15.Revision509.src)
and
\libavutil\sha.h (Version: 51.11.0)

You're doing it wrong. There is no such conflict. If you're getting compilation errors anyway, post the compilation log if you want assistance.

What outdated ffmpeg libavutil use this "Fabulous" site (with the toilet paper logo  ) to compile ffms2.15.Revision509.src?

If you want to compile FFMS2 trunk you can use any version of FFmpeg or libav, as long as it's not too old.

Let's presume I'll build ffms2.v15.Revision509, tricked with an older version of ffmpeg libav libs and everything is ok. But there are conflicts with many other actual libav libs headers not only with "sha.h/sha1.h" change. It seems like ffmpeg and ffms are going now in different directions. I think ffms must update its code to the actual ffmpeg libav libs.

You're dumb and you're probably doing it wrong. There are no such conflicts. The current version of FFMS2 is backwards compatibile with all FFmpeg/libav versions at the very least six months back.

Now it's become clear why x264 built with ffmpeg support from the actual stable v0.8.1 and with ffms support from ffms2.v15.Revision509 (built with some older ffmpeg libav libs) crash unexpectedly in some situations: maybe because the ffms/libav libs conflicts, I don't have a detailed view about this.

We're interested in any and all crash reports, but no, they're not caused by "libs conflicts".

Another x264 external support problem: ffmpeg dropped the libpostproc from its v.0.8.1 and x264 need libpostproc/postprocess.h and libpostproc.a for build the executable with lavf support. I see there are developers which work on both projects, ffmpeg and x264. What's their opinion?

If you want libpostproc I suggest you compile it yourself.


If you want actual help or meaningful answers rather than just flaming, I suggest you start posting some compilation logs.

[ophiuchus18]

Oh boy, so much dumb.
The API version is not the same as the user-friendly release version.
Your FFmpeg is too new. If you want to build an old FFMS2 you should use an old FFmpeg too.
You're doing it wrong. There is no such conflict. If you're getting compilation errors anyway, post the compilation log if you want assistance.
If you want to compile FFMS2 trunk you can use any version of FFmpeg or libav, as long as it's not too old.
You're dumb and you're probably doing it wrong. There are no such conflicts. The current version of FFMS2 is backwards compatibile with all FFmpeg/libav versions at the very least six months back.
We're interested in any and all crash reports, but no, they're not caused by "libs conflicts".
If you want libpostproc I suggest you compile it yourself.


If you want actual help or meaningful answers rather than just flaming, I suggest you start posting some compilation logs.

Fluffy,

I built ffmpeg.v0.7.1. The /libavutil/sha1.h is mandatory required to build the svn.ffms2.15.Revision509.src and sha1.h is missing in the latest months's ffmpeg releases. Then I overwrote /mingw/mingw32/ with the obtained 0.7.1 installed "include" and "lib" folders (libav headers, .a libs and the pkgconfig .pc files).

building svn.ffms2.15.Revision509.src with ffmpeg.v0.7.1 libs - logs

Doesn't worked... building errors... Then I thought to myself the ffmpeg.v0.7.1 libs are too old  (but have sha1.h included).
No problem, let's try something new, ffmpeg.v0.8.1...

I built ffmpeg.v0.8.1 and I overwrote /mingw/mingw32/ with the new obtained 0.8.1 installed "include" and "lib" folders (libav headers, .a libs and the pkgconfig .pc files). The old /libavutil/sha1.h remained there, it doesn't exist in the newest ffmpeg libav packs.

building svn.ffms2.15.Revision509.src with ffmpeg.v0.8.1 libs - logs

Again, doesn't work... The ffmpeg.v0.8.1 libav libs seems to be too new for ffms2...

Now, dumb questions for wise answers:

Q: Why the src version is named 2.15 and the created package version is 2.13.1 ?
A: ...

Q: Why don't you add in your release ffmscompat.h and libffms2.a to avoid all this mess (ffms2.dll and ffms2.lib don't fit with the "--enable-static" option and people don't want a bunch of files around to run eg. x264.exe)?
A:...

Q: Why it's easy to build x264, ffmpeg, libav, Glib, pkconfig,...  but with ffms2 only problems?
A:...


example of bug:

Code: [Select]

---------------------------------------------------
\svn.ffms2.15.Revision509.src\src\core\indexing.cpp
---------------------------------------------------
30 #include <libavutil/sha1.h>
---------------------------------------------------

libavutil/sha1.h: there is no such thing in the recent ffmpeg libav releases.
I don't know when they removed sha1.h from headers, but I suppose the change happend months ago.

So, before you talk about dumbs, check before if you have valid arguments. The rest is poetry.

Have a nice day

[Groucho2004]

avsmeter reports the colorspace as YV12

Please try this version:
http://www.mediafire.com/?bdx9lun6r7k649x

[qyot27]

Please try this version:
http://www.mediafire.com/?bdx9lun6r7k649x

Thanks, it reports the colorspaces correctly now.

[qyot27]

I'm thinking that FFMS2 does not actually support Uncompressed streams, as using those colorspaces with Uncompressed is resulting in CAVISynth System access exceptions if I attempt to seek forward  (when using ffdshow to handle output display for Raw video; otherwise)and warnings like 'FFVideoSource: no codec found' (if ffdshow isn't handling Raw video or doesn't support the colorspace involved).  Nevermind.  My brain is really roasted tonight.


H.264 and FFV1 are okay for the ones they support (as already illustrated); is there any chart or command that will show which colorspaces ffmpeg supports for which formats?

[kemuri-_9]

I've committed the aforementioned changes to the repository, so everyone can build as they please.

I've also renamed the avs64 branch to c_plugin as apparently the shenanigans to build an avs64 plugin with msvc was re-instated.

[TheRyuu]

Q: Why it's easy to build x264, ffmpeg, libav, Glib, pkconfig,...  but with ffms2 only problems?
A:...

If you can build libav you can build ffms2.  Works for me and everyone else.

example of bug:

Code: [Select]

---------------------------------------------------
\svn.ffms2.15.Revision509.src\src\core\indexing.cpp
---------------------------------------------------
30 #include <libavutil/sha1.h>
---------------------------------------------------


Do you even bother to check the svn.  Because it doesn't look like that in r509.  I'm not sure why you would want to build 2.15 anymore.  Just checkout the source from trunk.

So, before you talk about dumbs, check before if you have valid arguments. The rest is poetry.

Did it ever occur to you that it might be the other way around?
Maybe if your posts weren't completely nonsensical and actually contained a valid problem you might receive some actual help.

[ophiuchus18]

Do you even bother to check the svn.  Because it doesn't look like that in r509.  I'm not sure why you would want to build 2.15 anymore.  Just checkout the source from trunk.

I didn't knew before about this link with the most updated source. The site architecture is confuse. A newcomer arrived at ffms2 page to search for ffms.h, ffmscompat.h and libffms2.a (necessary to include the static ffms support in x264.exe) is going to DOWNLOAD button and there is only the outdated ffmpegsource-2.15_src.7z and some .exe releases.

I downloaded r512 source from link you provided and finally I built the libffms2.a, libffms2.la that match with the included ffms.h and ffmscompat.h. I could include the static ffms2 lib into x264.

But now there is another problem: ffmsindex.exe and x264.exe can't run without the presence of the next files:
libgcc_s_dw2-1.dll
libstdc++-6.dll
This never happend before and I successfully compiled and built many diff. source packs.
I tried to enable the -static-libgcc and -static-libstdc++ in my gcc 4.5.2 but doesn't work. It's something wrong in the source code of r512 or what?

[TheFluff]

I built ffmpeg.v0.7.1. The /libavutil/sha1.h is mandatory required to build the svn.ffms2.15.Revision509.src and sha1.h is missing in the latest months's ffmpeg releases.

2.15 was released in February. If you want to build it, you should use a FFmpeg at least that old, as it is hard to be forwards-compatible.

Q: Why the src version is named 2.15 and the created package version is 2.13.1 ?
A: ...

As I already told you, 2.13.1 is not the package version. It's the API version, which is a completely different thing.

Q: Why don't you add in your release ffmscompat.h and libffms2.a to avoid all this mess (ffms2.dll and ffms2.lib don't fit with the "--enable-static" option and people don't want a bunch of files around to run eg. x264.exe)?
A:...

If you actually look at the current source code instead of at outdated shit, you will notice we did this a long time ago.

Q: Why it's easy to build x264, ffmpeg, libav, Glib, pkconfig,...  but with ffms2 only problems?
A:...

Because you are doing it wrong.

I didn't knew before about this link with the most updated source. The site architecture is confuse. A newcomer arrived at ffms2 page to search for ffms.h, ffmscompat.h and libffms2.a (necessary to include the static ffms support in x264.exe) is going to DOWNLOAD button and there is only the outdated ffmpegsource-2.15_src.7z and some .exe releases.

We assumed that if you wanted to compile from source you'd at least know how to do a SVN checkout. This debacle tells me it's probably a good idea to remove the source archives completely and tell people to check out the SVN tags instead.

But now there is another problem: ffmsindex.exe and x264.exe can't run without the presence of the next files:
libgcc_s_dw2-1.dll
libstdc++-6.dll
This never happend before and I successfully compiled and built many diff. source packs.
I tried to enable the -static-libgcc and -static-libstdc++ in my gcc 4.5.2 but doesn't work. It's something wrong in the source code of r512 or what?

I have no idea what you've done to your MinGW libraries but apparently they're shared now for some reason. Don't do that.

[ophiuchus18]

2.15 was released in February. If you want to build it, you should use a FFmpeg at least that old, as it is hard to be forwards-compatible.
As I already told you, 2.13.1 is not the package version. It's the API version, which is a completely different thing.
If you actually look at the current source code instead of at outdated shit, you will notice we did this a long time ago.
Because you are doing it wrong.
We assumed that if you wanted to compile from source you'd at least know how to do a SVN checkout. This debacle tells me it's probably a good idea to remove the source archives completely and tell people to check out the SVN tags instead.
I have no idea what you've done to your MinGW libraries but apparently they're shared now for some reason. Don't do that.

My mingw is OK, I successfully build executables and libraries (.a and .dll) from ffmpeg, libav, x264, zlib, bzip2, pkg-config, GLib, lame, etc. from their sources and the built applications don't have unexpected dependencies like ffms application and its libraries.

In your release packages there are only ffmsindex.exe, ffms2.dll, FFMS2.avsi, ffms.h, ffms2.lib, ffms2.pdb, ffmsindex.pdb. I can use ffms2.dll, ffms.h and ffms2.lib form these packages to enable the EXTERNAL ffms support in x264.exe, but then x264.exe will run only together with ffms2.dll and it's annoying.

All I need from ffms2 site are the regularly up-to-date files: ffms.h, ffmscompat.h, libffms2.a, libffms2.la and ffms2.pc, to enable the STATIC ffms support in x264 when I build the executable. This is the only reason because I compile and build from your source.

Why don't you put all your libraries (.a and .la inclusive, not only .dll and .lib) and the matching headers in the dev folder of your regular releases ? it's a great mistery. This is not chinese, is just a simple way to simplify the access of third party to ffms libs.

[TheFluff]

My mingw is OK, I successfully build executables and libraries (.a and .dll) from ffmpeg, libav, x264, zlib, bzip2, pkg-config, GLib, lame, etc. from their sources and the built applications don't have unexpected dependencies like ffms application and its libraries.

In your release packages there are only ffmsindex.exe, ffms2.dll, FFMS2.avsi, ffms.h, ffms2.lib, ffms2.pdb, ffmsindex.pdb. I can use ffms2.dll, ffms.h and ffms2.lib form these packages to enable the EXTERNAL ffms support in x264.exe, but then x264.exe will run only together with ffms2.dll and it's annoying.

All I need from ffms2 site are the regularly up-to-date files: ffms.h, ffmscompat.h, libffms2.a, libffms2.la and ffms2.pc, to enable the STATIC ffms support in x264 when I build the executable. This is the only reason because I compile and build from your source.

Why don't you put all your libraries (.a and .la inclusive, not only .dll and .lib) and the matching headers in the dev folder of your regular releases ? it's a great mistery. This is not chinese, is just a simple way to simplify the access of third party to ffms libs.

We are actually planning on releasing an SDK package with pretty much what you're asking for (include files, library and debugging symbols), but we haven't gotten around to it yet.

As for your funny dependencies, I have no idea what you're doing wrong but something is clearly broken on your end. You're the first to report similar issues, and there is nothing special about how FFMS2 is built in MinGW.

[ophiuchus18]

We are actually planning on releasing an SDK package with pretty much what you're asking for (include files, library and debugging symbols), but we haven't gotten around to it yet.

As for your funny dependencies, I have no idea what you're doing wrong but something is clearly broken on your end. You're the first to report similar issues, and there is nothing special about how FFMS2 is built in MinGW.

That's will be a great help and will simplify the access to the updated ffms2's libs required to build third party software.

I actually opened an issue at site to not annoy this forum, where are all data to see inside this problem.

Issue 52

[TheFluff]

New test build: ffms2-r532.7z
Includes pthreads.

We're slowly working on trying to fix enough bugs to motivate a release of 2.16, so test everything, submit all your weirdest sample files and win a prize if it causes a reproducible crash. Test audio in particular since we've been fucking around with that a lot lately.

Full changelog (maybe) since 2.15:

• Reimplemented output colorspace selection, this should fix all issues with the avisynth plugin when opening yuv420p10 or yuv444 material plus several other less common cases. (Myrsloik)
• Added FFMS_SetOutputFormatV2 to the API. This function allows you to specify PixelFormats >= 64 for use as output. (Myrsloik)
• Fixed a serious bug that could cause crashes and completely useless index files with h264 in matroska. (Myrsloik)
• Automatically detect number of decoding threads. The avisynth video source funtion already did this, now moved so the api can use it as well. (TheRyuu)
• Re-add the ability to target x64 with msvc since it's a bit more sane now. (TheRyuu)
• Fixed a bug that could cause crashes when reading audio if FFMS2 was compiled with GCC. (Myrsloik)
• ffmsindex will no longer crash if it cannot open the file given to it for indexing. (TheFluff)
• FFMS2 will no longer crash if the video decoder feeds it an empty frame (can sometimes happen when using lots of decoder threads); you'll get a nice error message instead. (TheFluff)
• The C-plugin can now act as both an Avisynth 2.6 plugin (including support for new colorspaces) as well as an Avisynth 2.5 one, in the same binary. (kemuri_-9)
• Fixed an issue that could cause opening Vorbis audio to fail because FFMS2 couldn't find an initial valid PTS. (TheFluff)
• FFMS2 will no longer crash if forced or tricked into using an index file generated by a FFMS2 version compiled for a different architecture. (TheRyuu)
• Fixed a crash when the last frame was requested using the Avisynth plugin's forced CFR mode. (Plorkyeran)
• Fixed various issues with decoding audio from the Ogg container without Haali's splitter. (Myrsloik, TheFluff)

[TheRyuu]

Yet another new test build: ffms2-r533.7z

All of the above plus this should fix the invalid postprocess bug (for good).  Go forth and test.

[TheFluff]

FFMS 2.16 has been released. The following downloads are now available:

• ffms-2.16.7z - the usual binary. Includes multithreaded decoding functionality; you no longer need a special -mt version.
• ffms-2.16-src.tar.bz2 - source code.
• ffms-2.16_SDK.7z - package for Windows developers who want to develop programs that use FFMS2 but don't want to deal with MinGW.

Full changelog since 2.15:

• Reimplemented output colorspace selection, this should fix all issues with the avisynth plugin when opening yuv420p10 or yuv444 material plus several other less common cases. (Myrsloik)
• Added FFMS_SetOutputFormatV2 to the API. This function allows you to specify PixelFormats >= 64 for use as output. (Myrsloik)
• Fixed a serious bug that could cause crashes and completely useless index files with h264 in matroska. (Myrsloik)
• Automatically detect number of decoding threads. The avisynth video source funtion already did this, now moved so the api can use it as well. (TheRyuu)
• Re-add the ability to target x64 with msvc since it's a bit more sane now. (TheRyuu)
• Fixed a bug that could cause crashes when reading audio if FFMS2 was compiled with GCC. (Myrsloik)
• ffmsindex will no longer crash if it cannot open the file given to it for indexing. (TheFluff)
• FFMS2 will no longer crash if the video decoder feeds it an empty frame (can sometimes happen when using lots of decoder threads); you'll get a nice error message instead. (TheFluff)
• The C-plugin can now act as both an Avisynth 2.6 plugin (including support for new colorspaces) as well as an Avisynth 2.5 one, in the same binary. (kemuri_-9)
• Fixed an issue that could cause opening Vorbis audio to fail because FFMS2 couldn't find an initial valid PTS. (TheFluff)
• FFMS2 will no longer crash if forced or tricked into using an index file generated by a FFMS2 version compiled for a different architecture. (TheRyuu)
• Fixed a crash when the last frame was requested using the Avisynth plugin's forced CFR mode. (Plorkyeran)
• Fixed various issues with decoding audio from the Ogg container without Haali's splitter. (Myrsloik, TheFluff)
• Fixed the "invalid postprocessing settings"; they were caused by a parsing bug in libpostproc, and a workaround has been added. (Myrsloik)
• Tinkered a bit with the non-MSVS build system. (Daemon404, Kovensky)

Important notice for postprocessing users:
Support for postprocessing in FFMS2 will be dropped in the next release. The reason is that both libav and FFmpeg are dropping this library from their own releases, and so we cannot continue supporting it.

[TheRyuu]

ffms-2.16-x64.7z - 64-bit version, for use with avs64. Note that it is a native Avisynth plugin now; no need for LoadCPlugin or LoadStdcallPlugin
ffms-2.16_SDK.7z - updated to now include the 64-bit stuff.

Have at it.

[Super AudioCD]

Latest FFMS2 (32-bits) gives an "Access violation" error for anamorphic VC-1.
<lachs0r mode="on">please update your sh*t</lachs0r mode="off"> 

[TheRyuu]

Latest FFMS2 (32-bits) gives an "Access violation" error for anamorphic VC-1.
<lachs0r mode="on">please update your sh*t</lachs0r mode="off"> 

Sample.

[Super AudioCD]

Sample.

http://forum.doom9.org/showpost.php?p=1521308&postcount=13919

and

http://forum.doom9.org/showthread.php?t=162221

P.S.: speaking of lachs0r, he too needs to update his sh!t 

ERROR: Could not open required DirectShow codec wvc1dmod.dll 
You need to upgrade/install the binary codecs package.
Go to http://www.mplayerhq.hu/dload.html
VDecoder init failed
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffvc1] vfm: ffmpeg (FFmpeg WVC1)
===================================================
Audio: no sound
Starting playback...
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.

VO: [direct3d] 720x540 => 960x540 Planar YV12
<vo_direct3d>Allocating offscreen surface failed.
FATAL: Cannot initialize video driver.

FATAL: Could not initialize video filters (-vf) or video output (-vo).


Exiting... (End of file)

[TheWeirdo]

P.S.: speaking of lachs0r, he too needs to update his sh!t 

Sorry for off-topic, but lachs0r's mplayer2 build doesn't come with external binary codecs, like wvc1dmod.dll in this case.

Also AFAIK, FFMS2 official build is built against Libav libraries which don't contain this fix for VC-1.

EDIT: Libav have also fixed that issue with this commit.

[Super AudioCD]

Sorry for off-topic, but lachs0r's mplayer2 build doesn't come with external binary codecs, like wvc1dmod.dll in this case.

I did not say lachs0r should include a full codecs folder in his build of mplayer.

I meant the file wvc1dmod.dll itself is pretty outdated now.

P.S.: These new emoticons suck even more than the previous ones :—/

[TheWeirdo]

I did not say lachs0r should include a full codecs folder in his build of mplayer.

I meant the file wvc1dmod.dll itself is pretty outdated now.

Then I misunderstood your statement. Sorry. 
However, with his latest mplayer2 build (20110910), I'm able to play all of Midzuki's vc1-samples without any problems.

[Super AudioCD]

However, with his latest mplayer2 build (20110910), I'm able to play all of Midzuki's vc1-samples without any problems.

Yep, I had to add the switch "-vo directx" to the command-line.

"Regular" Mplayer.exes do NOT require that, though.