FFmpegSource

[Groucho2004]

Process exits with error: 0xC000007B STATUS_INVALID_IMAGE_FORMAT (-1073741701)That usually indicates the attempt to load a DLL with bitness mismatch (loading a 32 bit plugin with 64 bit Avisynth or vice versa).

[Gser]

That usually indicates the attempt to load a DLL with bitness mismatch (loading a 32 bit plugin with 64 bit Avisynth or vice versa).

That's one hellava misleading error. Seems the package only included the 32-bit version of ffmsindex. The updated ffmpegsource seems to work fine otherwise

[Groucho2004]

That's one hellava misleading error. Seems the package only included the 32-bit version of ffmsindex. The updated ffmpegsource seems to work fine otherwise
Yeah, the verbose message text from ntstatus.h is just as misleading:
// MessageId: STATUS_INVALID_IMAGE_FORMAT
//
// MessageText:
//
// {Bad Image}
// %hs is either not designed to run on Windows or it contains an error. Try installing the program again using the
// original installation media or contact your system administrator or the software vendor for support.
//
#define STATUS_INVALID_IMAGE_FORMAT ((NTSTATUS)0xC000007BL)

[LigH]

Check with DependencyWalker, load ffms2.dll in each specific bitness...

They require several API-MS-WIN-CORE-WINRT-*.DLL; are they unavailable in Windows 7? Several other API-MS-WIN-CORE-*.DLL are available, though.

This build is possibly not really independent of Visual Studio, or expects a newer Windows generation (WinRT is a hint, I guess).
_

Or maybe I am wrong, and they are only very indirect dependencies.

For me the AviSynth plugins seem to work. And they can create an index without the separate indexer too.

[l33tmeatwad]

That's one hellava misleading error. Seems the package only included the 32-bit version of ffmsindex. The updated ffmpegsource seems to work fine otherwiseThe original project files had ffmsindex disabled for the x64 build and I wasn't sure if that was on purpose so I just didn't include it. I can enable it and compile it as well.

[LigH]

I wonder if a separate indexer is really necessary. I believe it doesn't require the ffms2.dll itself (maybe the shared libav DLL's if it was built shared as well), and it will use an own 32 bit process which shall run on both a 32 and 64 bit Windows. So having it included in the package should be merely convenient for those {users who / applications which} run it explicitly.

[Gser]

I wonder if a separate indexer is really necessary. I believe it doesn't require the ffms2.dll itself (maybe the shared libav DLL's if it was built shared as well), and it will use an own 32 bit process which shall run on both a 32 and 64 bit Windows. So having it included in the package should be merely convenient for those {users who / applications which} run it explicitly.

It appears MeGUI does require the 64-bit version.

[l33tmeatwad]

It appears MeGUI does require the 64-bit version.I'll get it compiled when I get the chance. Is the current static binaries of 2.23.1 on the official repository not with FFMPEG 4.0? The shared libs build I did was just kinda....because I could, lol.

[LigH]

Release version 2.23.1 on github (https://github.com/FFMS/ffms2/releases) reports: "myrsloik released this on 18 Oct 2016". Do you know any newer (except your own)? MeGUI (32 bit) uses the same, according to its file date.

[l33tmeatwad]

Release version 2.23.1 on github (https://github.com/FFMS/ffms2/releases) reports: "myrsloik released this on 18 Oct 2016". Do you know any newer (except your own)? MeGUI (32 bit) uses the same, according to its file date.Oh, I suppose I should read...I guess not, I'll make sure to get that ffmsindex compile today then.

[l33tmeatwad]

Since there seemed to be interest...

FFMS2 2.23.1 (w/ FFmpeg 4.0)
Static Libs Build (x86 & x64) (http://www.mediafire.com/file/6e7ayxj6q8h7224) | Shared Libs Build (x86 & x64) (http://www.mediafire.com/file/dffpprzgud9xid6/) | Sources (https://www.mediafire.com/folder/3tv37w2c9ibps/Source)

Build Notes:
Compiled with Microsoft Visual Studio 2015
Shared Libs & Include Files were copied to the Visual Studio Directories in: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
Patch included with previous releases was applied to FFmpeg before compiling.

Static FFmpeg compiled with:
./configure --toolchain=msvc --enable-gpl --enable-version3 --disable-encoders --disable-programs --disable-filters \
--disable-network --disable-doc --disable-avdevice --disable-swresample --disable-postproc --disable-avfilter --enable-avresample
make install
Shared Libs FFmpeg compiled with:
./configure --toolchain=msvc --enable-gpl --enable-version3 --enable-shared --disable-encoders --disable-programs --disable-filters \
--disable-network --disable-doc --disable-avdevice --disable-swresample --disable-postproc --disable-avfilter --enable-avresample
make install

Visual Studio Project Modifications (Static Build)
Project Properties > Configuration Properties > Linker > Input
- Additional Dependencies: bcrypt.lib;

Changes to libs.cpp (Both Builds)
#pragma comment(lib, "zlibstat.lib")

Changes to libs.cpp (Shared Libs)
#pragma comment(lib, "avutil.lib")
#pragma comment(lib, "avcodec.lib")
#pragma comment(lib, "avformat.lib")
#pragma comment(lib, "swscale.lib")
#pragma comment(lib, "avresample.lib")

Included Libs:
LibAV (from FFmpeg 4.0) (https://github.com/ffmpeg/ffmpeg/releases)
zlib 1.2.11 (http://zlib.net)

Other Software:
MSYS2 (https://www.msys2.org/) (i686 & x86_64)
Yasm 1.3.0 (http://yasm.tortall.net/Download.html) (General Use Executables)

[Myrsloik]

Since there seemed to be interest...
Insert compiled stuff here

Feel free to compile a current git master as well. I've simply been too busy and it'll probably have fixed a lot of issues for some peopl.e.

[ChaosKing]

@l33tmeatwad VS chrashes instantly with no error. Tried with static and shared build, Vapoursynth x64. But it creates an index file.

[l33tmeatwad]

@l33tmeatwad VS chrashes instantly with no error. Tried with static and shared build, Vapoursynth x64. But it creates an index file.That's odd, I just installed VapourSynth and was able to preview a script in VapourSynth Editor and encode it through FFmpeg using the static build plugin.

[poisondeathray]

ffms2 static x64 compiled by l33tmeatwad, VS x64 works for me too. Win8.1

Thanks.


@ChaosKing - did older ffms2 crash too with that source?


-This newer ffms2 also decodes some VP9 variants that older ffms2's had problems with
-But still problems with interlaced VC-1

[ChaosKing]

I tried different videos, it's always the same. My cpu is a Ryzen 1700.
The old ffms2 work fine with all tested videos.

[l33tmeatwad]

I tried different videos, it's always the same. My cpu is a Ryzen 1700.
The old ffms2 work fine with all tested videos.What OS are you using?

[ChaosKing]

Win10 x64 Pro 17134 (the latest one)

[l33tmeatwad]

Win10 x64 Pro 17134 (the latest one)Could you give an error log? Also, what version of vcredist do you have installed?

[ChaosKing]

I haven't changed anything but now it's working O_O
I know that I restarted my pc, tried it in vs editor and with vspipe. It didn't work ... and now magically it works.

[ChaosKing]

Not that I need this, but I noticed that your ffms2 dll can not load http links like this:
clip = core.ffms2.Source("https://www.animemusicvideos.org/guides/avtech31/images/avs/rainbow-orig.jpg").std.DuplicateFrames([0]*20)
It works with Myrsloiks ffms2 dll.

[l33tmeatwad]

Not that I need this, but I noticed that your ffms2 dll can not load http links like this:
clip = core.ffms2.Source("https://www.animemusicvideos.org/guides/avtech31/images/avs/rainbow-orig.jpg").std.DuplicateFrames([0]*20)
It works with Myrsloiks ffms2 dll.I disabled a few things to reduce the size of the dependencies so that probably does not work because when compiling FFmpeg I used the option "--disable-network".

[ChaosKing]

@l33tmeatwad I know now why I had crashes with your ffms2 version. It crashes with a "Basic Windows bitmap format" avi.
I have one script where a logo.avi is imported with a BMP format and I didn't realise this immediately.


Writing application : Adobe After Effects CC 2018 (Windows)

Video
ID : 0
Format : RGB
Codec ID : 0x00000000
Codec ID/Info : Basic Windows bitmap format. 1, 4 and 8 bpp versions are palettised. 16, 24 and 32bpp contain raw RGB samples
Duration : 12 s 971 ms
Bit rate : 922 Mb/s
Width : 1 484 pixels
Height : 1 080 pixels
Display aspect ratio : 1.374
Frame rate : 23.976 (24000/1001) FPS
Bit depth : 8 bits
Bits/(Pixel*Frame) : 24.000
Time code of first frame : 00:00:00:00 / 00:00:00:00
Time code source : Adobe tc_A / Adobe tc_O
Stream size : 1.39 GiB (100%)

[LigH]

For such uncompressed DIB AVI sources, AviSource() is by far superior, because it lets Windows decode a bitmap format it knows best. FFMS2 is more suitable for compressed source formats.

A severe problem for AviSynth is reading video sources with a low number of palette colors. It does not support such indirect palette color modes, only "direct color" formats.

[poisondeathray]

I can replicate ChaosKing's issue with uncompressed 8bit RGB

some other observations (only x64 vpy versions tested, partly because his original crash was in vapoursynth). Tested both 1484x1080 and 1920x1080 (in case it was some weird frame dimension component contributing). And export from vdub2 (in case some weird metadata component was contributing from Adobe/AE)

l33tmeatwad => crash
ffms2000-test8 => ok
ffms2-2.23.1-msvc => crash
ffms2-2.23-clang => crash


And AVISource works fine on Win as expected, but do linux/mac users have access AVISource() in vapoursynth ?

[LigH]

Probably not as in "use VfW - ICM", because it won't require WINE, it would have to interpret DIB frames on its own ... apart from that, I don't know VapourSynth well, I don't know if it can handle palette color modes at all. If it does, basically, then you should convert it to a direct color mode ASAP.

[ChaosKing]

NICE! Some avi files that I tested yesterday that had problems with random seeking are now fixed too. thx

I get 50fps with "Holi Festival" 1080p from here https://www.elecard.com/videos

[zambelli]

Two questions about the colorspace parameter of FFVideoSource():

1. if an interlaced YUV 4:2:0 video is loaded with a colorspace parameter where the requested colorospace requires YUV 4:2:0 to be upsampled to 4:2:2 or 4:4:4 - e.g. "YUV422P10" or "YUV444P8" - does FFMS2 automatically decide whether to use progressive or interlaced chroma upsampling for each frame? Let's assume the interlaced video has proper metadata describing its interlaced coding methods.

2. if a YUV video is loaded with a colorspace parameter where the requested colorspace is RGB - e.g. "RGB24" or "RGBP10" - does FFMS2 automatically determine whether to use Rec.601, Rec.709 or Rec.2020 based on detected metadata? Or does it always default to one of them?

[Myrsloik]

Two questions about the colorspace parameter of FFVideoSource():

1. if an interlaced YUV 4:2:0 video is loaded with a colorspace parameter where the requested colorospace requires YUV 4:2:0 to be upsampled to 4:2:2 or 4:4:4 - e.g. "YUV422P10" or "YUV444P8" - does FFMS2 automatically decide whether to use progressive or interlaced chroma upsampling for each frame? Let's assume the interlaced video has proper metadata describing its interlaced coding methods.

2. if a YUV video is loaded with a colorspace parameter where the requested colorspace is RGB - e.g. "RGB24" or "RGBP10" - does FFMS2 automatically determine whether to use Rec.601, Rec.709 or Rec.2020 based on detected metadata? Or does it always default to one of them?

1. Maybe? Probably not? You should never use the internal conversion if at all possible anyway. That's my recommendation.

2. Maybe? Probably not? You should never use the internal conversion if at all possible anyway. That's my recommendation.

I hope that helps. Don't use the internal conversion. It only exists to give you the least bad output compromise based on the source format.

[Stereodude]

Is this the best plugin to use for opening a file with VP9 video? Also, does it support high-bit-depth AVIsynth+ color formats if the source is >8-bits?

[LigH]

VP9 should be supported by at least either FFMS2 or L-SMASH Works. Probably both.

[sneaker_ger]

Also, does it support high-bit-depth AVIsynth+ color formats if the source is >8-bits?
It does (automatically).

[Stereodude]

VP9 should be supported by at least either FFMS2 or L-SMASH Works. Probably both.
Am I allowed to ask why FFMS2 returns extra duplicated frames and an odd framerate for VP9 from YouTube? The same VP9 decodes with the LAV filters in MPC-HC without the duplicated frames and at the expected frame rate.

[LigH]

To let the developers check for reasons, it may be useful to provide a sample video ID hash and format ID number for youtube-dl... and did you compare with LwLibavVideoSource?

[Stereodude]

To let the developers check for reasons, it may be useful to provide a sample video ID hash and format ID number for youtube-dl... and did you compare with LwLibavVideoSource?
LwLibavVideoSource seems to decode it correctly. nGncW_ueyHA / 248

Using LwLibavVideoSource AVSmeter64 reports:
Number of frames: 12773
Length (hh:mm:ss.ms): 00:08:52.741
Frame width: 1920
Frame height: 1080
Framerate: 23.976 (24000/1001)

Using FFMS2 AVSmeter64 reports:
Number of frames: 13304
Length (hh:mm:ss.ms): 00:08:39.229
Frame width: 1920
Frame height: 1080
Framerate: 25.623 (250000/9757)

[Selur]

32bit version too please. :)

[ChaosKing]

Thx. I guess libdav1d will only be available in v4.2?

[Taurus]

32bit version too please. :)
Yes, please!

[LigH]

And L-SMASH Works too... ah, sorry, off-topic :o

[ChaosKing]

Thx for compiling ffms2 with dav1d. Sadly the decoding of av1 files looks broken. pink blocks etc.
But I get 200fps with dav1d and no seeking issues xD

[ChaosKing]

https://forum.doom9.org/showthread.php?p=1866894#post1866894
Looks fine with libaom. But I can't be sure that rav1e produced 100% valid encodes.

[ChaosKing]

I made an encode with the linked rav1e.exe: The image just "freezes" after ~20 frames with dav1d (but no pink blocks anymore). No problems with libaom. So is it a decoder or encoder issue?
https://www.dropbox.com/s/2dznywf410qoabe/rav1e_b_180.ivf?dl=1

[sneaker_ger]

The sample decodes fine through ffmpeg and ffplay with libdav1d 0.2.0.

[qyot27]

It might be related to this PR that has to do with fixing FFMS2's handling of VP9 (https://github.com/FFMS/ffms2/pull/323); the most recent note is that fixing the PR is probably needed for AV1 now too.

Read: it may have nothing to do with the encoder or the decoder, but about the ability of FFMS2 to use the FFmpeg API to parse the bitstream in the correct way, and certain encoder/decoder combinations expose errant behavior in the parser. This would explain why ffplay (or mpv) works fine on the same sample and the same build of libdav1d that FFMS2 uses, but FFMS2 exhibits problems.

[masterkivat]

ffms2-7c36121-win64 (https://drive.google.com/open?id=1uu38YBCStzE0Od0D7n5OWECxUzz7xQGp)

Libraries:
FFmpeg 4.2-dev-93293-gdb332832a1
libdav1d 0.2.1-e29cb9af
libvpx 1.8.0-198-gaba995832
libxml2 2.9.9
openssl 1.1.1b

Thanks HolyWu for the meson build system :)
this can be used on Vapoursynth? (like, renaming libffms2.dll to ffms2.dll and put on 'plugins64'?)

[ChaosKing]

this can be used on Vapoursynth? (like, renaming libffms2.dll to ffms2.dll and put on 'plugins64'?)

Yes, it even works without renaming. :eek:

[ChaosKing]

No decoding issues with this build. I get 66fps. With the previous build https://forum.doom9.org/showthread.php?p=1866411#post1866411 it's under 40fps, so a nice increase at least!

[qyot27]

It might be related to this PR that has to do with fixing FFMS2's handling of VP9 (https://github.com/FFMS/ffms2/pull/323); the most recent note is that fixing the PR is probably needed for AV1 now too.

Read: it may have nothing to do with the encoder or the decoder, but about the ability of FFMS2 to use the FFmpeg API to parse the bitstream in the correct way, and certain encoder/decoder combinations expose errant behavior in the parser. This would explain why ffplay (or mpv) works fine on the same sample and the same build of libdav1d that FFMS2 uses, but FFMS2 exhibits problems.
Now that I've had some time, I can confirm that yes, those patches (after being adjusted to also handle AV1 in addition to VP9) do appear to fix the problems FFMS2 has with AV1 through libdav1d. No apparent freezing, no corrupted blocks with the test sample I'd been using (https://www.youtube.com/watch?v=2nXYbGmF3_Q).

Of course, it's probably a case of the patches needing to be reworked differently from their current state, so...

[ChaosKing]

ffms2-7c36121-win64 (https://drive.google.com/open?id=18W6Hg1xEf78FOvL5lFp_YFQAQ368K15W)

New build with libdav1d and also applied the modified patch.

Libraries:
FFmpeg 4.2-dev-93320-g5ab44ff20c
libdav1d 0.2.1-7f7b5586
No more corrupted blocks and ~280fps with 1080p, tested video was encoded with rav1e.

[filler56789]

*bump* :)

32bit version too please. :)