FFmpegSource

[Boulder]

Nope, seems to be v9.20.

Digging some older threads revealed that "As for the 0x7E error, as IanB said, you seem to be missing a CPP runtime." So which runtime is required? I have quite a few of them installed but not the correct one, it seems.

[LigH]

There is only one reference to MSCVRT.DLL in it. No version.

But I also had error 0x7e when I mistyped the directory where to load the DLL. Check it over. Don't rely on autoloading.

[Boulder]

I did that too, putting the dll file to a separate directory and edited the script accordingly.

My msvcrt.dll is dated 16.12.2011 if that's of any help.

[qyot27]

The C plugin doesn't rely on a specific msvcrt, because it was built with GCC. Or rather, it ties it to the generic msvcrt that MinGW-w64 assumes the use of.

The 7z archive was actually packed with 9.32 alpha, so that might have an impact beyond the LZMA2 situation (or maybe not).

C-plugins autoload under AviSynth+ (making the following explanation a moot point), but under 2.5 and 2.6 they do not autoload, which is the reason that LoadCPlugin("ffms2.dll") is included in FFMS2.avsi (it merely mimics autoloading, and being tied to the relative position of the .dll is why it has to be in the same folder in order to work).

[LigH]

I have it installed in a sub-directory below AviSynth 2.5\plugins, so it is not auto-loadable even if it was a generic AviSynth 2.5+ plugin (other not VapourSynth compatible FFMS2 builds were compiled in this format).

In one of my last scripts, I only imported FFMS2.avsi from this sub-directory, and the plugin was correctly loaded by its integrated LoadCPlugin command in AviSynth MT 2.60 a5.

But while I mistyped the directory where to load the import (or the plugin explicitly), I got the "could not load plugin" error 0x7e too.

[Zathor]

There seems to be a memory leak in the ffms2_r827+36-avs+vsp plugin. When opening and closing a script in VirtualDub or MeGUI the memory will be increased during every loop. This happens with AVS 2.5.8 and AVS+ r1576 - but not with FFMS 2.19.

Also I get sometimes the message that it has been tried to read unprotected memory (even at the first loop). 2.19 is rock stable in my environment.

Script is e.g.:
LoadCPlugin("C:\MeGUI\tools\ffms\ffms2.dll")
FFVideoSource("C:\test.mkv", fpsnum=24000, fpsden=1001, threads=1)

Anyone else observing this?

[Boulder]

I have it installed in a sub-directory below AviSynth 2.5\plugins, so it is not auto-loadable even if it was a generic AviSynth 2.5+ plugin (other not VapourSynth compatible FFMS2 builds were compiled in this format).

In one of my last scripts, I only imported FFMS2.avsi from this sub-directory, and the plugin was correctly loaded by its integrated LoadCPlugin command in AviSynth MT 2.60 a5.

But while I mistyped the directory where to load the import (or the plugin explicitly), I got the "could not load plugin" error 0x7e too.
I got the plugin working, I had to create a folder outside the Avisynth plugins folder and put ffms2.dll there and edit the path accordingly. I don't know why using a folder called "cplugins" under the plugins folder and loading it from there didn't work.

Zathor: I've observed some errors with VirtualDub when using F2 to reload the script, maybe they are related.

[qyot27]

Okay, I can reproduce the memory increases with the C-plugin, but not with MSVC 2010 builds of r827. Using AviSynth+ r1695. What this means is that I actually need to do more digging:
*It could be a problem in FFMS2's AviSynth C code.
Does it happen with previous builds of the C plugin?

*It could be a compilation problem in either FFmpeg, or FFMS2.
This means I'll have to experiment with the build options. If it lies in here, I have an idea of what might be the issue based on the instructions given in FFMS2's documentation.

*It could be a problem in FFmpeg that may have affected the particular revision r827+36 was built against, and it's since been corrected.
Again, requires a newer or different build to show that it only cropped up recently.

*It could be a problem inherent to AviSynth's C interface, in which case it needs to be fixed in AviSynth+.
This just means it needs to be reported upstream.


I'll admit that I never encountered a problem with this (despite being on a setup with only 512 MBs of RAM) because I don't usually close and re-open scripts repeatedly.


I'll go ahead and post the MSVC 2010 test build:
ffms2_r827-msvc2010.7z (http://www.mediafire.com/?6phncxgalxxwtd3)

ffmpeg version N-61679-g87ecefd Copyright (c) 2000-2014 the FFmpeg developers
built on Mar 22 2014 04:25:45 with Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86
libavutil 52. 67.100 / 52. 67.100
libavcodec 55. 52.102 / 55. 52.102
libavformat 55. 34.101 / 55. 34.101
libavdevice 55. 11.100 / 55. 11.100
libavfilter 4. 3.100 / 4. 3.100
libavresample 1. 2. 0 / 1. 2. 0
libswscale 2. 5.102 / 2. 5.102
libswresample 0. 18.100 / 0. 18.100
libpostproc 52. 3.100 / 52. 3.100

configuration:
--toolchain=msvc
--enable-gpl
--enable-version3
--enable-avresample
--disable-encoders
--disable-muxers
--disable-doc
--disable-debug
--disable-network
--disable-hwaccels
--disable-indevs
--disable-outdevs
--extra-cflags=-I/msinttypes
It lacks Opus decoding support because I couldn't manage to get FFmpeg to see libopus when using --toolchain=msvc, despite trying both an MSVC build of libopus and a normal GCC build of it, and fiddling with the extra-cflags/ldflags and whatnot. Something more is required here.

It is a slightly newer build of FFmpeg, though, as I'd actually built it for LSMASHSource.

[Zathor]

Thank you very much for your work.

I can confirm that the MSVC plugin does not have the problem. But I have to make more test runs over the next days. I usually encounter the problem when I convert ~30 videos with MeGUI as for every file encoding the script will be opened and closed ~10 times (fps detection, cropping, automatic deinterlacing, ...) - likely this is not needed and could be optimized in the MeGUI process but it should work the way it is and is a good detection of plugin problems ;)

I cannot test it with old C plugins. Do you have an older build available? You have modified your last post here so that the download is not available anymore. But if I remember correctly I had a similar problem with it (the cannot write protected memory error) and that was the reason why I had not added it to MeGUI.

[sqrt(9801)]

I just get a "Unable to load C Plugin" error with that one :( ffms2.dll is in the Avisynth plugins folder along with the ffms2.avsi script.

Got the same error when trying to open a script in VirtualDub v1.10.4. It looks like getting rid of FFInputDriver solves the issue, somehow.

[qyot27]

I cannot test it with old C plugins. Do you have an older build available? You have modified your last post here so that the download is not available anymore. But if I remember correctly I had a similar problem with it (the cannot write protected memory error) and that was the reason why I had not added it to MeGUI.
C-plugin builds of 2.16 and 2.17 are available from the Google Code site:
https://code.google.com/p/ffmpegsource/downloads/list?can=1&q=cplugin&colspec=Filename+Summary+Uploaded+ReleaseDate+Size+DownloadCount

I didn't build them, but if those show the issue, then it'll at least show that it's not something recent.

My own limited tests still show it with a brand new FFmpeg, so it's not that, and the -D_SYSCRT option mentioned in the FFMS2 docs didn't seem to have an effect.

This narrows it down to it being in the C plugin, it being a problem with AviSynth's C interface itself, or something that occurred to me yesterday, a side-effect of linking in a static version of libgcc (which could explain why the memory increase happens in roughly equal chunks, although I'm not sure why that would result in memory not being freed when the script closes, aside from the fact that VirtualDub keeps AviSynth.dll and DevIL.dll loaded even after the user closes the script).

The solution for that last one is pretty straightforward, but it's a lot more inconvenient (since it requires re-compiling my entire MinGW-w64 cross environment and the entire dependency chain for FFmpeg*, and then distributing libgcc_s.dll as a system lib with the FFMS2 package).

*well, I'd run the test in a VM, but if this is really the source of the problem, normal builds with a shared libgcc would have to wait until mid-April (I recompile my cross environment every six months anyway, after upgrading to the newest release of Ubuntu).

[Zathor]

C-plugin builds of 2.16 and 2.17 are available from the Google Code site:
https://code.google.com/p/ffmpegsource/downloads/list?can=1&q=cplugin&colspec=Filename+Summary+Uploaded+ReleaseDate+Size+DownloadCount

I didn't build them, but if those show the issue, then it'll at least show that it's not something recent.
Yes, based on my limited tests both builds also have the same problem. I can see a more or less constant memory increase. :(

[qyot27]

As an update, my attempt at using a shared version of GCC (by simply installing the repository version of the MinGW-w64 toolchain in 14.04 beta) crashed and burned. Even with the requisite dlls present for FFMS2/ffmsindex to rely on, it ended up failing to index immediately, even though it didn't crash. I still need to test with Clang, though.

[Zathor]

I am using ffms2_r827-msvc2010 now for nearly 2 weeks and had not a single problem and especially no memory problem. So thank you very much for this build!

[LigH]

Other users in the german doom9/Gleitz board report a wrong audio skew in certain cases, like this sample (http://www.file-upload.net/download-8750103/Comp.rar.html) (40 MB).

This file is reported to have a negative delay (http://forum.gleitz.info/showthread.php?46901&p=443748#post443748), which FFMS2 apparently tries to respect by stuffing the audio stream, but the duration seems to be incorrect, 23 ms missing.

[sneaker_ger]

To add more info, timecodes of the sample:
track_ID: 1
Media timescale: 3000
DTS = 0, CTS = 0
DTS = 100, CTS = 100
DTS = 200, CTS = 200
DTS = 300, CTS = 300
[...]
DTS = 22200, CTS = 22200
DTS = 22300, CTS = 22300

track_ID: 2
Media timescale: 44100

Edit box of the video track:
[edts: Edit Box]
position = 248
size = 36
[elst: Edit List Box]
position = 256
size = 28
version = 0
flags = 0x000000
entry_count = 1
entry[0]
segment_duration = 21750
media_time = 598
media_rate = 1.000000

Both duration and sync seem to be off, but I'm not sure I interpreted the edit box correctly (negative video delay 598s/3000?).

[Overdrive80]

Possible bug in ffvideosource??? http://forum.doom9.org/showthread.php?p=1679175#post1679175

[Myrsloik]

Possible bug in ffvideosource??? http://forum.doom9.org/showthread.php?p=1679175#post1679175

No, not at all. Because of these reasons:

1. The two scripts are not equivalent, which is evident since you need assumefps() in there at all
2. Seeking in demuxed video streams is never accurrate
3. Seeking in mpeg-ish containers usually doesn't end well either
4. Why megui is adding vfr to cfr conversion to every ffvideosource call is also a bit of a mystery

[Overdrive80]

Ok, thanks for you answer.

[hello_hello]

Possible bug in ffvideosource??? http://forum.doom9.org/showthread.php?p=1679175#post1679175

No, not at all. Because of these reasons:

I did some more testing. It does appear to be a ffmpegsource bug.

1. The two scripts are not equivalent, which is evident since you need assumefps() in there at all

assumefps() wasn't needed. It was just a test.

4. Why megui is adding vfr to cfr conversion to every ffvideosource call is also a bit of a mystery

I think it's a good idea, because the input is expected to be CFR.
I tested the sample myself and it appears to only be a problem when the video is in an AVI created by VirtualDub(Mod) and the frame rate is 23.976 (well the only other frame rate I tested was 25fps and that was fine). If you take the AVI created by VirtualDubMod and remux it with avimux, the problem goes away, as it does if you remux as an MKV and index, so (not understanding how it works myself) there appears to be some sort of frame rate miscommunication going on between VirtualDub created AVIs and ffmpegsource.

[foxyshadis]

Numerator/Denominator overflow? Does the import use 32-bit arithmetic? Avisynth used to export enormous fractions that required 64-bit arithmetic to properly handle, until it was changed in 2.5.7 or 2.5.8 to recognize certain common numbers and reduce the rest. Any old files from before then will still have the bad behavior, at least until remuxed by something that'll reduce the fractions.

[hello_hello]

Numerator/Denominator overflow? Does the import use 32-bit arithmetic?

I vaguely understand what you're saying but I don't know how to check that.

The file in question was created via Avisynth 2.6.0.4, at least in my case. I also tried AviSynth+ 2.6.0.5 portable with the same result.
I originally thought it was a VirtualDub problem but after testing a little more I think I was wrong. If I create the AVI using MeGUI (the writing application is Lavf55.33.100) the same problem occurs. The encoder used seems to make no difference. I've tried Lagaryth, huffyuv and Xvid.

For whatever reason remuxing the AVI with Avimux fixes the problem. As does remuxing as an MKV with MKVMergeGUI. Remuxing with VirtualDub doesn't fix the problem.

Adding fpsnum and fpsden to each script seems like a good idea to me. That way the frame rate is always constant and should help prevent audio sync problems. If the frame rate is constant in the first place, adding them should make no difference.
It's one of the reasons I use ffvideosource in preference to LSmash, which doesn't (as far as I know) have a similar frame rate conversion function.

[hello_hello]

While we're on the subject, here's a sample of an instance where adding fpsnum and fpsden to a script is a good idea. Aside from one missing/duplicate frame, the video is constant frame rate, 25fps. Without fpsnum and fpsden in the script, ffvideosource outputs a total of one frame less, and a frame rate of 24.971fps (it seems to output the average frame rate). Lsmash does likewise, with no way to tell it not to. AviSource/DirectShowSource "get it right" and output the correct number of frames and the correct frame rate.

I don't quite understand why ffvideosource and LSmash don't output the same as AviSource by default, so fpsnum and fpsden wouldn't be required. Without them, I think the only way to encode the video "correctly" would be to extract the timecodes from the original file and use them when remuxing the encoded version. By adding fpsnum and fpsden to each script, MeGUI eliminates the need for doing so and the encoded version has a "constant frame rate".

http://ge.tt/6fbWjpe1/v/0

[qyot27]

FFMS2 C-plugin r892+41

Optimized for Pentium-III and SSE.

FFmpeg r63367 git-f932e5f, built on May 22 2014 03:46:47 with gcc 4.9.0 (GCC):
libavutil 52. 86.100 / 52. 86.100
libavcodec 55. 63.100 / 55. 63.100
libavformat 55. 40.100 / 55. 40.100
libavdevice 55. 13.101 / 55. 13.101
libavfilter 4. 5.100 / 4. 5.100
libavresample 1. 2. 0 / 1. 2. 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-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
--optflags=-O0

There's now a native Opus decoder in libavcodec, so there's no longer a need to link to libopus just for that.


EDIT 2014-06-29: Updated build here. (http://forum.doom9.org/showthread.php?p=1685186#post1685186)

[zinga]

Hi, just wondering, are 64-bit Windows builds available from anywhere?
A number of builds used to be provided on the Google Code page, but they're now rather outdated.
Thanks.

[LigH]

The original AviSynth 2.x did not continue the development of its 64-bit core version, which was left in a quite unstable state, therefore only few plugins were made for that platform.

Now with AviSynth plus, development appears to be rather equal for both 32-bit and 64-bit architectures, therefore support for both may be more useful again.

[foxyshadis]

Thanks qyot27, so far this is the only way I can decode HEVC. (Even the command-line fails usually.) It works great.

[jackoneill]

--optflags=-O0


Say, doesn't that disable compiler optimisations?

[qyot27]

Say, doesn't that disable compiler optimisations?
Yeah, although it's mostly to avoid the flacdec issues (http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=13&t=1960) caused by using -O2 with GCC 4.9.0 (it's fixed in the 4.9.1 prerelease branch).

I've not done any performance testing to see how much impact GCC's optimizations really have (generally, -O0 gets used with debug builds, so it may just be simpler to compare debug and release builds for any performance gap).

[qyot27]

FFMS2 C-plugin r927+41

Optimized for Pentium-III and SSE.

ffmpeg version r64300 git-f02a440 Copyright (c) 2000-2014 the FFmpeg developers
built on Jun 28 2014 22:59:08 with gcc 4.9.0 (GCC)
libavutil 52. 90.101 / 52. 90.101
libavcodec 55. 68.100 / 55. 68.100
libavformat 55. 44.100 / 55. 44.100
libavdevice 55. 13.101 / 55. 13.101
libavfilter 4. 9.100 / 4. 9.100
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-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
--optflags=-O0

EDIT 2014-07-30: Updated build here. (http://forum.doom9.org/showthread.php?p=1688398#post1688398)

[Sm3n]

@qyot27 Your plugin ain't compatible with avisynth, right? Quote: ...ffms2.dll is not an AviSynth 2.* plugin.
First time I use one of your mod. I use Avisynth MT (x86 on win 8.1 x64).

Besides, I would like to display this kind of info:

http://i.imgur.com/LdAhVDQ.png

"Quantizer" and "QPEL" things in particular. I know there is a ffms2mod (ffinfomod) existing but can't find it.
Maybe someone could help me.

Cheers.

[Selur]

Your plugin ain't compatible with avisynth, right?
It's an avisynth C-plugin -> you need to use LoadCPlugin(...) instead of LoadPlugin(...)

[Taurus]

@qyot27 Your plugin ain't compatible with avisynth, right? Quote: ...ffms2.dll is not an AviSynth 2.* plugin.
First time I use one of your mod. I use Avisynth MT (x86 on win 8.1 x64).
Did you copy FFMS2.avsi, ffmsindex.exe and finally ffms2.dll to your plugin folder?
If yes FFMS should start right out of the box.
If no follow Selur's suggestion.
Or read into the FFMS2.avsi.
It's self explaining....:D

Oh, by the way:
Thanks gyot27 for sharing:thanks:

[Reel.Deel]

Another option is to download the very recently released v2.20: https://github.com/FFMS/ffms2/releases/tag/2.20

This one is not a C-plugin so it loads like a regular plugin either by placing it in the Avisynth plugins folder (autoload) or explicitly using LoadPlugin(...).

[Sm3n]

It's an avisynth C-plugin -> you need to use LoadCPlugin(...) instead of LoadPlugin(...)
What a shame :o

Did you copy FFMS2.avsi, ffmsindex.exe and finally ffms2.dll to your plugin folder?
I didn't copy ffmsindex.exe but in fact I don't need it, just by adding "C" like Selur said, it works.


Thx everyone!

[Groucho2004]

Besides, I would like to display this kind of info:

http://i.imgur.com/LdAhVDQ.png

"Quantizer" and "QPEL" things in particular.
Avisynth doesn't know about these properties.

[phate89]

Another option is to download the very recently released v2.20: https://github.com/FFMS/ffms2/releases/tag/2.20

This one is not a C-plugin so it loads like a regular plugin either by placing it in the Avisynth plugins folder (autoload) or explicitly using LoadPlugin(...).

what's the difference between the 2 versions?

[Reel.Deel]

what's the difference between the 2 versions?
From GitHub description (versions and variants) (https://github.com/FFMS/ffms2#versions-and-variants):

avs-cplugin: Variant of the Avisynth plugin written in C. Primary purpose is to get access to the new colorspaces available in Avisynth 2.6.

[phate89]

From GitHub description (versions and variants) (https://github.com/FFMS/ffms2#versions-and-variants):

avs-cplugin: Variant of the Avisynth plugin written in C. Primary purpose is to get access to the new colorspaces available in Avisynth 2.6.


Thanks. About the "Optimized for Pentium-III and SSE" does it change anything for newer cpus?

[Sm3n]

Avisynth doesn't know about these properties.

AFAIK I see a lot of screenshots with the "B Qpel" frametype. But "Quantizer" I never seen that before today.
My first thought was it's subtitles but I don't think so.

If you say that Avisynth doesn't know that, I can just trust you on this.

[Boulder]

I'd like to compile FFMS2 to test various optimizations (just for the heck of it), but my MinGW/MSYS installation is missing some packages. This is what I get in the config.log:

No package 'libavformat' found
Package libavcodec was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavcodec.pc'
to the PKG_CONFIG_PATH environment variable

I've used the MinGW package provided by XhmikosR (http://xhmikosr.1f0.de/tools/) which I also use for compiling x264.

Can anyone point me to the right direction regarding where or how to get those missing packages (libavcodec, libswscale, libavutil, libavformat)?

[TheFluff]

Avisynth doesn't know about these properties.

FFMS2 does, though, and exports some info to Avisynth variables. Use FFInfo() (from ffms2.avsi) and it'll print the info on the video. Quantizer info is not exported though, just frame type.

[poisondeathray]

AFAIK I see a lot of screenshots with the "B Qpel" frametype. But "Quantizer" I never seen that before today.
My first thought was it's subtitles but I don't think so.

If you say that Avisynth doesn't know that, I can just trust you on this.

It's ffdshow's OSD . You can display the overlay in avisynth if you use DirectShowSource() with ffdshow configured as the directshow decoder, and the OSD enabled . (but beware of DSS issues, frame accuracy etc....) .

[Reel.Deel]

@Boulder

Have you read these compilation notes? https://github.com/FFMS/ffms2/blob/master/doc/ffms2-api.md#compilation

[Boulder]

Thanks, I'll take a look.

[qyot27]

Thanks. About the "Optimized for Pentium-III and SSE" does it change anything for newer cpus?
That only actually applies to the optimizations applied to the C and C++ code, not the assembly optimizations that exist in libavcodec. It also wouldn't affect libavcodec's runtime cpu detection of higher CPUs.

The current caveat with the C plugin is that, due to a bug in GCC 4.9.0, I have to use -O0 when building FFmpeg (which defaults to -O2 otherwise). This will get resolved once the final release of GCC 4.9.1 is released and I regenerate the toolchain I use to build everything.

I'd like to compile FFMS2 to test various optimizations (just for the heck of it), but my MinGW/MSYS installation is missing some packages. This is what I get in the config.log:

No package 'libavformat' found
Package libavcodec was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavcodec.pc'
to the PKG_CONFIG_PATH environment variable

I've used the MinGW package provided by XhmikosR (http://xhmikosr.1f0.de/tools/) which I also use for compiling x264.

Can anyone point me to the right direction regarding where or how to get those missing packages (libavcodec, libswscale, libavutil, libavformat)?
The builds I provide are cross-compiled, but on Windows I would now recommend relying on msys2 (https://msys2.github.io) rather than the old msys and various MinGW-w64 packages. First and foremost because it provides properly up-to-date versions of the software involved. It also provides its own package management (a port of Arch Linux's pacman), and you can pull in everything - or nearly everything - necessary from inside of it. And since it's managed, it's easier to keep updated. The GCC that it provides actually is one of the incremental updates from the 4.9.1 prerelease branch, so it would be unaffected by the bug I mentioned above.

As mentioned by the Compilation guide on FFMS2's wiki, GCC cannot be used to compile the AviSynth (C++) plugin in the master branch, although it can build the regular library that you could then link against x264. The C++ plugin can only be built by MSVC if you want it to actually, you know, work.

[Sm3n]

It's ffdshow's OSD . You can display the overlay in avisynth if you use DirectShowSource() with ffdshow configured as the directshow decoder, and the OSD enabled . (but beware of DSS issues, frame accuracy etc....) .

I've read something about OSD I remember. But I don't know what it is.
I'll take a look. Sure I don't want any issues so I think the best option is FFvideosource, no matter if I don't have these displayed options... It's good to know anyway.

Cheers.

[Selur]

btw. FFmpegSource crashes for me when fed with mkv(vp9) content, LibAVVideo works fine.

[qyot27]

btw. FFmpegSource crashes for me when fed with mkv(vp9) content, LibAVVideo works fine.
I tested with the VP9 sample provided here:
http://www.reduser.net/forum/showthread.php?111230-Google-VP9-4K-HD-Sample

And while my old Celeron is not up to the task of seeking around in there, the script would open in VirtualDub and display actual video.

The caveat: FFMS defaults to trying to use the Haali Matroska demuxing code. And that did crash, right at the end of indexing - 99% and boom, crash. But forcing it to use lavf as the demuxer (-m lavf or demuxer=lavf) allowed the index to be written without crashing and then as I said, I was able to open it in VDub.

[Selur]

adding '-m lavf' fixes the problem, thanks :)