FFmpegSource

[qyot27]

r688 should fix compilation in C stuff.
Confirmed. It compiles without issues again now.

try gcc 4.7. on my linux build fine
It wasn't tied to the version of GCC. And beyond that, I'm guessing that either:
A) That's the trunk, not the C branch. The trunk doesn't exhibit the problem.
B) If it was the C branch, you didn't do a HEAD catchup. An un-caught-up C branch is still back at like, r643.

[qyot27]

Due to request,

FFMS2 C-plugin r688

FFmpeg r41540 (git-2a622c2)
Both FFmpeg and FFMS2 optimized for Pentium III
MinGW-w64 GCC 4.8.0 20120610 (experimental)

EDIT: Updated, here (http://forum.doom9.org/showthread.php?p=1578387#post1578387)

[burfadel]

Due to request,

FFMS2 C-plugin r688 (http://www.mediafire.com/?96ynnprxdlgakq3)

FFmpeg r41540 (git-2a622c2)
Both FFmpeg and FFMS2 optimized for Pentium III
MinGW-w64 GCC 4.8.0 20120610 (experimental)

Wouldn't compiling for such an old processor be detrimental for newer processors?

What about SSEx etc instruction sets?

[sl1pkn07]

qyot27:

http://pastebin.com/pjj0XfHN

c-branch r.686 with gcc 4.7

gcc 4.8 is extreme experimental

[qyot27]

qyot27:

http://pastebin.com/pjj0XfHN

c-branch r.686 with gcc 4.7

gcc 4.8 is extreme experimental
I know that gcc 4.8 is experimental, and that pastebin isn't working so I can't see the result. But it doesn't change the point that something that 4.6.2 and 4.8.0 both error out on leaves little room for 4.7 to fix. Not that it matters now, since r688 resolves the problem.

It's also not being compiled natively for Linux, if that's what was happening. It's very specifically a MinGW-w64 build, because IMO there's very little point in compiling the C plugin on Linux. It has to have the AviSynth module enabled (as it's meant as the AviSynth plugin .dll, hence MinGW), since it's avisynth_c.o where the error is tripped.

Wouldn't compiling for such an old processor be detrimental for newer processors?

What about SSEx etc instruction sets?
I don't know, and without trying to sound callous, I'm not concerned about it. I optimize for the processor I actually have and use 99% of the time. I've never run a definitive test of whether - or how much - it affects the performance of newer processors.

[sl1pkn07]

oks. thanks :)

[LigH]

Probably as mentioned before for the ffdshow decoders: Most of their optimization is already done in Assembler. The little bit of C++ compiler optimization potential left to the sources is only related to the API.

[qyot27]

Slightly updated version since there were two more commits made while I was busy compiling everything the other day, and stupidly did not save the FFmpeg dev files.

FFMS2 C-plugin r690

FFmpeg r41586 (git-ddece75)
Still PIII and MinGW-w64 GCC 4.8.0



EDIT: New build here. (http://forum.doom9.org/showthread.php?p=1582286#post1582286)

[Abs62]

r694 don't compile.
..\src\core\haalivideo.cpp(157): error C2094: label 'Error' was undefined

[JEEB]

The following interlaced H.264 sample will not work correctly in ffms2 (tested 2.17, r644, r666):
http://www.mediafire.com/?ubxfydr4owr2rmo

Multi-threaded: insanity, decoder delivers empty frame after first(?) frame
1 thread: jumping back and forth

This sample seems to have mostly been fixed with the recent multithreading-fixing commits :)

After a brief test with Aegisub the only problem I was getting was that every frame came out twice, which could be sample-related (I would like to have someone with more knowledge on the matter comment on how broken this matroska remux is, as most things seem to fail to mux or deal with the H.264 stream included to begin with). Otherwise it seems like frame order was correct, and all frames seem to be output correctly. With Avisynth I did also try with threads=1 and that for some reason brought back the jerkiness in a bit different way.

A build is available for testing here (http://x264.fushizen.eu/builds/ffms2/ffms2-r695-libav-gitd77f4af.7z).
ffms2: r695, libav: git-d77f4af

libav configuration:
--prefix=/ffms --disable-network --disable-encoders --disable-muxers --disable-hwaccels --disable-indevs --disable-outdevs --extra-cflags='-U__STRICT_ANSI__ -D_SYSCRT' --disable-debug --enable-runtime-cpudetect

[Guest]

I would like to have someone with more knowledge on the matter comment on how broken this matroska remux is. It appears fine to me. Using DGDecodeNV it decodes perfectly and the GPU deinterlacing looks very nice as well. I reported this bug years ago to the lavc guys, but nobody ever cared about it.

[JEEB]

It appears fine to me. Using DGDecodeNV it decodes perfectly and the GPU deinterlacing looks very nice as well. I reported this bug years ago to the lavc guys, but nobody ever cared about it.
Alrighty, can you link to the old bug report or something that would have more details on it, or, if that's no longer available, can you give some more technical details that I can then push towards both projects? It seems like both sides are nowadays more active with regards to getting bug reports dealt with.

[Daemon404]

This sample seems to have mostly been fixed with the recent multithreading-fixing commits :)

After a brief test with Aegisub the only problem I was getting was that every frame came out twice, which could be sample-related (I would like to have someone with more knowledge on the matter comment on how broken this matroska remux is, as most things seem to fail to mux or deal with the H.264 stream included to begin with). Otherwise it seems like frame order was correct, and all frames seem to be output correctly. With Avisynth I did also try with threads=1 and that for some reason brought back the jerkiness in a bit different way.

A build is available for testing here (http://x264.fushizen.eu/builds/ffms2/ffms2-r695-libav-gitd77f4af.7z).

My own code using the ffms2 lib works fine, but this may be related:

pts: 80
pts: 100
pts: 0
pts: 20
pts: 0
pts: 0
pts: 20
pts: 20
pts: 242
pts: 274
pts: 306
[...]

[le_canz]

I all :) First, I'd like to thank all the devs for ffmpegsource, it's the only source method I use with avisynth, and I works great (well... not always :p)

I have some trouble opening MTS files from some digital camera with ffmpegsource. I don't know which camera unfortunately, as it wasn't mine... This file plays fine with VLC.

Video is H264 interlaced 1440x1080, and what ffmpegsource shows is quite messed up : frames are sometimes repeated twice, and fields appear not to be in the good order.

I tried with several ffmpegsource builds (683 from google code, 695 compiled by JEEB), same result. FFIndex() doesn't help, nor remuxing to mkv.

I use avisynth 2.6 with linux / wine 1.4

Here is a small sample if you want to try.
http://dl.free.fr/ghi9NtIxE

[LigH]

PAFF interlaced AVC videos recorded by AVCHD cameras are known problems for the libav decoder already for longer. Did you use the parameter 'threads=1'?

[le_canz]

PAFF interlaced AVC videos recorded by AVCHD cameras are known problems for the libav decoder already for longer.

I didn't know that. Thanks for the info.

Did you use the parameter 'threads=1'?

Yes, same result.

[leoenc]

Could someone please share a current build (r700)?

Thanks

[JEEB]

Random build time: clicky (http://x264.fushizen.eu/builds/ffms2/ffms2-r700-libav-gitc29c1a1.7z).
ffms2: r700, libav: git-c29c1a1

libav configuration:
--prefix=/ffms --disable-network --disable-encoders --disable-muxers --disable-hwaccels --disable-indevs --disable-outdevs --extra-cflags='-U__STRICT_ANSI__ -D_SYSCRT' --disable-debug --enable-runtime-cpudetect

[Wilbert]

Just curious. Is FFmpegSource be able to load MXF files? I see that it was added to libavformat at some point.

[JEEB]

Just curious. Is FFmpegSource be able to load MXF files? I see that it was added to libavformat at some point.
Tried with the Cars M2V sample (http://samples.mplayerhq.hu/MXF/Cars_TL4IO6_239_DEXX_MPEG_TDC_072006.m2v.mxf) available at mplayerhq, and it seems to load fine and linear decoding seems to be fine. Seeking backwards seemed a little awkward but I'm not sure if setting threads to one might help with that.

[wonkey_monkey]

Just out of curiosity, is there a simple explanation as to why ffmpegsource is frame-accurate with, for example, MKV, but not with VOB/MPG? Is it just a limitation of a library that's no-one's ever bothered to improve?

David

[Wilbert]

Tried with the Cars M2V sample available at mplayerhq, and it seems to load fine and linear decoding seems to be fine. Seeking backwards seemed a little awkward but I'm not sure if setting threads to one might help with that.
If I try to open it with 2.17 (ffms-2.17.7z) i get the following error:

Avisynth open failure:
FFVideoSource: Can't open blabla ...

script:

FFVideoSource("F:\Cars_TL4IO6_239_DEXX_MPEG_TDC_072006.m2v.mxf")

[Plorkyeran]

I made several MXF-related fixes recently to handle its lack of timestamps. r700 works correctly on all of the files I tested it on (which was not very many).

Just out of curiosity, is there a simple explanation as to why ffmpegsource is frame-accurate with, for example, MKV, but not with VOB/MPG? Is it just a limitation of a library that's no-one's ever bothered to improve?
DGIndex mostly works fine, so things it can open are lower priority than formats which don't have any reasonable alternatives. AFAIK MPEG-2 in VOB should work fine as long as RFF handling is enabled other than that split VOBs aren't supported.

[wonkey_monkey]

AFAIK MPEG-2 in VOB should work fine as long as RFF handling is enabled other than that split VOBs aren't supported.

Just today I was unable to get within 3 frames accurate on MPEG-2 in VOB (PAL, so no RFF) :( DGIndex is great, of course, but I'd love an alternative that didn't require demuxing audio.

David

[Plorkyeran]

If you can upload a sample with issues I'll take a look at it when I get a chance.

[qyot27]

FFMS2 C-plugin r700

FFmpeg version r42437 git-9b3f9f4
Both FFmpeg and FFMS2 built with GCC 4.8.0 20120610 (experimental)
Both optimized for Pentium III

Contains some really bleeding edge support for decoding 12-bit and 14-bit 4:2:0 H.264, thanks to recent commits to FFmpeg (http://git.videolan.org/?p=ffmpeg.git&a=search&h=HEAD&st=commit&s=14+bit). It seems to be most stable with 12-bit, although some of the problems I've been having getting the samples prepared could be due either to swscale issues or the tricky nature of trying to get the config files for JM (18.3, if that matters) correctly set. I had some 14-bit tests that seemed fine, but others went wonky and I can't determine which parts threw it off. 4:2:2 and 4:4:4 in either of the new bit depths result in mostly green output, which may or may not be due to swscale (my money is on swscale, but I can't be completely sure).

EDIT: New build here (http://forum.doom9.org/showthread.php?p=1588762#post1588762)

[burfadel]

FFMS2 C-plugin r700 (http://www.mediafire.com/?dmjyn5r74tnj7zl)

FFmpeg version r42437 git-9b3f9f4
Both FFmpeg and FFMS2 built with GCC 4.8.0 20120610 (experimental)
Both optimized for Pentium III

Contains some really bleeding edge support for decoding 12-bit and 14-bit 4:2:0 H.264, thanks to recent commits to FFmpeg (http://git.videolan.org/?p=ffmpeg.git&a=search&h=HEAD&st=commit&s=14+bit). It seems to be most stable with 12-bit, although some of the problems I've been having getting the samples prepared could be due either to swscale issues or the tricky nature of trying to get the config files for JM (18.3, if that matters) correctly set. I had some 14-bit tests that seemed fine, but others went wonky and I can't determine which parts threw it off. 4:2:2 and 4:4:4 in either of the new bit depths result in mostly green output, which may or may not be due to swscale (my money is on swscale, but I can't be completely sure).

This build appears to fail, at least opening AVI files. Jeeb's r700 build works fine.

I get the same error as Wilbert in post http://forum.doom9.org/showthread.php?p=1580834#post1580834

[qyot27]

I just tested an XviD AVI and an ffvhuff AVI. Both indexed without issue and the scripts played back fine.

Without more information, it's not possible to tell whether it's a compilation problem, a libavformat/codec problem, a script problem, or something in FFMS2 itself.

[qyot27]

It seems as though something has changed which makes MP4 files no longer work. All the MP4 files I tested with it fail, including music videos purchased from iTunes and videos that have been remuxed into MP4 with MP4Box. Files muxed by L-SMASH seem to be fine.

It's probably because of a change in libavformat, since a build of FFMS2 r700 from June 28th works, but ones from July 4th and 10th don't, responding with:
Indexing error: Invalid initial pts, dts, and duration
MOV and FLV files are unaffected, and FFmpeg itself deals with these same MP4s without an issue (as did the build of r700 from June 28th), so I'm guessing that what happened is that there was an API change and that's what's messing with FFMS2.


Also, I don't know what's going on (and I doubt it's related to the MP4 issue), but FFMS2 can't link to FFmpeg on any of my cross-compile environments through MinGW-w64, as it's complaining about libraries that FFmpeg shouldn't have linked to in the first place given this is a MinGW build:
checking whether i686-w64-mingw32-gcc works... yes
checking for -std=gnu99... yes
checking whether defined(_WIN32) is true... yes
checking for CoUninitialize(); in objbase.h... yes
checking whether LIBAVCODEC_VERSION_MICRO >= 100 is true... yes
checking for avcodec_decode_video2( 0, 0, 0, 0 ); in libavformat/avformat.h... no
Failed commandline was:
--------------------------------------------------
i686-w64-mingw32-gcc conftest.c -Wall -march=pentium3 -mtune=pentium3 -std=gnu99 -lz -lbz2 -lpthreadGC2 \
-lutvideo -lole32 -I/home/qyot27/win32_build/include -I/usr/local/include -L/home/qyot27/win32_build/lib \
-lswscale -lavformat -lavcodec -lavutil -lavifil32 -pthread -L/usr/local/lib -lavformat -lavcodec -ldl -lva \
-ljack -lasound -lSDL -lxvidcore -lutvideo -lstdc++ -lbz2 -lz -lrt -lswscale -lavutil -lm
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -ldl
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -lva
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -ljack
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -lasound
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -lSDL
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -lrt
collect2: error: ld returned 1 exit status
--------------------------------------------------
DIED: unable to link against FFmpeg
It's also trying to test FFMS2 against xvidcore and I didn't even have that in the FFmpeg configure, which was this:
configuration: --prefix=/home/qyot27/win32_build --cross-prefix=i686-w64-mingw32- --enable-gpl --enable-version3 \
--disable-w32threads --enable-memalign-hack --disable-decoder=utvideo --enable-libutvideo --disable-encoders \
--disable-muxers --disable-debug --disable-network --disable-hwaccels --disable-indevs --disable-outdevs \
--cpu=pentium3 --extra-cflags='-march=pentium3 -mtune=pentium3 -DPTW32_STATIC_LIB' --target-os=mingw32 --arch=x86
The FFmpeg binary seems unaffected, because it'll display its normal output just fine under actual Windows (I can't do further testing with it due to it being reduced like it is).

That particular issue seems to have cropped up in just the last week or so, since the July 10th build was cross-compiled, but my attempts over the last day or two have resulted in the error above.

[Kovensky]

(...) -L/home/qyot27/win32_build/lib \
-lswscale -lavformat -lavcodec -lavutil -lavifil32 -pthread -L/usr/local/lib -lavformat -lavcodec -ldl -lva \
-ljack -lasound -lSDL -lxvidcore -lutvideo -lstdc++ -lbz2 -lz -lrt -lswscale -lavutil -lm
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -ldl
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -lva
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -ljack
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -lasound
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -lSDL
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -lrt
collect2: error: ld returned 1 exit status

It's actually trying to link with two different "ffmpegs" at the same time, including your system one. Make sure pkg-config is properly configured; use PKG_CONFIG_LIBDIR to make sure it doesn't try to look in any of the default paths.

[qyot27]

It's actually trying to link with two different "ffmpegs" at the same time, including your system one. Make sure pkg-config is properly configured; use PKG_CONFIG_LIBDIR to make sure it doesn't try to look in any of the default paths.
I figured that it was trying to do something along those lines, and it also explains why it only ever seemed to happen with the the C-plugin - I've always used PKG_CONFIG_PATH on the trunk and x264, whereas with the C-plugin I don't/didn't because of it not working back when I first started building it (http://doom10.org/index.php?topic=25.msg4244#msg4244) (although re-reading it now it probably would have worked if I'd copied/symlinked pkg-config to include the cross-prefix; I can't remember if I'd gotten into the habit of doing that at the time), meaning that I was still using FFMPEG_LIBS and FFMPEG_CFLAGS to tell it where to look and never bothered to notice when the situation changed. So I just never thought of it being a pkg-config issue. Since it does work now, I'll just switch over to that.

[hello_hello]

I'm not overly knowledgeable when it comes to video indexing/encoding, but I'm having an ffms2 indexing problem and thought I'd ask about it here. I'm using version 2.17 and I've tried r683.

I have some MKVs which contain constant frame rate DivX video and I'm fairly sure the video contains duplicate frames. If I remux the MKVs as AVIs I can open them using AVISource and the duplicate frames seem be included when encoding. If I use ffms2 to index them however, the resulting video contains fewer frames than the original. The total video duration is basically correct, but the frame rate is reduced to achieve it. Adding "fpsnum=25, fpsden=1" to the script (25fps source) fixes the frame count and I can convert without audio sync issues.

If the issue is duplicate frames, is this expected behavior or should ffms2 handle them "correctly"?
Thanks.

[kolak]

If I try to open it with 2.17 (ffms-2.17.7z) i get the following error:

Avisynth open failure:
FFVideoSource: Can't open blabla ...

script:

FFVideoSource("F:\Cars_TL4IO6_239_DEXX_MPEG_TDC_072006.m2v.mxf")


Use different build based on ffmbc for mxf files- it should work much better and it also has 10bit support (eg you can read DNxHD MXF files at 10bit):

http://forum.doom9.org/showthread.php?p=1583307#post1583307

[Selur]

calling:
LoadPlugin("G:\Hybrid\avisynthPlugins\ffms2.dll")
FFVideoSource("H:\Output\input.m2ts",cachefile="H:\Temp\input_m2ts_41.ffindex",threads=1)
with any of JEEBs builds (http://x264.fushizen.eu/builds/ffms2/) I get distorted pictures (looks like decoding is broken), works fine with ffms2-r683 from http://code.google.com/p/ffmpegsource/downloads/list
input.m2ts contains avc video

Cu Selur

[mp3dom]

Use different build based on ffmbc for mxf files- it should work much better and it also has 10bit support (eg you can read DNxHD MXF files at 10bit):

http://forum.doom9.org/showthread.php?p=1583307#post1583307

I'm getting slighty different results on a ProResHQ file using the r700 build based on ffmpeg compared to the build based on ffmbc. The 10bit data are different (at least, watching the stacked clip on VirtualDub).
The ffms2 based on ffmbc outputs the same image of ffmbc->v210->readv210
The ffms2 based on ffmpeg outputs the same image of ffmpeg->v210->readv210

Now the main question is: which is the right decode?

[kolak]

What is the difference?

I tried decoding ProRes to v210 in different ways and always had same (or 99.9%) results. Seen some tiny differences in waveform, but it's impossible to so it by eye.
I have no clue which is correct, but as far as I can tell difference is marginal.
Will try again with new Resolve 9.

[jmac698]

I'm wondering if this is the proper way to force point sized 4:1:1 export with ffms2 (original build) and Avisynth 2.6a3:

A = FFAudioSource(dir+fn)
V = FFVideoSource(dir+fn, resizer="POINT")#attempt to avoid touching chroma in 4:1:1 -> 4:2:2
AudioDub(V, A)
ConvertToYV411(chromaresample="point")#convert from YUY2->YV411

The manual states that a resizer is used if the destination doesn't support chroma subsampling, but it's not stated how the conversion is done if the subsampling resolution differs. If my theory is correct, I am recreating true 4:1:1 via 4:2:2.

[TheFluff]

The proper thing to do would be to use the C-plugin, since it has support for the Avisynth 2.6 colorspaces and thus supports outputting 4:1:1.

[jmac698]

*headslap* great! Well, I didn't know what the difference was, I did notice it in the download list. Thanks.

[mp3dom]

What is the difference?

It's at pixel level. It concern only some pixels and it resemble something similar to a 'luma' difference. Nothing correlated to visual artefacts. Watching the clip stacked, you can see better where are the difference. They're small but I've seen some bigger 'portions' of difference. Anyway I can live with it, but since the decoded image should be the same from both ffmbc and ffmpeg, I'm wondering which provide the right decode.

[kolak]

Yes- I see the same problem. Tried Resolve, ffmbc, ffmpeg and all look bit different- none of the pairs looks exactly the same. I think it's down to processing precision or whatever :)

[jmac698]

Ok,
I'm having a bunch of problems.
FFMS2 is crashing.

dir="C:\project004\home video project\"
fn="testclip.mov"
plugindir="M:\Program Files\AviSynth 2.5\plugins\temp\"
pluginfn="ffms2.dll"
Load_Stdcall_Plugin(plugindir+pluginfn)
A = FFAudioSource(dir+fn)
V = FFVideoSource(dir+fn)
AudioDub(V, A)


File "pyavs.pyo", line 328, in _GetFrame
File "avisynth.pyo", line 277, in GetFrame
WindowsError: exception: access violation reading 0x00000048

When I seek back and forth at the start, it eventually crashes.
Avisynth 2.6a3
ffms-2.17-cplugin.7z
No other plugins loaded
And the source clip is here http://www.digitalfaq.com/forum/video-workflows/4413-how-quicktime-files-2.html#post22197
NTSC DV in mov
I couldn't find any more recent versions of the C version to try.

[Reel.Deel]

Hi jmac698, here is an updated FFMS2 C plugin (http://forum.doom9.org/showthread.php?p=1582286#post1582286).

BTW, since I'm not a member of DigitalFAQ I can't download your sample.

[qyot27]

EDIT 2012-08-17: A much better solution was committed to SVN. Disregard this post.

With current revisions of both FFmpeg and libav from git, compilation of r702 (both trunk and C-plugin) fails due to some CodecID changes.

The following patch resolves the issue by moving most of the CodecID instances to AVCodecID:
[doesn't exist anymore]

I don't know if I changed it in places that may have been unnecessary, but it doesn't seem to have caused any other problems (but I also don't compile FFMS2 with Visual Studio).

[qyot27]

FFMS2 r705 trunk:
CXX src/core/matroskavideo.lo
CXX src/core/numthreads.lo
CC src/core/stdiostream.lo
CXX src/core/utils.lo
src/core/utils.cpp: In function 'void FlushBuffers(AVCodecContext*)':
src/core/utils.cpp:569:34: error: invalid conversion from 'const AVCodec*' to 'AVCodec*' [-fpermissive]
AVCodec *codec = CodecContext->codec;
^
make: *** [src/core/utils.lo] Error 1
r705 C-plugin:
CXX src/core/matroskaaudio.o
CXX src/core/matroskaindexer.o
CXX src/core/matroskavideo.o
CXX src/core/utils.o
src/core/utils.cpp: In function 'void FlushBuffers(AVCodecContext*)':
src/core/utils.cpp:569:34: error: invalid conversion from 'const AVCodec*' to 'AVCodec*' [-fpermissive]
AVCodec *codec = CodecContext->codec;
^
make: *** [src/core/utils.o] Error 1

I got around it by tacking 'const' onto the beginning of line 569 in src/core/utils.cpp like the error message says. Dunno if that's right, though.

[JEEB]

Yes, to get ffms2 to build with current libav/ffmpeg you have to do something a la this (http://pastebin.com/9uFT7ZfH).

You get somewhat less errors as you are not building it on windows/MSVC, and the weird-looking include addition comes from the fact that FFMIN and friends are being used there, yet it was not included in order to use them.

[qyot27]

Something that I've been wondering lately, partially about testing the performance of certain decoding methods:

Is it possible (or rather, how easy/difficult would it be) to add a decoder= option to FFMS2 to cover those cases where multiple decoders for the same format are present in a build of libavcodec? Something similar is there with the demuxer option, and would provide some flexibility to test if there happens to be a problem with one of the decoders.

Currently, to test this with external decoders you have to explicitly disable the native one and enable the external, and consequently make multiple builds of both FFmpeg/libav and FFMS2 to cover the difference.

[Myrsloik]

Something that I've been wondering lately, partially about testing the performance of certain decoding methods:

Is it possible (or rather, how easy/difficult would it be) to add a decoder= option to FFMS2 to cover those cases where multiple decoders for the same format are present in a build of libavcodec? Something similar is there with the demuxer option, and would provide some flexibility to test if there happens to be a problem with one of the decoders.

Currently, to test this with external decoders you have to explicitly disable the native one and enable the external, and consequently make multiple builds of both FFmpeg/libav and FFMS2 to cover the difference.

I'm against this. Just use an original ffmpeg/libav build and see if it works outside avisynth. Then file a bug report with the appropriate project.

[abyss616]

How can I avoid FFMS2 "going insane" and returning empty frames at tiny little video stream errors another VfW codec or DirectShow decoder survives?

By not using FFMS2, not multithreading it also helps sometimes.

So is it still the recommendation if you have h.264 interlaced video (VHS>.ts captured using Hauppauge HD-PVR) to use something like DSS2 instead of FFVideoSource? I have a bunch of tapes I want to digitize and would like to use the best possible source.

[Gser]

So is it still the recommendation if you have h.264 interlaced video (VHS>.ts captured using Hauppauge HD-PVR) to use something like DSS2 instead of FFVideoSource? I have a bunch of tapes I want to digitize and would like to use the best possible source.

FFVideoSource doesn't really support .ts or .m2ts, so try muxing the file into a mkv. Some broadcasts work like this and some need to use DSS2.