FFmpegSource

[qyot27]

Originally Posted by Kovensky

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

Originally Posted by Wilbert

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.ph...07#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 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]

Originally Posted by kolak

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.ph...07#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]

Originally Posted by kolak

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)

Originally Posted by AVSP 2.31

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/vide...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.

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.

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]

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

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]

Originally Posted by LigH

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

Originally Posted by Gser

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]

Originally Posted by abyss616

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.