FFmpegSource

[LigH]

@ TheFluff:

1) Yes, we found out that one can make MeGUI use AviSource by pressing the button "DirectShowSource". Great feature, but surprising. That button might need a better title (e.g. [ DirectShow / VfW ] or similar).

2) Yes, iDCT differences are usually extremely minor. I already wonder how the linked thread was able to produce an example with such obvious green streaks.

[TheRyuu]

Originally Posted by arestarh

Same issue. Does anyone can confirm this ?
I used build 579.
Thanks.

Cannot reproduce with r579 or one which was just compiled (which would have an updated libav).

Originally Posted by pandv2

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.

Well the avisynth portion of ffms2 calls the same function and uses planar formats fine all the time (yv12). Could you if possible post the code in question which calls FFMS_SetOutputFormatV2?

[Mr VacBob]

Originally Posted by TheRyuu

You get something like 6-7 different iDCT options with both DGDecode and Mpeg2Dec3. They both default to whatever is found in the d2v file but can be overridden in avisynth. DGIndex defaults to Skal SSE and DVD2AVI defaults to SSE2MMX. The one most like libav's default is probably Simple iDCT although that's just a guess based on libav's naming of a constant.

Simple MMX is the libav default idct. It's called "XviD simple mmx" in some other places, but Xvid doesn't actually use it, it's just there but unused in the Xvid source.

The fastest idct available is libav's "xvidmmx", which is actually a version of Skal SSE2 which I/Michael optimized further. It's the default in libav for Xvid content but not for MPEG2.

If someone wants to write an even faster idct SSE4 has some nice instructions for it…

[pandv2]

Sorry for the delay. I get bussy.

This is the code used to activate a planar format, is c#:

int[] TargetFormat = new int[2];
            TargetFormat[0]=FFMS_GetPixFmt(fmt);
            TargetFormat[1]=-1;
            fixed (char* msg = ErrorMsg)
            {
                Error.Buffer = msg; //Attempted to read or write protected memory.
                ret = FFMS_SetOutputFormatV2(VideoSource, TargetFormat, TheWidth, TheHeight, 1, ref Error);
                if (ret != 0) throw new Exception("FFmpegSource2 error en SetOutputFormat." + new string((sbyte*)Error.Buffer));
            }

The values for vars are:
VideoSource (a created object. It works in rgb32 format).
fmt = "nv12" (yv12 is not a valid format name)
TheWidth = 64 (not the original width)
TheHeight = 64 (not the original height)

If I use fmt="rgb32" it works, only if i use a planar format it crashes with "Attempted to read or write protected memory"

With past versions the same code works. This happens with beta r580.

[pandv2]

add sanity check for cases where the video decoder returns an empty frame.

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 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?

I uploaded a sample. The url is:

https://rapidshare.com/files/2847794572/SupTest.avi

The error happens in the frames 298 & 744 (0 based).

[TheFluff]

Originally Posted by pandv2

Sorry for the delay. I get bussy.

This is the code used to activate a planar format, is c#:

int[] TargetFormat = new int[2];
            TargetFormat[0]=FFMS_GetPixFmt(fmt);
            TargetFormat[1]=-1;
            fixed (char* msg = ErrorMsg)
            {
                Error.Buffer = msg; //Attempted to read or write protected memory.
                ret = FFMS_SetOutputFormatV2(VideoSource, TargetFormat, TheWidth, TheHeight, 1, ref Error);
                if (ret != 0) throw new Exception("FFmpegSource2 error en SetOutputFormat." + new string((sbyte*)Error.Buffer));
            }

The values for vars are:
VideoSource (a created object. It works in rgb32 format).
fmt = "nv12" (yv12 is not a valid format name)
TheWidth = 64 (not the original width)
TheHeight = 64 (not the original height)

If I use fmt="rgb32" it works, only if i use a planar format it crashes with "Attempted to read or write protected memory"

With past versions the same code works. This happens with beta r580.

It's sort of hard to tell what's going on because you didn't include how you're allocating ErrorMsg but I'm betting that the problem is related to that in one way or another and not to the actual call to FFMS_SetOutputFormatV2.

[pandv2]

It's sort of hard to tell what's going on because you didn't include how you're allocating ErrorMsg but I'm betting that the problem is related to that in one way or another and not to the actual call to FFMS_SetOutputFormatV2.

I thinked this intially, too. But the error happens in the call to FFMS_SetOutputFormatV2 (or FFMS_SetOutputFormatV, I tried this also). Only happens with planar formats. Never with other formats. And if I pass a invalid value (as "YV12"), i get a correct error message in the msg buffer.

The error happens in the line calling FFMS_SetOutputFormatV2 (the comment is in the above line because there is more space).

This is the msg initialization (at class level).

private char[] ErrorMsg= new char[2050];

And this is the Error Object initialization (in the constructor):

        public FFVideo()
        {
            Error = new FFMS_ErrorInfo();
            Error.ErrorType = 0;
            Error.SubType = 0;
            Error.BufferSize = 1024;
        }

And, I am currently using the version dated Oct, 19, because this version works without this problem.

[pandv2]

Triyng to investigate if the bug is in my code or in the library, I tried your sample code directly in C++ (Visual Studio 2010). From:

http://ffmpegsource.googlecode.com/s...ffms2-api.html

First, there are 2 typos:

original: int pixfmts[2];
corrected: int pixfmt[2];

original: const FFMS_Frame *propframe = FFMS_GetFrame(videosource, 0, errinfo);
corrected: const FFMS_Frame *propframe = FFMS_GetFrame(videosource, 0, &errinfo);

I used the sample file uploaded to rapidshare messages ago.

The sample compiles and runs ok.

But, if I change the line:
pixfmt[0] = FFMS_GetPixFmt("bgra");

to:
pixfmt[0] = FFMS_GetPixFmt("nv12");

I get this error:
Unhandled exception at 0x0f42dc24 in TestFFMS2.exe: 0xC0000005: Access violation reading location 0xffffffff

The error happens in the call to FFMS_SetOutputFormatV2.

(using the dll from version r580).

So, I think there are a bug in the library.

Many thanks for your work. My level of english is not good, and sometimes my simple writing can be confused with rudeness. It's not.

[[DB-FR] Nikko]

Originally Posted by TheFluff

That (probably) isn't really a bug in FFMS2. The error message means exactly what it says: libavcodec returned a video frame object with no actual image data in it. Prior to 2.16 the behavior with such frames was to just crash.

Sometimes you can make this problem go away by setting threads=1.

I had the same problem since the 2.16 version, insanity detected randomly. I tested threads=1 on 5 h264 sources and I have no error anymore, so this trick seems to work until now ^^

Thx TheFluff !

[qyot27]

I've been experiencing an odd behavior with ffmsindex's progress meter. If I give it an MKV file, the progress is updated correctly. But for other types of files - I tried MOV, MP4, FLV, and even a couple AVIs I tested out of curiosity - it doesn't. It stays at 0% until it's finished, upon which it jumps to 100% and then exits normally. The strange thing is that I tried the C-plugin build of 2.16 on googlecode and it showed progress updates for those kinds of files just fine. So I go and checkout a revision from that point in time and compile it locally. It doesn't update. I tried changing the configuration for the libraries to [mostly*] fit what the working one used, nothing. Switched between using w32threads and pthreads, switched between branches of FFmpeg/libav, still nothing. In all of these cases the files used H.264, except for the AVIs, which were ASP and ffvhuff.

*I omitted the AMR stuff and changed the target CPU to pentium3. I think that was it.

The actual indexes that ffmsindex writes for these files seem fine, so I don't know if it's something ffmsindex-centric or if it was caused by some change in libavformat that doesn't affect MKV, or if it's another gcc-related issue.

It seems to occur on *all* files of those container types, and I noticed it both on my normal setup (the old PIII-based Celeron) with several revisions, including r582, and on a laptop that has a Core 2 Duo T5450 in it (and that build of FFMS2 is from the middle of October). Even if the file involved was 7.5 minutes long and 848x480. I took an MKV and remuxed it to MP4: the MKV shows update progress, the MP4 doesn't (the MP4's index file is also almost half the size of the MKV's, but I assume that's just because of the difference in how the indexing manages different containers).

If it helps, this is a debug build affected by the issue:
http://www.mediafire.com/?8axqb47gjfr7j5x

[TheFluff]

Sounds like whatever libav version you use has broken the byte position reporting that we use for reporting indexing progress. Are you using libav or ffmpeg? What version?

For MKV, FFMS2 will always use Haali's matroskaparser.c rather than lavf, unless you explicitly tell it to use lavf, so that's why it's not affected.

[the_weirdo]

Maybe because of this:
http://git.libav.org/?p=libav.git;a=...9947f5729841c3
lavf: deprecate AVFormatContext.file_size

[qyot27]

That particular debug build is using FFmpeg git-4b7ef5a, from November 8th. The libav test was yesterday morning. It was whatever the latest revision was at the time. When I saw that it exhibited the same issue I just deleted it without taking note of the exact version. Generally I update to the latest git right before compiling FFMS2, but I don't know exactly when this cropped up, except obviously some time after 2.16 was committed.

I don't know why I forgot that the default MKV demuxer isn't lavf.

Originally Posted by the_weirdo

Maybe because of this:
http://git.libav.org/?p=libav.git;a=...9947f5729841c3
lavf: deprecate AVFormatContext.file_size

Yeah, I think it is. I went to a backup I have of a build from October 16th, and sure enough, it has no issue with the progress meter.

[TheFluff]

Originally Posted by the_weirdo

Maybe because of this:
http://git.libav.org/?p=libav.git;a=...9947f5729841c3
lavf: deprecate AVFormatContext.file_size

That sounds like it, yep.

[TheRyuu]

Fixed in r584.

[forclip]

Originally Posted by forclip

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

So what?

[the_weirdo]

First, please excuse for my poor English. I'm not sure I can explain the problem clearly as my English is not good enough to express my thought.

Recently, after this commit, I've noticed FFMS2 build that linked against ffmpeg's lavc/lavf seems to have a timestamp issue. It seems there're delayed frames (number of delayed frames is number of decoding threads -1). I only tested with H.264 in MKV and MP4, so I don't know if this happens with other video formats or not. Because offical builds are linked againt libav's lavc/lavf so I thought nobody actually care about it, and I've switched to use libav for my builds. But now, libav have that commit too, so I think I should report it.

I added a series of images to demonstrate this issue. Top images are decoded by FFMS build that linked against libav before that commit, while bottom images are decoded by the build after that commit. (There's a Textsub line with a timed ASS so you can easily see the issue).

[jmac698]

I'm trying to open an interlaced ts, avc, and the frames are coming in some nearby but not sequential order (more like decode order maybe). ffdshow/directshowsource doesn't work (grey screen). I don't know how to open this.

[TheRyuu]

Originally Posted by jmac698

I'm trying to open an interlaced ts, avc, and the frames are coming in some nearby but not sequential order (more like decode order maybe). ffdshow/directshowsource doesn't work (grey screen). I don't know how to open this.

dgdecodenv/di.

Workarounds are provided in the ffms2 documentation to get interlaced stuff working sometimes but it is unreliable. The neuron2 stuff is the only reliable and guaranteed frame accurate way currently.

Workarounds suggested: specifying fpsnum/fpsden, threads=1, lavf demuxer, seekmode=-1 or 0.

[TheRyuu]

Well three weeks later and it's fixed.

ffms2-r588.7z

It should now perfectly emulate the old behavior of has_b_frames (which is a little funky to begin with I suppose). The problem commit as mentioned before caused the thread count to no longer get added as an additional delay which caused frame accuracy issues (off by number of threads - 1).

I tested it on a limited number of things and it appeared to work correctly but feel free to test it out and report any issues you find with it.