Log in

View Full Version : FFmpegSource


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 [45] 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60

TheFluff
29th March 2016, 03:27
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

126 (0x7E) ERROR_MOD_NOT_FOUND (https://msdn.microsoft.com/en-us/library/windows/desktop/ms681381(v=vs.85).aspx)
The specified module could not be found.

What would cause a 0x5 ? Possibly a permissions issue ?
Usually it's a permissions issue, yes. Dunno what else can cause it.

StainlessS
29th March 2016, 06:53
126 (0x7E) ERROR_MOD_NOT_FOUND

It seems to use a lot of external dll's, check it out with Dependency Walker or Groucho2004 Avisynth Info tool (for missing requirements).

manolito
29th March 2016, 12:40
Usually it's a permissions issue, yes. Dunno what else can cause it.

I am on XP-32, file system on my system partition is FAT32. This should pretty much rule out a permissin issue.

Tima
29th March 2016, 18:42
FFMS2 C-plugin r1110+98 (http://www.mediafire.com/?k3yoexl7xsvqv3m)


Still crashes for me on my samples above (tried VapourSynth only).

asarian
31st March 2016, 21:56
Just out of curiosity, why can't FFVideoSource be frame-safe after all these years?! I'm using DGSource again (for my more demanding projects, that use QTGMC and MCTemporalDenoise and such), so I'm okay; but just wondering why that can't happen with FFVideoSource (it's indexing, after all).

TheFluff
1st April 2016, 19:02
Just out of curiosity, why can't FFVideoSource be frame-safe after all these years?! I'm using DGSource again (for my more demanding projects, that use QTGMC and MCTemporalDenoise and such), so I'm okay; but just wondering why that can't happen with FFVideoSource (it's indexing, after all).

Nobody really works on it these days. In fact, nobody's done that for years. There are a few corporate users who make sure that it keeps working with new versions of ffmpeg and they also occasionally fix the odd bug, but that's it. As far as I know, supporting interlaced H264 would require some special case code that nobody wants to bother writing. In transport streams there's also timestamp discontinuities (https://github.com/FFMS/ffms2/issues/258) to worry about. Someone might or might not be interested in doing something about that. It's not really hard if you know what you're doing, it's just that nobody wants to bother. It's the same with a bunch of Avs-MT issues like those non-reentrant resizers in Avs-MT that were broken for like a decade until someone solved it in the least sophisticated way possible recently, or that silly QTGMC slowdown thing that's been going on since forever because nobody who actually knows how to debug anything has bothered looking at it.

asarian
2nd April 2016, 03:33
Nobody really works on it these days. In fact, nobody's done that for years. There are a few corporate users who make sure that it keeps working with new versions of ffmpeg and they also occasionally fix the odd bug, but that's it. As far as I know, supporting interlaced H264 would require some special case code that nobody wants to bother writing. In transport streams there's also timestamp discontinuities (https://github.com/FFMS/ffms2/issues/258) to worry about. Someone might or might not be interested in doing something about that. It's not really hard if you know what you're doing, it's just that nobody wants to bother. It's the same with a bunch of Avs-MT issues like those non-reentrant resizers in Avs-MT that were broken for like a decade until someone solved it in the least sophisticated way possible recently, or that silly QTGMC slowdown thing that's been going on since forever because nobody who actually knows how to debug anything has bothered looking at it.

Thanks. :) That was a very comprehensive answer.

LigH
2nd April 2016, 06:52
Still unnecessary to full-quote it, for just one sentence as reply... ;)

Selur
2nd April 2016, 10:33
Still crashes for me on my samples above (tried VapourSynth only).
Same here with Avisynth (Win10) , FFMS2 C-plugin r1110+98 still crashes with UT Video and lagarith samples. (LWLibavVideoSource works)

TheFluff
2nd April 2016, 17:30
You should probably report problems on Github, not here, if you want to be sure someone sees them. I don't think anyone who actually fixes ffms bugs reads d9 with any regularity anymore.

Bzor
5th April 2016, 12:57
It's happiness, 5 days passed!

Hi! I have problem to build FFms2 with shared DLL with Minwg64 in Msys2. This is my config
--prefix=xxx --enable-shared --disable-static CXXFLAGS='-static-libgcc -static-libstdc++ -Wl,-Bstatic -lpthread -lwinpthread'

error: undefined "___imp_pthread_once"

use flags to import static libgcc and libwinpthread. Its working for another source but not working for ffms2.

Its successful when i used config --enbale-static --disable-shared to build only ffmsindex.exe

Am i wrong or is that bugs? Please help!

Thank you!

jackoneill
11th April 2016, 18:07
It's happiness, 5 days passed!

Hi! I have problem to build FFms2 with shared DLL with Minwg64 in Msys2. This is my config
--prefix=xxx --enable-shared --disable-static CXXFLAGS='-static-libgcc -static-libstdc++ -Wl,-Bstatic -lpthread -lwinpthread'

error: undefined "___imp_pthread_once"

use flags to import static libgcc and libwinpthread. Its working for another source but not working for ffms2.

Its successful when i used config --enbale-static --disable-shared to build only ffmsindex.exe

Am i wrong or is that bugs? Please help!

Thank you!

I had to patch winpthread when I compiled it static only:

--- mingw-w64-libraries/winpthreads/include/pthread.h 2014-10-26 04:11:33.000000000 +0200
+++ mingw-w64-libraries/winpthreads/include/pthread.h 2014-12-10 14:17:45.542746397 +0200
@@ -82,7 +82,9 @@
/* MSB 8-bit major version, 8-bit minor version, 16-bit patch level. */
#define __WINPTHREADS_VERSION 0x00050000

-#if defined DLL_EXPORT
+/* No __declspec crap needed when winpthreads is static.
+ * In fact, it produces linker errors (can't find __imp_blah). */
+#if defined DLL_EXPORTzzzzzzzzzzz
#ifdef IN_WINPTHREAD
#define WINPTHREAD_API __declspec(dllexport)
#else

Reino
17th April 2016, 23:28
FFMS2 C-plugin r1110+98 (http://www.mediafire.com/?k3yoexl7xsvqv3m)
WinXP SP3 on an ancient AMD Athlon XP 3200+ here.
Today I've updated r944+69 to r1110+98, but only to find out that it doesn't work anymore, because AvsPmod and FFPlay now report: Unable to load C Plugin: "ffms2.dll", error=0x5.
So far r944+69 is the latest build that works for me, because I can't test r1015+85 and newer as their downloadlinks don't work anymore.

TheFluff
18th April 2016, 00:37
SSE2 and Vista+ are a minimum requirement for a lot of things these days - it's been fifteen years since SSE2 was introduced, so if you want to do anything that requires even a moderate amount of computing power today, you're kind of expected to have it. I don't think anyone (except possibly qyot27) will go out of their way to release builds that work on CPU's without SSE2. If XP support starts requiring even a minuscule amount of developer effort, expect that to disappear as well.

StainlessS
18th April 2016, 00:42
Here, Win XP32SP3 C plug r1110+98 working OK here (at least that is the recorded version number that I believe I have, 14,731,264 bytes. Just checked,
is same as one I'm using).

I'm not using AvsPMod and Intel CPU here (Core Duo).

EDIT: OK, Fluffy seems to have pin pointed problem.

qyot27
18th April 2016, 01:19
In the interest of full disclosure, I do very little in the way of anything video related on my Coppermine anymore, and the builds are mainly still built for it out of habit and that i686 is a fairly normalized baseline target for 32-bit; and it lets me test stability since older machines run into problems much faster if something starts eating memory for breakfast and sparks a crash. But for the last seven months I've mostly used a Silvermont-based mini-PC for my video tasks (along with most everything else; the Coppermine setup is now mainly a jukebox, storage area, and disc burner). Prices on similar machines are very affordable (read: I bought mine for $170), so the cost argument of staying on really old hardware isn't nearly as powerful as it once was - and it's a lot more powerful than the PIII is, although that should be pretty obvious. I can downscale from 720p to 720x480 with Lanczos4 for encoding with HCenc for DVD authoring and get usually in the 18-23fps range, compared to ~2fps on the Coppermine.

The weird nature of this particular situation makes me think it's something that changed somewhere deep in the MinGW-w64 or GCC parts, which would be a nightmare to untangle (and at some point I'm sure this will happen in regard to XP support; in which case the only hope is that ReactOS reaches general viability* before then). The most optimistic scenario is that I misconfigured something when building those pieces and all I'd have to do is rebuild them to fix everything.

*the key word there being 'general'; it seems to already be more or less capable of running the AviSynth and VapourSynth ecosystems and at least the CLI tools (which shouldn't be a surprise, since Wine has been able to do most of that for years now). It's just the rest of system that presents a challenge for everyday use at the present time.

Reino
18th April 2016, 10:53
It seems the lifespan of my secondary computer is really approaching its end, because not only with AviSynth (plugins), but with a lot more software it's getting harder and harder to keep up-to-date.
Thanks for the legacy support this far, qyot27.

lvqcl
18th April 2016, 12:58
The weird nature of this particular situation makes me think it's something that changed somewhere deep in the MinGW-w64 or GCC parts, which would be a nightmare to untangle

Try to recompile it with -mstackrealign option. Maybe it'll help, who knows...

FranceBB
18th April 2016, 15:11
Sounds kinda weird 'cause the C++ Redistributable 2015 (the last released) works under XP, so, basically, it should run on XP.
I'm gonna try it as soon as I get home.

EDIT: I confirm it works in XP SP4.

p.s it's not a spam, but check MSFN for Win XP mods.

LoRd_MuldeR
18th April 2016, 19:08
Sounds kinda weird 'cause the C++ Redistributable 2015 (the last released) works under XP, so, basically, it should run on XP.
I'm gonna try it as soon as I get home.

EDIT: I confirm it works in XP SP4.

p.s it's not a spam, but check MSFN for Win XP mods.

MinGW/GCC uses the MSVCRT.DLL (C-Runtime) that is an integral part of Windows, not the one specific to Visual Studio which needs to be installed separately. So, the Visual C++ redistributable is not required for MinGW.

Also MinGW/G++ does not use Microsoft's MSVCP.DLL (Standard C++ Library), it uses the Libstdc++ by GNU.

Finally, latest Visual Studio can still produce binaries for Windows XP, but does not do so by default. Not sure about latest MinGW (Mingw-w64), but I wouldn't be surprised if they start using API's not preset in XP sooner or later.

And, of course, the compiler (runtime libs) is only one side. If the application code or any of the third-party libs uses API's not present in XP, then the whole thing won't work on XP - regardless what compiler you use.

(BTW: AVX unavoidably requires Windows 7 with SP-1 or later, no matter what. Older Windows versions did not save/restore the AVX registers on task switch)

qyot27
19th April 2016, 05:26
Sounds kinda weird 'cause the C++ Redistributable 2015 (the last released) works under XP, so, basically, it should run on XP.
I'm gonna try it as soon as I get home.

EDIT: I confirm it works in XP SP4.

p.s it's not a spam, but check MSFN for Win XP mods.
What does this have to do with anything? The problem being addressed over the last few posts has nothing to do with XP, but with the hardware. It'd most probably have the same crash issue on Windows 7, if a user was determined enough to install Win7 on a Pentium III system (which is possible, just extraordinarily unlikely).

MinGW/GCC uses the MSVCRT.DLL (C-Runtime) that is an integral part of Windows, not the one specific to Visual Studio which needs to be installed separately. So, the Visual C++ redistributable is not required for MinGW.

Also MinGW/G++ does not use Microsoft's MSVCP.DLL (Standard C++ Library), it uses the Libstdc++ by GNU.

Finally, latest Visual Studio can still produce binaries for Windows XP, but does not do so by default. Not sure about latest MinGW (Mingw-w64), but I wouldn't be surprised if they start using API's not preset in XP sooner or later.

And, of course, the compiler (runtime libs) is only one side. If the application code or any of the third-party libs uses API's not present in XP, then the whole thing won't work on XP - regardless what compiler you use.

(BTW: AVX unavoidably requires Windows 7 with SP-1 or later, no matter what. Older Windows versions did not save/restore the AVX registers on task switch)
At least as of MinGW-w64 4.0.4, the only thing that impedes XP support is enabling the secure API when building it, which allows Vista+'s *_s functions. But that's still disabled by default, even in 4.0.5 (and probably 4.0.6, but I haven't checked; not sure about 5.x). 4.0.5 is what I'd switched my toolchain to before FFMS2 and x264 started freaking out, but a couple of GCC 5.3.0's dependencies were also updated at the same time. Perhaps 4.0.6 fixes some of it, maybe not - reading the git history was remarkably unhelpful on trying to figure that out.

FranceBB
19th April 2016, 15:17
@qyot27... Didn't know it was about instructions (so CPU-related) instead of software-related when I replied. My bad.
Thank you both (qyot and lord Mulder) for clarifying it. :)

StainlessS
28th April 2016, 19:20
Just checked on Comodo forums, and on Mar 02,
ffmsindex.exe has been whitelisted.
So no more false +ve's from Comodo on that.

Jamaika
1st May 2016, 15:55
How convert the metadata comments?
Why are comments duplicated to another type metadata 'Movie_More' (©swr)?
I don't see it as standard MOV container.
https://developer.apple.com/library/mac/documentation/QuickTime/QTFF/Metadata/Metadata.html#//apple_ref/doc/uid/TP40000939-CH1-SW43
What does the abbreviation metadata and why prevents the display of information in players?
Can type (©swr) delete with film?

LigH
1st May 2016, 16:12
I don't understand your last post, Jamaika... what do you refer to?

Regarding "QuickTime metadata", I do remember that there are applications on Macs which create additional MOV files to source material without altering it, just to be able to manage it in its raw format (e.g. there was a professional DVD Authoring tool "Sonic DVD Creator" which created a metadata MOV in addition to imported MPEG-2 video *.m2v to store their attributes, not multiplexing the m2v into the MOV, only "linking" it). Is that in any way related to your case?

TheFluff
1st May 2016, 16:17
Jamaika: I understand most of those words, but I have no idea what you're talking about.

Jamaika
1st May 2016, 16:31
Regarding "QuickTime metadata", I do remember that there are applications on Macs which create additional MOV files to source material without altering it, just to be able to manage it in its raw format (e.g. there was a professional DVD Authoring tool "Sonic DVD Creator" which created a metadata MOV in addition to imported MPEG-2 video *.m2v to store their attributes, not multiplexing the m2v into the MOV, only "linking" it). Is that in any way related to your case?
Sorry. I don't know how to specify in their own language.
Rather, it isn't a DVD authoring tool "Sonic DVD Creator".
Anyway, what would it was not, it does not allow the display info of metadata, eg. in MPC-BE. I Wonder, why?

LigH
1st May 2016, 22:42
The metadata MOV does not contain any video track. Therefore a video player cannot display video attributes. The video track is in a separate file. The metadata MOV file only links to the separate video track. Most applications will probably not know how to handle linked tracks, they only know contained tracks.

Jamaika
2nd May 2016, 02:46
THAT is true, but I don't mean metadata tracks. Everything is in a container (name, artist, date, comment and ©swr).
Hmm... I'm reading metadata from MediaInfo.

LigH
2nd May 2016, 08:04
Ah, you mean metadata tags in different containers.

rustyconc
10th June 2016, 04:52
Hi,

I just updated avisynth (v2.6) and the ffms2 plugin files (v2.22). All works well with other videos (e.g. an mp4), but I have whole set of old Indeo 5.1 AVI files that FFVideoSource no longer handles. I reverted to the previous plugin I had installed (2.17) and all worked fine. Is this a deliberate loss or inadvertent?

Thanks

hydra3333
19th June 2016, 03:13
Goodness me.

I just visited https://github.com/FFMS/ffms2/releases to download the latest version https://github.com/FFMS/ffms2/releases/download/2.22/ffms2-2.22-msvc.7z for vapoursynth

... and chrome spewed and told me that ffms2-2.22-msvc.7z is malicious and blocked the download.

Other files from github dowloaded fine earlier this morning which suggests it doesn't like ffms2-2.22-msvc.7z specifically.

Anyone else had that ?

Sparktank
19th June 2016, 03:22
malicious and blocked

There should be sticky/PSA about freeware and Chrome.
And SourceForge.

filler56789
19th June 2016, 05:13
Goodness me.

I just visited https://github.com/FFMS/ffms2/releases to download the latest version https://github.com/FFMS/ffms2/releases/download/2.22/ffms2-2.22-msvc.7z for vapoursynth

... and chrome spewed and told me that ffms2-2.22-msvc.7z is malicious and blocked the download.

Just stop using Chrome :devil: problem solved :)

hydra3333
19th June 2016, 06:10
yes. yes, that is an option :)

Other files from github dowloaded fine earlier this morning which suggests it doesn't like ffms2-2.22-msvc.7z specifically.

mostly avoided getting stung (apart from a hack of estonian origin a few years ago which 100% knobbled windows) by not downloading stuff the big crowds say is unsafe.

This one is bemusing since chrome only hates ffms2 on github, so someone has complained about it for some reason ...

asarian
21st June 2016, 17:25
Speaking of ffmpeg, at what frame does the following error occur?

[vc1 @ 000001f2d0afa4c0] warning: first frame is no keyframe:01:30

1f2d0afa4c0 = 2,142,394,885,312 decimal, so that can't be the frame number. :)

LigH
21st June 2016, 17:31
This may be a high resolution time stamp, in units as specified in the displayed video format's specifications.

asarian
21st June 2016, 17:38
This may be a high resolution time stamp, in units as specified in the displayed video format's specifications.

Okay, thx. I'll look into the format some further.

LigH
21st June 2016, 17:45
By the way, time stamps don't need to be zero based. Compare against the time stamp of the first GOP to subtract its offset...

To avoid underflows when rewinding (a serious issue in such decks), DigiBeta recordings for professional DVD material often start with a time stamp offset at 1 hour or 10 hours, I learned in a DVD authoring studio.

TheFluff
21st June 2016, 20:35
Speaking of ffmpeg, at what frame does the following error occur?

[vc1 @ 000001f2d0afa4c0] warning: first frame is no keyframe:01:30

1f2d0afa4c0 = 2,142,394,885,312 decimal, so that can't be the frame number. :)

000001f2d0afa4c0 is not a timestamp, it's a pointer to some internal data structure and is completely meaningless to 99.9% of the users

of course it's always printed to stderr anyway because it's ffmpeg, they don't like these newfangled "debuggers" and sincerely hate their users

stranno
25th June 2016, 11:46
I'm trying to fast-forward a video but i get this error.

"Input audio sample format to TimeStretch must be float"

Audio input is PCM in24 (Apple ProRes video). I had no trouble before with AAC.

Does it have something to do with the audio indexing? Can it be fixed?

LigH
25th June 2016, 12:11
Please show us the exact command in your AviSynth script you want to use to "fast-forward".

You should know that a nummerical value of e.g. 3 is of type integer, but 3.0 is of type float, and if a function requires a float parameter, you may have to provide it with a decimal (if the parameter is a variable with an integer value, multiply it with 1.0). But well, who knows if the reason for this error message is at a completely different position ...

Keiyakusha
25th June 2016, 12:19
I'm trying to fast-forward a video but i get this error.

"Input audio sample format to TimeStretch must be float"

Audio input is PCM in24 (Apple ProRes video). I had no trouble before with AAC.

Does it have something to do with the audio indexing? Can it be fixed?

Not sure what are you doing and where. And how this is related to FFMS2, but compressed audio such as aac does not have a concept of bits per sample. That could be the reason it worked. So try converting your PCM to float before applying any processing, whatever that is..

qyot27
25th June 2016, 17:44
It's the decoding sample format being passed from FFMS2 to TimeStretch. libavcodec decodes AAC to float (read: outputs pcm_f32le), but it won't do anything to PCM that's already in an integer format.

Put ConvertAudioToFloat() between FFMS2 and TimeStretch.

LigH
25th June 2016, 18:06
True, I misread a part. It's not related to parameters... :o

smok3
7th July 2016, 12:14
Any bleeding edge compiles that would support cineform.mov type of stuff? (Or a ffms2 alternatives that would?)

LigH
7th July 2016, 12:21
ffms2 alternatives

Probably "L-SMASH Works (http://forum.doom9.org/showthread.php?t=167435)" (LSMASHSource.dll: LSMASHVideoSource for ISO Media containers like MP4/MOV/3GPP, LwLibavVideoSource in general).

smok3
7th July 2016, 13:24
@LigH: thanks, but getting only some green stuff (http://shrani.si/f/1x/zp/2LLNmn6C/capture.png) in vdub window (LSMASHVideoSource and LwLibavVideoSource).
I've tested prores and cineform. Ideas? (win 7)

sneaker_ger
7th July 2016, 13:29
It's because L-Smash does not dither down to a format natively supported by AviSynth by default. See README on how to force an 8 bit output format or read up on AviSynth high bitdepth.

LigH
7th July 2016, 13:44
Yes, you may have to specify the desired color subsampling and depth explicitly, such deepcolor formats might get decoded into wrongly interpreted pixels when you don't specify a pixel format. Please do some research on your own, I know it has been discussed before...