FFmpegSource

[LigH]

Well ... would you call OpenDML AVI "nuts"?

Input was a YUY2 or YV12 AVI, analogue capture by VirtualDub, filtered with VirtualDub plugins, saved without any selected compressor.

MeGUI has a design flaw that it offers only [ OneClick | File Indexer | DirectShowSource ] when opening an AVI as video source for the AviSynth script creator. If OneClick is not your intention, then the remaining choice is between ffindex (which crashes) and DirectShowSource – which is only recommended as "last hope" ... you won't expect that MeGUI is then smart enough to prefer AviSource in the script. The button title appears not to be perfectly chosen.

Still, ffindex should not crash on a technically correct AVI. I'd recommend checking this issue because it may not be too uncommon to occur in some automatized workflows.

[Chikuzen]

Originally Posted by LigH

Well ... would you call OpenDML AVI "nuts"?

http://wiki.multimedia.cx/index.php?title=NUT

NUT is a container with most formats currently supported.
Especially, since almost all uncompressed formats are storable, I often use it.
If ffms2 comes to support uncompressed video, NUT will be more usefull.
But probably, it will be difficult.

[Dogway]

Is there a way to load this clip in avisynth?
bgr24 avi, 11Mb:
http://www.mediafire.com/?i47wys67hbmo25f

ffvideo returns the next error:

FFVideoSource: Insanity detected: decoder returned an empty frame
(New File (1), line 2)

I also tried RawSource but the image is shifted vertical and horizontaly.

[Chikuzen]

Originally Posted by Dogway

Is there a way to load this clip in avisynth?
bgr24 avi, 11Mb:
http://www.mediafire.com/?i47wys67hbmo25f

[Dogway]

Yes sorry, I needed to specify "frame accurate"
Although I reckon that if you are not trimming or calling frames in a non-linear way it is not important, but still.
I also have problems loading Indeo 5, "IV50"

[Chikuzen]

Originally Posted by Dogway

Yes sorry, I needed to specify "frame accurate"
Although I reckon that if you are not trimming or calling frames in a non-linear way it is not important, but still.
I also have problems loading Indeo 5, "IV50"

I can't understand what you say
1. AVISource() is frame accurate except VBR audio formats.
2. LAVC supports Indeo5. thus, ffms2 can decode it.
　also, latest ffdshow-tryouts has vfw support for Indeo5. thus, you can read it with AVISource() if your file is AVI.

[Dogway]

ah thank you! I didn't know avisource was frame accurate.
I was having some issues with an indeo file. So now I looked for another file and it worked, thus I think those indeo were corrupted. Sorry for the confusion.

[qyot27]

Originally Posted by LigH

The MeGUI thread discusses an issue with FFindex which crashes on uncompressed YUY2 / YV12 videos — not only with dozens of GB in size.

http://code.google.com/p/ffmpegsourc...e/detail?r=518
or read the changelog:
http://forum.doom9.org/showthread.ph...me#post1522092

That's an error message, not a crash. The problem is in some occasional quirks related to libavcodec outputting empty frames (often exacerbated/shown when using multiple threads), which then would cause an error. Prior to r518, FFMS2 really would crash (supposedly; I never recall encountering the problem myself in pre-r518 builds). Now it just errors out and tells you what's wrong.

The main thing is still whether or not FFMS2 should be used to open uncompressed formats at all, especially in AVI files. But the error message is a safety precaution because of something FFMS2 has no control over. The other solution is to disable multithreading and see if that fixes it.





On a different tangent, it's really not possible to compile a working AviSynth C plugin with native Cygwin, is it? I forced it in order to test the idea, but AviSynth didn't appreciate trying to load a natively Cygwin-compiled version of ffms2.dll (which also happened to be about 2 megs smaller than MinGW-compiled builds, probably because it was lacking the right functions/linked system libraries that make MinGW builds kosher).

[kemuri-_9]

Originally Posted by qyot27

On a different tangent, it's really not possible to compile a working AviSynth C plugin with native Cygwin, is it? I forced it in order to test the idea, but AviSynth didn't appreciate trying to load a natively Cygwin-compiled version of ffms2.dll (which also happened to be about 2 megs smaller than MinGW-compiled builds, probably because it was lacking the right functions/linked system libraries that make MinGW builds kosher).

Hmm, this scenario generally happens in the reverse...

A cygwin built ffms2.dll will have dependencies on the cygwin runtime.
So if you have those dependencies located in a place avisynth can find them when it loads that ffms2.dll (e.g. PATH), i don't currently see a reason why it couldn't open it...

[qyot27]

Originally Posted by kemuri-_9

Hmm, this scenario generally happens in the reverse...

A cygwin built ffms2.dll will have dependencies on the cygwin runtime.
So if you have those dependencies located in a place avisynth can find them when it loads that ffms2.dll (e.g. PATH), i don't currently see a reason why it couldn't open it...

I think it probably has to do with these stdcall fixups it performs:

Warning: resolving _FFMS_DestroyAudioSource@4 by linking to _FFMS_DestroyAudioSource
Use --enable-stdcall-fixup to disable these warnings
Use --disable-stdcall-fixup to disable these fixups
Warning: resolving _FFMS_GetAudio@28 by linking to _FFMS_GetAudio
Warning: resolving _FFMS_CreateAudioSource@20 by linking to _FFMS_CreateAudioSource
Warning: resolving _FFMS_GetAudioProperties@4 by linking to _FFMS_GetAudioProperties
Warning: resolving _FFMS_DestroyVideoSource@4 by linking to _FFMS_DestroyVideoSource
Warning: resolving _FFMS_GetFrame@12 by linking to _FFMS_GetFrame
Warning: resolving _FFMS_GetVideoProperties@4 by linking to _FFMS_GetVideoProperties
Warning: resolving _FFMS_GetFrameByTime@16 by linking to _FFMS_GetFrameByTime
Warning: resolving _FFMS_GetTrackFromVideo@4 by linking to _FFMS_GetTrackFromVideo
Warning: resolving _FFMS_GetTimeBase@4 by linking to _FFMS_GetTimeBase
Warning: resolving _FFMS_GetFrameInfo@8 by linking to _FFMS_GetFrameInfo
Warning: resolving _FFMS_SetOutputFormatV2@24 by linking to _FFMS_SetOutputFormatV2
Warning: resolving _FFMS_CreateVideoSource@24 by linking to _FFMS_CreateVideoSource
Warning: resolving _FFMS_SetPP@12 by linking to _FFMS_SetPP

ffmsindex also failed to build outright:

src/index/ffmsindex.o:ffmsindex.cpp:(.text+0x98b): undefined reference to `_FFMS_ReadIndex'
src/index/ffmsindex.o:ffmsindex.cpp:(.text+0xa00): undefined reference to `_FFMS_CreateIndexerWithDemuxer'
src/index/ffmsindex.o:ffmsindex.cpp:(.text+0xb05): undefined reference to `_FFMS_DoIndexing'
src/index/ffmsindex.o:ffmsindex.cpp:(.text+0xc33): undefined reference to `_FFMS_GetNumTracks'
src/index/ffmsindex.o:ffmsindex.cpp:(.text+0xc62): undefined reference to `_FFMS_GetTrackFromIndex'
src/index/ffmsindex.o:ffmsindex.cpp:(.text+0xc78): undefined reference to `_FFMS_GetTrackType'
src/index/ffmsindex.o:ffmsindex.cpp:(.text+0xc8b): undefined reference to `_FFMS_GetNumFrames'
src/index/ffmsindex.o:ffmsindex.cpp:(.text+0xdca): undefined reference to `_FFMS_WriteTimecodes'
src/index/ffmsindex.o:ffmsindex.cpp:(.text+0xf04): undefined reference to `_FFMS_WriteIndex'
src/index/ffmsindex.o:ffmsindex.cpp:(.text+0x114f): undefined reference to `_FFMS_Init'
src/index/ffmsindex.o:ffmsindex.cpp:(.text+0x117c): undefined reference to `_FFMS_SetLogLevel'
src/index/ffmsindex.o:ffmsindex.cpp:(.text+0x118a): undefined reference to `_FFMS_SetLogLevel'
src/index/ffmsindex.o:ffmsindex.cpp:(.text+0x1198): undefined reference to `_FFMS_SetLogLevel'
src/index/ffmsindex.o:ffmsindex.cpp:(.text+0x11a6): undefined reference to `_FFMS_SetLogLevel'
src/index/ffmsindex.o:ffmsindex.cpp:(.text+0x11b4): undefined reference to `_FFMS_SetLogLevel'
src/index/ffmsindex.o:ffmsindex.cpp:(.text+0x11cf): undefined reference to `_FFMS_DestroyIndex'
src/index/ffmsindex.o:ffmsindex.cpp:(.text+0x13e3): undefined reference to `_FFMS_DestroyIndex'
src/index/ffmsindex.o:ffmsindex.cpp:(.text+0x1460): undefined reference to `_FFMS_DestroyIndex'
src/index/ffmsindex.o:ffmsindex.cpp:(.text+0x14cf): undefined reference to `_FFMS_DestroyIndex'
collect2: ld returned 1 exit status
make: *** [ffmsindex.exe] Error 1

This is the AviSynth error:
Unable to load C Plugin: "C:\Program Files\AviSynth 2.5\plugins\ffms2.dll", error=0x7f

Even if I put cygwin1.dll and cygstdc++-6.dll in the PATH, that error remains. I'm not sure of whatever else it might need, but if I copy all cyg* .dlls into the PATH, it causes the script to crash.

[kemuri-_9]

if it's not building the stdcall function as stdcall then expecting them to be stdcall in other places, that's certainly an issue...

I would suggest try building with -mno-win32 but that's only going to prevent you from building the c plugin...
-U_WIN32 may work similarly to not have the API be stdcall-based? (chances are this will still break something else)

What is the reason why you're trying to build ffms2 with cygwin to have it be used with avisynth?

[LoRd_MuldeR]

@qyot27:
I would recommend to use Dependency Walker to check which DLL's are used/missing.

[TheRyuu]

What's wrong with mingw? Or are you trying to use it in such a way where you need it to be built with cygwin?

[qyot27]

Originally Posted by kemuri-_9

I would suggest try building with -mno-win32 but that's only going to prevent you from building the c plugin...
-U_WIN32 may work similarly to not have the API be stdcall-based? (chances are this will still break something else)

-mno-win32 with the modified ./configure resulted in a compile error because it couldn't find windows.h; -U_WIN32 either still set 'avs = no' (with a non-modified ./configure) or couldn't link to zlib or ffmpeg (with a modified ./configure).

Originally Posted by LoRd_MuldeR

@qyot27:
I would recommend to use Dependency Walker to check which DLL's are used/missing.

Dependency Walker reported the following: cygbz2-1.dll, cygwin1.dll, cygz.dll, cyggcc_s-1.dll, cygstdc++-6.dll, kernel32.dll

Of course, I'd also just went ahead and copied all of the .dlls in Cygwin's /bin with cyg* prefixes to C:\WINDOWS and it crashed even with all of them present. Then I whittled it down to just those particular dependencies listed above. Same result.

Originally Posted by kemuri-_9

What is the reason why you're trying to build ffms2 with cygwin to have it be used with avisynth?

Originally Posted by TheRyuu

What's wrong with mingw? Or are you trying to use it in such a way where you need it to be built with cygwin?

I was experimenting with libutvideo, and its memory mapping functions are too POSIX-ish to let MinGW build it, as far as I could tell (and if I messed around with the Makefile and actually got libutvideo.a to build, it refused to link with ffmpeg). This was mainly before the internal decoder got committed.

[TheRyuu]

Well this is kind of getting off topic but what's the point of doing it on Windows where you already have the vfw decoder?

[Chikuzen]

Originally Posted by qyot27

I was experimenting with libutvideo, and its memory mapping functions are too POSIX-ish to let MinGW build it, as far as I could tell (and if I messed around with the Makefile and actually got libutvideo.a to build, it refused to link with ffmpeg). This was mainly before the internal decoder got committed.

Umezawa is working so that libutvideo can be compiled with mingw now.
wait the next release.

[qyot27]

Originally Posted by TheRyuu

Well this is kind of getting off topic but what's the point of doing it on Windows where you already have the vfw decoder?

'Alternative containers' would be my official answer, but really just for the hell of it.

Originally Posted by Chikuzen

Umezawa is working so that libutvideo can be compiled with mingw now.
wait the next release.

Will do.

[LoRd_MuldeR]

Originally Posted by qyot27

'Dependency Walker reported the following: cygbz2-1.dll, cygwin1.dll, cygz.dll, cyggcc_s-1.dll, cygstdc++-6.dll, kernel32.dll

Of course, I'd also just went ahead and copied all of the .dlls in Cygwin's /bin with cyg* prefixes to C:\WINDOWS and it crashed even with all of them present. Then I whittled it down to just those particular dependencies listed above. Same result.

This would indicate that the plug-in first didn't load because dependencies were missing. And then, when all required DLL's were in place, it crashed for some other reason...

[forclip]

Can someone explain me please, what does it means:

Originally Posted by ffms2-avisynth.html, about FFIndex return value

0 if the index file already exists (and is valid) and overwrite was not enabled

"and is valid" - how it is calculating that the index-file is (still) valid? I'm asking this because when I use FFAudioSource like this (because of this):

FFIndex("my_file")
FFAudioSource("my_file")

everything is OK for the first time. But after replacing my_file with another file without changing its name and without deleting the index-file, FFIndex still returns 0 and don't re-indexing this (totally different!) file. So FFIndex can't see the difference.. However, FFAudioSource can see the difference and re-creating the index, but due to "error handling mode 1" it is useless for some kind of files..

Why FFIndex can't see that the source-file was changed?

[TheFluff]

Originally Posted by forclip

Can someone explain me please, what does it means:

"and is valid" - how it is calculating that the index-file is (still) valid? I'm asking this because when I use FFAudioSource like this (because of this):

FFIndex("my_file")
FFAudioSource("my_file")

everything is OK for the first time. But after replacing my_file with another file without changing its name and without deleting the index-file, FFIndex still returns 0 and don't re-indexing this (totally different!) file. So FFIndex can't see the difference.. However, FFAudioSource can see the difference and re-creating the index, but due to "error handling mode 1" it is useless for some kind of files..

Why FFIndex can't see that the source-file was changed?

FFIndex currently only checks if the index file exists and is a FFMS2 index file written by the correct version of the library. It does not check if the index actually belongs to the file you want to index, but it probably should.