FFmpegSource

[fvisagie]

Originally Posted by lansing

or at least add a dot extension to differentiate the two, like abc.mkv.32bit.ffindex and abc.mkv.64bit.ffindex

You're probably aware of this, but if you're prepared to script separately for 32 and 64-bit, you can do that yourself. Default parameter value for FFIndex(), FFVideoSource() & FFAudioSource():

string cachefile = source + ".ffindex"

[lansing]

Originally Posted by fvisagie

You're probably aware of this, but if you're prepared to script separately for 32 and 64-bit, you can do that yourself. Default parameter value for FFIndex(), FFVideoSource() & FFAudioSource():

string cachefile = source + ".ffindex"

that will lose the point of auto detect and one script for both version.

[icezellion]

Originally Posted by Selur

As a side note: LWLibavVideoSource might be also worth a try. (Personally I prefer DGs tools for transportstreams.)

DGAVCDec completely fails on particular AVC transport streams. In this case, FFVideoSource works perfectly. For MPEG-2 transport streams I still use DGMPGDec though. Haven't bothered to use anything else since it still seems to do the job (I don't have a Nvidia GPU). I'm always open to trying other source filters as long as they process transport streams properly, and provide some additional benefit.

[LigH]

DGAVCDec is outdated anyway, using an obsolete version of libavcodec which did not even support PAFF interlacing yet (it was just one of the few frame-accurate versions cooperating with the DG*Dec framework).

Selur rather refers to current hardware accellerated tools like DGDecNV/IM. But yes, they require specific video decoder chips (Nvidia / intel Core i). "L-SMASH Works" does not, and is very reliable too (more than FFMS2, even with Haali support, regarding TransportStreams). And in addition, there is a DSS2Mod filter which can also use a local copy of LAV Filters natively (it doesn't need to be installed as DirectShow filters).

The alternative, to use FFMS2 rather reliably, is to multiplex TS to MKV using mkvmerge.

[qyot27]

FFMS2 C-plugin r827+36-avs+vsp

Optimized for Pentium-III and SSE.

FFmpeg r61474 git-d1bb179, built on Mar 14 2014 22:33:23 with gcc 4.8.2 (GCC):

configuration:
  --prefix=/home/qyot27/win32_build
  --cross-prefix=i686-w64-mingw32-
  --disable-doc
  --enable-gpl
  --enable-version3
  --disable-w32threads
  --enable-avresample
  --enable-libopus
  --disable-decoder=utvideo
  --enable-libutvideo
  --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-05-22: Updated build here.

[LigH]

Here an excerpt from the changelog since v2.18:

2.20

• Add support for Opus in MKV when ffmpeg/libav are built with libopus (qyot27)
• vapoursource: Provide _AbsoluteTime metadata (Daemon404)
• Fix a pile of small things found by Coverity (Daemon404)
• Add support for HEVC in MKV (qyot27)
• Fix infinite loop on garbage data at the beginning of AAC files (Plorkyeran)
• Deal with the never-ending bitrot from FFmpeg/Libav API changes (Daemon404, Plorkyeran)
• Make indexes not arch-specific and trivially smaller (Plorkyeran)

[icezellion]

Thanks Is it possible for me to provide FFMS2 developers a 60 second H264 TS file (from Sky HD)? I haven't had any issues so far, and I think the issue is likely due to where the file was trimmed at with VideoReDo. Basically at the start of the encoded result, the video pauses for perhaps a second or two, but aside that everything else is perfect. I am doubtful it's a FFMS2 issue though, since all the other recordings from have been more or less perfect (and more of an issue where it was cut at).

[Taurus]

@qyot27
for sharing

[Boulder]

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.

[LigH]

Is your 7-zip outdated (older than version 9.20)? It seems to happen often for different people who use a 3rd-party unpacker which uses a 7-zip DLL from a stable but obsolete version. Since Version 9.20 beta, 7-zip prefers an improved LZMA2 algorithm for multithreading, which can't be unpacked reliably with older versions, but they are not able to detect the difference.

[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]

Originally Posted by 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.

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

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)]

Originally Posted by Boulder

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.