FFmpegSource

[komisar]

TheRyuu, ffms2-mt-r464.7z without post-processing support?

[TheRyuu]

TheRyuu, ffms2-mt-r464.7z without post-processing support?

It should have it. All my builds should have post-processing support along with opencore-amr. Why, is it not working?

[komisar]

TheRyuu, strange...
ffvideosource(source="file.m2v",pp="l5",threads=6)
show me "Invalid postprocessing settings"...

[TheFluff]

TheRyuu, strange...
ffvideosource(source="file.m2v",pp="l5",threads=6)
show me "Invalid postprocessing settings"...

If it's not build with postproc support you will get an error about postproc not being compiled in. "invalid postprocessing settings" is a message that's coming from within libpostproc (I think) so I dunno what's going on here.

[Chikuzen]

I tried ffms2-mt-r464-avs64.7z and got error.

script

LoadCPlugin("C:\AviSynth_2.x\Plugins_x64\ffms2.dll")
ColorBars(640, 480, "YV12")
SWScale(512, 288)


Error massage
VirtualDub Error
AviSynth open failure:
SWScale: Context creation failed
(D:\Source\test_ffms.avs, line 3)

Is function "SWScale" missing on x64?

[kemuri-_9]

I tried ffms2-mt-r464-avs64.7z and got error.

Error massage


VirtualDub Error
AviSynth open failure:
SWScale: Context creation failed
(D:\Source\test_ffms.avs, line 3)


Is function "SWScale" missing on x64?

no, you would've gotten a different error if SWScale was not a valid avisynth function.
that error is that swscale itself failed to initialize.
the issue has been fixed in r465
i had missed a required change back in r407 for the C interface which in turn caused swscale to fail initialization for cpus with MMX.

[LigH]

This video (http://www.holzon.de/PRIVAT/holzon_k2.m2ts) (96.5 MB) is not correctly decoded with FFMS2 r464 mt (currently used in MeGUI 2023), it shows some forth/back motions in the MeGUI preview window; x264 and VirtualDub even crash after the first frame, processing a simple script (just LoadPlugin and FFVideoSource("*.ffindex"), generated by the MeGUI File Indexer).

[Chikuzen]

From docs

Interlaced H.264 is decoded in an odd way
each field gets its own full-height frame and the fieldrate is reported as the framerate, and furthermore one of the fields (odd or even) may "jump around".
To get the correct behavior, you can try setting fpsnum and fpsden so that the framerate is halved (may or may not work). This issue is caused by libavcodec.

Decoding some M2TS files using Haali's splitter will cause massive blocking and other corruption issues.
You can work around the issue either by remuxing the file to MKV (using GDSMux (make sure you untick "minimize output file size" in the Global settings tab) or eac3to), or (if you will be doing linear decoding only) by setting demuxer="lavf" in FFIndex and using seekmode=0 with FFVideoSource.
The cause of this issue is unknown but being investigated.

[TheFluff]

Interlaced h264 in m2ts is probably the format ffms2 has the worst support for, unfortunately. I strongly recommend using something else for loading those files.

[LigH]

Well, I converted it to MKV as well, because FFMS2 supports MKV a lot better.

Unfortunately, mkvmerge 4.7.0 does not support M2TS directly. So I demultiplexed it first with tsmuxer, and multiplexed the raw streams. But that failed too; I guess mkvmerge confused frames and fields (~ per second) here. Therefore I believe the video part is the main reason.
__

I just remembered that there is Haali's GDSMUX too. I'll try that as well to mux M2TS directly into MKV... — Oh, that displayed corrupted video in the MeGUI preview window, and moving the slider, it crashed eventually.
__

Again without minimizing the output: Still currupt output, still crashing. I may try indexing that manually and seeking conservatively, but not today anymore.

[Chikuzen]

Interlaced h264 in m2ts is probably the format ffms2 has the worst support for, unfortunately. I strongly recommend using something else for loading those files.

I know it.
but it seems that ffms2 can process LigH's sample.


FFmpegSource2("holzon_k2.m2ts", atrack=-1, fpsnum=25)
Yadif(mode=1).BicubicResize(1280, 720)

result (http://www.mediafire.com/download.php?dml3bk3qungjran)

[qyot27]

I've been experiencing crashes with FFMS2's C interface when trying to index MKV files output from x264. I was able to replicate the issue using my own builds of x264 (including r1995) and FFMS2 (r465, but it's been happening with previous revisions too). If the files are over 13MB, it causes ffmsindex or regular script loading-based indexing to fail because msvcrt.dll crashes. If I remux the files with mkvmerge, then no crash occurs. Files under 13MB are unaffected.

(I'm not certain whether the 13MB limit is one based on my own computer's ancient specs, though; the size may be larger on newer setups)

I'm not sure if this is an FFMS2 C interface or x264 issue, though. It would appear that Visual Studio builds are unaffected, since the build of ffms2-mt_r464 from the Google Code downloads didn't crash with 13MB+ files output from x264. Using mkvinfo, there does seem to be differences in the headers, particularly that x264-outputted MKV files have an unknown Segment size.

File that crashes:
+ EBML head
|+ EBML version: 1
|+ EBML read version: 1
|+ EBML maximum ID length: 4
|+ EBML maximum size length: 8
|+ Doc type: matroska
|+ Doc type version: 2
|+ Doc type read version: 2
+ Segment, size unknown
|+ Segment information
| + Muxing application: Haali Matroska Writer b0
| + Writing application: x264 r1995 c1e60b9
| + Timecode scale: 50000
| + Duration: 41.708s (00:00:41.708)
|+ Segment tracks
| + A track
| + Track number: 1
| + Track UID: 1
| + Track type: video
| + Lacing flag: 0
| + Codec ID: V_MPEG4/ISO/AVC
| + CodecPrivate, length 36 (h.264 profile: Baseline @L3.0)
| + Default duration: 41.708ms (23.976 fps for a video track)
| + Video track
| + Pixel width: 848
| + Pixel height: 480
| + Display unit: 0 (pixels)
| + Display width: 848
| + Display height: 480
|+ Cluster


File that doesn't crash:
+ EBML head
|+ EBML version: 1
|+ EBML read version: 1
|+ EBML maximum ID length: 4
|+ EBML maximum size length: 8
|+ Doc type: matroska
|+ Doc type version: 2
|+ Doc type read version: 2
+ Segment, size 13842494
|+ Seek head (subentries will be skipped)
|+ EbmlVoid (size: 4045)
|+ Segment information
| + Timecode scale: 1000000
| + Muxing application: libebml v1.2.0 + libmatroska v1.1.0
| + Writing application: mkvmerge v4.7.0 ('Just Like You Imagined') built on Apr 21 2011 01:13:14
| + Duration: 41.709s (00:00:41.709)
| + Date: Mon May 23 21:22:48 2011 UTC
| + Segment UID: 0xb8 0x64 0x4c 0xb1 0x3f 0xa3 0x6c 0xda 0xb3 0x24 0xdc 0x4d 0x03 0x6e 0x67 0x0a
|+ Segment tracks
| + A track
| + Track number: 1
| + Track UID: 1
| + Track type: video
| + Lacing flag: 0
| + MinCache: 1
| + Codec ID: V_MPEG4/ISO/AVC
| + CodecPrivate, length 36 (h.264 profile: Baseline @L3.0)
| + Default duration: 41.708ms (23.976 fps for a video track)
| + Video track
| + Pixel width: 848
| + Pixel height: 480
| + Display width: 848
| + Display height: 480
|+ EbmlVoid (size: 1061)
|+ Cluster


The settings used to encode the files didn't seem to matter. I could duplicate it even with --preset ultrafast --tune zerolatency.

[TheFluff]

Upload a sample file that makes it crash. Or is any file at all encoded with x264 and bigger than 13MB sufficient to trigger the crash?

[TheRyuu]

I wasn't able to reproduce the issue so yea, please upload a sample and let me know exactly what I should do to reproduce the crash.

[qyot27]

Here's a sample that crashes for me:
http://www.mediafire.com/?at419w57vn7n933
It consistently happens to me on MKVs output from x264 that are over 13MBs. I can typically only test on settings like ultrafast due to time constraints, but I've seen files encoded with veryslow exhibit the problem too.

If necessary, here's the build of FFMS2 I was using also:
http://www.mediafire.com/?hxt3x3xmmyv4coo

I can recompile FFMS2 and x264 with debug enabled if that's what needs to be done. I wouldn't be surprised if it's something about my hardware or software setup. The builds of ffmpeg and FFMS2 were cross-compiled under Ubuntu 11.04 (gcc-mingw32 4.4.4), both using -march=pentium3. CPU/RAM are a 1GHz Celeron Coppermine and 512 MBs of PC133 SDRAM.



I wasn't able to reproduce the issue so yea, please upload a sample and let me know exactly what I should do to reproduce the crash.
The exact steps I took were just to attempt indexing it, it doesn't get any further than that. Crashes at 0%, or immediately upon loading the script if I don't try to use ffmsindex.

[TheRyuu]

Works for me using my avs64 build.
LoadCPlugin("D:\plugins64\ffms2.dll")
ffvideosource("D:\Sample\causes_crash.mkv")

ffmsindex works too.

[LigH]

Load FFMS2.dll as C plugin? Didn't know I should; does that have any advantage compared to LoadPlugin?

[sneaker_ger]

It only depends on the branch/compiler used AFAIK, not something you can simply change in your script without using a different binary - no advantages.

[LigH]

I could imagine that most users without C compiling experience will prefer the builds from http://code.google.com/p/ffmpegsource/ – v2.15 or r464 (the latter is currently supported and used by MeGUI).

[TheFluff]

Load FFMS2.dll as C plugin? Didn't know I should; does that have any advantage compared to LoadPlugin?

If it was compiled as a C plugin (i.e. compiled with gcc in mingw) you must load it with loadcplugin. If it was compiled as a native C++ plugin (i.e. compiled with MSVC) you must load it with loadplugin. If you do it wrong, plugin loading will simply fail.

Notably, the avs64 version must be built as a C plugin; it cannot be built as a C++ native plugin. On the other hand, the official 32-bit builds are all native C++ plugins.

[TheRyuu]

To avs64 users with regards to postprocess:
ffms2-mt-r469-avs64.7z (http://warpsharp.voodoo-powered.net/random/ffms2-mt-r469-avs64.7z)
Somehow an old version of the define that enabled the postproc code was forgotten about so this version actually has the code enabled (the older versions actually had it compiled in, but it would never get set properly so it would just silently do nothing when you specified pp="foo").

To everyone using the 32bit regular version the problem is less clear. Something is probably writing outside of a buffer or smashing the stack.
ffms2-mt-r469.7z (http://warpsharp.voodoo-powered.net/random/ffms2-mt-r469.7z)
This build has something of a workaround that coincidentally fixes the issue so feel free to try it if you were getting the "Invalid Postprocess Settings" error (on valid input).

[komisar]

TheRyuu, thnx :)

[kemuri-_9]

the avs64 fix is included into r470 (http://code.google.com/p/ffmpegsource/source/detail?r=470) for those building from source.

[burfadel]

In ffms2-mt-r469 it still crashes when you are trying to multiencode with the source files being avi/xvid. It works fine with some other source files, so it looks like it depends on the source being used. This has been the case with all previous MT versions that I have tried, the non-MT versions work perfectly!

[TheFluff]

In ffms2-mt-r469 it still crashes when you are trying to multiencode with the source files being avi/xvid. It works fine with some other source files, so it looks like it depends on the source being used. This has been the case with all previous MT versions that I have tried, the non-MT versions work perfectly!

see earlier reply:

Doing multiple encodes of different files in different script environments (i.e. different instances of the encoding program) at the same time cannot possibly affect anything. You're either getting an unrelated crash or you're just doing it wrong. You're not using that silly MT() filter or something, are you? (post your entire script)

[burfadel]

Its only when using ffmpegsource MT, and only with certain source files (xvid in an avi container for example). It is ok with threads=1 specified.

[SledgeHammer_999]

Hey guys, I've build r470 from source but I get this error message from avisynth when using FFVideoSource()
Evaluate: System exception - Access Violation

If I try the r469 posted by TheRyuu my script works fine. So something went wrong in the compilation. Where should I look? Could it be an ffms problem or an ffmpeg one?
More info about my build:
ffmpeg (git commit 895e4de8d5a0760a48) build with mingw32 under msys (mingw 4.5.2)
ffms build with msvc 2008 express and didn't use Haali's splitter
zlib 1.2.5
pthreads 2.8.0

Sidenote: I had built successfully ffms ~1 year ago. I followed the same steps now, but it is broken.

Another question: What should I use now that ffmpeg-mt was merged with ffmpeg and ffmpeg was forked? ffmpeg, ffmpeg-mt or libav?

[henryho_hk]

Its only when using ffmpegsource MT, and only with certain source files (xvid in an avi container for example). It is ok with threads=1 specified.

Just curious, if u are doing multi-parallel encodes, shouldn't you be minimizing the number of threads?

[IanB]

@SledgeHammer_999,

"Evaluate: System exception - Access Violation" is a crash in the creator/constructor code as the Avisynth graph is being built.

[SledgeHammer_999]

ok. I found the culprit. It's pthreads. If I disable them the dll/script works. Now, I have to find what's wrong with it, I need multithreaded ffmpeg. I think it is a linking issue with mingw and msvc picking up different lib versions. arggg

[TheRyuu]

ok. I found the culprit. It's pthreads. If I disable them the dll/script works. Now, I have to find what's wrong with it, I need multithreaded ffmpeg. I think it is a linking issue with mingw and msvc picking up different lib versions. arggg

Make sure your pthreads has autostatic and doesn't use the old hacky (actually had to modify ffmpeg source code) method of static linking it with ffmpeg (autostatic is in the windows pthreads cvs) along with a few other changes to make ffmpeg happy:
diff -ur pthreads-win32.orig/need_errno.h pthreads-win32/need_errno.h
--- pthreads-win32.orig/need_errno.h 2010-08-21 18:49:29.000000000 -0300
+++ pthreads-win32/need_errno.h 2010-08-21 18:50:39.000000000 -0300
@@ -59,7 +59,7 @@
#endif
#endif

-#if !defined(PTW32_STATIC_LIB)
+#if !defined(PTW32_STATIC_LIB) && !defined(__MINGW32__)
# ifdef PTW32_BUILD
# define PTW32_DLLPORT __declspec (dllexport)
# else
diff -ur pthreads-win32.orig/pthread.h pthreads-win32/pthread.h
--- pthreads-win32.orig/pthread.h 2010-08-21 18:49:29.000000000 -0300
+++ pthreads-win32/pthread.h 2010-08-21 19:54:35.000000000 -0300
@@ -533,7 +525,7 @@
* do NOT define PTW32_BUILD, and then the variables/functions will
* be imported correctly.
*/
-#if !defined(PTW32_STATIC_LIB)
+#if !defined(PTW32_STATIC_LIB) && !defined(__MINGW32__)
# ifdef PTW32_BUILD
# define PTW32_DLLPORT __declspec (dllexport)
# else
diff -ur pthreads-win32.orig/sched.h pthreads-win32/sched.h
--- pthreads-win32.orig/sched.h 2010-08-21 18:49:29.000000000 -0300
+++ pthreads-win32/sched.h 2010-08-21 18:50:54.000000000 -0300
@@ -76,7 +76,7 @@
* do NOT define PTW32_BUILD, and then the variables/functions will
* be imported correctly.
*/
-#if !defined(PTW32_STATIC_LIB)
+#if !defined(PTW32_STATIC_LIB) && !defined(__MINGW32__)
# ifdef PTW32_BUILD
# define PTW32_DLLPORT __declspec (dllexport)
# else
diff -ur pthreads-win32.orig/semaphore.h pthreads-win32/semaphore.h
--- pthreads-win32.orig/semaphore.h 2010-08-21 18:49:29.000000000 -0300
+++ pthreads-win32/semaphore.h 2010-08-21 18:51:00.000000000 -0300
@@ -75,7 +75,7 @@
* do NOT define PTW32_BUILD, and then the variables/functions will
* be imported correctly.
*/
-#if !defined(PTW32_STATIC_LIB)
+#if !defined(PTW32_STATIC_LIB) && !defined(__MINGW32__)
# ifdef PTW32_BUILD
# define PTW32_DLLPORT __declspec (dllexport)
# else

[SledgeHammer_999]

Make sure your pthreads has autostatic and doesn't use the old hacky (actually had to modify ffmpeg source code) method of static linking it with ffmpeg (autostatic is in the windows pthreads cvs) along with a few other changes to make ffmpeg happy:


OMG I wasted so many hours today. Yes, this is the answer. pthreads-win32 cvs + this patch.

Will this patch create problems for other projects? If not, I am playing with a idea to create a git repo on github with cvs head, commit this patch and tag it 2.8.1. This way it will show up in google and other people won't be frustrated like me.

[kemuri-_9]

A) pthread cvs head is 2.9.0, not 2.8.0
B) forking a project causes confusion. don't fork it for such a (IMO petty) reason.
C) it would be wiser if ffmpeg detected that it's using a version of static pthread-win32 that has auto-static capability to it, rather than blindly assume it does.

[SledgeHammer_999]

A) pthread cvs head is 2.9.0, not 2.8.0
B) forking a project causes confusion. don't fork it for such a (IMO petty) reason.

I suggested this because I thought that upstream is dead. The last release was from 2006

C) it would be wiser if ffmpeg detected that it's using a version of static pthread-win32 that has auto-static capability to it, rather than blindly assume it does.

Ffmpeg didn't detect the lib if I had compiled it as static. I compiled with the lib as a dll and chaos ensued. (I am talking about 2.8.0 vanilla). With the patch ffmpeg detects the static lib.

[LoRd_MuldeR]

Pthreads isn't dead. Just check out the latest revision from the CVS:
http://sourceware.org/cgi-bin/cvsweb.cgi/pthreads/?cvsroot=pthreads-win32&sortby=date#dirlist

[TheRyuu]

ffms2-r470.7z (http://ffmpegsource.googlecode.com/files/ffms2-r470.7z)
ffms2-r470-avs64.7z (http://ffmpegsource.googlecode.com/files/ffms2-r470-avs64.7z)

ffmpeg-mt (pretty much) merged into libav, so no more separate builds.
Built with libav rev. 6af2801088 (2011-06-03)

Remember for the 64bit binary is an avisynth_c plugin so load with:
LoadCPlugin("X:\path\to\ffms2.dll")

Now with 100% more Opeth influence while building.

Changes from last build:
-Updated libav

[Rumbah]

I found a sample of h263 video that crashes for me every time with FFMS r470 and Avisynth 2.6 on a Core2Quad, even without starting multiple instances on Windows 7.

http://img225.imageshack.us/img225/6105/errorku.png (http://imageshack.us/photo/my-images/225/errorku.png/)
You can download the sample here: http://www.megaupload.com/?d=5PNE67AH

If you need more information I'll be glad to help you.

[Chikuzen]

I found a sample of h263 video that crashes for me every time with FFMS r470 and Avisynth 2.6 on a Core2Quad, even without starting multiple instances on Windows 7.

Your clip has N-VOPs.
I recommend you to do as follows.
FFMPEGSource2("crashtest.avi",atrack=-1,threads=1,fpsnum=25)

to devs
I think that you should change the default value of "threads" to 1 as much as ffmpeg.
It is dangerous to use multi-threads for decoding without thinking well.

[burfadel]

Yeah it works for me consistently with r470 over multiple sources with threads=1, otherwise it depends on the source (the crash I mentioned earlier the same as Rumbah). I also have a Core 2 Quad if that affects anything in regards to this...

[Chumbo]

I probably should have posted this here rather than on doom10. I just grabbed r470 and I still have the issue reported here:
http://doom10.org/index.php?topic=25.msg8240#msg8240

Any help is really appreciated. Thank you.

[TheRyuu]

I probably should have posted this here rather than on doom10. I just grabbed r470 and I still have the issue reported here:
http://doom10.org/index.php?topic=25.msg8240#msg8240

Any help is really appreciated. Thank you.

Upload a sample that's broke.

Try remuxing to mkv.

Also it sounds like it might be decoding each field into it's own frame so try adding SelectEven() after the ffvideosource line, it might also stop it from crashing.

[Chumbo]

Upload a sample that's broke.

Try remuxing to mkv.

Also it sounds like it might be decoding each field into it's own frame so try adding SelectEven() after the ffvideosource line, it might also stop it from crashing.
Okay, I'll upload a short sample. I actually have the original in an MKV but it does the same thing. I then remuxed it to a TS with tsmuxer and the same thing happened with the TS. Per my post on doom10, the older DLL worked fine as even stuff I was able to encode back in August is now not working with the new versions.

I'll post back when the sample is ready.

[tebasuna51]

ffms2-r470.7z
ffms2-r470-avs64.7z

ffmpeg-mt (pretty much) merged into libav, so no more separate builds.
Built with libav rev. 6af2801088 (2011-06-03)

But ffms2-r470.7z work with AviSynth no_mt?
At least don't work for me.

The simple script (work with vanilla 2.15):
FFVideoSource("D:\input.mkv")
was open in AviSynth but don't play:

[Chumbo]

Upload a sample that's broke.

Try remuxing to mkv.

Also it sounds like it might be decoding each field into it's own frame so try adding SelectEven() after the ffvideosource line, it might also stop it from crashing.
Here's the sample: http://www.mediafire.com/file/qdgyom6vrpbn1vf/short.clip.mkv

I also tried the SelectEven() with the same results with the TS and the MKV sample.

[TheRyuu]

But ffms2-r470.7z work with AviSynth no_mt?
At least don't work for me.

The simple script (work with vanilla 2.15):
FFVideoSource("D:\input.mkv")
was open in AviSynth but don't play:

I don't see a link to a sample in that post.

Here's the sample: http://www.mediafire.com/file/qdgyom6vrpbn1vf/short.clip.mkv

I also tried the SelectEven() with the same results with the TS and the MKV sample.

It's the typical transport stream breakage and is a known issue. There are some posts in this thread that specify some work arounds such as adding fpsnum/fpsden and threads=1 (this made it not crash for me), also if you know you won't be doing any seeking you can try using demuxer=lavf (this is a parameter to ffmsindex, not ffvideosource) and seekmode=-1. Actually seeking will probably be broken anyway so you should use this anyway.

You maybe have to look to an alternative way of souring though such as dss2.

[Chumbo]

...It's the typical transport stream breakage and is a known issue. There are some posts in this thread that specify some work arounds such as adding fpsnum/fpsden and threads=1 (this made it not crash for me), also if you know you won't be doing any seeking you can try using demuxer=lavf (this is a parameter to ffmsindex, not ffvideosource) and seekmode=-1. Actually seeking will probably be broken anyway so you should use this anyway.

You maybe have to look to an alternative way of souring though such as dss2.
I'll go ahead and use megui 32bit version with dss2 in the script then. Any idea when this broke? The last time I used it without issues was back around August/September of 2010. Any idea on a fix? Thanks.

[EDIT] I just remembered that I can't use the 32bit version because x264 crashes so I can't megui.

[EDIT2] Okay, I tried the fpsnum/fpsden and threads and these two settings did the trick. I then tried only one setting at a time and all I needed was to set threads=1 and that worked. Not sure how this will impact encoding performance though. Thanks a lot.

[TheRyuu]

I'll go ahead and use megui 32bit version with dss2 in the script then. Any idea when this broke? The last time I used it without issues was back around August/September of 2010. Any idea on a fix? Thanks.

[EDIT] I just remembered that I can't use the 32bit version because x264 crashes so I can't megui.

[EDIT2] Okay, I tried the fpsnum/fpsden and threads and these two settings did the trick. I then tried only one setting at a time and all I needed was to set threads=1 and that worked. Not sure how this will impact encoding performance though. Thanks a lot.

It's always been broken. Also it's decoding each field to a frame so you have to either specify fpsnum/fpsden or use selecteven() (notice your fps is 60 without it).

[Chumbo]

It's always been broken. Also it's decoding each field to a frame so you have to either specify fpsnum/fpsden or use selecteven() (notice your fps is 60 without it).
So why did it work just fine last year? Was it due to it using threads=1 by default?

[TheRyuu]

So why did it work just fine last year? Was it due to it using threads=1 by default?

If you didn't use the -mt version possibly. Although I'm pretty sure that defaulted to the number of cores as well but it didn't have the frame based multi-threading which is in the regular version now.

[tebasuna51]

But ffms2-r470.7z work with AviSynth no_mt?

I don't see a link to a sample in that post.

If I use the parameter threads = 1, don't crash anymore, but still don't decode properly some samples like this HD TV capture:

http://www.megaupload.com/?d=NSJSNFEP

With fpsnum = 25, fpsden = 1 the fps is ok but the decode is still wrong.

Works fine with DSS2-ffdshow-libavcodec.