FFmpegSource

[hello_hello]

I can confirm this bug, although I haven't got an idea as to the exact cause. The first MKV file I attempted to index using MeGUI caused ffmsindex to crash. It'll demux the audio stream, but it won't index.
I also tried using a basic script (because that's all I know) but it refused to index the file.

LoadPlugin("C:\Program Files\ffms2\ffms2.dll")
FFVideoSource("E:\video.mkv")

Normally just opening the above script would cause the file to be indexed, but instead when opening it with MPC-HC I got:

Evaluate: System Exception - Access Violation
E:\script.avs, line 2

The MKV file contains AVC video, DTS audio and srt subtitles. Removing the subtitles when remuxing fixed the problem (I don't think removing the audio made any difference). Remuxing the MKV while retaining all three streams still caused ffmsindex to crash. Reverting to the previous ffms version used by MeGUI (seems to be r588) returned everything to normal.

Here's a sample (http://wikisend.com/download/802382/video.mkv).

[TheFluff]

Bug reproduced and fixed, thanks for the sample.
(it was TheRyuu's fault)

[burfadel]

Thats good :) was just about to get back to you on that! (late I know)

[Atak_Snajpera]

Image corruption in VC-1 (.m2ts remuxed to .mkv using eac3to)
http://i.imgur.com/Gv1Uc.jpg

Script
LoadPlugin("..\ffms2.dll") #rev624
FFVideoSource("..\video.mkv",threads=1) #seekmode=0 and -1 do not help either

Trim(240,240)

sample -> http://www.mediafire.com/?wg81zwe1cu1pv7u

[Sparktank]

Image corruption in VC-1 (.m2ts remuxed to .mkv using eac3to)
http://i.imgur.com/Gv1Ucl.jpg

Script
LoadPlugin("..\ffms2.dll") #rev624
FFVideoSource("..\video.mkv",threads=1) #seekmode=0 and -1 do not help either

Trim(240,240)

sample -> http://www.mediafire.com/?wg81zwe1cu1pv7u

I downloaded your sample and did an encode using the latest "eperimental" version of VirualDub (Virtualdub 1.9.11/1.10.1 experimental (December 24, 2011)).
I loaded the source mkv into VDub with ffms2 rev624.
Exact script you posted.

While it does show that the invidual frame is corrupted as you posted.
I decided to encode to x264.

The resulting encode turned out perfectly without any corruptions, especially in frame 240.

Frame 240 after encoding to x264
http://i.imgur.com/GTwWql.jpg

x264 codec via Vdub 1.9.11/1.10.1 experimental (December 24, 2011)
http://i.imgur.com/1v5E0l.png

x264 settings
http://i.imgur.com/GDhVSl.png

I'm not entirely sure, but it just maybe the program having a hiccup when displaying the video.

Resulting Test:
http://www.mediafire.com/download.php?xw8vwdsfv7nau09

[Atak_Snajpera]

could you try with x264 cli?

[Sparktank]

could you try with x264 cli?

I did with a very simple function.
(x264 build: x264 core:120 r2120 0c7dab9(from http://x264.nl/))

x264 --crf 19 -o "E:\Work\test_cli.mkv" E:\Work\video.mkv"

D:\App Bin\x264\32bit 8bit-depth>x264 --crf 19 -o "E:\Work\test_cli.mkv" E:\Work\video.mkv"
ffms [info]: 1920x1080p 1:1 @ 24000/1001 fps (vfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow SlowCTZ
x264 [info]: profile High, level 4.0
x264 [info]: frame I:12 Avg QP: 9.09 size: 56780
x264 [info]: frame P:865 Avg QP:18.32 size: 38949
x264 [info]: frame B:720 Avg QP:23.24 size: 5039
x264 [info]: consecutive B-frames: 35.1% 13.1% 3.9% 47.8%
x264 [info]: mb I I16..4: 61.0% 30.5% 8.5%
x264 [info]: mb P I16..4: 4.7% 6.2% 1.2% P16..4: 25.3% 10.3% 5.4% 0.0% 0.0% skip:47.0%
x264 [info]: mb B I16..4: 0.3% 0.1% 0.0% B16..8: 8.9% 1.4% 0.4% direct: 1.2% skip:87.7% L0:32.8% L1:48.0% BI:19.2%
x264 [info]: 8x8 transform intra:48.8% inter:67.8%
x264 [info]: coded y,uvDC,uvAC intra: 43.6% 47.6% 22.8% inter: 12.9% 11.1% 1.7%
x264 [info]: i16 v,h,dc,p: 72% 13% 4% 11%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 13% 32% 6% 8% 8% 5% 5% 8%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19% 21% 25% 6% 7% 6% 6% 4% 6%
x264 [info]: i8c dc,h,v,p: 64% 16% 17% 3%
x264 [info]: Weighted P-Frames: Y:15.3% UV:9.1%
x264 [info]: ref P L0: 65.8% 16.8% 12.5% 4.6% 0.3%
x264 [info]: ref B L0: 87.8% 10.2% 2.0%
x264 [info]: ref B L1: 96.7% 3.3%
x264 [info]: kb/s:4563.98

encoded 1597 frames, 3.88 fps, 4564.06 kb/s

Media Info of resulting CLI encode:
General
Complete name : E:\Work\test_cli.mkv
Format : Matroska
Format version : Version 2
File size : 36.3 MiB
Duration : 1mn 6s
Overall bit rate : 4 568 Kbps
Writing application : x264 r2120 0c7dab9
Writing library : Haali Matroska Writer b0

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1mn 6s
Bit rate : 4 478 Kbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 1.199 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 1.801
Stream size : 35.6 MiB (98%)
Writing library : x264 core 120 r2120 0c7dab9
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=19.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Language : English
Default : Yes
Forced : No

Although it does not load the resulting MKV in VDub, it gives an error that there is "no video". I'm not sure about that, will have to investigate that.

But eac3to was able demux the resulting video to elementary stream of x264.
I loaded the ES x264 into "DGAVCIndex" and saved the project.
However... http://i.imgur.com/02MFa.gif
The fps turned out to be a constant 25fps...

Stream Type: AVC Elementary
Profile: High
Level: 4
Frame Size: 1920x1080
SAR: 1:1
Display Size: 1920x1080
Frame Rate: 25.000000 fps
Colorimetry: BT.709* [2]
Frame Structure: Frame
Frame Type: not yet
Coded Number: 250
Playback Number: 250
Frame Repeats: 0
Field Repeats: 0
Bitrate: 10.391
Bitrate (Avg): 6.519
Bitrate (Max): 11.388
Elapsed: 0:00:00
Remain: 0:00:00
FPS:
Info: Finished!

I've never really used the CLI before on its own.
I usually use Vdub or other with it ^_____^

Here's the resulting video in MKV format, using x264 (core:120 r2120 0c7dab9)...

deleted, uploading proper converted file

[Abradoks]

While it does show that the invidual frame is corrupted as you posted.
I decided to encode to x264.

Yes, linear decoding works fine. But VC-1 seeking is still broken.

BTW, has anyone considered using Intel Media SDK software decoder inside FFMS? It would be a nice solution for interlaced VC-1 decoding.

[Atak_Snajpera]

@Sparktank
you were supposed to encode my script not video.mkv !

[Sparktank]

@Sparktank
you were supposed to encode my script not video.mkv !

>.< Fixed.

x264 log:
D:\App Bin\x264\32bit 8bit-depth>x264 --crf 19 -o "E:\Work\test_cli.mkv" E:\Work\ffms_test.avs"
avs [info]: 1920x1080p 0:0 @ 24000/1001 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Slow SlowCTZ
x264 [info]: profile High, level 4.0
x264 [info]: frame I:12 Avg QP: 9.09 size: 56786
x264 [info]: frame P:865 Avg QP:18.30 size: 38968
x264 [info]: frame B:720 Avg QP:23.28 size: 5030
x264 [info]: consecutive B-frames: 35.1% 13.1% 3.9% 47.8%
x264 [info]: mb I I16..4: 60.9% 30.5% 8.5%
x264 [info]: mb P I16..4: 4.6% 6.2% 1.2% P16..4: 25.3% 10.3% 5.4% 0.0% 0.0% skip:47.0%
x264 [info]: mb B I16..4: 0.3% 0.1% 0.0% B16..8: 8.8% 1.4% 0.4% direct: 1.2% skip:87.8% L0:32.6% L1:48.1% BI:19.4%
x264 [info]: 8x8 transform intra:48.8% inter:67.7%
x264 [info]: coded y,uvDC,uvAC intra: 43.6% 47.6% 22.7% inter: 12.9% 11.1% 1.7%
x264 [info]: i16 v,h,dc,p: 72% 13% 4% 11%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 13% 32% 6% 8% 8% 5% 6% 8%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19% 21% 25% 6% 7% 6% 6% 4% 6%
x264 [info]: i8c dc,h,v,p: 64% 16% 17% 3%
x264 [info]: Weighted P-Frames: Y:15.3% UV:9.1%
x264 [info]: ref P L0: 65.8% 16.8% 12.5% 4.7% 0.3%
x264 [info]: ref B L0: 87.8% 10.2% 2.0%
x264 [info]: ref B L1: 96.7% 3.3%
x264 [info]: kb/s:4565.26

encoded 1597 frames, 3.81 fps, 4565.35 kb/s

And it turned out the same, no corruption.

New conversion with AVS, new upload, same name.
http://www.mediafire.com/download.php?1ag4lcvbpqdu5jd

[Atak_Snajpera]

wrong again! you encoded whole file without trim!

[TheRyuu]

wrong again! you encoded whole file without trim!

Like I said on the bug tracker it works if it's accessed linearly. Doing trim(x,y) (where x isn't 0) counts as seeking. I don't know why there is corruption when seeking. Threads > 1 also appears to work correctly if accessed linearly.

[Atak_Snajpera]

maybe this is just a coincident but with trim(242,...) frame is not corrupted. according to mkvinfo frame 242 (10.082s) is a location of next cluster timecode. btw how to get list of keyframes with ffindex.exe?

[Atak_Snajpera]

Another example that there is seriously something wrong with VC-1 decoding while seeking
Now We have frame 1 mixed with frame 968 plus nice blocks. Probably the same happens with my previous example!

http://i.imgur.com/o3qjI.jpg

Script
LoadPlugin("..\ffms2.dll")
FFVideoSource("..\video.mkv",threads=1)

Trim(967,967)

Sample -> http://www.mediafire.com/?dh86soca2m66n6b

[may24]

Hi everyone,

A friend recorded some 'ITV HD' stream in 1080i and now wants to process it further.
I recommend him to use the latest ffms2 release 624. But parsing the file throws error: Insanity detected: Decoder returned an empty frame

Here is a snipp of his recording -> http://www.megaupload.com/?d=S7719U3P

I hope you guys could have a look at.

I was able to open and index/demux it with DGAVCdecode ...

[TheFluff]

MPEG TS support is even more broken than usual in r624, due to a regression introduced in r615. We're working on it. In the meantime you can remux the file to MKV with eac3to or just use 2.16.

[jmac698]

Really, I could serve avc interlaced properly if it's in mkv? With random access too?

[TheFluff]

Really, I could serve avc interlaced properly if it's in mkv? With random access too?

No, you still get various breakage on interlaced h264 in mkv for some reason, especially if it's remuxed from (M2)TS.

[moviefan]

I'm trying to compile the latest FFMS2 revision against the latest FFmpeg revision, but I keep getting the following error in the ./configure-phase.


checking for LIBAV... yes
checking whether linking with FFmpeg or Libav... FFmpeg
checking whether FFmpeg works... no
configure: error: in `/home/<user>/tmp/ffms2':
configure: error: cannot link with FFmpeg


I compile FFmpeg with


./configure --disable-everything --enable-gpl --enable-postproc --enable-protocols --enable-demuxer=matroska,ogg,avi,h264,mov,m4v,mpegts,mpegvideo --enable-decoder=h264,vc1,wmv*,mpeg2video,mpeg1video,mpeg4,theora,vp8 --enable-parser=h264,mpeg4video,mpegvideo,vc1,vp8 --prefix=/home/<user>/build
make
make install


and FFMS2 with


LIBAV_CFLAGS=-I/home/<user>/build/include LIBAV_LIBS=-L/home/<user>/build/lib ./configure --prefix=/home/<user>/build
make
make install


Can anyone tell me why this is happening?

[TheFluff]

I'm trying to compile the latest FFMS2 revision against the latest FFmpeg revision, but I keep getting the following error in the ./configure-phase.


checking for LIBAV... yes
checking whether linking with FFmpeg or Libav... FFmpeg
checking whether FFmpeg works... no
configure: error: in `/home/<user>/tmp/ffms2':
configure: error: cannot link with FFmpeg


I compile FFmpeg with


./configure --disable-everything --enable-gpl --enable-postproc --enable-protocols --enable-demuxer=matroska,ogg,avi,h264,mov,m4v,mpegts,mpegvideo --enable-decoder=h264,vc1,wmv*,mpeg2video,mpeg1video,mpeg4,theora,vp8 --enable-parser=h264,mpeg4video,mpegvideo,vc1,vp8 --prefix=/home/<user>/build
make
make install


and FFMS2 with


LIBAV_CFLAGS=-I/home/<user>/build/include LIBAV_LIBS=-L/home/<user>/build/lib ./configure --prefix=/home/<user>/build
make
make install


Can anyone tell me why this is happening?

Post your config.log.

[moviefan]

http://pastebin.com/GjCqakCE

[TheFluff]

You need to compile FFmpeg with swscale (--enable-swscale), but I think there might also be something funky going on with our autodetection of FFmpeg versus libav. Which one are you using?

[moviefan]

I downloaded the latest FFmpeg snapshot so I guess I'm using FFmpeg, right?

Edit: Compiling FFmpeg with swscale does not solve the problem.

[TheFluff]

I downloaded the latest FFmpeg snapshot so I guess I'm using FFmpeg, right?

Edit: Compiling FFmpeg with swscale does not solve the problem.

You're setting LIBAV_LIBS wrong. Consider using pkg-config in order to get it right automatically (by setting PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig, where $PREFIX is the prefix you built ffmpeg with), or if you can't or don't want to do that, check the libav*.pc file to see what -l flags you should be using.

[moviefan]

Where do I insert the -l flags? Like this? LIBAV_LIBS="-L..... -lavcodec -lavfilter ..."?

[komisar]

moviefan, try this:
LIBS="-lswscale -lavformat -lavcodec -lavutil -lpsapi [-lz -lbz2 -lpthreadGC2]" \
CFLAGS="-I/where/you/libav/include" \
LDFLAGS="-L/where/you/libav/lib" \
configure --you-libav-configure-options

"[-lz -lbz2 -lpthreadGC2]" if need...

TheFluff, why in current ffmpegsource changed FFMPEG_LIBS to LIBS in configure?

[TheFluff]

FFMS 2.17 has been released.
Again, this is mostly a bugfix and maintenance release; no major new features have been added. There are, however, two minor features that might be relevant to Avisynth users. First, you can now get the FFMS version by calling FFGetVersion(), which returns a string on the form "2.17.0.0", where the last two numbers are mostly relevant for API users. Second, all exported metadata variables can now have their names prefixed with a string of your choice, which prevents two or more subsequent calls to FFVideo/AudioSource from overwriting each other's variables. Oh, and for the three people who care (hello there, tebasuna51), the audio channel layout is now exported as a dwChannelMask-compatible integer, in the variable FFCHANNEL_LAYOUT.

Downloads

ffms-2.17.7z (http://code.google.com/p/ffmpegsource/downloads/detail?name=ffms-2.17.7z) - plain old 32-bit version
ffms-2.17-x64.7z (http://code.google.com/p/ffmpegsource/downloads/detail?name=ffms-2.17-x64.7z) - for use with 64-bit Avisynth
ffms-2.17-sdk.7z (http://code.google.com/p/ffmpegsource/downloads/detail?name=ffms-2.17-sdk.7z) - Software Development Kit, for people who want to develop Windows applications that depend on FFMS2, using Microsoft Visual Studio 2008 or later
ffms-2.17-src.tar.bz2 (http://code.google.com/p/ffmpegsource/downloads/detail?name=ffms-2.17-src.tar.bz2) - full source code


Full changelog since 2.16

Reworked color matrix and color range handling a bit, which fixed a bug that could cause FFMS2 to always output TV range even if the input was full range. (TheFluff)
The autotools build system can now create debug builds properly. (Daemon404)
Deprecated parts of the API will now cause compiler warnings when you use them. (TheFluff)
Added a FFMS_GetVersion function to the API (lets library users get the version number at runtime) and exposed it in Avisynth as FFGetVersion. (TheRyuu, TheFluff)
Added a variable prefix option to the Avisynth functions. Its primary purpose is to get subsequent calls to source functions from overwriting variables from earlier calls. (TheFluff)
Make it possible to open single-frame videos without explicitly setting seekmode to -1 for you weird people who want to open images with ffms (Plorkyeran)
Fixed bug where indices would sometimes be incorrectly considered valid (TheRyuu)
Add support for recent versions of Libav/FFmpeg built as shared libraries (Plorkyeran, TheRyuu, Kovensky)
When possible, non-API symbols are no longer exported (Daemon404, TheFluff)
Deprecate postprocessing support. Libav and FFmpeg are planning on removing it at some point in the near future and it's really not very useful.
Fix the pkg-config version on OS X (Plorkyeran).
Fixed a bug that could cause the FFmpegSource2() Avisynth function to not use UTF8 filenames even when told to do so. (pandv2)
Fixed a few minor memory leaks. (Plorkyeran)
Adjusting audio delay relative to the first video track should now work properly again (was broken in 2.16). (Plorkyeran)
General bitrot fixes to deal with changes in Libav/FFmpeg (everyone)
Corrected handling of codec private data when using a non-libavformat parser. Fixes decoding of FFV1 and UTVideo in MKV, among other things. (TheFluff)
Bump minimum required version of FFmpeg to 0.6.


Other notes
The VC-1 decoding issue is not fixed, but since it's been there since forever and is extremely mysterious and hard to debug, we've decided to release 2.17 anyway. We haven't given up on it, though.

We'd also like to again remind postprocessing users that postprocessing support is deprecated and will be removed in 2.18. The reason for this is that both libav and FFmpeg are planning on removing the library we use (libpostproc).

[TheFluff]

TheFluff, why in current ffmpegsource changed FFMPEG_LIBS to LIBS in configure?

I don't know, I don't maintain the Unix buildsystem. I'll pass the question along to the concerned parties, though.

[tebasuna51]

FFMS 2.17 has been released.
... Oh, and for the three people who care (hello there, tebasuna51), the audio channel layout is now exported as a dwChannelMask-compatible integer, in the variable FFCHANNEL_LAYOUT.

Thanks. I will test that.

[mastrboy]

FFMS 2.17 has been released.

Much appreciated :)

[aufkrawall]

It doesn't work for me with AviSynth 2.6 32bit, programs abort with error saying they can't open the avs files. :(
The plugin load command is correct.

But ffms-2.17.7z really is for AviSynth?

[LigH]

There are two distinct functions to load plugins, and it depends on the plugin code which of them are supported:

a) LoadPlugin()
b) LoadCPlugin() / Load_StdCall_Plugin()

FFMS2 supports both calling conventions; but using FFMS2 in AviSynth 2.6 requires the second style to access new colorspaces. To avoid issues with the plugin already loaded automatically using the first style, you should keep FFMS2 out of the autoload folder (AviSynth 2.5\plugins), but place it in a subdirectory instead and always load it explicitly.

[TheRyuu]

There are two distinct functions to load plugins, and it depends on the plugin code which of them are supported:

a) LoadPlugin()
b) LoadCPlugin() / Load_StdCall_Plugin()

FFMS2 supports both calling conventions; but using FFMS2 in AviSynth 2.6 requires the second style to access new colorspaces.

You can only load ffms2 with:
LoadPlugin("X:\path\to\ffms2.dll")

The cplugin builds are marked as such and are different.

To avoid issues with the plugin already loaded automatically using the first style, you should keep FFMS2 out of the autoload folder (AviSynth 2.5\plugins), but place it in a subdirectory instead and always load it explicitly.

Can we please stop using autoload. It's one of the major causes of avisynth related problems.

[aufkrawall]

Thank you, using the non-c load command did the trick. :)

[LigH]

Sorry then, I must have misunderstood... So it seems that C calling is no requirement for AviSynth 2.6; but then was it useful for x64 instead?

[TheFluff]

Sorry then, I must have misunderstood... So it seems that C calling is no requirement for AviSynth 2.6; but then was it useful for x64 instead?

I will try to explain the situation. It's a bit messy, and I'm going to explain a bit more than strictly necessary, but bear with me.

FFMS2 is a library that interacts with FFmpeg. You can use this library from C or C++ programs (and programs written in other languages too), but in itself it doesn't really do anything. You cannot use this library directly from Avisynth.

In order to interact with Avisynth, we have written two different Avisynth plugins. These two don't do very much work on their own; they just call the FFMS2 library and ask it to retrieve video and audio for them. Because we don't like DLL hell, these plugin interfaces normally reside in the same .dll file as the FFMS2 library, and thus for most end users the FFMS2 library is the same thing as the Avisynth plugin.

One of these two plugins is written in C++ and uses the Avisynth 2.5 interface. This is the ordinary plugin that most of you use; it is loaded with LoadPlugin. It can be compiled in either 32- or 64-bit mode and will work with both Avisynth 2.5 and 2.6, but in 2.6 it will not be able to handle the new colorspaces, since it uses the 2.5 interface that doesn't have those yet. If it had been written using the 2.6 interface, you would not have been able to load it in Avisynth 2.5.

The other plugin is written in C (by kemuri_-9) and uses the Avisynth C interface. It is loaded with LoadCPlugin/LoadStdCallPlugin, and just like the ordinary plugin it can be compiled in either 32- or 64-bit mode. Because the Avisynth C interface is a bit special, kemuri_-9 managed to hack this plugin up so it can be loaded in both Avisynth 2.5 and Avisynth 2.6 and still have access to the new colorspaces when loaded in Avisynth 2.6. The ordinary C++ plugin cannot do this.

Because there is no easy way for end users to tell the difference between a ffms2.dll that contains the C-plugin interface and one that contains the 2.5 C++ interface, we usually mark 7z archives that contain the C-plugin with -avs-cplugin. All other archives can be assumed to either contain the C++ plugin or just the library itself, without any Avisynth interfaces (although I don't think there's anyone building it that way right now; all DLL's most likely contain one of the Avisynth interfaces).

We have not yet posted a 2.17 build of the C-plugin. Harass TheRyuu if you want it.

End of tl;dr.

[Gavino]

Can we please stop using autoload. It's one of the major causes of avisynth related problems.
Why is that? (in the case of ffms2)

[TheFluff]

Why is that? (in the case of ffms2)

When someone is having bizarre and inexplicable Avisynth problems, such as odd crashes and mysterious failures of various kinds, odds are usually very good that it's related to some broken plugin being autoloaded. Therefore, TheRyuu thinks it's usually a good idea to keep your autoload directory clean. The C++ version of FFMS2 should be safe to autoload though.

[LigH]

:goodpost: :thanks:

That helped me understanding the relations better.
__

Crash reasons I remember from own experience were e.g. AviSynth 2.0 plugins, the LoadPluginEx() plugin, and plugin variants optimized for unsupported CPU instructions (e.g. RemoveGrain_SSE3 on Athlon XP).

[aufkrawall]

I encounter a problem with FFMS 2.17 that wasn't there with 2.16 cbuild: It seems that it doesn't convert range from PC to TV correctly.
I used the following script:
LoadPlugin("C:\Program Files (x86)\AviSynth 2.6\plugins\ffms2.dll")
FFVideoSource("alt.avi")
AssumeFPS(30.0)
ConvertToYV12(matrix="Rec709")
Source was FRAPS I420.
With 2.16 the x264 result looked like this:
http://www.ld-host.de/uploads/thumbnails/0e1983f8ae6fcdc52469cc8cdd7da85d.png (http://www.ld-host.de/show/0e1983f8ae6fcdc52469cc8cdd7da85d.png)
2.17 (too dark):
http://www.ld-host.de/uploads/thumbnails/3e0e91f92754d80b5c20a778ba45a4c3.png (http://www.ld-host.de/show/3e0e91f92754d80b5c20a778ba45a4c3.png)

[TheFluff]

I encounter a problem with FFMS 2.17 that wasn't there with 2.16 cbuild: It seems that it doesn't convert range from PC to TV correctly.
I used the following script:
LoadPlugin("C:\Program Files (x86)\AviSynth 2.6\plugins\ffms2.dll")
FFVideoSource("alt.avi")
AssumeFPS(30.0)
ConvertToYV12(matrix="Rec709")
Source was FRAPS I420.
With 2.16 the x264 result looked like this:
http://www.ld-host.de/uploads/thumbnails/0e1983f8ae6fcdc52469cc8cdd7da85d.png (http://www.ld-host.de/show/0e1983f8ae6fcdc52469cc8cdd7da85d.png)
2.17 (too dark):
http://www.ld-host.de/uploads/thumbnails/3e0e91f92754d80b5c20a778ba45a4c3.png (http://www.ld-host.de/show/3e0e91f92754d80b5c20a778ba45a4c3.png)

2.17 looks more correct to me, and I know Fraps has some super mysterious color matrix magic going on, but I can take a look anyway. Post a sample.

Your Avisynth script doesn't convert to RGB either, so that conversion happens elsewhere. What colorspace is FFMS2 outputting?

[aufkrawall]

2.17 looks more correct to me, and I know Fraps has some super mysterious color matrix magic going on, but I can take a look anyway.

The 2.16 screenshot looks exactly like the original FRAPS source.
2.17 really is too dark, details get lost in darkness.


Post a sample.

http://ht4u.net/images/reviews/2011/amd_radeon_hd_7900_southern_island_test/witcher_gtx580hq_neu.avi
Thanks for taking a look at it. :)


Your Avisynth script doesn't convert to RGB either, so that conversion happens elsewhere. What colorspace is FFMS2 outputting?
I assume it just outputs YV12/I420, just like the CSP of the source is.
x264's range conversion doesn't work (colors look slightly wrong), that's why I used Rec709 (I don't know why FRAPS keeps PC range in I420 mode...).
Here's the encoded video with ffmpegsource 2.16:
http://www.mediafire.com/?h2nsa7qtt6f56as

[TheFluff]

Took a look at the sample file. FFMS2 correctly detects the input as PC range I420 and does no conversions at all. Your ConvertToYV12() line does nothing since the input already is YV12 (I420 is the same thing as YV12 but with the chroma plane order swapped; Avisynth considers the two formats the same for most purposes). I assume that when VirtualDub (or whatever you're screenshotting with) converts the YV12 input to RGB for display, it does so while incorrectly assuming TV range. I added ConvertToRGB32(matrix="PC.709") to the end of the script and then I got mostly the same results as in your 2.16 screenshot (didn't compare exactly but it looks very similar at least). FFVideoSource(..., colorspace="RGB32") gives the same results as well.

If the same script worked in 2.16, what happened there was that you were a victim of that bug I fixed; FFMS2 internally scaled the PC range input to TV range, and by pure chance the rest of your encoding/playback chain happened to assume the input was TV range and thus rescaled it to PC range again for display.

Keep in mind that when you encode with x264 and the input is an Avisynth script, x264 cannot automatically detect the color range. You'll have to tell it to set the fullrange flag appropriately.

[henryho_hk]

I presume that x86 and x64 versions cannot share ffindex files. Hence, could FFGetVersion() include such info too?

[TheFluff]

I presume that x86 and x64 versions cannot share ffindex files. Hence, could FFGetVersion() include such info too?

Indeed, they cannot. FFGetVersion() could return that, yes.

[kemuri-_9]

Because there is no easy way for end users to tell the difference between a ffms2.dll that contains the C-plugin interface and one that contains the 2.5 C++ interface.

I've gone ahead and added version information to the dll when built within the c branch so you can better indicate what it is/what it can do, etc.

ex:
http://kemuri9.net/forumpics/ffms_dll_info.png

[aufkrawall]

Took a look at the sample file. FFMS2 correctly detects the input as PC range I420 and does no conversions at all. Your ConvertToYV12() line does nothing since the input already is YV12 (I420 is the same thing as YV12 but with the chroma plane order swapped; Avisynth considers the two formats the same for most purposes). I assume that when VirtualDub (or whatever you're screenshotting with) converts the YV12 input to RGB for display, it does so while incorrectly assuming TV range. I added ConvertToRGB32(matrix="PC.709") to the end of the script and then I got mostly the same results as in your 2.16 screenshot (didn't compare exactly but it looks very similar at least). FFVideoSource(..., colorspace="RGB32") gives the same results as well.

But the result isn't right, colors are wrong. For example red turns more orange:
http://www.ld-host.de/uploads/thumbnails/67a2cdd861f645208dad2fcef097f3f4.png (http://www.ld-host.de/show/67a2cdd861f645208dad2fcef097f3f4.png) http://www.ld-host.de/uploads/thumbnails/f795ce8061a6b748e15fa823665ed78b.png (http://www.ld-host.de/show/f795ce8061a6b748e15fa823665ed78b.png)


If the same script worked in 2.16, what happened there was that you were a victim of that bug I fixed; FFMS2 internally scaled the PC range input to TV range, and by pure chance the rest of your encoding/playback chain happened to assume the input was TV range and thus rescaled it to PC range again for display.

I liked this bug, it served me well. :p
With it I could convert from PC to TV range without visual quality loss.
With 2.17 it even looks wrong with PC range. :(

[LigH]

A change in the hue rather sounds like different colorimetrics?!

[aufkrawall]

A change in the hue rather sounds like different colorimetrics?!
The same happens when I let x264 convert range from PC to TV with FRAPS I420 videos.
The range conversion of AviSynth/ffms 2.16 is the only thing that works.

Range of the output file has to be TV because most decoders can't deal right with non-RGB video with PC range.

[Rumbah]

If I remember correctly Fraps does not use standard colorimetrics. That's why the normal Fraps decoder outputs RGB so it can do the correct conversion.
I did some tests a year ago and then the only way to get correct colours was to either use the normal Fraps decoder and then convert to YV12 or just capture in RGB. Else I got hue shifts in red and green (WoW chat text colours ;) ).