FFmpegSource

[burfadel]

Ah ok, thanks!

[TheRyuu]

Ah ok, thanks!

And as soon as I said it makes no difference we now have attempt #2:
ffms2-r725-icl-2.7z (https://ffmpegsource.googlecode.com/files/ffms2-r725-icl-2.7z)

Requires SSE2 capable CPU (isn't restricted to Intel) because as it turns out it does make a difference once you get fate to give you the green light.

[active1]

i got this error when using ffms2-r722 with vapoursynth-r10 :
vapoursynth.Error: 'Core only supports API R2 but the loaded plugin uses API R1'

script:
import vapoursynth as vs
import sys
core = vs.Core()
core.std.LoadPlugin(path='D:\\ffms2.dll')
v = core.std.FFVideoSource(source='d:\\v.mkv')
v.output(sys.stdout, y4m=True)

[Chikuzen]

i got this error when using ffms2-r722 with vapoursynth-r10 :


Myrsloik broke VS-API at VS-r9.
Therefore, you can't use old ffms2 on latest VS any more.
use ffms2-r724 or later.

[Keiyakusha]

active1
Not really sure about your exact problem but It maybe that your FFMS2 is too old
Also in recent ffms2, function FFVideoSource is no more. This is what I asked in vapoursynth thread not so long ago.

edit: i'm too slow

[active1]

ok, i used ffms2-r725-icl-2 and it works with: v = core.ffms2.Source(source='d:\\v.mkv')
thanx! :)

[kolak]

Why ffms2 is so slow when decoding ProRes in avisynth- only 30fps on my 8 core machine (and 15fps with 1 core)? Looks like very poor scaling?

[cretindesalpes]

Is it slow also when reading with FFmpeg in command line? If so, the right place to complain is the FFmpeg development mailing list, not here because FFmpegSource is "just" a wrapper around the FFmpeg libraries and the FFMS dev won't do anything regarding codec issues.

[kolak]

No- ffmpeg can read much faster, at least 2x faster.
Funny enough hacked ffms2 with 10bit read turned on is also way faster. Is it 10bit to 8bit scaling slowing it down?
It's way faster to read it at 10bit and simply crop 10bit part :)

To make it more funny DNxHD is opposite- ffms2 8bit is much faster in decoding it (than hacked ffms2 at 10bit). I'm lost now- it makes no sense :) It has to be difference in decoding between ffmpeg and ffmbc for each format.

[mastrboy]

indexing seems broken with large files in the latest revisions, last working one for me is ffms2-r712-2.
File information:

Format : AVI
Format/Info : Audio Video Interleave
Format profile : OpenDML
File size : 4.72 GiB
Duration : 19mn 34s
Overall bit rate : 34.5 Mbps
Writing library : VirtualDub build 32842/release

Video
ID : 0
Format : Huffman
Codec ID : HFYU
Duration : 19mn 34s
Bit rate : 34.5 Mbps
Width : 704 pixels
Height : 480 pixels
Display aspect ratio : 3:2
Frame rate : 23.976 fps
Standard : NTSC
Color space : RGB
Bit depth : 8 bits
Bits/(Pixel*Frame) : 4.262
Stream size : 4.72 GiB (100%)


ffms2-r722.7z and ffms2-r725-icl-2.7z jumps up to 100% and returns "Unknown error" after a while. Atleast when using ffmsindex.exe

[TheRyuu]

indexing seems broken with large files in the latest revisions, last working one for me is ffms2-r712-2.


I think I know why, I'll put up a test build later when I have a bit of time with the changes so you can test it.

[cyberbeing]

I've also noticed that x264 reports indexing fails with the ICL r725 builds, when FFMS2 is automatically loaded by x264 via Avisynth. The r722 MSVC build on GoogleCode works fine.

[mastrboy]

I think I know why, I'll put up a test build later when I have a bit of time with the changes so you can test it.

Thanks, but i found different issues with ffms2-r712-2 and ffms2-r706.

I had to go back to ffms2-r683 to get indexing to work properly.

Here are the issues i experience with the different revisions:
ffms2-r683: working, complete index file (accurate progress report)
ffms2-r706 and ffms2-r712-2: creates a index files but fails at about 4-5000 frames, even though it reports success and 100%. The indexing file when opened with avisynth FFVideoSource only returns 4-5000 frames. The progress report is also weird, it goes very fast to 99% then stays there for a while.
ffms2-r722 and ffms2-r725-icl-2: Fails with unknown error during indexing and exits.

[the_weirdo]

Just FYI, I don't have this problem with my own build (built against latest Libav git master and FFMS r725 source code using MinGW-w64 GCC for lav* and MSVC2010 for FFMS). I tried index a ~7GB MKV file with ffmsindex.exe and it works properly. Opening the indexed file in AvsPmod by FFVideoSource also doesn't show any problems.

[mastrboy]

Just FYI, I don't have this problem with my own build (built against latest Libav git master and FFMS r725 source code using MinGW-w64 GCC for lav* and MSVC2010 for FFMS). I tried index a ~7GB MKV file with ffmsindex.exe and it works properly. Opening the indexed file in AvsPmod by FFVideoSource also doesn't show any problems.

Care to share that version so i can test it on my files?

[the_weirdo]

Care to share that version so i can test it on my files?

Sure. Here (http://www.mediafire.com/?zu3dm941dhxyzfr) you go.
(32-bit only and you'll need to install MSVC++ 2010 Redist x86 (http://www.microsoft.com/en-us/download/details.aspx?id=8328) if you don't have it installed already).

[mastrboy]

Sure. Here (http://www.mediafire.com/?zu3dm941dhxyzfr) you go.
(32-bit only and you'll need to install MSVC++ 2010 Redist x86 (http://www.microsoft.com/en-us/download/details.aspx?id=8328) if you don't have it installed already).

Thanks :), your version works as it's supposed to. So i guess for the revisions i have problems with, it's not a code issue but a compiler or compiler settings issue...

[TheRyuu]

Thanks :), your version works as it's supposed to. So i guess for the revisions i have problems with, it's not a code issue but a compiler or compiler settings issue...

Yes, I haven't had time to do up a new one but like I said I'm pretty sure I know what's wrong.

[TheRyuu]

ffms2-r725-icl-3.7z (https://ffmpegsource.googlecode.com/files/ffms2-r725-icl-3.7z)

Hopefully doesn't crash. Try it and let me know if we're good now.
Also added code to override the cpu dispatcher Intel uses so it doesn't penalize AMD cpu's at all (although it should have been very minimal/not noticeable before with the settings being used).

Also now contains nearly all of the inline asm (ICL can compile a restricted version of GNU style inline assembly).

This also further improves YV12->RGB32 performance (gains about 8-10fps (from ~60fps) on a 720p file).

[TheRyuu]

ffms2-r725-icl-4.7z (https://ffmpegsource.googlecode.com/files/ffms2-r725-icl-4.7z)

Have some more experimental asm changes for even more speed (gets rid of the need for an aligned stack for certain h264/vp8 8-bit stuff).

[burfadel]

Thanks! ffms2-r725-icl-4 is noticeably faster to encode with than the standard r725 builds, at least 8 percent (roughly) on the current file.
(on i5-3570K)

[mastrboy]

ffms2-r725-icl-4.7z (https://ffmpegsource.googlecode.com/files/ffms2-r725-icl-4.7z)

Have some more experimental asm changes for even more speed (gets rid of the need for an aligned stack for certain h264/vp8 8-bit stuff).

Seems i still have problems with large files with this compiled version. It only manages to index about 7-8000 frames before exiting and reporting 100%, while the AVI file in question has about 20.000 frames.

[TheRyuu]

Seems i still have problems with large files with this compiled version. It only manages to index about 7-8000 frames before exiting and reporting 100%, while the AVI file in question has about 20.000 frames.

Oh? That's interesting. It sounds like a sample probably isn't very feasible considering the size, in which case what exactly are the specifics of the file? I'll try making one on my end to reproduce to see if I can track down the problem. Considering only ICL builds are broken it may very well be the compiler is barfing on something. I'll try and upload an updated MSVC build later as well, but I still want to try and reproduce it even if the MSVC build works.

Sample length seems to be about 20,000 frames. All I really need at that point is frame size (e.g. 1280x720) and codec used.

[mastrboy]

Media info from 2 different files which indexing fails for:

General
Format : AVI
Format/Info : Audio Video Interleave
Format profile : OpenDML
File size : 4.58 GiB
Duration : 19mn 34s
Overall bit rate : 33.5 Mbps
Writing library : VirtualDub build 32842/release

Video
ID : 0
Format : Huffman
Codec ID : HFYU
Duration : 19mn 34s
Bit rate : 33.5 Mbps
Width : 704 pixels
Height : 480 pixels
Display aspect ratio : 3:2
Frame rate : 23.976 fps
Standard : NTSC
Color space : RGB
Bit depth : 8 bits
Bits/(Pixel*Frame) : 4.135
Stream size : 4.58 GiB (100%)

General
Format : AVI
Format/Info : Audio Video Interleave
Format profile : OpenDML
File size : 5.22 GiB
Duration : 19mn 34s
Overall bit rate : 38.1 Mbps
Writing library : VirtualDub build 32842/release

Video
ID : 0
Format : Huffman
Codec ID : HFYU
Duration : 19mn 34s
Bit rate : 38.1 Mbps
Width : 768 pixels
Height : 576 pixels
Display aspect ratio : 4:3
Frame rate : 23.976 fps
Color space : RGB
Bit depth : 8 bits
Bits/(Pixel*Frame) : 3.596
Stream size : 5.22 GiB (100%)

The files where created with Virtualdub newest stable with the following settings: http://postimage.org/image/irl68g4gf/ and saved with "Fast recompress".
The source for the avi files is avs scripts which use DGindex and IVTC on vob files.

[Chikuzen]

Seems i still have problems with large files with this compiled version. It only manages to index about 7-8000 frames before exiting and reporting 100%, while the AVI file in question has about 20.000 frames.

This bug (http://git.libav.org/?p=libav.git;a=blobdiff;f=libavformat/file.c;h=c552a9eaa58c544285413d99a6f160441ea3da22;hp=fc0af92277ee7b7813c51a6ea2256b9caed233f0;hb=e04826c34e9b19cc4da60fd028334f12f84b4b2a;hpb=f79364b2c30aaaec9f0b1500a74da5a859c2ff37) that VFR_maniac fixed before half a day may be related.

[qyot27]

Testing build:
http://www.mediafire.com/?3r7xcwl4lhh8mw4

I've unfortunately been unable to load it into VapourSynth under Windows (it works on Linux; natively, I mean, not this build). I'm not sure if it's an issue with MinGW, or because both AviSynth C-plugin and VapourSynth interfaces were active (or possibly because on Windows I went with the installers for Cython and VS instead of [re-]building them myself). If I open ffms2.dll in dllexp, it shows that it contains:
VapourSynthPluginInit@12 0x6edaf13b 0x0002f13b 102 (0x66) ffms2.dll C:\Program Files\AviSynth 2.5\plugins\ffms2.dll Exported Function
But when I try to load it in VS, it complains about not finding an entry point.
Traceback (most recent call last):
File "vstestscript.vpy", line 4, in <module>
core.std.LoadPlugin(r'C:\Program Files\AviSynth 2.5\plugins\ffms2.dll')
File "vapoursynthpp.pyx", line 870, in vapoursynth.Function.__call__ (src\cython\vapoursynthpp.c:12399)
vapoursynth.Error: 'No entry point found in C:\\Program Files\\AviSynth 2.5\\plugins\\ffms2.dll'

Script:
import vapoursynth as vs
import sys
core = vs.Core()
core.std.LoadPlugin(r'C:\Program Files\AviSynth 2.5\plugins\ffms2.dll')
ret = core.ffms2.Source(r'Those Three Words Final.mp4')
ret.output(sys.stdout, y4m=True)

[Myrsloik]

How did you compile it? That's a partially decorated symbol. The exported fun tion name has to start with a _ or be without @12

[qyot27]

Cross-compiled with MinGW-w64 (gcc 4.8.0 prerelease) under Ubuntu 12.04. The integration with the C plugin's build system is here (https://github.com/qyot27/ffms2/commit/3b5da710cecc23c5a238d4a8e42b30b3af6dc555).
PKG_CONFIG_PATH=$HOME/win32_build/lib/pkgconfig ./configure --prefix=$HOME/ffms2-avs \
--cross-prefix=i686-w64-mingw32- --host=i686-pc-mingw32 --enable-avs --enable-vapoursynth \
--enable-shared --extra-cflags="-march=pentium3 -mtune=pentium3" --extra-ldflags="-lz -lbz2 -lpthreadGC2 -lutvideo"
make
make install-avs

[TheRyuu]

The files where created with Virtualdub newest stable with the following settings: http://postimage.org/image/irl68g4gf/ and saved with "Fast recompress".
The source for the avi files is avs scripts which use DGindex and IVTC on vob files.

Out of curiosity, why are you using ffms2 to open up these AVI files?

[qyot27]

I tried again, with a couple of other configurations.

It seems that having the AviSynth C-plugin active was masking a build issue with the VapourSynth code. If I tried to use only --enable-vapoursynth, I was getting errors from ffmsindex about not finding the functions in ffms.h. I'd not added vapoursynth detection to the shared library rules; once I did that, it compiled without issue, although the symbol looks exactly the same as before.

When using the trunk and using autogen.sh to get VS support enabled, it experienced similar errors about not finding things. It got resolved with:
LIBS="-lpthreadGC2 -lole32" SOFLAGS="-Wl,--export-all-symbols"
but also doesn't have a correct symbol.

[active1]

i have a problem with using ffms2 with vapoursynth under ubuntu linux
after i compiled the latest libav (with ./configure && make && sudo make install) i downloaded the latest source code for ffmpegsource and compiled it:

svn checkout http://ffmpegsource.googlecode.com/svn/trunk/ ffmpegsource-read-only
cd ffmpegsource-read-only
./configure --enable-shared=yes
make
sudo make install
then in python3:
>>> import vapoursynth as vs
>>> import sys
>>> core = vs.Core()
>>> core.std.LoadPlugin(path='/usr/local/lib/libffms2.so')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "vapoursynth.pyx", line 857, in vapoursynth.Function.__call__ (build/src/cython/vapoursynth.c:12374)
vapoursynth.Error: 'No entry point found in /usr/local/lib/libffms2.so'

(i can load libeedi3.so the same way without any problem)

[sneaker_ger]

Here's a TS file that ffms2 seems to have some serious problems with, even when remuxed to mkv. Video is interlaced H.264 from a Sony camera. If you are interested in a sample:
http://www.file-upload.net/download-6680403/sonyTS.7z.html (TS + MKV)
http://www.mjkk.de/maps/test.MTS ( TS only, direct download)

The mts starts screwed up (wrong colors, smearing etc.), the mkv jumps back and forth and does not work at the correct framerate.
The mkv can be made working by forcing fpsnum/fpsden(/threads=1), though. I know (interlaced) TS is a known issue, but maybe you are interested anyways or at least in the mkv.

[Guest]

Why is interlaced TS such a problem? Is the TS demuxer broken? Seems like a pretty simple thing to fix if so.

Works fine with DGSource() by the way, so the stream is fine.

[qyot27]

i have a problem with using ffms2 with vapoursynth under ubuntu linux
after i compiled the latest libav (with ./configure && make && sudo make install) i downloaded the latest source code for ffmpegsource and compiled it:

svn checkout http://ffmpegsource.googlecode.com/svn/trunk/ ffmpegsource-read-only
cd ffmpegsource-read-only
./configure --enable-shared=yes
make
sudo make install
The trunk hasn't had its build system regenerated yet. You have to use autogen.sh before (or instead of) configure to make it see the VapourSynth sources and use them.

./autogen.sh --enable-shared
or
./autogen.sh
./configure --enable-shared



With r730, FFMS2 has had its build system regenerated. Running autogen first is no longer necessary.

[active1]

The trunk hasn't had its build system regenerated yet. You have to use autogen.sh before (or instead of) configure to make it see the VapourSynth sources and use them.

./autogen.sh --enable-shared
or
./autogen.sh
./configure --enable-shared

ok, i will :thanks:

[sneaker_ger]

Why is interlaced TS such a problem? Is the TS demuxer broken? Seems like a pretty simple thing to fix if so.

The funny thing is that ffmpeg, LAV filters, vlc etc. seem to have no problem whatsoever. ffms2 is really messed up in this regard.

[tebasuna51]

Why is interlaced TS such a problem? Is the TS demuxer broken? Seems like a pretty simple thing to fix if so.

In this thread:

...The next time you see someone complain about interlaced h264 you can quote what I just posted here...

[Guest]

TheFluff attributes the issue to the lavf TS parser but sneaker_ger says that ffmpeg itself works fine. :confused:

[TheFluff]

TheFluff attributes the issue to the lavf TS parser but sneaker_ger says that ffmpeg itself works fine. :confused:

There are actually several different problems that contribute to the mess. lavf's TS parser is terrible, but it's not solely responsible for the problems. I don't know the details of what is currently broken though because I haven't worked on FFMS2 in a long time now. This (http://code.google.com/p/ffmpegsource/issues/detail?id=83) used to be a problem but I think plorkyeran might have fixed it, or at least tried to.

[poisondeathray]

The funny thing is that ffmpeg, LAV filters, vlc etc. seem to have no problem whatsoever. ffms2 is really messed up in this regard.


Are you sure about that?

On this sample, ffmpeg has problems (as usual with interlaced AVC transport streams) - duplicate frames, 2x fps

ffmbc has no problems , but the ffms2 build based on ffmbc has problems . Not sure why

[sneaker_ger]

Are you sure about that?

I'm not 100% sure, but I just re-converted to ffv1 and didn't see any problems. Still 25 fps, 507 frames. I went through all frames but wasn't able to spot any problems. Or do these problems only appear when seeking, not when progressively converting?

ffmpeg -i test.mts -vcodec ffv1 -acodec copy -sn ffv1.mkv
(ffmpeg (http://ffmpeg.zeranoe.com/builds/win64/static/ffmpeg-20121010-git-1a104bf-win64-static.7z))

[poisondeathray]

I'm not 100% sure, but I just re-converted to ffv1 and didn't see any problems. Still 25 fps, 507 frames. I went through all frames but wasn't able to spot any problems. Or do these problems only appear when seeking, not when progressively converting?

ffmpeg -i test.mts -vcodec ffv1 -acodec copy -sn ffv1.mkv
(ffmpeg (http://ffmpeg.zeranoe.com/builds/win64/static/ffmpeg-20121010-git-1a104bf-win64-static.7z))


Interesting, I did the same test but with huffyuv and an older binary from the same site (maybe a few months old) and it had the typical problems . If I have time I'll look into it farther, maybe they fixed it ?

[qyot27]

Well, it's probably not going to work for win64, but the VapourSynth side of the non-autotools/C plugin can actually be recognized now under win32.

New build:
ffms2-r725-2_avs+vsp (http://www.mediafire.com/?p7m8fkr8aarpacv)

Works as both C-plugin and VapourSynth plugin. 32-bit.

[kolak]

Just to inform-DNxHD 10bit decoding bug is fixed now in ffms2, but custom build based on ffmbc is still useful in some cases. It would be nice to have ffms2 based on ffmbc with vapoursynth support.

[Pat357]

Still 25 fps, 507 frames. I went through all frames but wasn't able to spot any problems.

ffmpeg -i test.mts -vcodec ffv1 -acodec copy -sn ffv1.mkv
(ffmpeg (http://ffmpeg.zeranoe.com/builds/win64/static/ffmpeg-20121010-git-1a104bf-win64-static.7z))

Strange, as this gives me a very shaky video (incl. audio drops). I can't find anything that plays the file correctly.
Neither Lav filters (softw + CUVID +DXVA) or anything else I've tried did decode the FFV1 video as it should.

This makes me wonder what software you've used to check the file ?

[sneaker_ger]

It's very high bitrate, so not suited for real time playback. Go through the frames one by one or use something sane just for the test:
ffmpeg -i test.mts -vcodec libx264 -preset medium -crf 18 -an -sn x264.mkv (progressive encoding, but should be sufficient for this test)
my output for reference (http://www.mediafire.com/?a421elp059mw19h)

Also make sure you don't have any deinterlacer trying to work with the wrong field order.

[mastrboy]

Out of curiosity, why are you using ffms2 to open up these AVI files?

When using avisynth mt i have experienced less crashes using ffvideosource(threads=1) rather than avisource, so using ffvideosource has just became a habit even if i use setmtmode or not...

Have you been able to reproduce the issue?

[kolak]

Well, it's probably not going to work for win64, but the VapourSynth side of the non-autotools/C plugin can actually be recognized now under win32.

New build:
ffms2-r725-2_avs+vsp (http://www.mediafire.com/?p7m8fkr8aarpacv)

Works as both C-plugin and VapourSynth plugin. 32-bit.

Any new builds?
ProRes decoding is more than 2x slower than DNxHD- any reason for this?

[qyot27]

Any new builds?
ProRes decoding is more than 2x slower than DNxHD- any reason for this?
There haven't been any new commits to FFMS2 (or x264, or really cool new decoders in libavcodec) to warrant it. The only thing a newer build would be doing is using a newer version of FFmpeg and a couple of the external decoders (read: libutvideo and libopus). So unless FFmpeg dramatically sped up within the last three weeks, it'd likely just stay the same performance-wise.

[kolak]

Can you make a build based on ffmbc?- some things are different there.