FFmpegSource

[Farfie]

I'm no ffms developer, but here are some basic questions that you might want to answer:

0. What version of ffms are you using? (Have you tried other versions?)
1. You wrote you open x264 8/10bit with open-gop content, is it RAW content or does is reside in a container? If your streams are not raw streams in what container are they?
2. Do you use other filters than ffms.dll in your script? If you do, try to throw these out first to make sure this really is a ffms problem.
3. Are you using 32bit or 64bit Avisynth? What version of Avisynth are you using? (No clue what you call the ' "new" Avisynth thread'.)
4. What is the memory consumption of the Virtual Dub while opening and scrolling through your clip on your system?
5. Can you can reproduce the problem with a small clip ? If you can, it might help if you could share that clip with others so they too can try to reproduce the problem.
6. Is your system is overclocked in any way? (If so reset it to the default system speed, to make sure the problem is not caused due to a problem with your system.)
....
other users or a developer might have additional questions, but these should help to get a better grip on the problem.

Cu Selur

0. r683 x86
1. Raw or in an MKV, the same problem is observed. I could try mp4, but I believe the same thing would happen.
2. This was the first thing I did actually :), but yes, only FFMS is used.
3. I was referring to this http://forum.doom9.org/showthread.php?t=166951&page=2, in which a new Avisynth was released on the 25th of January 2013. I'm not actually sure if it's 32 or 64 bit, but I think it's 32.
4. At first, it uses about 185K, but after it throws an error (typically that seeking is not frame accurate, or "insanity detected: decoder returned an empty frame", in which after that point the whole video is just gray, and the memory goes down to about 51k. It either does this or virtual dub hangs indefinitely until I kill the process.
5. Here we go: opengop testfile (http://www.mediafire.com/download.php?q9fx50it550axzh) SC2 anyone?:D Sorry for the size, but I can't get this working with the aforementioned software. You should be able to reproduce my problem with the newest Avisynth (http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/AVS%202.6.0%20Alpha%204%20%5B130114%5D/AviSynth_130114.exe/download). Of course, I've been there already (the avisynth thread), and they told me to come here because they think this is an ffms problem.
6. My system is overclocked, but it has been this way for a lot of time now. Only with the new avisynth does this exist. I'm fairly positive (given all this new software in this workchain at one time) that the problem is software related, but if someone truly wants me to go stock, I'll do it.

Hope this helps!

[Selur]

file, works fine with the ffms2.dll I use (https://docs.google.com/file/d/0B_WxUS1XGCPAY3NKNXFYX0VOV3c/edit?usp=sharing) (not sure which version it is).

Cu Selur

[Farfie]

file, works fine with the ffms2.dll I use (https://docs.google.com/file/d/0B_WxUS1XGCPAY3NKNXFYX0VOV3c/edit?usp=sharing) (not sure which version it is).

Cu Selur

Well, thanks for the help Selur, my problem has been solved. Those files are a newer version of the ones I was using, and I guess that's the last time I trust MeGUI to keep stuff updated (even using the development update server.)
I realize this isn't really the thread for this, but do you know of any custom servers I could throw in that do a particularly good job of keeping stuff updated?

[Selur]

Nope, sorry. + FFmpegSource filter test versions are always a challenge so I understand that the MeGui folks are probably waiting for the next stable release,..

[Zathor]

Nope, sorry. + FFmpegSource filter test versions are always a challenge so I understand that the MeGui folks are probably waiting for the next stable release,..
Correct. For every build after r683 users have reported various problems (also here in the thread or in the issues list) which is the reason that r683 is still being used.

[qyot27]

With r743+7 (+7 referring to https://github.com/tgoyne/ffms2), I'm getting segfaults when FFMS2 tries to load audio in a script being served to an FFmpeg build that uses the rewritten AviSynth demuxer (https://github.com/qyot27/FFmpeg/commits/avisynth-demuxer6). I reported it on AvxSynth's issues tracker (https://github.com/avxsynth/avxsynth/issues/90) first, and their analysis pointed back at FFMS2. I produced debug builds of both FFmpeg and FFMS2 and re-ran the test, which resulted in a segfault. The backtrace is as follows:
$ gdb -readnow ffmpeg.exe
Reading symbols from c:\dap\vid\Incoming Files\ffmpeg.exe...expanding to full symbols...done.
(gdb) r -i test.avs -vn -acodec ac3 -ab 192k test.ac3
Starting program: c:\dap\vid\Incoming Files\ffmpeg.exe -i test.avs -vn -acodec ac3 -ab 192k test.ac3
[New Thread 3616.0xe18]
ffmpeg version N-50567-g5686652 Copyright (c) 2000-2013 the FFmpeg developers
built on Mar 8 2013 10:53:44 with gcc 4.7.2 (GCC)
configuration: --prefix=/home/qyot27/win32_build --cross-prefix=i686-w64-mingw
32- --enable-gpl --enable-version3 --enable-debug --disable-stripping --enable-a
vresample --disable-w32threads --enable-libutvideo --enable-libxvid --enable-lib
twolame --enable-libmp3lame --enable-libvorbis --enable-libopus --enable-libvo-a
acenc --enable-libvpx --enable-libtheora --enable-avisynth --cpu=pentium3 --extr
a-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW32_STATIC_LIB'
--target-os=mingw32 --arch=x86
libavutil 52. 18.100 / 52. 18.100
libavcodec 54. 92.100 / 54. 92.100
libavformat 54. 63.104 / 54. 63.104
libavdevice 54. 3.103 / 54. 3.103
libavfilter 3. 42.103 / 3. 42.103
libswscale 2. 2.100 / 2. 2.100
libswresample 0. 17.102 / 0. 17.102
libpostproc 52. 2.100 / 52. 2.100
warning: FFMS2 avs plugin: Initializing...
warning: FFMS2 - avs 2.6 mode
Guessed Channel Layout for Input Stream #0.1 : stereo
Input #0, avisynth, from 'test.avs':
Duration: 00:00:15.28, start: 0.000000, bitrate: 0 kb/s
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 848x480, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc
Stream #0:1: Audio: pcm_f32le, 48000 Hz, stereo, flt, 3072 kb/s
Output #0, ac3, to 'test.ac3':
Metadata:
encoder : Lavf54.63.104
Stream #0:0: Audio: ac3, 48000 Hz, stereo, fltp, 192 kb/s
Stream mapping:
Stream #0:1 -> #0:0 (pcm_f32le -> ac3)
Press [q] to stop, [?] for help

Program received signal SIGSEGV, Segmentation fault.
std::__detail::_List_node_base::_M_hook (this=0x5d29fb8, __position=0x5f0f3b8)
at ../../../../../source/gcc-4.7.2/libstdc++-v3/src/c++98/list.cc:132
132 ../../../../../source/gcc-4.7.2/libstdc++-v3/src/c++98/list.cc: No such file or directory.
(gdb) bt
#0 std::__detail::_List_node_base::_M_hook (this=0x5d29fb8,
__position=0x5f0f3b8)
at ../../../../../source/gcc-4.7.2/libstdc++-v3/src/c++98/list.cc:132
#1 0x6f48adc7 in std::list<FFMS_AudioSource::AudioBlock, std::allocator<FFMS_AudioSource::AudioBlock> >::insert (this=0x66aa9d8, __position=..., __x=...)
at /usr/bin/../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/include/c++/4.7.2/bits/list.tcc:103
#2 0x6ed8eb6c in FFMS_AudioSource::ResampleAndCache (this=0x66aa9c8, pos=...)
at src/core/audiosource.cpp:253
#3 0x6ed8ed8b in FFMS_AudioSource::CacheBlock (this=0x66aa9c8, pos=...)
at src/core/audiosource.cpp:276
#4 0x6ed8f20a in FFMS_AudioSource::DecodeNextBlock (this=0x66aa9c8,
pos=0x22f0c4) at src/core/audiosource.cpp:322
#5 0x6ed8fd9e in FFMS_AudioSource::GetAudio (this=0x66aa9c8, Buf=0x67dc030,
Start=10240, Count=36803) at src/core/audiosource.cpp:412
#6 0x6ed90b20 in FFMS_GetAudio@28 (A=0x66aa9c8, Buf=0x67dc030, Start=2943,
Count=44100, ErrorInfo=0x22f1f8) at src/core/ffms.cpp:215
#7 0x6eda7b50 in get_audio (fi=0x5e33e90, buf=0x67dc030, start=2943,
count=44100) at src/avisynth_c/ff_audsource.c:52
#8 0x10011092 in ?? () from C:\WINDOWS\system32\avisynth.dll
(gdb)

Under normal running conditions, this just results in FFmpeg hanging until I kill the Command Prompt.

It only occurs under particular circumstances. SSRC is what seems to be triggering the problem, as using it with certain framerates sparks the issue. Forcing a different framerate in FFMS2 or via ChangeFPS allows it to work correctly again, as does commenting out SSRC, or using KillVideo.

A sampling of framerates that I tested with. yes = working (even with SSRC), no = hang/segfault

12000/1000 = yes
12000/1001 = yes

15000/1000 = yes
15000/1001 = no

23000/1000 = no #to illustrate an arbitrary fps
23000/1001 = no

24000/1000 = yes
24000/1001 = yes

25000/1000 = yes
25000/1001 = no

30000/1000 = yes
30000/1001 = no

48000/1000 = yes
48000/1001 = no

50000/1000 = yes
50000/1001 = no

60000/1000 = yes
60000/1001 = no

[Plorkyeran]

One of the reasons I haven't committed that patchset to SVN is that it basically only handles the things Aegisub cares about (and Aegisub only asks for audio in large aligned power-of-two blocks, partially to work around various bugs FFMS2 has had). Finishing it up will be one of my top priorities once I have time to work on open-source stuff again, but that won't be for at least another week or two.

[fvisagie]

I'm having trouble seeking in supposedly PAL DVD-compliant MPEG-2 clips encoded by ffmpeg. When I remux in Avidemux, seeking works fine.

Here's a short sample of an original encode (http://www.mediafire.com/file/psrepdvupvv4peg/MPEG-2.mpg). Scrolling forward from frame 0, the display stays frozen and only starts updating from frame 12 (3 frames before the next keyframe). Thereafter scrolling forward works fine.

Scrolling back from the end of the clip, the first problem is that the first frame shown is out of sequence. The next problem is that the display only moves for the 3-4 frames immediately preceding each keyframe in time and otherwise stays frozen.

With the remuxed clip (http://www.mediafire.com/file/5zzs8mo7tpyw54h/MPEG-2_remuxed.mpg), everything works perfectly.

I load the clips with this Avisynth script:

source = "MPEG-2.mpg"
FFIndex(source=source, cachefile=source+".ffindex", indexmask=-1, dumpmask=0, errorhandling=3, overwrite=false)
Audio = FFAudioSource(source=source, track=-1, cache=true, cachefile=source+".ffindex", adjustdelay=-1)
Video = FFVideoSource(source=source, track=-1, cache=true, cachefile=source+".ffindex", seekmode=1, rffmode=0, width=-1, height=-1)
AudioDub(Video, Audio)
Info()


This behaviour is the same for every client app I use - AvsPmod, VirtualDub etc.

Versions:
Avisynth 2.58
FFMS2 r722 (version 2.18 according to the changelog)
Windows 7 Professional 32-bit SP1

Is there something I'm doing wrong? Or any way I can work around this within FFMS2, perhaps an earlier version that doesn't have this problem? Or perhaps an encode setting I can change, bearing in mind it must stay within the PAL spec?

Thanks,
Francois

[fvisagie]

Thanks.

Try using demuxer="lavf" in FFIndex

This makes no difference that I can notice.

and seekmode=-1 in FFVideoSource, though you can't do non-linear access this way.

Also this disables any kind of backward navigation :(. EDIT: for completeness I should mention that I've tried all seekmode options, and all have a problem of sorts.

And, why not use DGDecode for MPEG2 streams?

I'd love an alternative that doesn't require external preparation or work-around. Otherwise I might as well have used the remuxing work-around above.

Can you confirm that you get the same behaviour with these 2 clips?

[Selur]

LWLibavVideoSource first Time I hear of it :) btw. where to get a up-to-date version of LSMASHSource.dll ? (https://code.google.com/p/l-smash/ and https://github.com/VFR-maniac/L-SMASH-Works/tree/master/AviSynth have no downloads; aside from source code)

[fvisagie]

Yes.

Thanks for the confirmation.

One other alternative is LWLibavVideoSource(in LSMASHSource.dll of L-SMASH-Works).

Thanks, I'll try that,

LWLibavVideoSource first Time I hear of it :) btw. where to get a up-to-date version of LSMASHSource.dll ? (https://code.google.com/p/l-smash/ and https://github.com/VFR-maniac/L-SMASH-Works/tree/master/AviSynth have no downloads; aside from source code)

as soon as we get hold of it ;).

I should also mention that even with the demuxing work-around, only seekmode=0 works completely correctly.

According to MediaInfo there are some bitrate-related differences between the original and remuxed files, which I don't have much control over as this was a straight-forward remux. However, the original also has Video delay : -5ms which the remuxed does not have. Getting this to 0 in the encode caused ffmpeg to throw many warnings but didn't help FFmpegSource. I also tried all adjustdelay options without any luck.

The above were all tried with both demuxer="default" and demuxer="lavf".

So I'm looking foward to trying LWLibavVideoSource. :)

[forclip]

One other alternative is LWLibavVideoSource(in LSMASHSource.dll of L-SMASH-Works).Thanks for the info! Nice to know that we have another one source filter for AviSynth :)

P.S. I've found where to download it, but not sure that it is allowed to post link here, so everyone who interested - just ask Google for "LSMASHSource.dll" + "blog-page_17".

[Selur]

Thanks!
I created a new thread for LSMASHSource (https://forum.doom9.org/showthread.php?t=167435), so all LSMASHSource related stuff can be posted there. :)

[Plorkyeran]

With r743+7 (+7 referring to https://github.com/tgoyne/ffms2), I'm getting segfaults when FFMS2 tries to load audio in a script being served to an FFmpeg build that uses the rewritten AviSynth demuxer (https://github.com/qyot27/FFmpeg/commits/avisynth-demuxer6). I reported it on AvxSynth's issues tracker (https://github.com/avxsynth/avxsynth/issues/90) first, and their analysis pointed back at FFMS2. I produced debug builds of both FFmpeg and FFMS2 and re-ran the test, which resulted in a segfault.
Can you upload a complete set of files which reproduces this, including debug symbols? I haven't been able to trigger it, both with and without libavresample support enabled.

[qyot27]

Can you upload a complete set of files which reproduces this, including debug symbols? I haven't been able to trigger it, both with and without libavresample support enabled.
avxtest.7z
http://www.mediafire.com/?rcizx4ur7659djk

Contains a slightly newer build of FFmpeg that still exhibits the issue, the build of FFMS2, video file, and script. Both FFmpeg and FFMS2 have debug symbols. The script shows a sampling of fpsnum and fpsden values which spark the issue when used with SSRC, using the same framerates I mentioned in the previous post. It also shows working framerate/SSRC combinations that are still close to the non-working ones (as in, the difference between a denominator of 1000 vs. 1001).

My initial reason for thinking it was in the demuxer was because disabling the code that does fps/samples calculations in avisynth_read_packet_audio (here (https://github.com/qyot27/FFmpeg/commit/22c97a83d11ef684affdd4588e4dcb86b2e392e6#L1R497)) allows those non-working framerates to work with SSRC (also, the fact that wavi, the old VFW-based AviSynth demuxer, and Windows Media Player 6.4 don't have problems with it in those fps/SSRC combos). But I was told that that is part of the code that keeps video and audio in sync when used together and that it seemed to stem from FFMS2 (and the backtrace I generated did show...something that had FFMS2's audio functions in it).

My testing environment:
Windows XP SP3, 512MBs PC133 SDRAM, 1GHz Celeron Coppermine

[Selur]

I got the following script on this (http://vimeo.com/9810793) clip:
SetMemoryMax(768)
LoadPlugin("G:\Hybrid\avisynthPlugins\ffms2.dll")
Source = FFVideoSource("H:\TESTCL~1\CANONE~1.MOV",cachefile="H:\Temp\165714630mov_deb1536f480475f7d593219aa1afd74c_41.ffindex",fpsnum=29970,fpsden=1000)
SourceFiltered = Source
Source = Source.Crop(0,0,960,1088)
SourceFiltered = SourceFiltered.Crop(960,0,960,1088)
StackHorizontal(Source, SourceFiltered)
return last
when trying to open it with Virtual Dub I get:
Avisynth open failure:
Crop: you cannot use crop to enlarge or 'shift' a clip
(H:\Temp\tempPreviewAvisynthFile08_24_20_176.avs, line 5)

which first confused me until I looked at the MediaInfo output for this file, which contained:
Width : 1 920 pixels
Height : 1 080 pixels
Original height : 1 088 pixels
So from the looks of it, FFVideoSource doesn't return 1920x1088 as I assumed, but 1920x1080.
(so using ',1080)' instead of ',1088)' fixes the imminent problem, but I would prefer it if FFmpegSource would return 1088 lines,..)
-> is this behavior intended?

[LigH]

Probably yes. There are encoders which encode a height of 1088 lines (MOD 16) and store a cropping area of 1080 lines in the header. I remember that DGDecNV and DGAVCDec report something similar for FullHD AVC videos in their info windows while playing [F6].

[Selur]

but DGDecNV&Co only crops to 1080 if 'Options->Always crop 1088->1080' is enabled, since FFmpegSource doesn't have such an option, wouldn't it be more resonable to display the whole 1920x1088 pixels?

[Plorkyeran]

There are encoders which encode a height of 1088 lines (MOD 16) and store a cropping area of 1080 lines in the header.
All encoders do this; it's the only way to encode a non-mod16 resolution. The 8 extra lines are garbage data, and and there shouldn't be any reason to want to see them.

[qyot27]

FFMS2 C-plugin r753 (http://www.mediafire.com/?7le9legt1r2k8lz)

AviSynth/VapourSynth dual plugin
Optimized for Pentium III/SSE fpmath


Regarding the issue from before, I'm starting to think it's very dependent on hardware constraints. The same build of r753 exhibits the issue on my computer (running a [2001] Celeron Coppermine w/ 512MBs of RAM), but does not exhibit it on a [2006] Athlon64 Orleans w/ 2GB of RAM. My first impulse, as stated before, is that it may be some sort of memory size issue that mine gets tripped up on only because of how little I have (similar to the long-standing issue with matroskaparser.c when using any active level of optimization in GCC), the other one is that it may lie somewhere in the floating point math (or how the float stuff actually gets compiled) that the Athlon64 can compensate for but mine can't.

[Abs62]

r753 can't decode flac audio. No errors indicated, but output is empty data.

Upd.
It looks like the BytesPerSample variable don't set if codec return data not in planar format.

[zettai]

r753 and v2.17 have made a change whereby mpeg2 elementary streams are always interpreted as 25fps.

v2.16 works fine.

[qyot27]

No new build of FFMS2, but it does indeed seem that the weird framerate/SSRC issue in ffmpeg truly was in the demuxer as I first thought, because it doesn't do it now. There was recently a fix for the fact that the demuxer was off by one frame (causing the first frame to be truncated and the last frame to be duplicated; another issue was that it was inserting a null frame/sample into the video/audio before real decoding started, but that doesn't seem to be what caused the issue - it was also fixed) and this may have been what underlaid the problem, unless it was just a general libavformat problem that got fixed by some other commit.

[Soliloquy]

Is it possible to read x264's 444 lossless (not 100% on the terms there, hah) with ffms2 or should i be using something else?
Tried using the previously mentioned r753 build in vapoursynth and I get a very green output.

[TheRyuu]

ffms2-2.18-rc1.7z (https://ffmpegsource.googlecode.com/files/ffms2-2.18-rc1.7z)

Includes both 32 and 64-bit compiles.
Requires SSE2 capable CPU and XP SP3 or newer.

Changelog for 2.18:
Fix regression (r483) with rffmode that caused it to error out even if using the default output colorspace. (TheRyuu)
High(er) quality YUV->RGB conversion. (TheRyuu)
Fix indexing on files with cover art. (TheRyuu)
Add support for libav/ffmpeg built with msvc, this is the default on windows when building with msvc. (TheRyuu)
Remove postproc support. (TheRyuu)
Added VapourSynth support. (Myrsloik)
ffmsindex can now output keyframe numbers to a file while indexing. (Plorkyeran)
configure now defaults to building a shared library, except when building MinGW/Cygwin, since you usually want static for those. (Plorkyeran)
The source color space and color range used when converting with swscale can now be overridden. (Plorkyeran)
Fix issues with unicode filenames when building with mingw. (Plorkyeran)
Fix progress reporting when indexing files with non-zero initial timestamp with haali's splitter. (Plorkyeran)
Add support for formats with packet durations but no packet timestamps. (Plorkyeran)
Fix corruption when seeking in VC-1 in MKV. (Plorkyeran)
Fix bug that resulted in files opened with Haali's splitter sometimes always decoding from the beginning on every seek. (Plorkyeran)
Add support for VP8. (Plorkyeran)
Fix crash when indexing video formats with no parser. (Plorkyeran)
Fix compilation errors with recent versions of libav/ffmpeg. (Plorkyeran)
Fix NVOP handling with frame-based threading (aka zero-size frames with mp4 bug). (Plorkyeran)
Add support for vc1image. (Plorkyeran)
Use the container SAR when the codec SAR is unset when opening via lavf. (Plorkyeran)
Actually set the ColorRange and ColorSpace of frames when nothing has been overridden. (Plorkyeran)
Add support for files without timestamps to lavf audio. (Plorkyeran)
Fix handling of audio delay with invalid inital timestamps. (Plorkyeran)
Sort of partially fix interlaced H.264. (Plorkyeran)
Fix errors when the client asks for audio past the end of the file. (Plorkyeran)
Fix rounding error with MKV timestamps that resulted in things getting a FPS like 60001/1001. (TheRyuu)
Bump required version to libav 0.8/FFmpeg 0.9. (Plorkyeran)
Switch to avcodec_decode_audio4. (Plorkyeran)
Add support for planar audio from lavc. (Plorkyeran)
Add SetOutputFormatA for audio resampling/mixing using libavresample. (Plorkyeran)
There may be a few additional things not listed because the changelog wasn't updated yet.

[Abs62]

ffms2-2.18-rc1 don't decode flac audio like r753 (see my post above).
And it hangs after jump back from current frame. It seems the cache iterator "cachePos" in FFMS_AudioSource::GetAudio() becomes invalid after Cache.erase() in FFMS_AudioSource::CacheBlock().

[filler56789]

FFMS2 doesn't support MKVs with RealVideo wrapped in VFW-mode :confused:

Avisynth open failure:
FFVideoSource: video codec not found

Sample file: http://www.mediafire.com/?aab0uxsf55ef9ru

[mastrboy]

Is indexing of larger lossless avi huffyuv been fixed in 2.18-rc1?

Ref former posts:
http://forum.doom9.org/showthread.php?p=1594019#post1594019
http://forum.doom9.org/showthread.php?p=1594170#post1594170
http://forum.doom9.org/showthread.php?p=1595022#post1595022
http://forum.doom9.org/showthread.php?p=1595010#post1595010

[TheRyuu]

Is indexing of larger lossless avi huffyuv been fixed in 2.18-rc1?

Ref former posts:
http://forum.doom9.org/showthread.php?p=1594019#post1594019
http://forum.doom9.org/showthread.php?p=1594170#post1594170
http://forum.doom9.org/showthread.php?p=1595022#post1595022
http://forum.doom9.org/showthread.php?p=1595010#post1595010

Try it.

[mastrboy]

Seems fixed :)
Same amount of frames as the revision before indexing broke on my files when using ffvideosource.
Also backwards seeking seems to have gotten quite a speedup? (at least in avspmod)

[phate89]

Sort of partially fix interlaced H.264. (Plorkyeran)
Hi. Thanks for the work.
One question about the interlaced fix. Can now ffms2 be trusted to be used with interlaced h264? And if it's not are we still far from a reliable implementation?

[henryho_hk]

ffms2-2.18-rc1 don't decode flac audio like r753 (see my post above).

That's really disappointing. :(

Does ffms2 support other lossless audio compression format?

[fvisagie]

I'd also like to understand better about the sort of partially fix. :) Thanks in advance.

[Plorkyeran]

If the entire file alternates between frames with valid and invalid file positions, it skips outputting the frames with invalid positions. This happens to make all of the interlaced h264 files I had lying around appear to decode correctly when linearly decoding with no seeks, but is a pretty awful solution that'll probably break in a bunch of cases. I didn't really test it much.

[Reino]

Requires SSE2 capable CPUWhy? People without a SSE2 cpu are just out of luck now?

[sl1pkn07]

any uses p3 or amd-k7 for encode videos?

[LigH]

Development keeps progressing... ;)

I doubt there are many multi-core CPUs without SSE2 support.

[sl1pkn07]

about SSE2: http://en.wikipedia.org/wiki/SSE2#CPUs_supporting_SSE2

[Wilbert]

any uses p3 or amd-k7 for encode videos?
Yes me, i still use an old athlon ;)

[qyot27]

Since it's been a couple months since the r753 build,

FFMS2 C-plugin r755

Optimized for Pentium III and SSE. The FLAC issue and backwards seeking stuff is the same situation as r753 since neither commit has anything to do with them (r754 was for the autotools buildsystem that the C-plugin doesn't use, r755 fixed building with older point versions of FFmpeg, which is irrelevant to my builds because I always use FFmpeg-git). It does use a two months newer build of FFmpeg, though.

ffmpeg version r53371 git-ac2c521

Configuration:
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--enable-libopus
--disable-decoder=utvideo --enable-libutvideo
--disable-decoder=vp8 --enable-libvpx
--disable-encoders
--enable-avisynth
--disable-muxers
--disable-debug
--disable-network
--disable-hwaccels
--disable-indevs
--disable-outdevs
--cpu=pentium3
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW32_STATIC_LIB'
--target-os=mingw32
--arch=x86

(--enable-avisynth only got used for the novelty of accessing scripts through lavf with x264, not because of anything related to FFMS2)

[Keiyakusha]

I decided to try new ffms2 on bluray m2ts/h264 file. (normally I don't use it for bluray at all)
Uh, am I doing something wrong? Or this is some long-standing bugs still not fixed?
ffms-2.17 (https://dl.dropboxusercontent.com/u/110558786/Comparison/ffms-2.17_004170.jpg)
ffms2-2.18-rc1 (https://dl.dropboxusercontent.com/u/110558786/Comparison/ffms2-2.18-rc1_004170.jpg)

In other words with ffms2-2.18-rc1 (from googlecode) 1st frame after loading is green, after seeking first frame (and few frames after that) is whatever green, with artefacts or in-between.
Without seeking seem to be working, but framerate is wrong.

Edit:
qyot27, link seem to be broken...

[qyot27]

The link should be fixed now. I didn't pay enough attention to how the URL they provide changed to realize the ? was no longer there.

[Plorkyeran]

I decided to try new ffms2 on bluray m2ts/h264 file. (normally I don't use it for bluray at all)
Uh, am I doing something wrong? Or this is some long-standing bugs still not fixed?
ffms-2.17 (https://dl.dropboxusercontent.com/u/110558786/Comparison/ffms-2.17_004170.jpg)
ffms2-2.18-rc1 (https://dl.dropboxusercontent.com/u/110558786/Comparison/ffms2-2.18-rc1_004170.jpg)

In other words with ffms2-2.18-rc1 (from googlecode) 1st frame after loading is green, after seeking first frame (and few frames after that) is whatever green, with artefacts or in-between.
Without seeking seem to be working, but framerate is wrong.

Open GOP and PIR are still not supported. AFAICT the only way to fix them are to either write a custom h264 frame parser or add stuff to the lavc API.

[leoenc]

With 2.18 RC1 and also the above r755, I'm getting access violation errors from VirtualDub when trying to play simple scripts with FFaudioSource.

"Avisynth: access violation at 0x000067B5 in C:\Program Files (x86)\AviSynth 2.5\plugins\ffms2.dll, attempting to read from 0x038C000B"

I have so far tried MKV with DTS, an MKV with AC3, an MXF with PCM.
When it's just FFvideoSource, it works.

Version 2.17 works fine.

[pancserzso]

Hi,

I'd like to ask one question: which one is higher quality:

FFVideoSource( "mts.mts", seekmode = -1, colorspace = "RGB24", resizer = "LANCZOS" )

or

FFVideoSource( "mts.mts", seekmode = -1 )
ConvertToRGB24( matrix = "Rec709", chromaresample = "lanczos" )

[Reino]

Instead of copying the mts-files from the camera's sd-card to your harddrive and using that file for all the editing, I recommend wrapping the mts-file's streams in a Matroska container.
Pretty good chance the default seekmode=1 would be sufficient then, but above all the streams are aligned. Two weeks ago I made some recordings (multiple mts-files) at the wedding of a friend. But afterwards when I tried to splice these recordings, no matter what I tried, I always ended up with the audio out of sync. None of these problems with the footage muxed to mkv.

[raffriff42]

I think I have stumbled in a possible issue in FFMS2.avsi (including the latest version, 2.18-rc1)
FFVideoSource and FFAudioSource are called out of optimum order as per the User Manual (http://ffmpegsource.googlecode.com/svn/trunk/doc/ffms2-avisynth.html)

EDIT - No, they are not out of order, as FFIndex is explicitly called first. Please disregard. :o

[Tima]

Someone, please, share FFMS v2.19 binaries (mostly interested in VapourSynth plugin).

[Overdrive80]

Someone, please, share FFMS v2.19 binaries (mostly interested in VapourSynth plugin).

https://github.com/FFMS/ffms2/releases

[mastrboy]

https://github.com/FFMS/ffms2/releases

Latest binary on that page is still just ffms2-2.18-rc1.7z, though you can get the source code for 2.18 and 2.19, but no binary...