FFmpegSource

[TheRyuu]

Okay, so I finally got around to taking a look at these.

20110522_11163.mkv ("bug 1") can't be played at all with Haali's media splitter for some reason. A remux with mkvmerge fixes that issue, but whatever, that's unrelated; it's probably just lavf's mkv muxer doing odd stuff again. FFMS2 opens and decodes it fine (well, "fine" if you disregard the usual funky interlaced h.264 issues) if you use threads=1. Didn't I ask you to try that a few posts ago? Oh well, whatever, the issue here is that libavcodec's multithreaded decoding is broken. Who coulda' thunk it. I can't do anything about that, unfortunately, so just use threads=1 for now.

20110521_11462.mkv ("bug 2") works just fine with 32-bit FFMS2. I don't have a 64-bit OS nor 64-bit Avisynth so I can't reproduce your issue. I've asked TheRyuu to take a look.

So in 64-bit avisynth:
Bug 1 - Usual interlaced shit, x64 has the same behavior as the 32bit version. Setting threads=1 makes it 'work' although all the interlaced shit is still there. You can try using dss2 (of which there is a 64-bit build floating around) or one of the dgtools (nv/di).

Bug 2 - Works just fine in x64 as well.

To those wanting an updated x64 version which contained the colorspace/range fixes. Archive contains both 32 & 64-bit builds:
ffms2-r570.7z (http://code.google.com/p/ffmpegsource/downloads/detail?name=ffms2-r570.7z)

[TheRyuu]

Sorry, I don't understand your answer. Did you found no any bugs here? %-()

I have just tried ffms2-r570.7z and threads=1.
The result: x86 version works fine, as worked always. The x64 version has an infinite loop in VirtualDub, so I must kill the process. Ok. Killed and played again. After some clicks to the timeline and to the play button I get the infinite loop again. Ok, kill. Play again. Again I get the infinite loop... It is very simple to catch the bug, I really don't understand how you cannot get it.

Please look at the example again. I really cannot use your x64 version. It works only if no any position changes. It is useless to edit video and play it if I have Trim() calls). Your x86 version works fine.

I did the steps exactly as you listed out in the avs file and it worked fine for me, I didn't even need to specify threads=1.

So in both cases the 64-bit version exhibits the exact same behavior as the 32-bit version.

Edit:
Seems the problem is with ffaudiosource, do your audio processing outside of avisynth (for now) since that's apparently is what's causing the issue.

Re-Edit:
Works for me.

[TheFluff]

I even ready to debug it myself. But I don't know how to use your environment. Is there any libraries or a special debug version of Avisynth x64? I can install MS VC++ Express with Windows SDK. Some time ago in different thread I get an answer that a developer cannot recompile a tool to x64 because a special x64 lib of Avisynth x64 is needed, but it is not available.

You do not need a 64-bit debug Avisynth to be able to debug FFMS2.

Quick FFMS2 debug howto:

Compile FFMS2 (instructions on how to do this are available in the API documentation), in debug mode. You don't need to link to a debug ffmpeg, so just use --disable-debug as usual. Visual Studio can't read gcc debugging symbols anyway so a debug ffmpeg is useless to you.
Make sure you don't have any ffms2.dll copies in your Avisynth folder.
Create an Avisynth script that explicitly loadplugin()'s the debug ffms2.dll, and then does whatever you want to test.
Go to the FFMS2 project properties in Visual Studio, go to the debugging pane, set the debug command to launch virtualdub.exe, and its commandline to path to the Avisynth script you want to test.
Place a breakpoint somewhere in the Avisynth code in FFMS2. A good place to start would be in the CreateVideoSource() or CreateAudioSource() functions in avisynth.cpp.
Hit start debugging.


If you just want to get stack traces, you can just get the .dll and the .pdb from the SDK package and attach Visual Studio to an already running vdub process.

[TheRyuu]

Update: Now it works fine (even with audio, I wonder if there was any correlation at all to begin with...)

Honestly it seems it's just some weird shit going on because these came from transport streams (interlaced at that) which is a known problem. You already know the possible work arounds for that so good luck.

And obviously your best option would be to just not use ffms2 for stuff that's broken (dgtools/dss2).

Also if 32-bit works for you, you could just use 32-bit...

[Yellow_]

I was very bored so I made a quick hack that makes FFMS2 able to output 10-bit YV12 video as the ugly 16-bits-per-sample doubled height stuff that cretindesalpes' Dither package uses. I've tested it on a grand total of one (1) video so far but it seems to work.

Download: ffms-r561+10bithack.7z (http://mod16.org/ffms2/ffms-r561+10-bithack.7z)

It will act just like an ordinary FFMS2 and downsample 10-bit input to 8-bit, unless you set the colorspace parameter to ffvideosource like so:
ffvideosource("10-bit.mkv", colorspace="YV12_10-bit_hack")



I get Invalid colorspace name specified trying to use the above ffvideosource line. :-(

**EDIT**

oops my bad, used the wrong FFMS2 build. :-)

trying to use this with Dither functions like:

Dither_convert_yuv_to_rgb(matrix="601", tv_range=false, cplace="MPEG2", chromak="bicubic", lsb_in=true, output="rgb48y")

Dither_convey_rgb48_on_yv12 (SelectEvery (3, 0),SelectEvery (3, 1),SelectEvery (3, 2) )

gives:

Avisynth error:
Evaluate: Unrecognized exception!

I've basically just replaced FFMS2 plugin with 10bit hack version, added the colorspace and hashed out Dither_convert_8_to_16() from scripts that worked with Dither but the scripts are failing with above error.

[TheFluff]

That doesn't look like a FFMS2 error. The patch does get the LSB wrong but that probably shouldn't crash dither in and of itself. That said, the patch was developed purely out of boredom and will not be maintained by me nor supported by me. If you want it debugged, either debug it yourself or get someone else to do it for you.

[leoenc]

I'm trying to frameserve an AIFF audio file via FFMS (latest 2.16).
The filesize is 2.14GB and the script comes out silent when played back in Vdub, or encoded to another format.
When I trim the source AIFF under 2GB - the script plays fine.
I'm on 32-bit Win7.
Could it be related to a 32-bit limitation (OS/AVIsynth)?

This is my script:

a = FFAudioSource("source.aiff")
v = BlankClip(length=int((audiolengthF(a)/audiorate(a))*25.0000),fps=25.0000)
AudioDub(v,a)

[TheRyuu]

I'm trying to frameserve an AIFF audio file via FFMS (latest 2.16).
The filesize is 2.14GB and the script comes out silent when played back in Vdub, or encoded to another format.
When I trim the source AIFF under 2GB - the script plays fine.
I'm on 32-bit Win7.
Could it be related to a 32-bit limitation (OS/AVIsynth)?

This is my script:

a = FFAudioSource("source.aiff")
v = BlankClip(length=int((audiolengthF(a)/audiorate(a))*25.0000),fps=25.0000)
AudioDub(v,a)

I believe it has the same limitation as WAV with regards to file size so the maximum for some programs is 2GB (because of signed integers).

You can split the file in 2GB chunks and then bring them back together in avisynth.
a1 = ffaudiosource("X:\path\to\file1.aiff")
a2 = ffaudiosource("X:\path\to\file2.aiff")
v = BlankClip(herpderp)
AudioDub(v, a1 + a2)

[leoenc]

Thanks.
However, I ended up using QTinput instead. It seems to be able to work with >2GB AIFF files with no issues.
(The last version: http://forum.doom9.org/showthread.php?t=156777)

[pandv2]

Hello, It's not related directly to AviSynth, but it's a bug report about ffmpegsource (I think). I am using it in a C# program.

I have a Matroska file with the first track ac3 audio and the second a avc video (I know this order is bizarre). I index the video with FFMS_MakeIndex, I consult the video track with FFMS_GetFirstTrackOfType (the response is 1). And I save the index with FFMS_WriteIndex. The second time I open the index with FFMS_ReadIndex. When I consult the video track with FFMS_GetFirstTrackOfType the response is 0 (and CreateVideo fails because 0 is the audio track). So, if you save a index for a video not in the first track, when you retrieve it the information is incorrect.

Tested with: 2.16 and r578.

Sorry for my english. I hope you can understand the bug.

[Myrsloik]

Hello, It's not related directly to AviSynth, but it's a bug report about ffmpegsource (I think). I am using it in a C# program.

I have a Matroska file with the first track ac3 audio and the second a avc video (I know this order is bizarre). I index the video with FFMS_MakeIndex, I consult the video track with FFMS_GetFirstTrackOfType (the response is 1). And I save the index with FFMS_WriteIndex. The second time I open the index with FFMS_ReadIndex. When I consult the video track with FFMS_GetFirstTrackOfType the response is 0 (and CreateVideo fails because 0 is the audio track). So, if you save a index for a video not in the first track, when you retrieve it the information is incorrect.

Tested with: 2.16 and r578.

Sorry for my english. I hope you can understand the bug.

Would you mind sharing the sourcecode for your program or make a small program that shows the same issue?

I really have no idea what you could be doing wrong.

[pandv2]

Of course I can share the code, but I think I am not doing anything wrong. The program works if the first track is Video, it only doesn't work if the video is the second track in the Matroska file. It's a bug in ffmpegsource because it appeared after the update.

If I downgrade to version 2.15 of FFMpegSource the code works ok, the bug doesn't appears. It's a bug introduced in the lastest versions (2.16 fails).

The code is:


bool newindex = false;
if (UseFileIndexes && File.Exists(sourcefile + ".vsyidx"))
{
Index = FFMS_ReadIndex(sourcefile + ".vsyidx", ref Error);
}
else
{
Index = FFMS_MakeIndex(sourcefile, 0, 0, IntPtr.Zero, IntPtr.Zero, true, IntPtr.Zero, IntPtr.Zero, ref Error);
newindex = true;
}
if (Index == IntPtr.Zero) throw new Exception("Imposible crear el índice de FFmpegSource2." + new string((sbyte*)Error.Buffer));
//Busca el track
int trackno = FFMS_GetFirstTrackOfType(Index, 0, ref Error);
if (trackno < 0) throw new Exception("FFmpegSource2 no ha encontrado track de video");
trackVideoNum = trackno;
//Carga el video
VideoSource = FFMS_CreateVideoSource(sourcefile, trackno, Index, 4, 1, ref Error);
if (VideoSource == IntPtr.Zero)
throw new Exception("Imposible crear el video en FFmpegSource2: " + new string((sbyte*)Error.Buffer));
trackVideo = FFMS_GetTrackFromVideo(VideoSource);
if (UseFileIndexes && newindex) FFMS_WriteIndex(sourcefile + ".vsyidx", Index, ref Error);


(UseFileIndexes is true). The first time the code read the file and creates and save the index (it works). The second time the code retrieves the index from disk and GetFirstTrackOfType fails (returns 0, but the video is the track 1).

Also the format is incompatible between versions. 2.15 can't read files saved with 2.16. But maybe this is by design.

Thanks for your time, your program and your attention.

[TheFluff]

Also the format is incompatible between versions. 2.15 can't read files saved with 2.16. But maybe this is by design.

Yes, that's by design.

I think your issue might be related to the one fixed in r578 (http://code.google.com/p/ffmpegsource/source/detail?r=578). Have you tried that version?

[pandv2]

Yes I tried the last version, and it's the same. It worked ok whit the previous versions.

But I found it.

With a video in not the first track. If you save the Index to a File, AFTER using it in CreateVideoSource, the saved index is wrong (its roughly double size), if you save it before the call to CreateVideoSource the index is correct.

Now I save it previously to CreateVideoSource and my program works. Maybe, all is needed is a commentary in the API documentation about not saving the Index after CreateVideoSource.

[Plorkyeran]

It looks like video has the exact same bug as was fixed for audio in r578.

[TheRyuu]

Yes I tried the last version, and it's the same. It worked ok whit the previous versions.

But I found it.

With a video in not the first track. If you save the Index to a File, AFTER using it in CreateVideoSource, the saved index is wrong (its roughly double size), if you save it before the call to CreateVideoSource the index is correct.

Now I save it previously to CreateVideoSource and my program works. Maybe, all is needed is a commentary in the API documentation about not saving the Index after CreateVideoSource.

ffms2-pandv2-videoindex.7z (http://warpsharp.info/ffms2/ffms2-pandv2-videoindex.7z)

Try this one.

Edit: Now commited as r579.

[pandv2]

It worked.

Thanks.

[TheRyuu]

ffms2-r579.7z (http://code.google.com/p/ffmpegsource/downloads/detail?name=ffms2-r579.7z)

Commited as r579 (http://code.google.com/p/ffmpegsource/source/detail?r=579).

[LigH]

The MeGUI thread (http://forum.doom9.org/showthread.php?p=1532631#post1532631) discusses an issue with FFindex which crashes on uncompressed YUY2 / YV12 videos — not only with dozens of GB in size.

[Chikuzen]

The MeGUI thread (http://forum.doom9.org/showthread.php?p=1532631#post1532631) discusses an issue with FFindex which crashes on uncompressed YUY2 / YV12 videos — not only with dozens of GB in size.

I've never heard that ffms2 can process uncompressed formats.
Are they using nut container?

[LigH]

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

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]

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

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]

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

http://i53.tinypic.com/4udx0m.jpg

[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]

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 :confused:
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]

The MeGUI thread (http://forum.doom9.org/showthread.php?p=1532631#post1532631) 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/ffmpegsource/source/detail?r=518
or read the changelog:
http://forum.doom9.org/showthread.php?p=1522092&highlight=empty+frame#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]

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]

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 (http://www.dependencywalker.com/) 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]

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).

@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.

What is the reason why you're trying to build ffms2 with cygwin to have it be used with avisynth?
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]

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]

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.

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

[LoRd_MuldeR]

'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:


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 (http://doom10.org/index.php?topic=25.msg6431#msg6431)):

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]

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 (http://doom10.org/index.php?topic=25.msg6431#msg6431)):

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.

[AMED]

I'm currently using FFMS v579 with MeGUI and i have noticed some random blocking when encoding a bluray VC1 stream in MKV.

http://i44.tinypic.com/veox3l.png

These blocks in Frame 947 do actually come out on the final encode as well.

General
Unique ID : 151178532468450782821249184430171641178 (0x71BBED1F9198E6CA80E93BBF4664555A)
Complete name : D:\backup\CINDERELLA_MAN\CINDERELLA_MAN.mkv
Format : Matroska
Format version : Version 1
File size : 24.7 GiB
Duration : 2h 24mn
Overall bit rate : 24.5 Mbps
Encoded date : UTC 2011-10-23 01:15:30
Writing application : eac3to
Writing library : Haali DirectShow Matroska Muxer 1.11.96.14

Video
ID : 1
Format : VC-1
Format profile : AP@L3
Codec ID : WVC1
Codec ID/Hint : Microsoft
Duration : 2h 24mn
Bit rate : 24.0 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.483
Stream size : 24.2 GiB (98%)

Uploading a sample right now....

Sample
http://www.mediafire.com/?8cy5i8179hunmcy

MD5: 604190103a687e07bddd243d83ec0295
SHA1: 1b1eee32e5e8a765de0b4980ba0a06d57f4766c2

[TheRyuu]

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 (http://doom10.org/index.php?topic=25.msg6431#msg6431)):

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?

(Probably) Fixed in r580 (http://code.google.com/p/ffmpegsource/source/detail?r=580).

Give it a shot: ffms2-r580.7z (http://ffmpegsource.googlecode.com/files/ffms2-r580.7z)
Built with libav ec6d743.

[forclip]

(Probably) Fixed in r580 (http://code.google.com/p/ffmpegsource/source/detail?r=580).
Probably - yes :thanks: . But this fix also must be added to ffmsindex.cpp I guess, so ffmsindex.exe will check the index file the same way?

[TheRyuu]

Probably - yes :thanks: . But this fix also must be added to ffmsindex.cpp I guess, so ffmsindex.exe will check the index file the same way?

ffmsindex will always throw an exception if the index file already exists.

[forclip]

ffmsindex will always throw an exception if the index file already exists.
How about adding an option to change this behavior and check that this index file is "valid" for the source file?

Also, I must notice that after r580 the FFmpegSource2() function, when "cachefile" is specified, is working not as expected acordingly to

The arguments do the same thing as in FFVideoSource and FFAudioSource; see those functions for details

As expected is: since "cachefile" was specified, this function will throw an error if this index isn't belong to the source file. But instead this index file will be overwritten - I want this behavior for FFIndex(), and not for FFmpegSource2(), but since call to FFIndex is part of FFmpegSource2(), we get what we get.

So again. How about adding an option to ffmsindex.exe and to FFIndex, that will turn on\off this "file signature check" (off = everything works as before r580)? And then FFMS2.avsi can be modified to call FFIndex without this check, so FFmpegSource2() will work as before r580. At least for me with my workflow I would like to have such an option for ffmsindex and for ffindex..

Also the first call of FFindex in FFMS2.avsi seems to missing the "utf8=utf8" atribute (at line 31 column 40).

[pandv2]

About this:

add sanity check for cases where the video decoder returns an empty frame.
"fixes" issue #50 by virtue of not crashing anymore, but just returning a nice
error message instead.

I get this error in a video (in 2 frames), but previously (2.15 version) the same video (same file, not touched) decodes ok. FFMS2 doesn't crash. I can't say if there are frame corruption or not (because it's a unattended process) but not error and not crash.

I am using the library. Not avisynth.

______________________________________________________

With the lastest beta r580, if I try to set the output format (with FFMS_SetOutputFormatV or FFMS_SetOutputFormatV2) to any planar format (I tested all) the program crashes with a memory violation (trying to write in protected area). I tested with non planar formats (rgb & yuv) and it worked.

[TheFluff]

About this:

add sanity check for cases where the video decoder returns an empty frame.
"fixes" issue #50 by virtue of not crashing anymore, but just returning a nice
error message instead.

I get this error in a video (in 2 frames), but previously (2.15 version) the same video (same file, not touched) decodes ok. FFMS2 doesn't crash. I can't say if there are frame corruption or not (because it's a unattended process) but not error and not crash.

I am using the library. Not avisynth.

That's not good at all and sounds like a regression in either FFMS2 or libavcodec. Can you provide a sample file?

With the lastest beta r580, if I try to set the output format (with FFMS_SetOutputFormatV or FFMS_SetOutputFormatV2) to any planar format (I tested all) the program crashes with a memory violation (trying to write in protected area). I tested with non planar formats (rgb & yuv) and it worked.

That's probably some silly typo somewhere. I'll take a look.

[MatLz]

On all mpeg2 I can have (dvd rips, dvb recordings, fresh HCEnc encodes...),
this script does show something wrong :

a=mpeg2source("v.d2v") # or avisource("v_uncompressed_by_virtualdub.avi")
b=ffvideosource("v.mkv") # muxing the stream in a mkv does fix the ffms2 frame inaccuracy
subtract(a,b)
histogram("luma") # needed for humans eyes



I remember when testing some ffdshow settings, I did try the "use speedup tricks" and got some funky pixels like that (but much more visible).
Dunno if it is related since both ffms2 and ffdshow use ffmpeg.

[jmac698]

I'm fairly new to using ffms2, but I just discovered something simple that seems impossible: I can't open a 5.1 and make it dolby stereo. There is no way to downmix to DPL/2. Also can you add a simple feature in the PP string for contrast adjust on import, cont:100
You have functions to support different colorspaces so don't ignore audio.

[arestarh]

I'm currently using FFMS v579 with MeGUI and i have noticed some random blocking when encoding a bluray VC1 stream in MKV.

http://i44.tinypic.com/veox3l.png

These blocks in Frame 947 do actually come out on the final encode as well.

General
Unique ID : 151178532468450782821249184430171641178 (0x71BBED1F9198E6CA80E93BBF4664555A)
Complete name : D:\backup\CINDERELLA_MAN\CINDERELLA_MAN.mkv
Format : Matroska
Format version : Version 1
File size : 24.7 GiB
Duration : 2h 24mn
Overall bit rate : 24.5 Mbps
Encoded date : UTC 2011-10-23 01:15:30
Writing application : eac3to
Writing library : Haali DirectShow Matroska Muxer 1.11.96.14

Video
ID : 1
Format : VC-1
Format profile : AP@L3
Codec ID : WVC1
Codec ID/Hint : Microsoft
Duration : 2h 24mn
Bit rate : 24.0 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.483
Stream size : 24.2 GiB (98%)

Uploading a sample right now....

Sample
http://www.mediafire.com/?8cy5i8179hunmcy

MD5: 604190103a687e07bddd243d83ec0295
SHA1: 1b1eee32e5e8a765de0b4980ba0a06d57f4766c2
Same issue. Does anyone can confirm this ?
I used build 579.
Thanks.