FFmpegSource

[kaefert]

I'm trying to get a "newer" mov file created by an Canon SX230HS camera into avisynth. It looks a lot like a h264 mp4, and it loads fine with
AudioDub(FFVideoSource(X1), FFAudioSource(X1))

But I get a lot of bad artefacts.
Sample including script + encoding + log:
http://koega.no-ip.org/misc/avisynth_load-mov/

How do I get rid of those artefacts? Opening the MOV source in any video player doesn't show any artefacts for me.

UPDATE: SOLVED: simply take the newest version of FFMS2 (ffms2-2.20-icl.7z) from https://github.com/FFMS/ffms2/releases ;)

[pandv2]

But this version doesn't works with accents and foreign chars in the path o file name.

It's dificult to find the perfect version, but thanks for all the efforts.

[qyot27]

FFMS2 C-plugin r931+50

Optimized for Pentium-III and SSE.

ffmpeg version r65087 git-65746bf Copyright (c) 2000-2014 the FFmpeg developers
built on Jul 29 2014 07:21:26 with gcc 4.9.1 (GCC)
libavutil 52. 92.101 / 52. 92.101
libavcodec 55. 71.100 / 55. 71.100
libavformat 55. 49.100 / 55. 49.100
libavdevice 55. 13.102 / 55. 13.102
libavfilter 4. 11.102 / 4. 11.102
libavresample 1. 3. 0 / 1. 3. 0
libswscale 2. 6.100 / 2. 6.100
libswresample 0. 19.100 / 0. 19.100
libpostproc 52. 3.100 / 52. 3.100

configuration:
--prefix=/home/qyot27/win32_build
--cross-prefix=i686-w64-mingw32-
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--disable-doc
--disable-encoders
--disable-muxers
--disable-doc
--disable-debug
--disable-network
--disable-hwaccels
--disable-indevs
--disable-outdevs
--cpu=pentium3
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW32_STATIC_LIB'
--target-os=mingw32
--arch=x86

No more need to set FFmpeg's optflags to -O0, so performance on some decoders should be improved compared to the GCC 4.9.0 builds.

I did slightly patch FFmpeg by commenting out the two-line change from commit 76b5e99 (http://git.videolan.org/?p=ffmpeg.git;a=commit;h=76b5e99ce9c1245e2e426203a1f535a5d83cced6) as documented in ticket #3809 (http://trac.ffmpeg.org/ticket/3809), but it's otherwise the same as git master @ 65746bf.

EDIT 2014-08-02: Updated build here. (http://forum.doom9.org/showthread.php?p=1688624#post1688624)

[LigH]

Please note that MediaFire started to un-support '+' chars in filenames during uploads; you may have to rename your file right after uploading.

[qyot27]

Please note that MediaFire started to un-support '+' chars in filenames during uploads; you may have to rename your file right after uploading.
Renaming it afterward doesn't do anything to the stored name or the download link. It still pushed it to Firefox with spaces rather than the renamed title. And at the time that file was uploaded, it didn't do anything to the + character, so this was a retroactive change applied to existing files.

Of course, it doesn't affect the links I post here because I always ever use the short-form URL. It also doesn't damage the file at all.

The only actual 'remedy' is to use a different filename, period.

[jdobbs]

I'm getting an error condition with r931+50. With rffmode=1 or rffmode=2 it says I have to use the default output colorspace -- even though I am. I noticed this note in post #1787:

- Fix regression (r483) with rffmode that caused it to error out even if using the default output colorspace. (TheRyuu)

Is this something that perhaps hasn't been included in this build?

[qyot27]

It is*, and has been since April.

*the original commit:
Fix regression in rffmode error handling.

The regression caused by r483 would cause it to error out even if we
didn't specify any change in the output color space.

Fixes issue 95.

Originally committed to SVN as r720.

diff --git a/src/avisynth/avssources.cpp b/src/avisynth/avssources.cpp
index 883ff7b..41be596 100644
--- a/src/avisynth/avssources.cpp
+++ b/src/avisynth/avssources.cpp
@@ -243,7 +243,7 @@ void AvisynthVideoSource::InitOutputFormat(
if (RFFMode > 0 && ResizeToHeight != F->EncodedHeight)
Env->ThrowError("FFVideoSource: Vertical scaling not allowed in RFF mode");

- if (RFFMode > 0 && TargetPixelFormat != PIX_FMT_NV12)
+ if (RFFMode > 0 && TargetPixelFormat != PIX_FMT_NV21)
Env->ThrowError("FFVideoSource: Only the default output colorspace can be used in RFF mode");

// set color information variables
and the corresponding commit to the C-interface:
c_plugin: Fix regression in rffmode error handling.

The regression caused by r483 would cause it to error out even if we
didn't specify any change in the output color space.

Applies change from master @ ef81fe1

diff --git a/src/avisynth_c/ff_vidsource.c b/src/avisynth_c/ff_vidsource.c
index 4ec4904..fcf8ca1 100644
--- a/src/avisynth_c/ff_vidsource.c
+++ b/src/avisynth_c/ff_vidsource.c
@@ -232,7 +232,7 @@ static AVS_Value init_output_format( ffvideosource_filter_t *filter, int dst_wid
if( filter->rff_mode > 0 && dst_height != frame->EncodedHeight )
return avs_new_value_error( "FFVideoSource: Vertical scaling not allowed in RFF mode" );

- if( filter->rff_mode > 0 && dst_pix_fmt != PIX_FMT_NV12 )
+ if( filter->rff_mode > 0 && dst_pix_fmt != PIX_FMT_NV21 )
return avs_new_value_error( "FFVideoSource: Only the default output colorspace can be used in RFF mode" );

// Set color information


EDIT: I see what happened. That change was brought over without bringing over the change in r483 to the corresponding source file. I have to fix that.

[qyot27]

FFMS2 C-plugin r931+51

Optimized for Pentium-III and SSE.

ffmpeg version r65173 git-afd62b3 Copyright (c) 2000-2014 the FFmpeg developers
built on Aug 1 2014 18:09:55 with gcc 4.9.1 (GCC)
libavutil 52. 94.100 / 52. 94.100
libavcodec 55. 71.100 / 55. 71.100
libavformat 55. 50.100 / 55. 50.100
libavdevice 55. 13.102 / 55. 13.102
libavfilter 4. 11.102 / 4. 11.102
libavresample 1. 3. 0 / 1. 3. 0
libswscale 2. 6.100 / 2. 6.100
libswresample 0. 19.100 / 0. 19.100
libpostproc 52. 3.100 / 52. 3.100

configuration:
--prefix=/home/qyot27/win32_build
--cross-prefix=i686-w64-mingw32-
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--disable-doc
--disable-encoders
--disable-muxers
--disable-doc
--disable-debug
--disable-network
--disable-hwaccels
--disable-indevs
--disable-outdevs
--cpu=pentium3
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW32_STATIC_LIB'
--target-os=mingw32
--arch=x86

This should fix the rffmode issue. The slight mod in FFmpeg mentioned last time is also no longer necessary, as it was fixed upstream.

EDIT 2014-09-15: New build available here. (http://forum.doom9.org/showthread.php?p=1693710#post1693710)

[filler56789]

^ Thanks for the fixed build :thanks:

[jdobbs]

Thanks!

[Reino]

FFMS2 C-plugin r931+51 (http://www.mediafire.com/?wm71g1ribrcbezy)

Optimized for Pentium-III and SSE.
About a week ago I updated FFMS2 2.19 to this one, but only today, when I wanted to do some video editing, I found out that the moment I opened AviSynth-scripts in MPC-BE/HC the player would crash. It took my more than an hour to find out FFMS2 to be the culprit; ffms2.dll to be precise, that now appears to be a C-plugin instead of a normal AviSynth plugin.
This is ffavisynth.dll all over again. So to fix it...

FFMS2.avsi:
# FFmpegSource 1.21 syntax compatibility
# Created by TheFluff
LoadCPlugin("C:\Program Files\Media\AviSynth 2.6.0\plugins\ffms2.dll")
...
This again only seemed to somehow affect MPC-BE/HC. I could still open the AviSynth-script with GraphStudioNext, AvsPmod, FFMpeg and avs2pipemod without having to touch FFMS2.avsi.
I guess this could probably fix your problem too, Boulder.
Do you have any idea why this would only affect MPC-BE/HC, qyot27?
I'm using Avisynth 2.6.0 Alpha 5 + SEt's avisynth.dll (28.09.2013), btw.

[TheFluff]

About a week ago I updated FFMS2 2.19 to this one, but only today, when I wanted to do some video editing, I found out that the moment I opened AviSynth-scripts in MPC-BE/HC the player would crash. It took my more than an hour to find out FFMS2 to be the culprit; ffms2.dll to be precise, that now appears to be a C-plugin instead of a normal AviSynth plugin.
It says right there in the post you quoted: "FFMS2 C-plugin r931+51"

FFMS2 has both regular Avisynth 2.5 and Avisynth-C interfaces because the Avisynth 2.6 API is a terrible hack that nobody wants to interface with, so in order to get support for the new Avisynth 2.6 colorspaces some enterprising individual hacked those into the C interface instead. Unfortunately there's no straightforward way to tell from the DLL which version you have, so you have to read the packaging when you download.

[qyot27]

The FFMS2.avsi included with the C-plugin also has the LoadCPlugin line already included. It's been there for a good 2+ years already (https://github.com/FFMS/ffms2/commit/6819c6ce046f2061579765074c0fa24afb5280ed). The only time that line isn't needed for the C-plugin is when using AviSynth+, since it autoloads C plugins.

Some [IMO, broken] programs have issues with the relative path to ffms2.dll in the C-plugin's FFMS2.avsi. mencoder, for example (like I said, broken). I even switched avisynth.dll back to 2.6 MT to test with MPC-HC. The relative path works fine.

[Reino]

It says right there in the post you quoted: "FFMS2 C-plugin r931+51"Doh! haha.
As a last resort I noticed adding AviSynth's plugin map to %PATH% (Environment Variables) would help too.

If AviSynth 6.0 is so terrible, what are you 2 using? AviSynth+, or another fork?

[LigH]

There is no AviSynth 6.0 yet. ;)

And no matter which fork, to be compatible, it would have to implement the same programming interfaces.

AviSynth+ at least supporst a list of plugin directories, similar to %PATH%.

[szabi]

Hi

I have a simple question.
FFVideoSource("D:\movie\Video.mkv", fpsnum=24, fpsden=1, threads=1)
MCTemporalDenoise(settings="medium")
crop(68, 0, -68, 0)
This script was loaded to virtualdub and compressed by ffdshow video codec with following:
Encoder: HuffYUV (FFmpeg variant), FOURCC: FFVH, colorspace: YV12, Predictor: plane, disabled adaptive huffman tables

Now i have a huge video.avi file.
I want to encode by x264.
I can not load it by FFVideoSource.
Only AviSource is working.
Why is FFVideoSource not working? Even it was created by ffdshow video codec.
Is there any quality loss by AviSource in use, not FFVideoSource?

bye
szabi

[raffriff42]

OP should perhaps be updated with link to the latest releases?
https://github.com/FFMS/ffms2/releases (if that's correct)

[Myrsloik]

OP should perhaps be updated with link to the latest releases?
https://github.com/FFMS/ffms2/releases (if that's correct)

Fixed. Guess I forgot to update it when everything moved to github.

[Groucho2004]

I can not load it by FFVideoSource.
It should work. It will however take some time to create the index file. Can you be a bit more specific than "I can not load it"?

[szabi]

Hi

When I tried by megui, the program simple crashed.
Other was simple x264 launcher, which turned unresponsive for a 1 minutes, after stopped by following message:
Warning: Input process did not respond for 60 seconds, potential deadlock...
error: FFVideoSource: Can't open 'D:\D:\movie\Video.avi' (\D:\movie\Video.avs, line 1)

Do you think any quality loss occurs by AviSource in use instead of FFVideoSource?

bye
szabi

[Groucho2004]

Do you think any quality loss occurs by AviSource in use instead of FFVideoSource?
Not that I know of.

[LigH]

D:\D:\movie\Video.avi — looks suspicious.

It might depend on the video format in the AVI. Lossless formats (like Huffyuv) should decode equally with all decoders. Lossily compressed formats may reconstruct with slight differences, depending on the decoder.

The YV12 version of Huffyuv by ffmpeg won't decode with BenRG's VfW codec, you will need ffdshow (ffvfw) installed and activated. Current builds of FFMS2 or L-SMASH Works should support it too; I remember there has been a problem with lossless AVIs though, possibly related to the huge index because every frame is a keyframe.

[szabi]

D:\D:\movie\Video.avi — looks suspicious.
Typing issue, not the reason.

Of cource ffdshow is installed, anyway not available for encoding.
Decoder setting is this one for VFW:
http://abload.de/img/ffdshowqasv2.png

HuffYUV and HuffYUV FFmpeg variant is activated.
Unfortunately add it by AviSource input there is no feedback which codec in use.

bye
szabi

[LigH]

Because the FourCC "FFVH" will only be supported by ffvfw, this codec will have been used. If there is a choice between several VfW codecs, then it depends on the preference order in the registry.

So in this case, using AviSource is a rather reliable choice for you. FFMS2 may have choked on its index.

[szabi]

Ok, thanks for it.

bye
szabi

[Boulder]

Warning: Input process did not respond for 60 seconds, potential deadlock...
error: FFVideoSource: Can't open 'D:\D:\movie\Video.avi' (\D:\movie\Video.avs, line 1)As has been mentioned earlier, it can take quite a while to index a file if it is large.

[RTW47]

for a massive source file(s) preferred way would be to perform manual indexing beforehand via ffmsindex, instead of automatic, if application waiting for FFMS2 to construct index crashes, stops responding or implements deadlock prevention such as Simple x264/x265 Launcher. Additionally user will get progress report on the indexing.

[Andouille]

Hi guys,

Because I wanted to play with the new hevc toys around (and also have a bug/artifacts free prores decoder), I updated my good old r579 to the new 2.20.

Hevc decoding and prores are just fine and I'm happy.
Compared to r579, I also found a nice 2% to 2.6% speedup for h264 decoding.(the biggest speedup is for lossless, which is really good)

However I found it is slower on other codecs like :
div3, xvid -20%
divx5 -10%
(I don't really care for this three codecs but the speed loss is quite big)

But the really annoying one :
mpeg2 -15%

I'm running Avisynth 2.5.8.5 on WinXP 32bits.

Can someone confirm this ?

Thx

[Groucho2004]

However I found it is slower on other codecs like :
...
But the really annoying one :
mpeg2 -15%

I'm running Avisynth 2.5.8.5 on WinXP 32bits.

Can someone confirm this ?
Ran a few tests with a SD PAL mpeg-2 clip on my i5 2500K (Sandy Bridge), same Avisynth version, same OS.

Script:
loadplugin("ffms2.dll")
ffvideosource("test.m2v", threads = 1)


Results:
FFMS2 r579: 1014 fps
FFMS2 2.20 (ICL): 974 fps
FFMS2 2.20 (MSVC): 545 fps

[Lenchik]

Can you please upload somewhere this r576 build for share.

[the_weirdo]

That speed loss may be a result of different compilers using to build lav* (lav* of official builds were built with ICL and MSVC, which are slower than GCC builds). You can try those FFMS2 builds (https://www.dropbox.com/sh/w1zt5qvfywj6r9z/AADtFdbpcnRole0wja_o_6TYa?dl=0) to see if that's the case.

[qyot27]

The C-plugin is another option.

[Taurus]

Can you please upload somewhere this r576 build for share.
https://code.google.com/p/ffmpegsource/downloads/list?can=1&q=&colspec=Filename+Summary+Uploaded+ReleaseDate+Size+DownloadCount
r576 is not found in this list.
But r579, the one Groucho2004 is poking on, is available.
Try your poison.

[qyot27]

FFMS2 C-plugin r936+55

Optimized for Pentium-III and SSE.

ffmpeg version r66281 git-e587a42 Copyright (c) 2000-2014 the FFmpeg developers
built on Sep 15 2014 10:35:35 with gcc 4.9.1 (GCC)
libavutil 54. 7.100 / 54. 7.100
libavcodec 56. 1.100 / 56. 1.100
libavformat 56. 4.101 / 56. 4.101
libavdevice 56. 0.100 / 56. 0.100
libavfilter 5. 1.100 / 5. 1.100
libavresample 2. 1. 0 / 2. 1. 0
libswscale 3. 0.100 / 3. 0.100
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 0.100 / 53. 0.100

configuration:
--prefix=/home/qyot27/win32_build
--cross-prefix=i686-w64-mingw32-
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--disable-encoders
--disable-muxers
--disable-doc
--disable-debug
--disable-network
--disable-hwaccels
--disable-indevs
--disable-outdevs
--cpu=pentium3
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW32_STATIC_LIB'
--target-os=mingw32
--arch=x86

EDIT 2014-11-05: Newer build available here. (http://forum.doom9.org/showthread.php?p=1698838#post1698838)

[Taurus]

@qyot27
:thanks: for the new build!
I could not resist:

Script:
ffvideosource("test.m2v", threads = 1)
Testing ffms2_r936c55-avs_vsp:
Frames processed: 4738 (0 - 4737)
FPS (min | max | average): 117.3 | 204.0 | 146.1
CPU usage (average): 98%
Thread count: 2
Physical Memory usage (peak): 18 MB
Virtual Memory usage (peak): 22 MB
Time (elapsed): 000:00:32.437


Testing ffms2-r579:
[Runtime info]
Frames processed: 4736 (0 - 4735)
FPS (min | max | average): 80.36 | 148.8 | 113.0
CPU usage (average): 89%
Thread count: 2
Physical Memory usage (peak): 24 MB
Virtual Memory usage (peak): 29 MB
Time (elapsed): 000:00:41.899

This is on an old laptop.
The speed increase of the new version is remarkable.

[Groucho2004]

Testing ffms2_r936c55-avs_vsp:
Frames processed: 4738 (0 - 4737)
Testing ffms2-r579:
[Runtime info]
Frames processed: 4736 (0 - 4735)
I wonder why the number of frames is different (assuming you did not cancel AVSMeter before all frames were processed)...

[Andouille]

Thx for all the replies.
I forgot to mention that I run an old t5500 processor and the ffms2 2.20 was the icl compiler build.
I will test the other compiler builds that you pointed out.
thx

[Lenchik]

More testing from me.
CPU: Intel Core i7-2600K CPU @ 3.40GHz (MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, EM64T, VT-x, AES, AVX)
Video Source: Previously screencaptured presentation like video 1824x992 @15fps encoded by x264 core 142 r2431kMod ac76440 with following parameters:
cabac=1 / ref=4 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=10 / psy=1 / fade_compensate=0.00 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / fgo=0 / bframes=10 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=1 / scenecut=80 / intra_refresh=0 / rc_lookahead=80 / rc=crf / mbtree=1 / crf=19.0000 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=20000 / vbv_bufsize=20000 / crf_max=0.0 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00

LoadPlugin (…)
# Load_Stdcall_plugin (…) # for C-plugins, marked as (C)
FFVideoSource(source=source, threads=1)

AVSMeter 1.8.1 set to process first 3001 frames (0 - 3000).


Log file created with: AVSMeter 1.8.1 (x86)
Avisynth version: AviSynth 2.60, build:Sep 28 2013 [15:09:12] (MT)
Active MT Mode: 0
Avg FPS Virtual Memory usage (peak, MB):
ffms2-r579 271.6 66
ffms-2.17-cplugin (C) 284.0 122
ffms2_r836-avs+vsp (C) 267.2 128
ffms2-2.19 269.2 70
ffms2-2.20-icl 261.3 77
ffms2-2.20-msvc 262.2 77
ffms2_r931+51-avs+vsp (C) 276.8 141
FFMS2-2.20-15-g08f94ee-FFmpeg-g365b9cf-32bit 277.1 77
FFMS2-2.20-15-g08f94ee-Libav-g775a0b0-32bit 276.5 76
ffms2_r936+55-avs+vsp (C) 272.9 140

[Andouille]

Here are my results with the different builds

*divx3
r579 820.76 fps
2.20gcc 691.59 fps
2.20icl 659.02 fps
2.20msvc 447.78 fps

*divx5
r579 2935.90 fps
2.20gcc 2788.51 fps
2.20icl 2674.95 fps
2.20msvc 1639.05 fps

*xvid
2.20gcc 735.20 fps
r579 722.51 fps
2.20icl 579.65 fps
2.20msvc 368.61 fps

*h264 baseline
2.20gcc 1282.36 fps
2.20icl 1246.05 fps
r579 1227.67 fps
2.20msvc 1210.35 fps


*h264 high profile
2.20gcc 165.05 fps
2.20icl 152.59 fps
r579 149.23 fps
2.20msvc 143.32 fps


*h264 lossless
2.20gcc 240.21 fps
2.20icl 237.34 fps
r579 234.14 fps
2.20msvc 224.93 fps


*mpeg2
r579 522.30 fps
2.20gcc 513.40 fps
2.20icl 453.07 fps
2.20msvc 353.64 fps


The C plugin is really fast for h264 !

Other thing I discovered :
The mpeg2 IDCT algorithm for the builds seem different :

2.20icl and 2.20gcc outputs are bit identical (crc) but not the r579 and the msvc

r579.png FF40A416 488 193
220icl.png 28C25109 488 106
220msvc.png 094891E6 488 128
220gcc.png 28C25109 488 106

[Taurus]

I wonder why the number of frames is different (assuming you did not cancel AVSMeter before all frames were processed)...
Yeah, I discovered this too.
Redid the tests, carefully deleting the index file -> same behaviour.
The old ffms2-r579 seems to be not frame accurat.
I verified with a bitrateviewer, 4738 frames is the real number.
ffms2-r579 is spitting out 4736 frames.
Two frames are missing with the older build.
Only tested on mpeg2, cant say for newer codecs.
So one should avoid the older build(s) for mpeg2!

[qyot27]

I wonder why the number of frames is different (assuming you did not cancel AVSMeter before all frames were processed)...
It could be either that FFMS2's demuxing has improved in regard to MPEG containers (as I'm not entirely sure whether this is one of the cases that FFMS2 defaults to Haali*), or it could be in libavformat itself. Since r579 is from October 2011, that's 357 commits to FFMS2 and a mountain of commits to FFmpeg (some of which I know are related to MPEG containers since I saw them in the Git log a few months ago).

*the C-plugin can't access the Haali DirectShow filter, though, so the only Haali code I think the C-plugin uses is for Matroska, as that's separate.

I'd compare the frame count against what DGIndex reports. I recall that there was a one frame difference even in recent builds. But whether the disparity is caused by FFMS2's internal stuff or simply what it gets from libavformat, I don't know.

[Taurus]

I'd compare the frame count against what DGIndex reports. I recall that there was a one frame difference even in recent builds.

DGIndex is reporting the same (correct) numbers here.
No mismatch to the newer FFMS2 builds.
Only the older builds are affected.

[qyot27]

FFMS2 C-plugin r936+55

Optimized for Pentium-III and SSE.

ffmpeg version r67362 git-db0471c Copyright (c) 2000-2014 the FFmpeg developers
built on Nov 3 2014 17:50:57 with gcc 4.9.2 (GCC)
libavutil 54. 11.100 / 54. 11.100
libavcodec 56. 10.102 / 56. 10.102
libavformat 56. 12.100 / 56. 12.100
libavdevice 56. 2.100 / 56. 2.100
libavfilter 5. 2.102 / 5. 2.102
libavresample 2. 1. 0 / 2. 1. 0
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 3.100 / 53. 3.100

configuration:
--prefix=/home/qyot27/win32_build
--cross-prefix=i686-w64-mingw32-
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--disable-encoders
--disable-muxers
--disable-doc
--disable-debug
--disable-network
--disable-hwaccels
--disable-indevs
--disable-outdevs
--disable-decoder=utvideo
--enable-libutvideo
--cpu=pentium3
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW32_STATIC_LIB'
--target-os=mingw32
--arch=x86

New build, no changes to the FFMS2 portions. Just a nearly-two-months newer version of FFmpeg, built with GCC 4.9.2 instead of 4.9.1.

Also, the return of libutvideo for decoding Ut Video streams, since support for UQY2 (the 10-bit 4:2:2 'Ut Video Pro' format) was added to the libutvideo wrapper.

EDIT 2014-12-23: New build available here. (http://forum.doom9.org/showthread.php?p=1703624#post1703624)

[poisondeathray]

Thanks for the update qyot27

[qyot27]

FFMS2 C-plugin r936+59

Optimized for Pentium-III and SSE.

ffmpeg version r68649 git-03b84f2 Copyright (c) 2000-2014 the FFmpeg developers
built on Dec 22 2014 08:09:17 with gcc 4.9.2 (GCC)
libavutil 54. 15.100 / 54. 15.100
libavcodec 56. 16.100 / 56. 16.100
libavformat 56. 16.101 / 56. 16.101
libavdevice 56. 3.100 / 56. 3.100
libavfilter 5. 4.100 / 5. 4.100
libavresample 2. 1. 0 / 2. 1. 0
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 3.100 / 53. 3.100

configuration:
--prefix=/home/qyot27/win32_build
--cross-prefix=i686-w64-mingw32-
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--disable-encoders
--disable-muxers
--disable-doc
--disable-decoder=utvideo
--enable-libutvideo
--disable-debug
--disable-network
--disable-hwaccels
--disable-indevs
--disable-outdevs
--cpu=pentium3
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW32_STATIC_LIB'
--target-os=mingw32
--arch=x86

This build has the Haali DirectShow code removed. It seems as if the C-plugin actually might have been able to use it, as all the COM stuff was being thrown around. I'm not entirely certain of that, but regardless, 'haalimpeg' and 'haaliogg' no longer exist in this build. This is not in FFMS2 master (yet; I've opened a pull request).

The big test: do those troublesome M2TS files mentioned in the docs still need seekmode=0 to work right with the LAVF splitter?

EDIT 2015-02-15: Newer build available here. (http://forum.doom9.org/showthread.php?p=1709647#post1709647)

[qyot27]

FFMS2 C-plugin r940+64

Optimized for Pentium-III and SSE.

ffmpeg version r69783 git-bbb0634 Copyright (c) 2000-2015 the FFmpeg developers
built with gcc 4.9.2 (GCC)
libavutil 54. 18.100 / 54. 18.100
libavcodec 56. 22.100 / 56. 22.100
libavformat 56. 21.100 / 56. 21.100
libavdevice 56. 4.100 / 56. 4.100
libavfilter 5. 11.100 / 5. 11.100
libavresample 2. 1. 0 / 2. 1. 0
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 3.100 / 53. 3.100

configuration:
--prefix=/home/qyot27/win32_build
--cross-prefix=i686-w64-mingw32-
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--disable-encoders
--enable-libutvideo
--disable-muxers
--disable-doc
--disable-debug
--disable-network
--disable-hwaccels
--disable-indevs
--disable-outdevs
--cpu=pentium3
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW32_STATIC_LIB'
--target-os=mingw32
--arch=x86

Going even further than the last build did, this one removes the Matroska demuxer too. This means that the *only* demuxer this build of FFMS2 uses is LAVF. The test this time is whether VP8 (and maybe VP9) bearing WebM files can be used correctly with the LAVF demuxer.

Additionally, developers using FFMS2 (the standard C++ plugin .dll) as a library can now use the C-plugin .dll with their program without much/any changes, since it now exports its functions with a leading underscore like the C++ plugin does - but only in the case of the C-plugin interface being enabled (--enable-avisynth). If you build FFMS2 with GCC but don't enable the C-plugin, it will export the functions like it always has, without the underscore.

EDIT 2015-03-26: Newer build available here. (http://forum.doom9.org/showthread.php?p=1714813#post1714813)

[LigH]

:thanks: Not yet tested; but exchanging Haali dependencies with LAVF appears to me to be probably useful, the splitters used to be the main weakness of FFMS2.

[qyot27]

It's not really exchanging it since LAVF was always there, it's more that it was becoming increasingly common to have to say 'did you try with -m lavf' when responding to bug reports, and much of the time, that was all the user actually needed to do. Defaulting to Haali demuxers for MPEG, OGM, and MKV (albeit to a lesser extent than the other two) has lost whatever advantage it might have had over libavformat a few years ago, and actually was beginning to be an active disadvantage. For most containers, LAVF has always been the default.

The relevant stuff on Github:
https://github.com/FFMS/ffms2/issues/175
https://github.com/FFMS/ffms2/issues/176
https://github.com/FFMS/ffms2/pull/183 (this covers only the removal of the code from the master branch; the C-plugin migration process is handled differently)

[stax76]

Will this plugin be C only or will there be a non C version, atm. StaxRip supports only non C. I've not followed the thread in detail and I'm rather confused, I want to try the latest build because the one StaxRip currently uses fails to open a eac3to created raw h264 file.

[qyot27]

Will this plugin be C only or will there be a non C version, atm. StaxRip supports only non C. I've not followed the thread in detail and I'm rather confused, I want to try the latest build because the one StaxRip currently uses fails to open a eac3to created raw h264 file.
This depends entirely on how you're using the .dll and/or AviSynth.

The builds I provide are only of the C plugin. Builds of the traditional C++ plugin version are available officially from github.com/FFMS/ffms2/releases, but builds are usually only made available when FFMS2 reaches a point release.

If you're using the .dll directly as a library rather than an AviSynth plugin, then the latest build I provided a couple posts ago should work (as I forcibly made underscore-prefixed API calls visible).

If you're using it as an AviSynth plugin, then one of the following can be true:
Use LoadCPlugin or Load_Stdcall_Plugin to load it manually
Use the provided FFMS2.avsi to mimic autoloading (it calls LoadCPlugin) - the AviSynth plugins folder should be on the Windows %PATH% (or the calling application should treat the directory as if it is on the %PATH%) for this to work right because the .avsi uses a relative path to ffms2.dll.
If using AviSynth+, C plugins do autoload, so nothing extra should be needed for it.