FFmpegSource

[Thunderbolt8]

this might be a stupid question, but where can I find FFV1 so that I can use it as external codec in other kinds of video editing software?

[qyot27]

this might be a stupid question, but where can I find FFV1 so that I can use it as external codec in other kinds of video editing software?
Either you encode it through ffmpeg.exe, or ffdshow-tryouts VfW interface (although ffdshow is way, way outdated; you can't use FFV1v3, you're restricted to v1).

[filler56789]

FFMS2 C-plugin 1140+101 (http://www.mediafire.com/?wkzc7249b6u8d6r)

Many :thanks: again.

I switched to your C-plugin "ages ago" :cool: , and I never looked back :)

[TheRyuu]

FFMS2 v 2.23 - Windows XP

https://drive.google.com/file/d/0BzH7YVbfkU3oWVMzM1RpRWtHblU/view?usp=sharing

Yep, it's working! ;)
There are several dlls you'll need to put in your plugin folder because FFMS2 uses some APIs that are not natively available in XP.
(you may get some "weird" error at the startup, but it's just a warning, it will load)

Dlls are x86 only.

Enjoy! ;)

The official build works on XP. I've no idea how you're building this but it looks very very wrong with those included dependencies. What exactly is wrong with linking to the static runtime? Why are you including Windows system files?

In any case I cannot recommend anyone use this since the official builds should still work perfect fine with XP and don't contain the dll hell that this does. Using the system dll's from this package also has the potential to be dangerous.

[manolito]

FFMS2 C-plugin 1140+101 (http://www.mediafire.com/?wkzc7249b6u8d6r)


Thanks so much for this version, works perfectly on my WinXP Non-SSE2 computer... :thanks:

So far I was using version r1103 because the followup version FFMS2 C-plugin r1110+98 crashed right on startup. But this new version is perfect.
And I've not gotten back to building the C plugin because sometime between December and May(-ish), something started causing Access Violations and I've not had the patience to attempt bisecting it.

Looks like you sorted out these problems, and I really hope that you will continue to provide ffms2 C-Plugins for us poor XP users.

Except for you XP users. HAHAHAHAHAHAHAHAHA
Funny how such a very disrespectful remark triggered a lot of activity in this area...


BTW I tested the official Myrsloik release and the FranceBB release on my old Non-SSE2 machine, and they both did not work. Probably because they both expect a CPU with SSE2 capability.


Cheers and thanks again
manolito

[TheFluff]

Most things started requiring SSE2 years ago. There really isn't much benefit to supporting 15 year old CPU's when SSE2 brings so much useful stuff.

XP is kinda the same, nobody wants to test that shit and maintain additional codepaths (however few they might be) for a 15 year old OS that like three people on d9 use (it's the same three or four people who pop up every time this gets brought up). It's just not worth the effort, so if you want support you better provide it yourself - and do it right, don't ship with this huge pile of DLL garbage you found God knows where.

Sticking to XP is pure obstinacy at this point. If you're concerned about UGH EVIL M$!!! business practices you could just switch to Linux - while it has its own issues, not supporting modern software on old hardware isn't one of them. There's a reason we don't respect XP users: if you insist on using an ancient OS, you should expect to have to use ancient software with it. It's your choice to remain stuck in the past, nobody's forcing you to do it.

[FranceBB]

Use the official ones, don't use mine. I'll remove the link.

Edit: link removed.

Anyway, I'm sure I tried a previous releases (the test build he released before the official ones) and they didn't work in XP saying "it's not a valid C plugin". That's why when he released the new stable version, I didn't even download it, because I was sure they wouldn't have been working anyway. Then I read the comment, so... xD
Anyway, since the official ones work, there's no need to use mine, so I removed the link ;)
Thank you for supporting XP

[qyot27]

Looks like you sorted out these problems, and I really hope that you will continue to provide ffms2 C-Plugins for us poor XP users.
The problem hasn't really been sorted out (I said I was still getting Access Violations when using a couple of the patches not included in the newest build), but whether the problem with Access Violations I was referring to getting hit by in the first half of the year is the same problem with them I'm seeing now, I don't know.

[StainlessS]

It's strange what some people get their knickers in a twist over.
Come on Fluffy, stop living in the past and get on with your own life
(and let others get on with theirs).

[Myrsloik]

You're right, I shouldn't have posted those statements. Without a trigger warning (http://forum.doom9.org/showthread.php?t=127037). I'm so sorry about that. It's really great that we can settle this in a civilized and progressive way.

[FranceBB]

Myrsloik:
TRIGGER WARNING

The posts contained in this thread may be very upsetting for users of old operating systems


lol...
Well, now we have been warned xD

[GMJCZP]

Thank you for your builds, friends.

[Emulgator]

Because I have to maintain and run useful, but partly abandoned, and beautifully working software
from many different years across 8 different machines ranging from 2x XP32ProSP2, 3x XP32ProSP3, 2x Win7U64, 1x Win10...
Many thanks for the joint efforts to support XP, older hardware and the new stuff !

[Kein]

Original:


Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 5mn 8s
Source duration : 5mn 7s
Bit rate mode : Constant
Bit rate : 192 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 7.19 MiB (1%)
Source stream size : 7.19 MiB (1%)
mdhd_Duration : 308000


Processed through FFMS2:

https://i.imgur.com/MilYKbJ.png

Is it, um, supposed to output it like that, pardon the dumb question?

Same recording opened through Vdub's FFMPEG's plugin:

https://i.imgur.com/ZTFWESc.png

[dipje]

what is weird with this output? That it outputs float?

Those audio compression formats are actually always something 'like float' internally. They most often don't have a concept of 'bitdepth' like hard PCM has.

So most decoders output to float if the other side supports it.
You see from that Vdub FFMPEG plugin screenshot that it also outputs to float (fltp) but the plugin directly converts the float to 16-bit integer.

The differences in length I wouldn't worry too much about. Most readers estimate the length by using the detected bitrate and such.

FFMS2 uses the index so it should know the exact number of samples so I'm betting it's the most precise length, the others lengths are estimates.

I (always) might be wrong though :P

[tebasuna51]

I (always) might be wrong though
Nope, you are (here) right.

[leoenc]

Let's say I don't need indexing. How difficult would it be to disable it in the code? Is it completely rooted in the design of ffms?
Is there any reason to expect problems when not indexing? Considering ffms is only used to decode the full source linearly. No trimming, no filters.

[Groucho2004]

Is it completely rooted in the design of ffms?Yes (pretty sure).

Is there any reason to expect problems when not indexing?The decoder won't work.

Considering ffms is only used to decode the full source linearly. No trimming, no filters.
In that case use DSS or AVIsource, no indexing required.

[LigH]

Yes, indexing is a quite important part of FFMS2, it will not rely on container formats having any keyframe index at all, but instead gather positions of all keyframes on its own, which is necessary for quick seeking across the whole movie to be able to know the decoding start position of each GOP (this is even more important when decoding with several threads).

But you can use FFVideoSource(cache=false); in this case, no cache file will be generated, instead a keyframe index will be kept in RAM. Still, it needs to be generated, each time you run the script.

If you don't want indexing at all, but rely on the container having a valid keyframe index (or a source filter handling the source format anyway), you have to use a different source filter. AviSource will use a keyframe index chunk in AVI containers. LSMASHVideoSource does this for ISO Media containers (MP4, MOV, 3GPP...). DSS2 in LAV Filters mode will use a local copy of LAV Filters and rely on their wits to handle the source format. And any DirectShow related source filter will rely on DirectShow ... (usually an "optimistic" solution).

[Myrsloik]

There's basically only one container where you most of the time don't need an index: AVI

This is under the assumption that the container index is correct and that dropped frames duplicate the previous frame. But with all these restrictions you can (more or less) just use the ffmpeg api directly without doing any fancy tricks.

[leoenc]

In that case use DSS or AVIsource, no indexing required.

DSS doesn't support 10-bit with AVIsynth+. ffms does.

[LigH]

Well, if ya ain't got no time for a keyframe index, ya ain't got time for optimal quality either. ;)

[leoenc]

Well, if ya ain't got no time for a keyframe index, ya ain't got time for optimal quality either. ;)

You have a point:)
You can't rush art...

[Myrsloik]

Here's the RC for FFMS 2.23.1 (https://dl.dropboxusercontent.com/u/73468194/ffms2-2.23.1-msvc.7z). The only change is that it's been compiled with a recent FFmpeg which should fix some issues. For example conversion to planar RGB output now works properly.

Report success/failure. I'll make the release official if nothing is broken.

[Atak_Snajpera]

Quick question. Is FFM2 v2.23.1 with Interlaced AVC footage still reports double number of frames?

[dipje]

@Myrsloik It's been a while since I tried FFMS2 builds. I tested 2.23.1 x64 through Vapoursynth. My usual tests are to see if it opens variants of Cineform, Prores and DNXHD OK or not.

I tried Cineform YUV422 P10, Cineform RGB, Prores HQ (422 P10), Prores 4444 without alpha (444 P10) and Prores 4444XQ with and without alpha (444 P10, recently added to ffmpeg so unknown vtag in previous ffms2 builds), and DNXHD 422 P10 and DNXHD 444 P10.

All open OK, but I have issues with Cineform RGB. A recent ffmpeg build (ffprobe) reports it as gbrap12le(10 bpc, bt709, progressive). I see that as planar RGB with alpha (which sounds correct). I don't get why the 'p12' and then the '10 bpc'. Cineform is often named as '12bit RGBA' while internally everything works as 10bpc as far as I know.

ANYWAY (I digress), the issue I have is that if I just try to open it without any special parameters, Vapoursynth (or ffms2, don't really know) gives an error 'Resize error 1026: RGB color family cannot be YUV'. The pixel format of the clip is reported as vs.RGB48. I only get the error while trying to preview / display the clip in Vapoursynth Editor. If I just 'run' the script VapoursynthEditor reports a valid script with RGB48 output. It seems as if it actually gives YUV data but reports it as RGB or the other way around or something? If I open the .vpy script in VDFilterMod (with RGB48) I just get the correct video showing. It seems as if the video output is OK, but wrongly tagged that trips up the preview-code or the resizers in Vapoursynth / VapoursynthEditor.

(I know realize this might also be VapoursynthEditor related which of course is not an official part of Vapoursynth).

If I add the 'format = vs.RGB48' or 'format = vs.RGB30' options the script still won't display in VapoursynthEditor, but if I add 'format = vs.YUV444P16' or 'format = vs.YUV444P10' the script opens and displays fine n VapoursynthEditor. But I don't know if I'm loosing some data or precision now? (Inside of FFMS2 the clip is apparently RGB '12bit' which it puts in RGB48, so if I add the format parameter it gets converted 'inside FFMS2' before being passed to Vapoursynth I guess, so the only thing I'm loosing in precision is RGB to YUV444 conversion I guess.

edit: Tried with L-Smash r921 (latest in the dropbox folder as of now) and it crashes on the Cineform RGB (RGBA) and the prores 4444 XQ Alpha file, so l-smash seems to have an issue with alpha channels so I can't compare. FFMS2 wins for now :)

[Myrsloik]

@Myrsloik It's been a while since I tried FFMS2 builds. I tested 2.23.1 x64 through Vapoursynth. My usual tests are to see if it opens variants of Cineform, Prores and DNXHD OK or not.
...

Are you really using the latest versions of everything? That Vapoursynth Editor issue sounds familiar

[Mystery Keeper]

L-Smash doesn't set correct matrix property for the clip after conversion. It confuses VS internal resize plugin which is used in VSEditor for preview.

[dipje]

I might have an outdated VapoursynthEditor on this machine, hold on let me update (since it only happened with rgb-a with ffms2 didn't think of anything else).

edit: Nope, that's not it. Latest r13 vs editor: Error on frame 0 request: Resize error 1026: RGB color family cannot be YUV

[VS_Fan]

Here's the RC for FFMS 2.23.1 (https://dl.dropboxusercontent.com/u/73468194/ffms2-2.23.1-msvc.7z). The only change is that it's been compiled with a recent FFmpeg which should fix some issues. For example conversion to planar RGB output now works properly.

Report success/failure. I'll make the release official if nothing is broken.
Good: It's working fine reading FFV1 videos (Versions 1 and 3). Previous release of FFMS2 (2.23) crashed immediately.

Thanks

[Myrsloik]

Now it's officially released as 2.23.1. Everyone should update. Should actually be usable as a high bitdepth image source now. Kinda.

[dipje]

So my yuv/rgb issue is classified as a problem with VapoursynthEditor ?

Since it happens only with ffms2 and only with Cineform RGB I thought it was something funky ffms2 was signaling. (Something like 'hey Cineform, that is yuv p10, but then not expecting that recent ffmpeg/libavcodec versions are returning RGB p10 or RGB p12 or something like that )

[Mystery Keeper]

So my yuv/rgb issue is classified as a problem with VapoursynthEditor ?

Since it happens only with ffms2 and only with Cineform RGB I thought it was something funky ffms2 was signaling. (Something like 'hey Cineform, that is yuv p10, but then not expecting that recent ffmpeg/libavcodec versions are returning RGB p10 or RGB p12 or something like that )There's no problem with VapourSynth Editor. There's problem with L-SMASH.
Instead ofres = core.lsmas.LWLibavSource(a,threads = 1,format = "RGB48")Usesrc_file = r"D:\vstests\遊魂 2 -you're the only one- 遊戲開場動畫（中文字幕版）.mp4"
src = core.lsmas.LWLibavSource(src_file, threads = 1)
src = core.resize.Spline16(src, format=vs.RGB48)

[LigH]

Is FFIndex (either in ffms2.dll or via ffmsindex.exe) able to support a list of VOB segments as source (like DGMPGDec does), if not even an IFO (ideally with a PGC/angle definition, or at least a PGC/angle VOB set stripped by the ripper in IFO/movie mode or PGCDemux), and an MPLS Blu-ray playlist?

If not yet ... where is the recommendable place to add such a feature request?
__

P.S.: Exists already... (http://code.google.com/p/ffmpegsource/issues/detail?id=78)

It's been on the todo list for ages, issue #33 (http://code.google.com/p/ffmpegsource/issues/detail?id=33) is an even older feature request for the same thing.

Phew, 4 years ago already. And since converters are moving towards 64 bit, the existence of source plugins supporting DGMPGDec indexes (*.d2v) could be useful. :rolleyes:

[dipje]

There's no problem with VapourSynth Editor. There's problem with L-SMASH.


.. but we're talking about ffms2 here, not l-smash.

[Jamaika]

@Myrsloik It's been a while since I tried FFMS2 builds. I tested 2.23.1 x64 through Vapoursynth. My usual tests are to see if it opens variants of Cineform, Prores and DNXHD OK or not.

I tried Cineform YUV422 P10, Cineform RGB, Prores HQ (422 P10), Prores 4444 without alpha (444 P10) and Prores 4444XQ with and without alpha (444 P10, recently added to ffmpeg so unknown vtag in previous ffms2 builds), and DNXHD 422 P10 and DNXHD 444 P10.

All open OK, but I have issues with Cineform RGB. A recent ffmpeg build (ffprobe) reports it as gbrap12le(10 bpc, bt709, progressive). I see that as planar RGB with alpha (which sounds correct). I don't get why the 'p12' and then the '10 bpc'. Cineform is often named as '12bit RGBA' while internally everything works as 10bpc as far as I know.

If I add the 'format = vs.RGB48' or 'format = vs.RGB30' options the script still won't display in VapoursynthEditor, but if I add 'format = vs.YUV444P16' or 'format = vs.YUV444P10' the script opens and displays fine n VapoursynthEditor. But I don't know if I'm loosing some data or precision now? (Inside of FFMS2 the clip is apparently RGB '12bit' which it puts in RGB48, so if I add the format parameter it gets converted 'inside FFMS2' before being passed to Vapoursynth I guess, so the only thing I'm loosing in precision is RGB to YUV444 conversion I guess.

edit: Tried with L-Smash r921 (latest in the dropbox folder as of now) and it crashes on the Cineform RGB (RGBA) and the prores 4444 XQ Alpha file, so l-smash seems to have an issue with alpha channels so I can't compare. FFMS2 wins for now :)
Never converts RGB48 to RGBxx CineForm, ProRes or DNxHD. This is absurd.
There are limitations with the colormatrix. ProRes is always in RGB BT601 and CineForm BT709.
The sony vegas 14 is illegal and incorrect operation. Even using the V210 or R210 then I would use yuv422p10le.
In my opinion this is not a problem editors only muxing encoders.

[Myrsloik]

Phew, 4 years ago already. And since converters are moving towards 64 bit, the existence of source plugins supporting DGMPGDec indexes (*.d2v) could be useful. :rolleyes:

It's stuck in "patches welcome" land. I never need it and now we have d2vsource as well...

[LigH]

... for VapourSynth. And what do users of AviSynth+ 64-bit use?

:eek: Oh, there is one (http://forum.doom9.org/showthread.php?p=1374605).

[Reel.Deel]

... for VapourSynth. And what do users of AviSynth+ 64-bit use?

:eek: Oh, there is one (http://forum.doom9.org/showthread.php?p=1374605).

MPEG2DecPlus: https://github.com/chikuzen/MPEG2DecPlus
Binary here (https://kuroko.fushizen.eu/bin/mpeg2decplus-0.1.1.zip); this version is for AVS+ only, support for avs 2.6 was added but you'll have to compile it yourself.

[dipje]

Never converts RGB48 to RGBxx CineForm, ProRes or DNxHD. This is absurd.
There are limitations with the colormatrix. ProRes is always in RGB BT601 and CineForm BT709.
The sony vegas 14 is illegal and incorrect operation. Even using the V210 or R210 then I would use yuv422p10le.
In my opinion this is not a problem editors only muxing encoders.

Not sure what you're saying here. I'm trying to load Cineform files.
A simple core.ffms2.Source() seems to return RGB48 for the Cineform files (reported as 12bpp RGB, so I guess it makes it 16bpp RGB because no support for 'RGB36'), but somehow still sets the format-tag to something YUV based which trips up the resizers in Vapoursynth which means I can't convert / resize it to anything.

edit:
Btw: (not to try to prove you wrong, but more to explain to me how it could be :))
I'm in After Effects (which doesn't understand the concept of YUV, it's completely RGB compositer), I make a little comp, export it yo ProRes 4444.
With ffms2 I load the file into Vapoursynth which returns it as '4444'. I convert it with fmtconv to RGB _with specifying the bt709_ color matrix. The end result in RGB is _exactly_ the same as my After Effects start. So the file seems to be bt709.
Ffmpeg had a time (or still does?) where it writes incorrect bt601 matrix-tags in the output file for ProRes, but those are ignored (in FCPX and the Adobe suite at least) anyway.

As another example, I can load a .MTS AVCHD file from one my cameras, which opens as YUV420P8. I use fmtconv to 'convert' it to YUV422P10. That YUV422P10 I pass to ffmpeg to encode to prores.
When I then load the original .MTS file and my ffmpeg-generated .mov file in After Effects and toggle the layers on and off, I see no differences. Which to me also seems to suggest the Prores data is bt709 and being interpreted as bt709. (The AVCHD .mts file is bt709 for sure).

[Jamaika]

Not sure what you're saying here. I'm trying to load Cineform files.
A simple core.ffms2.Source() seems to return RGB48 for the Cineform files (reported as 12bpp RGB, so I guess it makes it 16bpp RGB because no support for 'RGB36'), but somehow still sets the format-tag to something YUV based which trips up the resizers in Vapoursynth which means I can't convert / resize it to anything.
Maybe yes, maybe no.
I don't like to use Cineform becose the codec leaves sharp edges when converting RGB to YUV or YUV to RGB.
Examples of conversion in Sony Vegas 14. I do not have the ability to change parameters color range and matrix:
RGB48 to BlackMagic R210 --> The result far removed from the source. All colors changed.
RGB48 to Sony V210 --> Changed color range with PC to TV. Supposedly as standard.
RGB48 to Cineform yuv422p10le --> OK
RGB48 to Magix_prores_hq --> Changed color range with PC to TV. Supposedly as standard.

PS Codecs 10/12 bit don't have a color matrix bt2020nc.;)

[dipje]

Well, that's all fine and all, but it doesn't explain why I can't convert or resize Cineform RGB loaded files in Vapoursynth.
Saying why you don't like a codec doesn't help in figuring out if there is a bug in Vapoursynth, ffms2 or in my process :).

(btw, no color casts or changes here. Compared the native Cineform encoder/decoder in Adobe suite to other near-lossless intermediate codecs that I have access to (DNHD/DNXHR is now native in Adobe suit as well) and looked at them through 'difference maps'. No sharp edges and no visual differences at all. Looking at difference-maps when testing yuv422 codecs will of course show the differences at the edges in color-details because of the lower chroma resolution, but all yuv422 codecs have that. ffmpeg prores_ks with -q:v 3 together with the mirazon-prores suite on PC actually gave the least differences, specially considering the bitrate. But I have to use an outdated abonded 3rd party prores-codec to export it from Adobe suite and other programs. Cineform had a bit more differences, but they were much less in intensity and very natural over the image. Looking at the image while pixel-peeping I rated them in Cineform-first, prores 2nd, dnxhd last. The cineform files were a bit bigger though so it's a bit cheating).

[Selur]

What's the latest C Plugin version of ffms2 and where to get it?

[Groucho2004]

What's the latest C Plugin version of ffms2 and where to get it?qyot27 is the one who builds these so you go back a few posts in this thread and eventually arrive at this one (https://forum.doom9.org/showthread.php?p=1783312#post1783312). :)

[Selur]

Thanks totally overlooked that when I was scrolling back the posts,.. :)

[Selur]

Small question when using FFmpegSource in Vapoursynth.
When I use:
clip = core.ffms2.Source(source="C:/Users/Selur/Desktop/Test.ts",cachefile="H:/Temp/ts_6172c2a2969c38a25728d49450effe0d_491.ffindex",fpsnum=50)
my source get's decoded properly, when set a format using:
clip = core.ffms2.Source(source="C:/Users/Selur/Desktop/Test.ts",cachefile="H:/Temp/ts_6172c2a2969c38a25728d49450effe0d_491.ffindex",fpsnum=50,format=vs.YUV420P8)
I get an error.
The whole script is:
# Imports
import vapoursynth as vs
core = vs.get_core()
# Loading Plugins
core.std.LoadPlugin(path="G:/Hybrid/vsfilters/SourceFilter/FFMS2/ffms2.dll")
# Loading C:\Users\Selur\Desktop\Test.ts using FFMS2
clip = core.ffms2.Source(source="C:/Users/Selur/Desktop/Test.ts",cachefile="H:/Temp/ts_6172c2a2969c38a25728d49450effe0d_491.ffindex",fpsnum=50,format=vs.YUV420P8)
# Output
clip.set_output()
and the error I get is:
Failed to evaluate the script:
Python exception: 'list' object has no attribute 'set_output'
Traceback (most recent call last):
File "src\cython\vapoursynth.pyx", line 1491, in vapoursynth.vpy_evaluateScript (src\cython\vapoursynth.c:26905)
File "H:\Temp\encodingTempSynthSkript_22_51_09_5510.vpy", line 9, in <module>
clip.set_output()
AttributeError: 'list' object has no attribute 'set_output'

=> how to properly set the format ?

Cu Selur

[Myrsloik]

Look at the output. You get an array of two clips. Pick one. Or set alpha to false.

[Selur]

Thanks!

[qyot27]

FFMS2 C-plugin r1140+105-avs+vsp

Optimized for Pentium-III and SSE (32-bit)
Optimized for Core2 (64-bit)

ffmpeg version r83723 git-9ae762d Copyright (c) 2000-2017 the FFmpeg developers
built with gcc 6.3.0 (GCC)
libavutil 55. 47.101 / 55. 47.101
libavcodec 57. 82.100 / 57. 82.100
libavformat 57. 66.103 / 57. 66.103
libavfilter 6. 74.100 / 6. 74.100
libavresample 3. 2. 0 / 3. 2. 0
libswscale 4. 3.101 / 4. 3.101
libswresample 2. 4.100 / 2. 4.100
libpostproc 54. 2.100 / 54. 2.100

32-bit 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-devices
--disable-avdevice
--cpu=pentium3
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3'
--target-os=mingw32
--arch=x86

64-bit configuration:
--prefix=/home/qyot27/win64_build
--cross-prefix=x86_64-w64-mingw32-
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--disable-encoders
--disable-muxers
--disable-doc
--disable-debug
--disable-devices
--disable-avdevice
--cpu=core2
--extra-cflags='-march=core2'
--target-os=mingw32
--arch=x86_64

Now supporting almost all of the new pix_fmts in AviSynth+. High bit depth in/out works, also YUVA, Planar RGB, and Planar RGBA are outputting green video - they don't crash, though. Not sure if that's due to something that needs fixing in FFMS2 or in AviSynth+ (r2420 was used for the tests).

I'm pretty certain now that the issues I was having with previous builds when trying to use the AviSynth+ header were caused by GCC miscompiling things, because Debug builds (-g) work, but Release builds immediately crash. Of course, even with Debug builds mostly working, there's some kind of issue with crashes on exit, which I wouldn't be surprised to find is also being caused by GCC miscompiling it.

AviSynth 2.6 will not work with this build. I may be able to avert this with the same sort of tactic I used to make Libav and FFmpeg distinguish between 2.6 and Plus. Because of this and the crash-on-exit thing mentioned above, I've also left the previous non-Plus build available.

EDIT 2018-01-02: Newer build available. (https://forum.doom9.org/showthread.php?p=1829061#post1829061)

[Atak_Snajpera]

Is this normal that in latest ffms2 2.23.1 all frames in VC-1 are detected as keyframes?
Example
# keyframe format v1
fps 0
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

FFMS 2.20
# keyframe format v1
fps 0
0
1
25
49
53
77
101
106
130
154
178
202
226
250
274
298
322
346
370
394
418
442
466
490