View Full Version : FFmpegSource
Groucho2004
25th October 2015, 19:09
It's clearly a false positive but check out the analysis from Virustotal (https://www.virustotal.com/en/file/af42e338285477302b93243331873fd21185126883fdbd2b2472c663c1f6e486/analysis/). The AV engines seem to get more stupid with each release.
Is there a solution?
Yes, don't use a AV program or use one that does not constantly try to keep you from using your computer.
szabi
26th October 2015, 12:34
Previous version does not have this issue.
Only new one.
Groucho2004
26th October 2015, 12:53
Previous version does not have this issue.
Only new one.
Are you going to post this until you get an answer that suits you? Which part of 'false positive' don't you understand?
StainlessS
26th October 2015, 23:09
szabi,
Some time ago I got a false + on a Visual Basic program that had a lot of small buttons on the form in multiple row/column,
only difference between data describing buttons was in the x,y coords. Some Antivirus programs saw this repeated
pattern with only slight differences, as a sort of malware mutation device and issued malware warnings.
All I had to do was rearrange the buttons in a different sequential order but same locations on form. (EDIT: To avoid false +ve).
Anti-Malware heuristics are not that good and do provide a lot of false +ve's.
If most AV software says its OK then trust that.
EDIT: Also, you can point this out as a potential false +ve to Avast (they will look into it and hopefully drop the false +ve,
the problem seems not to be with FFMpegSource but with Avast).
EDIT:
Threat:Win32:Malware-gen
I'm taking 'Malware-Gen' (generator) to be exactly as described above, it sees some kind of (almost identical) repeated sequence and thinks it is
some kind of malware mutation device. (BUT IT IS ONLY GUESSING, that's what heuristics are, guesses based on past experience
of real malware, but guesses nonetheless).
LigH
27th October 2015, 08:07
Well, it's not that simple. Yesterday I got emails looking like phishing or spyware injectors. The analysis by VirusTotal returned only 9/55, partially "generic", partially named.
I looked into the binary EXE, which was surprisingly not even packed or encrypted (I already have an eye for entropy), just a plain C build. Very suspicious, it seems to access an MS Jet database, and even contained an SQL statement looking for pageranks. Searching for this pattern in the web, I came to another malware "genome" analysis site: Invincea Cynomix. Didn't detect many suspicious features either. So this seems to be the case of a "false negative".
But we are drifting away. Might be best to cut off some of the last malware related posts?
MysteryX
17th November 2015, 21:32
What's the right way of using FFmpegSource2 with MT? Which MT mode has to be used?
SetMTMode(3,8)
And if I'm using MT mode, and when caching is disabled, does it repeat the indexing for each thread, increasing time?
LigH
17th November 2015, 21:57
If you call the FF*Source functions in a range where MT mode 3 or 5 is active, then they will be called only once. You can switch to MT mode 2 (omit the thread count here!) afterwards for thread-safe, cooperative filters. It is recommendable to use the function Preroll (http://avisynth.nl/index.php/Preroll)(video_frames, audio_seconds), available since MT 2.60 alpha 4.
Do not exaggerate the number of threads, especially when calling a function which may fork threads internally (e.g. QTGMC does so, more than 4 MT threads won't be recommendable, also due to RAM consumption).
MysteryX
17th November 2015, 22:06
How should I use Preroll? I'm searching online and cannot find *any* documentation or information at all about its 2 parameters.
I'm writing a simple script to auto-pitch the audio to 432hz in real-time. Do you see anything that needs tweaking?
PluginPath=""
LoadPlugin(PluginPath+"ffms2.dll")
LoadPlugin(PluginPath+"TimeStretch.dll")
SetMTMode(3,4)
FFmpegSource2(source="Like a Cat.mp4", atrack=-1, cache=false, threads=1)
SetMTMode(2)
SemiTone = -0.3176665363342977
TimeStretchPlugin(pitch = 100.0 * pow(2.0, SemiTone / 12.0))
I'm still having occasional audio/video sync problems.
TheFluff
18th November 2015, 01:57
don't try to mt ffms2, it does multithreaded decoding internally already
actually, don't use avs-mt at all, it's a bad idea and you're gonna have a bad time
MysteryX
18th November 2015, 02:27
don't try to mt ffms2, it does multithreaded decoding internally already
actually, don't use avs-mt at all, it's a bad idea and you're gonna have a bad time
Probably a good advice. I was having the problem of doubling the rate of instabilities and crashes by feeding an AviSynth script into MPC-HC, which then feeds the video into ffdshow and into SVP which creates another AviSynth instance to return it back to the player.
Two AviSynth instances within each other. If I disable MT for one, it should make it more stable. I'll test this tonight.
Plus it clearly is very optional in this scenario; although I was seeing a few lags and that's the reason why I had added it in the first place.
MysteryX
18th November 2015, 03:35
If I don't enable MT, the audio and video fall out of sync. If I do enable it, then it's in sync "most of the time".
Keep in my the CPU and GPU are loaded with SVP+madVR.
LigH
18th November 2015, 09:08
In your case, not using even one video filter, there is indeed no reason to use MT. It looks like you could even execute this brief sequence inside the AviSynth post-processing filter of ffdshow if you used this as DirectShow decoder filter to play your video in a media player, then you would not use FFMS2 but the internal ffdshow_source. Or it may even have an own TimeStretch PP filter, I'm not sure right now. At least both would be much more useful than reading an AviSynth script as source with MPC-HC.
MysteryX
18th November 2015, 14:55
SVP is doing exactly that: plugging into the ffdshow chain. I tried inserting the code into the AviSynth script it is already processing. However, it doesn't seem to have the ability to process the audio, which is processed some other way. Or is there a way to force the audio to be processed at the same time through ffdshow?
MysteryX
24th November 2015, 07:44
The script I'm using is working "most of the time", but I'm seeing some really weird behaviors when playing in MPC-HC. Occasionally, the playback will reset to the beginning. Occasionally, it will skip to the next video in the middle of playback. I never had any kind of such issue before using this auto-tuning script, and it's a very strange issue that is totally random and hard to reproduce. Can this be caused by FFmpegSource2, and is there a way to avoid that? Trying to figure out why it's happening and where it could be coming from.
I'm also controlling MPC-HC via API from a software I wrote, so the code in my software also could be responsible for some of it. It's just really weird. One thing I can think of that could cause problem in my software is if MPC-HC sees and reports the wrong video length, which could explain why it would skip to the next video in the middle of playback, but that wouldn't explain the times where it resets to the beginning of the same video in the middle of playback.
StainlessS
24th November 2015, 07:56
Not sure, but I think that I've experienced MPC-HC jumping back to beginning when hitting some kind of error
(when it should display an Avisynth error message).
EDIT: Think it happened mostly when error is on opening script, and just keeps trying and retrying again and again, etc.
MysteryX
25th November 2015, 03:33
Not sure, but I think that I've experienced MPC-HC jumping back to beginning when hitting some kind of error
(when it should display an Avisynth error message).
EDIT: Think it happened mostly when error is on opening script, and just keeps trying and retrying again and again, etc.
This would make sense. And when it skips to the next video, it's because it restarted the video and my software detected it had looped back to the beginning, assuming it ended, so it's switching to the next.
sl1pkn07
19th January 2016, 03:30
chromium (49.0.2618.8) detect https://github.com/FFMS/ffms2/releases/download/2.22/ffms2-2.22-msvc.7z as malicious and can't save it
Myrsloik
19th January 2016, 03:31
chromium (49.0.2618.8) detect https://github.com/FFMS/ffms2/releases/download/2.22/ffms2-2.22-msvc.7z as malicious and can't save it
That's a chromium bug
LigH
19th January 2016, 11:09
It will probably have looked up this URL at a service which contains a false positive. The fact that there are false positives about this file is known for months already, but unfortunately not for all of such "protection services".
burfadel
22nd February 2016, 00:28
Any new builds?
szabi
22nd February 2016, 07:09
szabi,
Some time ago I got a false + on a Visual Basic program that had a lot of small buttons on the form in multiple row/column,
only difference between data describing buttons was in the x,y coords. Some Antivirus programs saw this repeated
pattern with only slight differences, as a sort of malware mutation device and issued malware warnings.
All I had to do was rearrange the buttons in a different sequential order but same locations on form. (EDIT: To avoid false +ve).
Anti-Malware heuristics are not that good and do provide a lot of false +ve's.
If most AV software says its OK then trust that.
EDIT: Also, you can point this out as a potential false +ve to Avast (they will look into it and hopefully drop the false +ve,
the problem seems not to be with FFMpegSource but with Avast).
EDIT:
I'm taking 'Malware-Gen' (generator) to be exactly as described above, it sees some kind of (almost identical) repeated sequence and thinks it is
some kind of malware mutation device. (BUT IT IS ONLY GUESSING, that's what heuristics are, guesses based on past experience
of real malware, but guesses nonetheless).
Hi
Many thanks for the explaination.
bye
szabi
qyot27
25th February 2016, 19:18
FFMS2 C-plugin r1103+98
Optimized for Pentium III and SSE.
ffmpeg version r77598 git-dbfb2c1 Copyright (c) 2000-2015 the FFmpeg developers
built with gcc 5.3.0 (GCC)
libavutil 55. 11.100 / 55. 11.100
libavcodec 57. 21.100 / 57. 21.100
libavformat 57. 21.100 / 57. 21.100
libavfilter 6. 22.100 / 6. 22.100
libavresample 3. 0. 0 / 3. 0. 0
libswscale 4. 0.100 / 4. 0.100
libswresample 2. 0.101 / 2. 0.101
libpostproc 54. 0.100 / 54. 0.100
configuration:
--prefix=/home/qyot27/win32_build
--cross-prefix=i686-w64-mingw32-
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--disable-encoders
--disable-decoder=dca
--enable-libdcadec
--disable-muxers
--disable-doc
--disable-debug
--disable-devices
--disable-avdevice
--enable-avisynth
--cpu=pentium3
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3'
--target-os=mingw32
--arch=x86
EDIT: Replaced the build with one from January that should work fine.
EDIT 2016-03-28: Newer build available here. (http://forum.doom9.org/showthread.php?p=1762372#post1762372)
manolito
25th February 2016, 21:58
Thanks for the new build...
Unfortunately this latest build does not like my Non-SSE2 Coppermine CPU any longer (access violation). :scared:
The previous build r1072c90 from last August still worked fine. Too bad...
Cheers
manolito
feisty2
25th February 2016, 22:15
Sadly nobody cares about copper mine CPUs
LigH
25th February 2016, 22:16
Strange if it is only optimized for P3 architecture. Can single libraries have higher requirements?
Regarding SSE2 ... I am already glad that AVX is not a required minimum already, thinking of the x265 development. ;)
qyot27
26th February 2016, 04:59
Thanks for the new build...
Unfortunately this latest build does not like my Non-SSE2 Coppermine CPU any longer (access violation). :scared:
The previous build r1072c90 from last August still worked fine. Too bad...
The difference in instruction sets wouldn't cause an access violation and allow AviSynth to error out cleanly. If there was a problem with the instruction set, it would crash immediately and you wouldn't get any actual error message (and running it in say, gdb, would show the problem as SIGILL). Or rather, the error would get thrown by Windows itself; AviSynth wouldn't know what hit it.
And more importantly, it also throws the access violation on Silvermont, so it's definitely not related to SSE2 and probably happens everywhere. Whatever it is happened on the FFMS2 side (which could also mean the C-plugin parts, after all) between January 2nd and yesterday, since the FFmpeg build it's linked against runs fine.
Absolute worst case is that GCC 5.3 is the cause of this, and nothing short of waiting for the next update (or rolling back to 5.2 or even 5.1) would fix it.
Sadly nobody cares about copper mine CPUs
My main hub computer uses a 1GHz Coppermine-128 Celeron. It's also the reason my builds have always targeted P3/SSE, although the need for that has all but been rendered moot since I got the Quantum Byte last October (I can't edit on the Byte due to disk space limitations, so pre-processing is still one reason for me to target it).
Strange if it is only optimized for P3 architecture. Can single libraries have higher requirements?
In the sense of one of the libs FFmpeg links to requiring a higher CPU or OS than FFmpeg itself is technically built to require? Sure, although that's not the case here.
The above description is actually what will happen if you build x264 on its defaults and FFmpeg on its defaults links against it, or if you happen to build FFmpeg with a MinGW toolchain that has the Secure API enabled. Neither of those FFmpeg builds would run on a P3 or XP setup, respectively, even though nothing about FFmpeg was explicitly set to require SSE2 or Vista+ - it simply inherits the limitations of the things it's linked against. The only way around that is through dynamic loading of the offending library, in which case you only hit this if you try to use that particular library. Regular static or dynamic linking will make the inheritance active in the host program pervasively, and any attempt at running it will hit the problem, regardless of whether the lib causing it was trying to be used or not.
In the case of the FFmpeg build I use for FFMS2, the only external libs it uses are zlib, bz2, lzma, and maybe iconv, aside from all the MinGW-related ones for network access and whatnot. None of them have been built to require SSE2 or Vista at a minimum.
qyot27
26th February 2016, 06:03
Yeah, there's something very weird happening here. Sometimes attempting to run the script a second or third time will finally succeed without an Access Violation, sometimes it might work on the first but fail on the second, and multiple runs may throw back different offending lines in FFMS2.avsi each time, and even bypassing FFMS2 and using FFVideo/AudioSource directly might work at first but then fail on the second.
I've updated the build announcement post with an older build (from January 2nd) that works. The differences are FFmpeg is about 1000 commits older, and FFMS2 is 6 commits older on the master branch.
I'll try to experiment more and try to figure out what's going on here. No ETA, though.
manolito
26th February 2016, 18:53
I've updated the build announcement post with an older build (from January 2nd) that works. The differences are FFmpeg is about 1000 commits older, and FFMS2 is 6 commits older on the master branch.
Yes, this one works! Thanks very much... :thanks:
Taurus
26th February 2016, 20:42
@qyot27: :thanks:
Some new fuel for an old XP Rig :D
Thanks
burfadel
26th February 2016, 21:36
FFMS2 C-plugin r1103+98 (http://www.mediafire.com/?nphy91iauld12ua)
Optimized for Pentium III and SSE.
EDIT: Replaced the build with one from January that should work fine.
I never tried the newer one, but this version doesn't work for me, it says %1 is an invalid win32 application when using with Staxrip. I then realised this is probably a 32 bit build only, and Staxrip is now 64-bit :).
Any chance of 64-bit builds? I'm guessing you would have to optimise for something a bit never than Pentium 3 :).
StainlessS
26th February 2016, 21:50
Perhaps qyot27 has more than enough on his plate, maybe Staxrip guy can make 64 bit compilation (not many others would be interested and qyot27's time might be better spent).
qyot27
26th February 2016, 22:13
The real problem is that I have no 64-bit Windows to accurately test against, and the times I've tried to test with 64-bit Wine (or building a 64-bit MinGW/GCC cross toolchain to even start working with) didn't fare so well. The 64-bit builds of AviSynth+ were different, since that still used MSVC.
Admittedly, that's been quite a while, and I should probably try again.
stranno
28th February 2016, 16:27
How can i load ProRes video (10bit) into FFMS2 64-bit + Avisynth+ 64-bit? Only 32-bit worked so far.
burfadel
29th February 2016, 05:13
How can i load ProRes video (10bit) into FFMS2 64-bit + Avisynth+ 64-bit? Only 32-bit worked so far.
You need to use a 64-bit build of ffms2. I have found that LSMASH-Works doesn't seem to work with a lot of 10-bit x264 sources whereas FFMS2 works beautifully. Not sure the cause of this. It seems 10-bit x264 has always caused a bit of a quandary on the decoder side of things with support. This is only with x264, with x265 10-bit doesn't have this issue and should really be the mainstream format (not 8-bit).
If you are using a proper 64-bit build of ffms2, you may need to try a different build?
stranno
29th February 2016, 18:18
You need to use a 64-bit build of ffms2. I have found that LSMASH-Works doesn't seem to work with a lot of 10-bit x264 sources whereas FFMS2 works beautifully. Not sure the cause of this. It seems 10-bit x264 has always caused a bit of a quandary on the decoder side of things with support. This is only with x264, with x265 10-bit doesn't have this issue and should really be the mainstream format (not 8-bit).
If you are using a proper 64-bit build of ffms2, you may need to try a different build?
I get a system exception error (access violation) with ffms2 2.22 64-bit + avisynth+ 1576 x64.
stax76
2nd March 2016, 06:54
I never tried the newer one, but this version doesn't work for me, it says %1 is an invalid win32 application when using with Staxrip. I then realised this is probably a 32 bit build only, and Staxrip is now 64-bit :).
Any chance of 64-bit builds? I'm guessing you would have to optimise for something a bit never than Pentium 3 :).
StaxRip don't support C plugins, there is probably still a big memory leak that happens only in the C version of ffms2.
burfadel
2nd March 2016, 12:07
It was a 32 bit build, running with 64 bit ffmpeg and x265 is probably the reason. It's good to have both ffms2 and lsmash-works, the (doom9 curse word) one depends on the source material.
StainlessS
3rd March 2016, 04:17
Comodo Internet Security, still flags ffmsIndex.exe as malware, have submitted to Comodo (again), and posted in their forum a request to be White Listed.
18fps
23rd March 2016, 12:27
I have a 100 GB prores HQ file, which I wasn't able to open with the 2.22. After the indexing, which the program completed without trouble, I got an access violation error. 2.21 opens it without trouble. I converted the file to FFV1 with ffmpeg, and when opening it with 2.22 got the same error as with the prores.
LigH
23rd March 2016, 12:46
Just out of curiosity, how large are the index files in such cases? I remember that FFMS2 used to have trouble with indexing key-frame-only files, e.g. raw YUV AVIs, but I don't remember if that has been fixed in a specific range of versions. FFV1 may not have only key frames, but delta frames as well; still, there are probably a lot.
18fps
23rd March 2016, 14:15
Just out of curiosity, how large are the index files in such cases?
Around 350 kb, I think. But version 2.21 had no trouble with them...
Tima
27th March 2016, 18:40
I have a 100 GB prores HQ file, which I wasn't able to open with the 2.22. After the indexing, which the program completed without trouble, I got an access violation error. 2.21 opens it without trouble. I converted the file to FFV1 with ffmpeg, and when opening it with 2.22 got the same error as with the prores.
I have the same problem with my 8Mb sample:
- FFMS 2.20 and 2.22 crash on opening
- FFMS 2.21 opens the video without crash (but some frames are wrong during stepping forward the first time)
- Same behaviour for both Lagarigth- and UT-encoded samples.
test-LAGS.avi: http://rghost.net/8CpZWhTvc
test-ULY2.avi: http://rghost.net/6vtBFTCqG
Here's also the same sample with audio stripped and without dropped frames (the original one has one such frame):
test-ULY2-nodrop.avi: http://rghost.net/6VwR5Sg6M
qyot27
28th March 2016, 19:44
FFMS2 C-plugin r1110+98
Optimized for Pentium III and SSE.
ffmpeg version r79153 git-c2bbcf1 Copyright (c) 2000-2016 the FFmpeg developers
built with gcc 5.3.0 (GCC)
libavutil 55. 19.100 / 55. 19.100
libavcodec 57. 32.100 / 57. 32.100
libavformat 57. 29.101 / 57. 29.101
libavfilter 6. 40.102 / 6. 40.102
libavresample 3. 0. 0 / 3. 0. 0
libswscale 4. 0.100 / 4. 0.100
libswresample 2. 0.101 / 2. 0.101
libpostproc 54. 0.100 / 54. 0.100
configuration:
--prefix=/home/qyot27/win32_build
--cross-prefix=i686-w64-mingw32-
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--disable-encoders
--disable-muxers
--disable-doc
--disable-debug
--disable-devices
--disable-avdevice
--enable-avisynth
--cpu=pentium3
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -fno-tree-vectorize'
--target-os=mingw32
--arch=x86
Actually up-to-date this time. The Access Violation issue from before was due to FFmpeg getting miscompiled (-fno-tree-vectorize fixes that problem).
EDIT 2016-10-19: Newer build available here. (http://forum.doom9.org/showthread.php?p=1783312#post1783312)
filler56789
28th March 2016, 22:50
FFMS2 C-plugin r1110+98 (http://www.mediafire.com/?k3yoexl7xsvqv3m)
Actually up-to-date this time.
The Access Violation issue from before was due to FFmpeg getting miscompiled
(-fno-tree-vectorize fixes that problem).
Thanks for the new&&fixed build :thanks:
qyot27
28th March 2016, 23:52
Users with older (read: ancient ones like my Pentium III drive host) computers may want to hold off, there's now an outright crash that gdb can't parse. It's not showing up as a missing function (the indicator for OS churn), or an illegal instruction (bad SIMD), so either FFMS2 doesn't like its own GCC optimization level* or something else has gone screwy. It's not happening on Silvermont, so if you have a decently new enough CPU you probably won't run into it.
*the Haali Matroska parser would cause a nasty memory problem on PIII with any optimization level, which is why I usually built the C-plugin as -O0. It may be doing it in some other part of the code now, since the Haali stuff was removed over a year ago.
manolito
29th March 2016, 00:49
Yeah, just found out on my real ancient Coppermine CPU (no SSE2). Can't even load the plugin:
http://i.imgur.com/2uIOsTK.png
Still thanks a lot for keeping your C-plugin updated.
Cheers
manolito
poisondeathray
29th March 2016, 01:06
@manolito - in some versions of avisynth/vdub combos , I've noticed that you need to specify the full path for LoadCPlugin ffms2.dll in the .avsi for it to work. Worth a try anyways
manolito
29th March 2016, 01:52
Yes, worth a try, but also no luck... Same error message.
TheFluff
29th March 2016, 02:08
System error 0x5 is ERROR_ACCESS_DENIED.
poisondeathray
29th March 2016, 02:40
I thought it was the same error, but my memory failed . I just tested by taking out the full path and it gives error=0x7e , just curious what that one means ? It loads fine with avspmod - ie. it's specific to vdub and ffms2 C-Plugin. Adding full path works for that error
What would cause a 0x5 ? Possibly a permissions issue ?
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.