FFmpegSource

[hwti]

Hi,

I'm trying to open a TS file (recorded from DVB-T, H264 1440x1080i50 MBAFF) with FFVideoSource.
I tried with both the TS and remuxed to MKV, and the number of frames is not correct.
The loaded video is strange : the odd field only changes every two frames, and the even field often jumps forward and backward by several frames.
If I force the fps (fpsnum=25, fpsden=1) it loads correctly.

[TheFluff]

That's a known bug. FFMS2 hates TS; writing our own TS parsing library and supporting that format properly is on the todo list but nobody I know including myself has time to work on it right now.

[hwti]

That's a known bug. FFMS2 hates TS; writing our own TS parsing library and supporting that format properly is on the todo list but nobody I know including myself has time to work on it right now.

But it is the same when converted to MKV (which plays correctly in MHC-HC and WMP12 with Haali Media Splitter, and MPC-HC internal source).

[TheFluff]

The field duplication issue is because of a libavcodec quirk with interlaced h264; it decodes each field into its own frame.

[ganymede]

http://mod16.org/ffms2/ffms2-r408.7zI tried this version under linux/wine. It works well with H.264 and mpeg2 video, but cannot decode ffvhuff codec (tried avi and mov containers). It returns an error message : "No video stream found". Current stable version of ffms2 (2.14 vanilla) can decode the same files without problem.

[torwart]

I have one question about ffmpegsource2. Which is the best wrapper for it. I want to make a fake avi using this ffmpeg2.
sorry for my bad english. :thanks:

[LoRd_MuldeR]

I have one question about ffmpegsource2. Which is the best wrapper for it. I want to make a fake avi using this ffmpeg2.
sorry for my bad english. :thanks:

What exactly do you mean? FFmpegSource2 already is a wrapper to make libavcodec/libavformat available as source filter in Avisynth.

(Actually the Avisynth plug-in is yet another wrapper around the FFmpegSource2 core library. Applications, like x264, can use the FFmpegSource2 library directly)

[torwart]

for example: I have an avi file(divx) and I want to open it in Edius, Vegas or Premiere Pro in uncompressed. I write a script for avisinth(ffvideosource("C:\avifile")). now I can import this script in virtual dub, but how can I make a fake avi to open it in this big programms like Premiere Pro. I tried makeavis and vfapi , but it didn't work.

[LoRd_MuldeR]

So your question is NOT specific to FFmpegSource2. You want to know how you can open Avisynth scripts in the aformentioned applications.

I think this can not be answered in general, but at least for Premiere Pro a plug-in exists:
http://urchin.earth.li/~tomford/avisynth/

See also:
http://forum.doom9.org/showthread.php?t=47194

[cretindesalpes]

but how can I make a fake avi to open it in this big programms like Premiere Pro. I tried makeavis and vfapi , but it didn't work.

Do you mean this (http://forum.doom9.org/showthread.php?t=133313)?

[torwart]

Thank you gyes for you answers. I think I'll find the information that I need in links,that you gave me.

[torwart]

AVFS is wrapper number 1 !!!!! Thank you once more!!!!!!!!!! :thanks:

[TheRyuu]

ffms2-mt-r411.7z (http://ffmpegsource.googlecode.com/files/ffms2-mt-r411.7z)
ffms2-mt-r412-avs64-2.7z (http://ffmpegsource.googlecode.com/files/ffms2-mt-r412-avs64-2.7z)

For avs64 (for use with 64bit avisynth) be sure to load with LoadCPlugin.

Edit: Uploaded fixed avs64 version.

[burfadel]

The 411 build from the link about doesn't seem to work properly for xvid AVI's, whereas the 408 build and earlier has no issues. I tried 411 with a mkv x264 file I did earlier and it worked fine, so it seems its only 411. The encoding crashed pretty quickly, and if I quickly jump quickly back and forth through staxrip's preview with 411 it ends up crashing too...

[Maccara]

I tried this version under linux/wine. It works well with H.264 and mpeg2 video, but cannot decode ffvhuff codec (tried avi and mov containers). It returns an error message : "No video stream found". Current stable version of ffms2 (2.14 vanilla) can decode the same files without problem.

Hmm. I got this same issue with x264 ffms decoding mkv (muxed with ffmpeg) containing vmw streams (x264 --demuxer lavf was fine). Indexing seemed to start ok but failed with that "no video stream found" immediately after encoding was supposed to start.

Versions were ffmpegsource svn trunk + ffmpeg svn trunk + x264 git trunk built on Jan 11.

I need to try if I can still replicate this.

[burfadel]

Neither the FFmpegsouce build 411 and the new 423 build work correctly, once indexed and the video loads, it crashes. I'm using Staxrip, and yes I did do everything correctly!!! This is with multiple source files, with no exisiting index files etc.

Sticking with 408 for now.

[TheFluff]

I tried this version under linux/wine. It works well with H.264 and mpeg2 video, but cannot decode ffvhuff codec (tried avi and mov containers). It returns an error message : "No video stream found". Current stable version of ffms2 (2.14 vanilla) can decode the same files without problem.

I'll take a look.

Neither the FFmpegsouce build 411 and the new 423 build work correctly, once indexed and the video loads, it crashes. I'm using Staxrip, and yes I did do everything correctly!!! This is with multiple source files, with no exisiting index files etc.

Sticking with 408 for now.

A lot of users (well, like three or four) are reporting crashing issues with TheRyuu's -mt builds, so I think he needs to fix his shit.

[burfadel]

Ah ok! Are they the builds on code.google.com/p/ffmpegsource ? They're the ones I were having issues with.

Are there other sites that keep the builds up to date? I was thinlking a weekly build wouldn't be a bad thing... i realise ffmpegsource2.14 is technically the latest release version, but that is quite old. At least with the weekly version, if anyone encounters an unknown problem it can be reported and listed quicker, and they can go back to using the previous weeks build (which isn't several months old)...

[TheFluff]

I tried this version under linux/wine. It works well with H.264 and mpeg2 video, but cannot decode ffvhuff codec (tried avi and mov containers). It returns an error message : "No video stream found". Current stable version of ffms2 (2.14 vanilla) can decode the same files without problem.

I can't reproduce this with my current build on some of my own ffvhuff files, so I guess it's been fixed (possibly in r410). If it still doesn't work for you, give me a small (10-20mb or so is enough) sample that fails for you.

Ah ok! Are they the builds on code.google.com/p/ffmpegsource ? They're the ones I were having issues with.

Are there other sites that keep the builds up to date? I was thinlking a weekly build wouldn't be a bad thing... i realise ffmpegsource2.14 is technically the latest release version, but that is quite old. At least with the weekly version, if anyone encounters an unknown problem it can be reported and listed quicker, and they can go back to using the previous weeks build (which isn't several months old)...

All -mt builds, and also all non-release builds on the googlecode page are TheRyuu's.

I'm actually planning to release 2.15 quite soon. Have a test build (vanilla ffmpeg as usual): http://mod16.org/ffms2/ffms2-r426.7z

Changes since 2.14:

FFMS2 can now be used to decode Lagarith, but note that libavcodec's decoder is very experimental at the moment. (Plorkyeran)
SWScale can now use SSE2 optimizations for certain operations if your CPU supports it. (kemuri_-9)
Fixed a bug that could cause SWScale initialization to fail. (kemuri_-9)
Fixed a bug that could cause index files to never be considered valid, forcing a reindexing every time a script was loaded. (TheRyuu)
Trying to use postprocessing on a fullrange YUV clip will no longer cause errors. (TheFluff)
Fixed a few random decoding bugs related to unaligned memory or buffers that were not initialized properly. (TheFluff)
It is now possible to force FFMS2 to use a specific demuxer instead of letting it pick one automatically. (TheFluff)
When converting YUV to RGB, FFMS2 will now try to actually use the correct color coefficients rather than assuming everything is bt470bg. (Plorkyeran)
Moved support for container-level audio delay from the Avisynth plugin to the core and exposed it in the API (Plorkyeran)
Audio decoding has been substantially reworked. Linearly decoding audio now almost always works correctly and seeking is now actually sample-accurate for many formats. (Plorkyeran)
It is now possible to build 64bit versions of the plugin for use with Avisynth (and whatever else) from MSVC by means of black magic (this probably only works when the planets are aligned, also 64bit builds might require msvcr90.dll). (TheRyuu)
The Avisynth plugin now supports UTF8 filenames; ffmsindex.exe also supports Unicode filenames. FFMS_USE_UTF8_PATHS is now a runtime option instead of a compile-time one. (TheFluff)
The FFInfo() function (supplied by ffms2.avsi) will now round timestamps to nearest millisecond instead of truncating them. It's also been cleaned up in general and no longer relies on global variables. (Gavino)
Containers opened with libavformat will now report a framerate based on the average frame duration instead of the duration of the first frame, just like Matroska files and files opened with Haali's splitter does. Should fix CFR framerates being reported incorrectly in dumb containers like FLV. (TheFluff)
PC/TV luma range (16-235 versus 0-255) detection should now be a bit more reliable. (TheFluff)
Fixed a crash when opening files with Unicode filename support enabled. (Plorkyeran)


Quite a few regressions in earlier test builds have also been fixed.

To force a demuxer, use demuxer="lavf" as an argument to ffindex(). Possible choices are lavf, matroska, haalimpeg and haaliogg.

[TheRyuu]

I've poked the ffmpeg-mt dev about the issue, apparently there may have also been some talk in #ffmpeg-devel about it although I don't know the details.

So I'm trying to figure out what the issue is with my ffmpeg-mt builds, vanilla builds (even mine) do not seem affected so they should be safe for the time being albeit a little slower on things like h264. :p

[burfadel]

Thanks, 426 works well :)

[ganymede]

I tried this version under linux/wine. It works well with H.264 and mpeg2 video, but cannot decode ffvhuff codec (tried avi and mov containers). It returns an error message : "No video stream found". Current stable version of ffms2 (2.14 vanilla) can decode the same files without problem.
I can't reproduce this with my current build on some of my own ffvhuff files, so I guess it's been fixed (possibly in r410). If it still doesn't work for you, give me a small (10-20mb or so is enough) sample that fails for you.
The problem is now fixed with your latest revision (r426). Thank you very much.

[sneaker_ger]

This sample (http://www.mediafire.com/?v2benur48ewkor0) gets very jerky if I specify fpsnum=24000 and fpsden=1001 using r426.

[TheRyuu]

This sample (http://www.mediafire.com/?v2benur48ewkor0) gets very jerky if I specify fpsnum=24000 and fpsden=1001 using r426.

Although the behavior probably isn't what we want (and I guess should be fixed), specifying fpsnum/fpsden is meant for vfr->cfr conversions. As far as I can tell the sample is purely cfr and you don't get the jerkiness if you don't specify the fpsnum/fpsden.

Also made a few builds while doom9 was down for a bit. I rolled back ffmpeg-mt to a December version which fixes the two issues people were having with it (I believe the issues have been addressed in the ffmpeg-mt src).

ffms2-mt-r430.7z (http://ffmpegsource.googlecode.com/files/ffms2-mt-r430.7z)
ffms2-mt-r430-avs64.7z (http://ffmpegsource.googlecode.com/files/ffms2-mt-r430-avs64.7z)

Some vanilla ffmpeg builds if you want them (dunno why):
ffms2-r430.7z (http://ffmpegsource.googlecode.com/files/ffms2-r430.7z)
ffms2-r430-avs64.7z (http://ffmpegsource.googlecode.com/files/ffms2-r430-avs64.7z)

[sneaker_ger]

Although the behavior probably isn't what we want (and I guess should be fixed), specifying fpsnum/fpsden is meant for vfr->cfr conversions. As far as I can tell the sample is purely cfr and you don't get the jerkiness if you don't specify the fpsnum/fpsden.

But if it already fails on CFR content, why would it suddenly work fine on VFR content? Shouldn't both be affected in exactly the same way?

2.14 and r375 work fine, problem appears with 411 for the first time. (all mt)

[TheFluff]

But if it already fails on CFR content, why would it suddenly work fine on VFR content? Shouldn't both be affected in exactly the same way?

2.14 and r375 work fine, problem appears with 411 for the first time. (all mt)

You should've said it was a regression earlier. I was going to have a look at it anyway but now it suddenly became a lot more important.

e: pretty sure Plorkyeran broke it in r385 (http://code.google.com/p/ffmpegsource/source/detail?r=385).

[sneaker_ger]

Yes, my fault.

[TheRyuu]

But if it already fails on CFR content, why would it suddenly work fine on VFR content? Shouldn't both be affected in exactly the same way?

2.14 and r375 work fine, problem appears with 411 for the first time. (all mt)

Status update, it was indeed broken in r385 as fluff said (ffmpeg-mt had nothing to do with it).

[Plorkyeran]

Fixed in r432.

[TheFluff]

FFMS 2.15 is now released; you can grab it from the Google Code page (http://code.google.com/p/ffmpegsource/).

Changes since 2.14:

FFVideoSource and FFAudioSource will now automatically reindex and overwrite the index file if it doesn't match the file being opened and the <tt>cachefile</tt> argument is left as the default. (Plorkyeran)
FFMS2 can now be used to decode Lagarith, but note that libavcodec's decoder is very experimental at the moment. (Plorkyeran)
SWScale can now use SSE2 optimizations for certain operations if your CPU supports it. (kemuri_-9)
Fixed a bug that could cause SWScale initialization to fail. (kemuri_-9)
Fixed a bug that could cause index files to never be considered valid, forcing a reindexing every time a script was loaded. (TheRyuu)
Trying to use postprocessing on a fullrange YUV clip will no longer cause errors. (TheFluff)
Fixed a few random decoding bugs related to unaligned memory or buffers that were not initialized properly. (TheFluff)
It is now possible to force FFMS2 to use a specific demuxer instead of letting it pick one automatically. (TheFluff)
When converting YUV to RGB, FFMS2 will now try to actually use the correct color coefficients rather than assuming everything is bt470bg. (Plorkyeran)
Moved support for container-level audio delay from the Avisynth plugin to the core and exposed it in the API (Plorkyeran)
Audio decoding has been substantially reworked. Linearly decoding audio now almost always works correctly and seeking is now actually sample-accurate for many formats. (Plorkyeran)
It is now possible to build 64bit versions of the plugin for use with Avisynth (and whatever else) from MSVC by means of black magic (this probably only works when the planets are aligned, also 64bit builds might require msvcr90.dll). (TheRyuu)
The Avisynth plugin now supports UTF8 filenames; ffmsindex.exe also supports Unicode filenames. FFMS_USE_UTF8_PATHS is now a runtime option instead of a compile-time one. (TheFluff)
The FFInfo() function (supplied by ffms2.avsi) will now round timestamps to nearest millisecond instead of truncating them. It's also been cleaned up in general and no longer relies on global variables. (Gavino)
Containers opened with libavformat will now report a framerate based on the average frame duration instead of the duration of the first frame, just like Matroska files and files opened with Haali's splitter does. Should fix CFR framerates being reported incorrectly in dumb containers like FLV. (TheFluff)
PC/TV luma range (16-235 versus 0-255) detection should now be a bit more reliable. (TheFluff)
Fixed a crash when opening files with Unicode filename support enabled. (Plorkyeran)


I've updated the Avisynth plugin documentation a bit; it should be easier to read and understand now. I've also updated the known issues part of it, so all actual known issues are listed there now. If you find a problem that isn't listed there, please report it, regardless of what I or other people have said or claimed about it in the past.

Edit: ATTN the three of you who downloaded this before 00:35 GMT: your version doesn't handle zlib compressed streams in MKV correctly. Redownload it to fix the issue.

[b66pak]

thanks a lot...
_

[Maccara]

Thanks for the update!

Edit: ATTN the three of you who downloaded this before 00:35 GMT: your version doesn't handle zlib compressed streams in MKV correctly. Redownload it to fix the issue.

FYI, from the "last minute" fixes (SVN 444), probably not intended: :)

src/core/utils.cpp: In function 'void safe_aligned_reallocz(T*&, size_t, size_t)':
src/core/utils.cpp:233: error: there are no arguments to 'min' that depend on a template parameter, so a declaration of 'min' must be available
src/core/utils.cpp:233: note: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated)
src/core/utils.cpp: In function 'void safe_aligned_reallocz(T*&, size_t, size_t) [with T = uint8_t]':
src/core/utils.cpp:262: instantiated from here
src/core/utils.cpp:233: error: 'min' was not declared in this scope

(on mingw gcc 4.4.5)

[burfadel]

What FFMPEG revision is FFMS 2.15 based on? for both the normal and MT version of FFMS?

Thanks

[TheRyuu]

What FFMPEG revision is FFMS 2.15 based on? for both the normal and MT version of FFMS?

Thanks

ffmpeg-mt uses the Dec. 15th update (http://gitorious.org/ffmpeg/ffmpeg-mt/commit/2bbb64dae018cbb09ea47a6bdcb184f551136c26) (basically the last one that nothing breaked on).

The vanilla ffmpeg builds I would imagine use whatever was the last revision before the files were posted.

[burfadel]

Ah ok! well, 2 months for FFMPEG = lots of changes, I think I'll use the standard one! Multithreaded ffms doesn't really affect me, I usually encode 2 videos at once which equals 100 percent CPU usage, speed wise its not noticeable since Staxrip defaults x264 etc to the lowest priority. Parallel encoding files seems more effective than multithreading, since there are still stages in the pipeline that are slowed down either by processing requirements or being unoptimised and/or single threaded.

[TheFluff]

Thanks for the update!



FYI, from the "last minute" fixes (SVN 444), probably not intended: :)

src/core/utils.cpp: In function 'void safe_aligned_reallocz(T*&, size_t, size_t)':
src/core/utils.cpp:233: error: there are no arguments to 'min' that depend on a template parameter, so a declaration of 'min' must be available
src/core/utils.cpp:233: note: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated)
src/core/utils.cpp: In function 'void safe_aligned_reallocz(T*&, size_t, size_t) [with T = uint8_t]':
src/core/utils.cpp:262: instantiated from here
src/core/utils.cpp:233: error: 'min' was not declared in this scope

(on mingw gcc 4.4.5)

Fixed, I think.

[sneaker_ger]

Setting fpsnum and fpsden seems to work correctly now.

[Maccara]

Fixed, I think.

Yeah, that works. Thanks!

[b66pak]

@TheFluff does this improvements go to x264's ffms too? (especially the timebase/timescale fix)...may be in the next release?
_

[TheFluff]

That depends on who compiles x264 and what version of FFMS they're linking against. JEEB usually uses the SVN HEAD so in his builds the changes should have been in for a long time, but I dunno about anyone else.

[b66pak]

it looks like everybody (JEEB, Komisar, X5-452) still use FFMS2 2.14.2 (svn-432)...x264.nl is using svn-431...
_

[b66pak]

@TheFluff x264.nl is using now "2011-02-19 00:59:01 SVN: ffmpegsource revision 448" but timescale/timebase is still returning HUGE values...can you investigate?

source:
Seems stream 0 codec frame rate differs from container frame rate: 47.95 (20000000/417083) -> 23.98 (20000000/834166)

x264 info:
[21:56:09.312] ffms [info]: 1280x720p 1:1 @ 24000/1001 fps (vfr)

resulting mp4 (x264 gpac muxer):
Track # 1 Info - TrackID 1 - TimeScale 1000000000

if i use ffmpegsource-2.15 for indexing i get the correct timescale/timebase 24000/1001...
_

[TheFluff]

@TheFluff x264.nl is using now "2011-02-19 00:59:01 SVN: ffmpegsource revision 448" but timescale/timebase is still returning HUGE values...can you investigate?

source:
Seems stream 0 codec frame rate differs from container frame rate: 47.95 (20000000/417083) -> 23.98 (20000000/834166)

x264 info:
[21:56:09.312] ffms [info]: 1280x720p 1:1 @ 24000/1001 fps (vfr)

resulting mp4 (x264 gpac muxer):
Track # 1 Info - TrackID 1 - TimeScale 1000000000

if i use ffmpegsource-2.15 for indexing i get the correct timescale/timebase 24000/1001...
_

I don't understand what you're saying at all nor what the problem is nor if it's likely that it's a problem in ffms2 or not. What is "source" and where is it printing that message? It looks like ffmpeg, but who knows? What do you mean by "if I use ffmpegsource-2.15 for indexing"?

Also, how about a sample file?

[b66pak]

"source" is the source file: a mkv with a near 24000/1001 fps encoded using directshowsource...see this (http://forum.doom9.org/showthread.php?p=1476069#post1476069) for more info...
the report is from ffmpeg: it outline the timescale/timebase of the "source"...

if i use your latest fmpegsource-2.15 to index the "source" and make an avs and feed it to the latest x264.nl build i get a corrected timescale/timebase witch is very good! (20000000/834166 > 24000/1001)...

the question is why can't x264 do the same if its using the latest ffms? can you investigate?
_

[TheFluff]

"source" is the source file: a mkv with a near 24000/1001 fps encoded using directshowsource...see this (http://forum.doom9.org/showthread.php?p=1476069#post1476069) for more info...
the report is from ffmpeg: it outline the timescale/timebase of the "source"...

if i use your latest fmpegsource-2.15 to index the "source" and make an avs and feed it to the latest x264.nl build i get a corrected timescale/timebase witch is very good! (20000000/834166 > 24000/1001)...

the question is why can't x264 do the same if its using the latest ffms? can you investigate?
_

I haven't looked at the file at all but judging from the description it seems pretty simple. There is no such thing as a CFR Matroska file; there is no real "timebase" in the container, and no container-level framerate either. All frames have timestamps in wallclock nanoseconds (by default; you can change the precision/timecode scale at mux-time if you want to). Hence FFMS2 reports the timebase for MKV's as 1/1000000 or something silly like that (assuming the default timecode scale) because pretty much what it is.

In order to get a "constant" framerate for MKV files that can be reported to things that aren't VFR-aware (like Avisynth), FFMS2 calculates a framerate based on the average frame duration, and then checks if it's "close enough" to a well-known NTSC fraction, and if it is, the otherwise huge fractional value gets corrected to the usual 24000/1001 or 30000/1001.

In this case, as you can see from what x264 says about the framerate, the behavior described above was triggered and the reported "constant" framerate is 24000/1001 (note how x264 says "vfr"; it knows the reported framerate may be complete bogus). The timebase is still 1000000/1, though, and apparently x264 decided to stick with that and pass it through to its MP4 muxer, since it cannot know if there are uneven frame durations or not.

The reason you get a timebase of 24000/1001 when doing it via Avisynth is that Avisynth doesn't store a separate timebase value at all; since it only supports CFR, all frames have the same duration and there's no reason to have a separate timebase. In other words, the framerate is the same as the timebase and the frame number is functionally equivalent with a PTS. x264 never sees the original timebase from the MKV at all when using Avisynth input.

If you know and can GUARANTEE that your source is CFR, you can always force a timebase in one way or another, but if you cannot, the only really correct way to handle it is to keep the original timebase. You could also write some more or less complex algorithm that inspects all frame durations, determines the smallest possible timebase and then converts all timestamps to that, but that will probably cause all sorts of other interesting issues later down the chain instead.


I hope you're sufficiently confused, since you did ask for it. What I'd really like to know though is what real-world problems this issue causes you.

[b66pak]

thank you for the explanation...the problem is that mp4 files with huge timescale/timebase can't be played on any device other than PCs (QTime excluded) and NMTs...
_

[b66pak]

here (http://www.mediafire.com/?dqr1ff7abcj8b8j) is a small sample...

on the same "source" mkv i forced the lavf demuxer (instead of ffms - default) and i get a more friendly timescale:
Track # 1 Info - TrackID 1 - TimeScale 1000

now i and really confused...ffms+x264 = big timescale in mp4...lavf+x264 = normal timescale in mp4...
_

[TheFluff]

I have no idea what x264 does or does not do with the lavf demuxer or what lavf might do internally with regards to the timebase of Matroska files. FFMS2 does not use lavf for Matroska.

[b66pak]

kenuri-_9 posted an explanation here (http://forum.doom9.org/showthread.php?p=1479790#post1479790):
_

[lintran]

I got problem with both 2.15 vanila and mt version when index this file (http://wdmp.rd.llnwd.net/wdsmp/IAN4/USExtLook/IANF_USExtLook_1080.mov).
My avs script
----------------------------------------------------------
LoadPlugin("D:\ffmpegsource-2.15\ffms2.dll")
FFVideoSource("D:\thisfile.mov",fpsnum=24000,fpsden=1001)
----------------------------------------------------------
When play .avs by MPC, it was broken when video nearly end.
But everything OK when using 2.14 version.
Could you please figure it out?
Thank you.

[TheFluff]

fpsnum and fpsden are broken in 2.15. They have been fixed in SVN, and I'll probably do a 2.15.1 release to fix them, but until then you can either a) not use them, b) downgrade to 2.14, or c) find someone to compile a SVN version for you.

[lintran]

fpsnum and fpsden are broken in 2.15. They have been fixed in SVN, and I'll probably do a 2.15.1 release to fix them, but until then you can either a) not use them, b) downgrade to 2.14, or c) find someone to compile a SVN version for you.
Thank you. But do you mean fpsnum and fpsden are always broken in 2.15 or sometime or in some special cases?
Because it only broken with that file that i posted. I tried to test with many other h264 in.mov files (like Apple Trailers), everything are OK. So is it still safe to use?

[TheFluff]

Thank you. But do you mean fpsnum and fpsden are always broken in 2.15 or sometime or in some special cases?
Because it only broken with that file that i posted. I tried to test with many other h264 in.mov files (like Apple Trailers), everything are OK. So is it still safe to use?

By broken I mean "it may crash near the end of the video". If it doesn't crash, the output should be fine. See http://code.google.com/p/ffmpegsource/issues/detail?id=41

[henryho_hk]

Can I .....
1) enable "Always skip in-loop H.264 deblocking" as in ffdshow?
2) control the number of threads in the ffmpeg-mt version"?

And the 2.15 version seems to parse/decode VC-1 m2ts files incorrectly (BBC Life Bluray Disc 1's 00026.m2ts which is a clip about color tuning). When I jump to frame 1917, the ffmpeg-mt version (both 32 and 64 bit) shows a grey frame followed by a few corrupted frames... and the vanilla ffmpeg version shows a non-corrupted frame, but of a wrong frame number. If I demux the m2ts file to VC1, both mt and non-mt versions seem to work fine.

[TheFluff]

Can I .....
1) enable "Always skip in-loop H.264 deblocking" as in ffdshow?
2) control the number of threads in the ffmpeg-mt version"?

And the 2.15 version seems to parse/decode VC-1 m2ts files incorrectly (BBC Life Bluray Disc 1's 00026.m2ts which is a clip about color tuning). When I jump to frame 1917, the ffmpeg-mt version (both 32 and 64 bit) shows a grey frame followed by a few corrupted frames... and the vanilla ffmpeg version shows a non-corrupted frame, but of a wrong frame number. If I demux the m2ts file to VC1, both mt and non-mt versions seem to work fine.

1) Not at the moment. Noted as a feature request, though. (edit: why do you want to do this anyway?)
2) Yes, use the "threads" parameter to ffvideosource().

As for the m2ts stuff: do you have Haali's media splitter installed? The issue you describe sounds suspiciously like you're trying to seek in a ts with libavformat's demuxer (don't do that unless you've set seekmode=-1 first, or it'll end in tears). In general, ffms2's support for ts/m2ts is pretty poor; you'll get better results if you remux the file to mkv with eac3to or gdsmux first.

[henryho_hk]

1) coz some BD bitrates are so high that there is little need to do any deblock.... and I want to save the CPU for other stuffs.
2) thanks.

m2ts .... I have Haali's splitter installed and so dss2() works (too bad that they dun make any x64 version). I do expect issues from libavf's demuxer but not MT and non-MT versions behaving differently.

[TheFluff]

1) coz some BD bitrates are so high that there is little need to do any deblock.... and I want to save the CPU for other stuffs.
2) thanks.

m2ts .... I have Haali's splitter installed and so dss2() works (too bad that they dun make any x64 version). I do expect issues from libavf's demuxer but not MT and non-MT versions behaving differently.

If the bitrate is so high that there's no need to deblock the deblocking filter will actually not get used, so there's not really any significant amount of CPU power to save here.

The MT issues may be ffmpeg or it may be something else, it is a mystery. I don't build it myself so I won't debug it for you. If you upload a small sample where seeking isn't frameaccurate with the vanilla ffmpeg I'll take a look, though.

[TheRyuu]

ffms2-mt-r452.7z (http://ffmpegsource.googlecode.com/files/ffms2-mt-r452.7z)
ffms2-mt-r452-avs64.7z (http://ffmpegsource.googlecode.com/files/ffms2-mt-r452-avs64.7z)

There was a rather large merge a few days ago that brings ffmpeg-mt up to date (first one since 12/2010 I believe). And I guess ffmpegsource got a fix or two since 2.15.

Edit: Added avs64 build.

[zys4416]

Could anyone answer the #987 (http://forum.doom9.org/showpost.php?p=1462468&postcount=987) question? Because I get the same problem now. Thanks a lot!

[kemuri-_9]

FFMS2 does output I420 and not YV12.
megui sucks at handling this, use something else.

I could spit out techno babble here about how the difference between the two doesn't matter (which it doesn't for everything except the VFW interface),
but that won't change the issue that megui doesn't handle it well.

[zys4416]

I see. Would there by any problem if I ignore megui's warning, avoid adding CoverToYV12() to the end of the script and start encoding after that?
Thx again!

[kemuri-_9]

I see. Would there by any problem if I ignore megui's warning, avoid adding CoverToYV12() to the end of the script and start encoding after that?
Thx again!

It's been a long while since i looked at ConvertToYV12(), but last i remember it did nothing if the input was I420 or YV12.
this might've changed in 2.6, i'll have to check later...

x264cli will work for sure (As it uses avisynth directly rather than the vfw interface)

not sure about xvid's cli as i am not aware of how it reads .avs files.

and i don't recall what other video encoders megui uses these days, so can't say anything about any other possible ones.

[zys4416]

The encoder megui usually uses is Mencoder, at least for the version 0.3.4 i'm using.

[kemuri-_9]

The encoder megui usually uses is Mencoder, at least for the version 0.3.4 i'm using.

i don't recall megui ever using mencoder, so i grabbed a package off of sf.net (which ended up being newer than 0.3.5.30 as that's what's last listed before svn revisions are used instead) and mencoder is not there either.
i found x264cli and a fairly outdated xvid_encraw though.

there's notes in the changelog about
* 1895 [Snow] replaced mencoder with ffmpeg
* 1894 [pre-rendering job] replaced mencoder with ffmpeg for MeGUI x86
so that it seems at one point mencoder was actually used, but ffmpeg is now used instead of mencoder for pre-rendering and snow output.

anyway,
as i said before, x264cli uses avisynth directly and has no problems with I420 input.
xvid_encraw uses vfw, but had no issues with encoding from a ffms2 loaded file (I420) it seems, though i have avs 2.6 and i'm not sure if that makes a difference...
ffmpeg also uses vfw.
and I don't know about mencoder, but a hunch says it also uses vfw.

[Zathor]

Could anyone answer the #987 (http://forum.doom9.org/showpost.php?p=1462468&postcount=987) question? Because I get the same problem now. Thanks a lot!
Please update to a recent MeGUI build as this problem has been fixed a while ago. If even with a recent build (1989 or above) the problem appears please post you complete log in order to fix it. But please post it here: http://forum.doom9.org/showthread.php?t=151159

[zys4416]

Thank you all for your help, the problem is solved after i updated megui.
x264cli is good stuff, I usually use that directly on linux. However I do prefer gui on windows.

[TheFluff]

This same issue was discussed 30 pages and two years back, see http://forum.doom9.org/showthread.php?p=1283724#post1283724 for the dramatic conclusion. (tl;dr: what everyone calls YV12 is actually I420; MeGUI authors didn't know this and tried to ConvertToYV12() when this will in fact be a no-op since the video already is YV12; ancient versions of MeGUI would happily go into an infinite ConvertToYV12() loop. Use something that isn't MeGUI if you have to use a GUI. Or you could just update it, I guess, but I personally try to discourage people from using MeGUI.)

[burfadel]

Any chance of a non MT r459, utilising the latest ffmpeg?

The r459-MT works for me, but ONLY when doing a single encode. If I try to encode 2 different things at once the second one fails trying to write to protected memory (so Staxrip complains). At least I can have one instance running, which is better than r452-MT which didn't work at all.

The non MT version for me isn't really any slower, and in fact since I can't do two different encodes simulatenously with the MT version its actually noticeably slower overall!

To encode two things at once, I add them all the the queue list in staxrip, select every second item in the queue in one instance, and in another instance of staxrip select the opoosite every second item. The two lists don't interfere with each other which is good, however if you stop both of them and reload, only the last list will show so you have to resort them.

Anways, can you look into this? obviously the MT version is calling for the same address space in the second instance, which is not an issue with the non-MT one. Believe me, running two encodes simultaneously is the perfect choice for multithreading, regardless of house much you try and mutlithread the source filters and avisynth filters, its the ideal way to get 100 percent CPU usage. It probably gets both encodes done 15 percent quicker than doing each one individually?... (even with MT).

[burfadel]

On a separate note, I do appreciate FFmpegsource, its my favourite source filter :)

I was wondering whether mpeg2 support could be improved. It works fine, however it can be very slow when cutting adverts out of a 2 hr movie. Some parts of the mpeg2 support is really quick, but other parts have this slowdown. I really want to get off the mpeg2source filter. Not that I don't like the mpeg2source filter, but it is not updated anymore and the actual decoder it uses is ancient.

[TheFluff]

On a separate note, I do appreciate FFmpegsource, its my favourite source filter :)

I was wondering whether mpeg2 support could be improved. It works fine, however it can be very slow when cutting adverts out of a 2 hr movie. Some parts of the mpeg2 support is really quick, but other parts have this slowdown. I really want to get off the mpeg2source filter. Not that I don't like the mpeg2source filter, but it is not updated anymore and the actual decoder it uses is ancient.

What container are we looking at?

[TheFluff]

http://mod16.org/ffms2/ffms2-r460.7z

Compiled with libav from just now. Not tested so I have no idea if it actually works. There have been no significant user-visible changes since 2.15.

[burfadel]

What container are we looking at?

.m2v, as output from ProjectX 0.90.04.00.b32 from 31.10.2009 (from oozoon.de)

Thanks for the r460 as well, it seems to be working perfectly! The above slugginess issue is still there though when dealing with .m2v files. I tried a 720x576 30 min file and it was really quick (as expected), quicker than using mpeg2source (dginex). A 1440x1080 30 min recording was very fast, you can trigger it to be very sluggish or even seeming by it by moving the preview back and forth a little! It usually pauses when you first try and navigate through the file. At a completely uneducated guess, is it because its dealing with a completely unindex file? - the same reason why dgindex was used in the first place on these files, unlike sourcing from say, an mkv or .avi file?

The problem is frequent enough for me not to use it for .m2v files, but they're the only ones affected.

This is on Windows 7 SP1 kernel 7601.21701.amd64fre.win7sp1_ldr.110408-1634 (had it before with Windows 7 RTM though), Q9400 processor. This occurs on any opening of the .m2v files, regardless of whether there are other encodes running or not. I also tried it on another friends computer (similar specs though) and it had the same results.

[burfadel]

Just curious, any news on this in regards to multiple instances of ffms-mt?

I should point out I am using Avisynth 2.60 non-MT AviSynth_260_110418_MSVC2010.exe from http://xhmikosr.1f0.de/

Of course, I could always just use the Avisynth-MT and ffms-MT, but I can safely say that doing 2 encodes in parallel is much faster! (this is relative to filters used and current per-encode cpu use), and having it set to low priority means you don't even notice it running computer performance wise, even if the CPU is running at 100 percent. With more cores I can only imagine this being even more noticeable.

[TheRyuu]

Just curious, any news on this in regards to multiple instances of ffms-mt?

What happens when you manually set the threads=1 or half your cores for each script?

[burfadel]

It appears to be working now, I've encoded a fwe things (in parallel) and left it running. Strange!

I have also been torrenting, recording stuff off tv and watching some stuff, and everything is working like it should (like it usually does). I don't know why it wasn't working before and is now, its probably a case of 'in the scenario of having...', in other words something which only shows when certain conditions are met.

[burfadel]

Ok, been encoding all this time, and started it before my last post. Its only now that it caused a crash that it was trying to write to write protected memory.

It occurs when one instance of encoding (using x264) is being undertaken, and the second instance starts to encode. It worked quite well for several instances changes, so its a bit hard to track down...

[sumawo13]

Can someone explain to me why indexing only uses 1-2% CPU? It takes 10-15 minutes to index a Blu-ray video stream remuxed from M2TS to MKV, and then when I load my script in VirtualDub, it takes another 6 minutes for the script to open, all the while VirtualDub using about 1-2% CPU, it does this everytime I load the script, even if I specifiy the index file directly in the script.

[LoRd_MuldeR]

Can someone explain to me why indexing only uses 1-2% CPU? It takes 10-15 minutes to index a Blu-ray video stream remuxed from M2TS to MKV, and then when I load my script in VirtualDub, it takes another 6 minutes for the script to open, all the while VirtualDub using about 1-2% CPU, it does this everytime I load the script, even if I specifiy the index file directly in the script.

Because the indexing process obviously is I/O-limited and not CPU-limited. A faster CPU doesn't help, if the program is idle, waiting for the HDD, most of the time ;)

[TheRyuu]

Can someone explain to me why indexing only uses 1-2% CPU? It takes 10-15 minutes to index a Blu-ray video stream remuxed from M2TS to MKV, and then when I load my script in VirtualDub, it takes another 6 minutes for the script to open, all the while VirtualDub using about 1-2% CPU, it does this everytime I load the script, even if I specifiy the index file directly in the script.

It should not have to index the same file twice, make sure your ffmsindex is using the same ffms2.dll file (they come together in the 7z for a reason) that you're loading with your LoadPlugin() line, otherwise the versions won't match in the ffindex file and it'll remake the index anyway.

Some of the older versions had a bug that would have them reindex files even if the index file already existed (although I'm pretty sure it only affected m2ts or something like that) so you should be fine but update to the latest anyway.

[sneaker_ger]

Is there any reason to index a file manually beforehand in the first place? Despite buggy programs hanging up on loading the script due to the long wait.

[TheRyuu]

Is there any reason to index a file manually beforehand in the first place? Despite buggy programs hanging up on loading the script due to the long wait.

If you want to see the progress I guess. I find it more useful on bigger files like lossless h264 or BD material where I don't want to blindly wait 5-10 minutes.

[sneaker_ger]

I see. Just wondered as to why people were doing it manually.

[Rumbah]

If I'm converting a Bluray to PSP or DivX avi I have to write an avs file and look through the subtitles. While I'm busy there I'm running the index process.

[henryho_hk]

It seems ffindex() from r259-x64 is re-indexing MKV files unnecessarily. I mux a H264 MKV from a M2TS using eac3to. The AVS script is simply:

ffindex("abc.mkv")
ffvideosource("abc.mkv")

If I open the AVS script in VirtualDub x86, the index file is created once and re-used when opened subsequently. But when opened in VirtualDub x64, the index file is overwritten every time. Does anyone have similar experience?

[kypec]

I have never ever used ffindex() in AVS script, what is the point of doing so?
Though I don't have deep knowledge how ffindex() inside Avisynth works I'd assume that what you are experiencing in VD x64 is probably correct behaviour in this case.
My assumption is based on the following:
ffvideosource() is clever enough to create (when used for non-indexed material yet) the index automatically and will re-use that index as long as the source didn't change.
Calling ffindex() explicitly OTOH just does what you are asking it to do = to index the source file over and over again.

If my understanding is wrong then feel free to correct me, thanks.

[TheFluff]

It seems ffindex() from r259-x64 is re-indexing MKV files unnecessarily. I mux a H264 MKV from a M2TS using eac3to. The AVS script is simply:

ffindex("abc.mkv")
ffvideosource("abc.mkv")

If I open the AVS script in VirtualDub x86, the index file is created once and re-used when opened subsequently. But when opened in VirtualDub x64, the index file is overwritten every time. Does anyone have similar experience?

r259? That's like a year and a half old, bro. Also, you can't load avs64 in x86 virtualdub, so that's a completely different FFMS2 compile you're using there. Note that index files are not compatible between x64 and x86 compiles, even if they're the exact same revision using the exact same ffmpeg.

I have never ever used ffindex() in AVS script, what is the point of doing so?
Though I don't have deep knowledge how ffindex() inside Avisynth works I'd assume that what you are experiencing in VD x64 is probably correct behaviour in this case.
My assumption is based on the following:
ffvideosource() is clever enough to create (when used for non-indexed material yet) the index automatically and will re-use that index as long as the source didn't change.
Calling ffindex() explicitly OTOH just does what you are asking it to do = to index the source file over and over again.

If my understanding is wrong then feel free to correct me, thanks.

From the documentation:

FFIndex(string source, string cachefile = source + ".ffindex", int indexmask = -1,
int dumpmask = 0, string audiofile = "%sourcefile%.%trackzn%.w64", int errorhandling = 3,
bool overwrite = false, bool utf8 = false, string demuxer = "default")
Indexes a number of tracks in a given source file and writes the index file to disk, where it can be picked up and used by FFVideoSource or FFAudioSource. Normally you do not need to call this function manually; it's invoked automatically if necessary by FFVideoSource/FFAudioSource. It does, however, give you more control over how indexing is done and it can also dump audio tracks to WAVE64 files while indexing is in progress.


So yes, unless you have some particular reasons for overriding certain default indexing behaviors, there's generally no need to use FFIndex().

FFIndex() will not overwrite an existing index file if it is considered valid, unless you explicitly pass overwrite=true as a parameter. On the other hand, if it thinks the index file isn't valid it'll be overwritten.

FFVideoSource()'s automatic indexing behavior is subtly different. From the manual again:
string cachefile = source + ".ffindex"
The filename of the index file (where the indexing data is saved). Defaults to sourcefilename.ffindex. Note that if you didn't change this parameter from its default value and FFVideoSource encounters an index file that doesn't seem to match the file it's trying to open, it will automatically reindex and then overwrite the old index file. On the other hand, if you do change it, FFVideoSource will assume you have your reasons and throw an error instead if the index doesn't match the file.

[henryho_hk]

Sorry, it's r459, not r259. Silly typo :D I've done another test.... now it's r462 and the script is simply

ffvideosource("abc.avi") # a normal 500MB AVI

I keep opening the same AVS in VirtualDub 1.9.11. When I re-open (again and again) the AVS in VD x86, it loads instantaneously and the index file (file date) is not updated. Then when I try it in VD x64, it pauses for quite a while and the index file (file date) is updated every time. If I open the AVS script in VD x86 and x64 alternately, the index file is always updated. What I observed is:

1) x64 never re-uses the index file it produces.
1) Even both are r462, x86 and x64 do not share their index files.

[kemuri-_9]

Sorry, it's r459, not r259. Silly typo :D I've done another test.... now it's r462 and the script is simply

ffvideosource("abc.avi") # a normal 500MB AVI

I keep opening the same AVS in VirtualDub 1.9.11. When I re-open (again and again) the AVS in VD x86, it loads instantaneously and the index file (file date) is not updated. Then when I try it in VD x64, it pauses for quite a while and the index file (file date) is updated every time. If I open the AVS script in VD x86 and x64 alternately, the index file is always updated. What I observed is:

1) x64 never re-uses the index file it produces.

I am unable to reproduce this issue, the 64bit plugin is using the index cache and is not reindexing every time, as you state it is.
This was tested with both ffmpeg-mt and ffmpeg vanilla.

[TheRyuu]

I wasn't able to reproduce it either.

[henryho_hk]

Would it be related to the version of AVISynth x64, OS, codecs, or media splitters installed?

[burfadel]

The issues I had regarding running two encodes simultaneously with r459 and previous builds now seems to be resolved :)

Thanks!

[TheFluff]

1) Even both are r462, x86 and x64 do not share their index files.
I just posted this in the post before yours but since you apparently didn't read it I'll just say it again:

Index files are NOT COMPATIBLE between different FFMS binaries. Generally a given index file can ONLY be used with the exact binary it was generated with.

Would it be related to the version of AVISynth x64, OS, codecs, or media splitters installed?

No.

[TheRyuu]

Index files are NOT COMPATIBLE between different FFMS binaries.

Additional checks now take place to better ensure this.
And it will recreate the index if such an incompatibility is found.

ffms2-mt-r464.7z (http://ffmpegsource.googlecode.com/files/ffms2-mt-r464.7z)
ffms2-mt-r464-avs64.7z (http://ffmpegsource.googlecode.com/files/ffms2-mt-r464-avs64.7z)

[burfadel]

The issues I had regarding running two encodes simultaneously with r459 and previous builds now seems to be resolved :)

Thanks!

The issue is still there. It depends on the source being encoded. For example, I just tried an old xvid encode with r462-mt and r464-mt, no luck! back to r460 non-MT for now...

[henryho_hk]

Installed r464 and cleaned up my plugin directory and the AVIS script. Now it works as expected. Thank you very much for your help. But it is a bit disappointed that x32 and x64 of the same revision write different index files.

BTW, I am also doing multi-process encodes. 4 parallel single/minimal-threaded pass-0 encodes are really faster (at the time being), especially on a SSD.

[burfadel]

Yeah doing multiple encodes is the way to go :) although it seems the MT version doesn't like some source files doing this (like xvid...). h.264 etc is fine.

[TheFluff]

Doing multiple encodes of different files in different script environments (i.e. different instances of the encoding program) at the same time cannot possibly affect anything. You're either getting an unrelated crash or you're just doing it wrong. You're not using that silly MT() filter or something, are you? (post your entire script)

[IanB]

Doing multiple encodes of different files in different script environments (i.e. different instances of the encoding program) at the same time ...All the processes running on the machine although independent from each other still share the operating resource of the machine, principally RAM and swap space.

Unfortunately both the Avisynth core and many plugins tend to handle memory allocation failures ungracefully, i.e. they crash and burn.

[TheFluff]

All the processes running on the machine although independent from each other still share the operating resource of the machine, principally RAM and swap space.

Unfortunately both the Avisynth core and many plugins tend to handle memory allocation failures ungracefully, i.e. they crash and burn.

If he's managed to completely run out of both physical and virtual memory that in itself is sort of impressive (since he's using avs64 I'm assuming he has at least 4GB of physical RAM, plus at least as much swap), but it's also completely unrelated to FFMS2. Furthermore, it should be easy to detect that sort of problem just by staring at the task manager.

[LoRd_MuldeR]

Unfortunately both the Avisynth core and many plugins tend to handle memory allocation failures ungracefully, i.e. they crash and burn.

If memory allocation fails, it either means the process has exceeded its maximum virtual memory size (which can easily happen with 32-Bit processes, but is completely unrelated from other processed running on the system) or the operating system really cannot allocate any additional memory pages (i.e. all the physical memory and all the swap-space on the HDD is completely full). The latter case indeed can be influenced by other processes, but its unlikely to happen under normal circumstances. And, if it does happen, it will cause serious trouble for all programs running on the computer. Windows would also pop up a fat warning message in that case...

[komisar]

TheRyuu, ffms2-mt-r464.7z without post-processing support?

[TheRyuu]

TheRyuu, ffms2-mt-r464.7z without post-processing support?

It should have it. All my builds should have post-processing support along with opencore-amr. Why, is it not working?

[komisar]

TheRyuu, strange...
ffvideosource(source="file.m2v",pp="l5",threads=6)
show me "Invalid postprocessing settings"...

[TheFluff]

TheRyuu, strange...
ffvideosource(source="file.m2v",pp="l5",threads=6)
show me "Invalid postprocessing settings"...

If it's not build with postproc support you will get an error about postproc not being compiled in. "invalid postprocessing settings" is a message that's coming from within libpostproc (I think) so I dunno what's going on here.

[Chikuzen]

I tried ffms2-mt-r464-avs64.7z and got error.

script

LoadCPlugin("C:\AviSynth_2.x\Plugins_x64\ffms2.dll")
ColorBars(640, 480, "YV12")
SWScale(512, 288)


Error massage
VirtualDub Error
AviSynth open failure:
SWScale: Context creation failed
(D:\Source\test_ffms.avs, line 3)

Is function "SWScale" missing on x64?

[kemuri-_9]

I tried ffms2-mt-r464-avs64.7z and got error.

Error massage


VirtualDub Error
AviSynth open failure:
SWScale: Context creation failed
(D:\Source\test_ffms.avs, line 3)


Is function "SWScale" missing on x64?

no, you would've gotten a different error if SWScale was not a valid avisynth function.
that error is that swscale itself failed to initialize.
the issue has been fixed in r465
i had missed a required change back in r407 for the C interface which in turn caused swscale to fail initialization for cpus with MMX.

[LigH]

This video (http://www.holzon.de/PRIVAT/holzon_k2.m2ts) (96.5 MB) is not correctly decoded with FFMS2 r464 mt (currently used in MeGUI 2023), it shows some forth/back motions in the MeGUI preview window; x264 and VirtualDub even crash after the first frame, processing a simple script (just LoadPlugin and FFVideoSource("*.ffindex"), generated by the MeGUI File Indexer).

[Chikuzen]

From docs

Interlaced H.264 is decoded in an odd way
each field gets its own full-height frame and the fieldrate is reported as the framerate, and furthermore one of the fields (odd or even) may "jump around".
To get the correct behavior, you can try setting fpsnum and fpsden so that the framerate is halved (may or may not work). This issue is caused by libavcodec.

Decoding some M2TS files using Haali's splitter will cause massive blocking and other corruption issues.
You can work around the issue either by remuxing the file to MKV (using GDSMux (make sure you untick "minimize output file size" in the Global settings tab) or eac3to), or (if you will be doing linear decoding only) by setting demuxer="lavf" in FFIndex and using seekmode=0 with FFVideoSource.
The cause of this issue is unknown but being investigated.

[TheFluff]

Interlaced h264 in m2ts is probably the format ffms2 has the worst support for, unfortunately. I strongly recommend using something else for loading those files.

[LigH]

Well, I converted it to MKV as well, because FFMS2 supports MKV a lot better.

Unfortunately, mkvmerge 4.7.0 does not support M2TS directly. So I demultiplexed it first with tsmuxer, and multiplexed the raw streams. But that failed too; I guess mkvmerge confused frames and fields (~ per second) here. Therefore I believe the video part is the main reason.
__

I just remembered that there is Haali's GDSMUX too. I'll try that as well to mux M2TS directly into MKV... — Oh, that displayed corrupted video in the MeGUI preview window, and moving the slider, it crashed eventually.
__

Again without minimizing the output: Still currupt output, still crashing. I may try indexing that manually and seeking conservatively, but not today anymore.

[Chikuzen]

Interlaced h264 in m2ts is probably the format ffms2 has the worst support for, unfortunately. I strongly recommend using something else for loading those files.

I know it.
but it seems that ffms2 can process LigH's sample.


FFmpegSource2("holzon_k2.m2ts", atrack=-1, fpsnum=25)
Yadif(mode=1).BicubicResize(1280, 720)

result (http://www.mediafire.com/download.php?dml3bk3qungjran)

[qyot27]

I've been experiencing crashes with FFMS2's C interface when trying to index MKV files output from x264. I was able to replicate the issue using my own builds of x264 (including r1995) and FFMS2 (r465, but it's been happening with previous revisions too). If the files are over 13MB, it causes ffmsindex or regular script loading-based indexing to fail because msvcrt.dll crashes. If I remux the files with mkvmerge, then no crash occurs. Files under 13MB are unaffected.

(I'm not certain whether the 13MB limit is one based on my own computer's ancient specs, though; the size may be larger on newer setups)

I'm not sure if this is an FFMS2 C interface or x264 issue, though. It would appear that Visual Studio builds are unaffected, since the build of ffms2-mt_r464 from the Google Code downloads didn't crash with 13MB+ files output from x264. Using mkvinfo, there does seem to be differences in the headers, particularly that x264-outputted MKV files have an unknown Segment size.

File that crashes:
+ EBML head
|+ EBML version: 1
|+ EBML read version: 1
|+ EBML maximum ID length: 4
|+ EBML maximum size length: 8
|+ Doc type: matroska
|+ Doc type version: 2
|+ Doc type read version: 2
+ Segment, size unknown
|+ Segment information
| + Muxing application: Haali Matroska Writer b0
| + Writing application: x264 r1995 c1e60b9
| + Timecode scale: 50000
| + Duration: 41.708s (00:00:41.708)
|+ Segment tracks
| + A track
| + Track number: 1
| + Track UID: 1
| + Track type: video
| + Lacing flag: 0
| + Codec ID: V_MPEG4/ISO/AVC
| + CodecPrivate, length 36 (h.264 profile: Baseline @L3.0)
| + Default duration: 41.708ms (23.976 fps for a video track)
| + Video track
| + Pixel width: 848
| + Pixel height: 480
| + Display unit: 0 (pixels)
| + Display width: 848
| + Display height: 480
|+ Cluster


File that doesn't crash:
+ EBML head
|+ EBML version: 1
|+ EBML read version: 1
|+ EBML maximum ID length: 4
|+ EBML maximum size length: 8
|+ Doc type: matroska
|+ Doc type version: 2
|+ Doc type read version: 2
+ Segment, size 13842494
|+ Seek head (subentries will be skipped)
|+ EbmlVoid (size: 4045)
|+ Segment information
| + Timecode scale: 1000000
| + Muxing application: libebml v1.2.0 + libmatroska v1.1.0
| + Writing application: mkvmerge v4.7.0 ('Just Like You Imagined') built on Apr 21 2011 01:13:14
| + Duration: 41.709s (00:00:41.709)
| + Date: Mon May 23 21:22:48 2011 UTC
| + Segment UID: 0xb8 0x64 0x4c 0xb1 0x3f 0xa3 0x6c 0xda 0xb3 0x24 0xdc 0x4d 0x03 0x6e 0x67 0x0a
|+ Segment tracks
| + A track
| + Track number: 1
| + Track UID: 1
| + Track type: video
| + Lacing flag: 0
| + MinCache: 1
| + Codec ID: V_MPEG4/ISO/AVC
| + CodecPrivate, length 36 (h.264 profile: Baseline @L3.0)
| + Default duration: 41.708ms (23.976 fps for a video track)
| + Video track
| + Pixel width: 848
| + Pixel height: 480
| + Display width: 848
| + Display height: 480
|+ EbmlVoid (size: 1061)
|+ Cluster


The settings used to encode the files didn't seem to matter. I could duplicate it even with --preset ultrafast --tune zerolatency.

[TheFluff]

Upload a sample file that makes it crash. Or is any file at all encoded with x264 and bigger than 13MB sufficient to trigger the crash?

[TheRyuu]

I wasn't able to reproduce the issue so yea, please upload a sample and let me know exactly what I should do to reproduce the crash.

[qyot27]

Here's a sample that crashes for me:
http://www.mediafire.com/?at419w57vn7n933
It consistently happens to me on MKVs output from x264 that are over 13MBs. I can typically only test on settings like ultrafast due to time constraints, but I've seen files encoded with veryslow exhibit the problem too.

If necessary, here's the build of FFMS2 I was using also:
http://www.mediafire.com/?hxt3x3xmmyv4coo

I can recompile FFMS2 and x264 with debug enabled if that's what needs to be done. I wouldn't be surprised if it's something about my hardware or software setup. The builds of ffmpeg and FFMS2 were cross-compiled under Ubuntu 11.04 (gcc-mingw32 4.4.4), both using -march=pentium3. CPU/RAM are a 1GHz Celeron Coppermine and 512 MBs of PC133 SDRAM.



I wasn't able to reproduce the issue so yea, please upload a sample and let me know exactly what I should do to reproduce the crash.
The exact steps I took were just to attempt indexing it, it doesn't get any further than that. Crashes at 0%, or immediately upon loading the script if I don't try to use ffmsindex.

[TheRyuu]

Works for me using my avs64 build.
LoadCPlugin("D:\plugins64\ffms2.dll")
ffvideosource("D:\Sample\causes_crash.mkv")

ffmsindex works too.

[LigH]

Load FFMS2.dll as C plugin? Didn't know I should; does that have any advantage compared to LoadPlugin?

[sneaker_ger]

It only depends on the branch/compiler used AFAIK, not something you can simply change in your script without using a different binary - no advantages.

[LigH]

I could imagine that most users without C compiling experience will prefer the builds from http://code.google.com/p/ffmpegsource/ – v2.15 or r464 (the latter is currently supported and used by MeGUI).

[TheFluff]

Load FFMS2.dll as C plugin? Didn't know I should; does that have any advantage compared to LoadPlugin?

If it was compiled as a C plugin (i.e. compiled with gcc in mingw) you must load it with loadcplugin. If it was compiled as a native C++ plugin (i.e. compiled with MSVC) you must load it with loadplugin. If you do it wrong, plugin loading will simply fail.

Notably, the avs64 version must be built as a C plugin; it cannot be built as a C++ native plugin. On the other hand, the official 32-bit builds are all native C++ plugins.

[TheRyuu]

To avs64 users with regards to postprocess:
ffms2-mt-r469-avs64.7z (http://warpsharp.voodoo-powered.net/random/ffms2-mt-r469-avs64.7z)
Somehow an old version of the define that enabled the postproc code was forgotten about so this version actually has the code enabled (the older versions actually had it compiled in, but it would never get set properly so it would just silently do nothing when you specified pp="foo").

To everyone using the 32bit regular version the problem is less clear. Something is probably writing outside of a buffer or smashing the stack.
ffms2-mt-r469.7z (http://warpsharp.voodoo-powered.net/random/ffms2-mt-r469.7z)
This build has something of a workaround that coincidentally fixes the issue so feel free to try it if you were getting the "Invalid Postprocess Settings" error (on valid input).

[komisar]

TheRyuu, thnx :)

[kemuri-_9]

the avs64 fix is included into r470 (http://code.google.com/p/ffmpegsource/source/detail?r=470) for those building from source.

[burfadel]

In ffms2-mt-r469 it still crashes when you are trying to multiencode with the source files being avi/xvid. It works fine with some other source files, so it looks like it depends on the source being used. This has been the case with all previous MT versions that I have tried, the non-MT versions work perfectly!

[TheFluff]

In ffms2-mt-r469 it still crashes when you are trying to multiencode with the source files being avi/xvid. It works fine with some other source files, so it looks like it depends on the source being used. This has been the case with all previous MT versions that I have tried, the non-MT versions work perfectly!

see earlier reply:

Doing multiple encodes of different files in different script environments (i.e. different instances of the encoding program) at the same time cannot possibly affect anything. You're either getting an unrelated crash or you're just doing it wrong. You're not using that silly MT() filter or something, are you? (post your entire script)

[burfadel]

Its only when using ffmpegsource MT, and only with certain source files (xvid in an avi container for example). It is ok with threads=1 specified.

[SledgeHammer_999]

Hey guys, I've build r470 from source but I get this error message from avisynth when using FFVideoSource()
Evaluate: System exception - Access Violation

If I try the r469 posted by TheRyuu my script works fine. So something went wrong in the compilation. Where should I look? Could it be an ffms problem or an ffmpeg one?
More info about my build:
ffmpeg (git commit 895e4de8d5a0760a48) build with mingw32 under msys (mingw 4.5.2)
ffms build with msvc 2008 express and didn't use Haali's splitter
zlib 1.2.5
pthreads 2.8.0

Sidenote: I had built successfully ffms ~1 year ago. I followed the same steps now, but it is broken.

Another question: What should I use now that ffmpeg-mt was merged with ffmpeg and ffmpeg was forked? ffmpeg, ffmpeg-mt or libav?

[henryho_hk]

Its only when using ffmpegsource MT, and only with certain source files (xvid in an avi container for example). It is ok with threads=1 specified.

Just curious, if u are doing multi-parallel encodes, shouldn't you be minimizing the number of threads?

[IanB]

@SledgeHammer_999,

"Evaluate: System exception - Access Violation" is a crash in the creator/constructor code as the Avisynth graph is being built.

[SledgeHammer_999]

ok. I found the culprit. It's pthreads. If I disable them the dll/script works. Now, I have to find what's wrong with it, I need multithreaded ffmpeg. I think it is a linking issue with mingw and msvc picking up different lib versions. arggg

[TheRyuu]

ok. I found the culprit. It's pthreads. If I disable them the dll/script works. Now, I have to find what's wrong with it, I need multithreaded ffmpeg. I think it is a linking issue with mingw and msvc picking up different lib versions. arggg

Make sure your pthreads has autostatic and doesn't use the old hacky (actually had to modify ffmpeg source code) method of static linking it with ffmpeg (autostatic is in the windows pthreads cvs) along with a few other changes to make ffmpeg happy:
diff -ur pthreads-win32.orig/need_errno.h pthreads-win32/need_errno.h
--- pthreads-win32.orig/need_errno.h 2010-08-21 18:49:29.000000000 -0300
+++ pthreads-win32/need_errno.h 2010-08-21 18:50:39.000000000 -0300
@@ -59,7 +59,7 @@
#endif
#endif

-#if !defined(PTW32_STATIC_LIB)
+#if !defined(PTW32_STATIC_LIB) && !defined(__MINGW32__)
# ifdef PTW32_BUILD
# define PTW32_DLLPORT __declspec (dllexport)
# else
diff -ur pthreads-win32.orig/pthread.h pthreads-win32/pthread.h
--- pthreads-win32.orig/pthread.h 2010-08-21 18:49:29.000000000 -0300
+++ pthreads-win32/pthread.h 2010-08-21 19:54:35.000000000 -0300
@@ -533,7 +525,7 @@
* do NOT define PTW32_BUILD, and then the variables/functions will
* be imported correctly.
*/
-#if !defined(PTW32_STATIC_LIB)
+#if !defined(PTW32_STATIC_LIB) && !defined(__MINGW32__)
# ifdef PTW32_BUILD
# define PTW32_DLLPORT __declspec (dllexport)
# else
diff -ur pthreads-win32.orig/sched.h pthreads-win32/sched.h
--- pthreads-win32.orig/sched.h 2010-08-21 18:49:29.000000000 -0300
+++ pthreads-win32/sched.h 2010-08-21 18:50:54.000000000 -0300
@@ -76,7 +76,7 @@
* do NOT define PTW32_BUILD, and then the variables/functions will
* be imported correctly.
*/
-#if !defined(PTW32_STATIC_LIB)
+#if !defined(PTW32_STATIC_LIB) && !defined(__MINGW32__)
# ifdef PTW32_BUILD
# define PTW32_DLLPORT __declspec (dllexport)
# else
diff -ur pthreads-win32.orig/semaphore.h pthreads-win32/semaphore.h
--- pthreads-win32.orig/semaphore.h 2010-08-21 18:49:29.000000000 -0300
+++ pthreads-win32/semaphore.h 2010-08-21 18:51:00.000000000 -0300
@@ -75,7 +75,7 @@
* do NOT define PTW32_BUILD, and then the variables/functions will
* be imported correctly.
*/
-#if !defined(PTW32_STATIC_LIB)
+#if !defined(PTW32_STATIC_LIB) && !defined(__MINGW32__)
# ifdef PTW32_BUILD
# define PTW32_DLLPORT __declspec (dllexport)
# else

[SledgeHammer_999]

Make sure your pthreads has autostatic and doesn't use the old hacky (actually had to modify ffmpeg source code) method of static linking it with ffmpeg (autostatic is in the windows pthreads cvs) along with a few other changes to make ffmpeg happy:


OMG I wasted so many hours today. Yes, this is the answer. pthreads-win32 cvs + this patch.

Will this patch create problems for other projects? If not, I am playing with a idea to create a git repo on github with cvs head, commit this patch and tag it 2.8.1. This way it will show up in google and other people won't be frustrated like me.

[kemuri-_9]

A) pthread cvs head is 2.9.0, not 2.8.0
B) forking a project causes confusion. don't fork it for such a (IMO petty) reason.
C) it would be wiser if ffmpeg detected that it's using a version of static pthread-win32 that has auto-static capability to it, rather than blindly assume it does.

[SledgeHammer_999]

A) pthread cvs head is 2.9.0, not 2.8.0
B) forking a project causes confusion. don't fork it for such a (IMO petty) reason.

I suggested this because I thought that upstream is dead. The last release was from 2006

C) it would be wiser if ffmpeg detected that it's using a version of static pthread-win32 that has auto-static capability to it, rather than blindly assume it does.

Ffmpeg didn't detect the lib if I had compiled it as static. I compiled with the lib as a dll and chaos ensued. (I am talking about 2.8.0 vanilla). With the patch ffmpeg detects the static lib.

[LoRd_MuldeR]

Pthreads isn't dead. Just check out the latest revision from the CVS:
http://sourceware.org/cgi-bin/cvsweb.cgi/pthreads/?cvsroot=pthreads-win32&sortby=date#dirlist

[TheRyuu]

ffms2-r470.7z (http://ffmpegsource.googlecode.com/files/ffms2-r470.7z)
ffms2-r470-avs64.7z (http://ffmpegsource.googlecode.com/files/ffms2-r470-avs64.7z)

ffmpeg-mt (pretty much) merged into libav, so no more separate builds.
Built with libav rev. 6af2801088 (2011-06-03)

Remember for the 64bit binary is an avisynth_c plugin so load with:
LoadCPlugin("X:\path\to\ffms2.dll")

Now with 100% more Opeth influence while building.

Changes from last build:
-Updated libav

[Rumbah]

I found a sample of h263 video that crashes for me every time with FFMS r470 and Avisynth 2.6 on a Core2Quad, even without starting multiple instances on Windows 7.

http://img225.imageshack.us/img225/6105/errorku.png (http://imageshack.us/photo/my-images/225/errorku.png/)
You can download the sample here: http://www.megaupload.com/?d=5PNE67AH

If you need more information I'll be glad to help you.

[Chikuzen]

I found a sample of h263 video that crashes for me every time with FFMS r470 and Avisynth 2.6 on a Core2Quad, even without starting multiple instances on Windows 7.

Your clip has N-VOPs.
I recommend you to do as follows.
FFMPEGSource2("crashtest.avi",atrack=-1,threads=1,fpsnum=25)

to devs
I think that you should change the default value of "threads" to 1 as much as ffmpeg.
It is dangerous to use multi-threads for decoding without thinking well.

[burfadel]

Yeah it works for me consistently with r470 over multiple sources with threads=1, otherwise it depends on the source (the crash I mentioned earlier the same as Rumbah). I also have a Core 2 Quad if that affects anything in regards to this...

[Chumbo]

I probably should have posted this here rather than on doom10. I just grabbed r470 and I still have the issue reported here:
http://doom10.org/index.php?topic=25.msg8240#msg8240

Any help is really appreciated. Thank you.

[TheRyuu]

I probably should have posted this here rather than on doom10. I just grabbed r470 and I still have the issue reported here:
http://doom10.org/index.php?topic=25.msg8240#msg8240

Any help is really appreciated. Thank you.

Upload a sample that's broke.

Try remuxing to mkv.

Also it sounds like it might be decoding each field into it's own frame so try adding SelectEven() after the ffvideosource line, it might also stop it from crashing.

[Chumbo]

Upload a sample that's broke.

Try remuxing to mkv.

Also it sounds like it might be decoding each field into it's own frame so try adding SelectEven() after the ffvideosource line, it might also stop it from crashing.
Okay, I'll upload a short sample. I actually have the original in an MKV but it does the same thing. I then remuxed it to a TS with tsmuxer and the same thing happened with the TS. Per my post on doom10, the older DLL worked fine as even stuff I was able to encode back in August is now not working with the new versions.

I'll post back when the sample is ready.

[tebasuna51]

ffms2-r470.7z
ffms2-r470-avs64.7z

ffmpeg-mt (pretty much) merged into libav, so no more separate builds.
Built with libav rev. 6af2801088 (2011-06-03)

But ffms2-r470.7z work with AviSynth no_mt?
At least don't work for me.

The simple script (work with vanilla 2.15):
FFVideoSource("D:\input.mkv")
was open in AviSynth but don't play:

[Chumbo]

Upload a sample that's broke.

Try remuxing to mkv.

Also it sounds like it might be decoding each field into it's own frame so try adding SelectEven() after the ffvideosource line, it might also stop it from crashing.
Here's the sample: http://www.mediafire.com/file/qdgyom6vrpbn1vf/short.clip.mkv

I also tried the SelectEven() with the same results with the TS and the MKV sample.

[TheRyuu]

But ffms2-r470.7z work with AviSynth no_mt?
At least don't work for me.

The simple script (work with vanilla 2.15):
FFVideoSource("D:\input.mkv")
was open in AviSynth but don't play:

I don't see a link to a sample in that post.

Here's the sample: http://www.mediafire.com/file/qdgyom6vrpbn1vf/short.clip.mkv

I also tried the SelectEven() with the same results with the TS and the MKV sample.

It's the typical transport stream breakage and is a known issue. There are some posts in this thread that specify some work arounds such as adding fpsnum/fpsden and threads=1 (this made it not crash for me), also if you know you won't be doing any seeking you can try using demuxer=lavf (this is a parameter to ffmsindex, not ffvideosource) and seekmode=-1. Actually seeking will probably be broken anyway so you should use this anyway.

You maybe have to look to an alternative way of souring though such as dss2.

[Chumbo]

...It's the typical transport stream breakage and is a known issue. There are some posts in this thread that specify some work arounds such as adding fpsnum/fpsden and threads=1 (this made it not crash for me), also if you know you won't be doing any seeking you can try using demuxer=lavf (this is a parameter to ffmsindex, not ffvideosource) and seekmode=-1. Actually seeking will probably be broken anyway so you should use this anyway.

You maybe have to look to an alternative way of souring though such as dss2.
I'll go ahead and use megui 32bit version with dss2 in the script then. Any idea when this broke? The last time I used it without issues was back around August/September of 2010. Any idea on a fix? Thanks.

[EDIT] I just remembered that I can't use the 32bit version because x264 crashes so I can't megui.

[EDIT2] Okay, I tried the fpsnum/fpsden and threads and these two settings did the trick. I then tried only one setting at a time and all I needed was to set threads=1 and that worked. Not sure how this will impact encoding performance though. Thanks a lot.

[TheRyuu]

I'll go ahead and use megui 32bit version with dss2 in the script then. Any idea when this broke? The last time I used it without issues was back around August/September of 2010. Any idea on a fix? Thanks.

[EDIT] I just remembered that I can't use the 32bit version because x264 crashes so I can't megui.

[EDIT2] Okay, I tried the fpsnum/fpsden and threads and these two settings did the trick. I then tried only one setting at a time and all I needed was to set threads=1 and that worked. Not sure how this will impact encoding performance though. Thanks a lot.

It's always been broken. Also it's decoding each field to a frame so you have to either specify fpsnum/fpsden or use selecteven() (notice your fps is 60 without it).

[Chumbo]

It's always been broken. Also it's decoding each field to a frame so you have to either specify fpsnum/fpsden or use selecteven() (notice your fps is 60 without it).
So why did it work just fine last year? Was it due to it using threads=1 by default?

[TheRyuu]

So why did it work just fine last year? Was it due to it using threads=1 by default?

If you didn't use the -mt version possibly. Although I'm pretty sure that defaulted to the number of cores as well but it didn't have the frame based multi-threading which is in the regular version now.

[tebasuna51]

But ffms2-r470.7z work with AviSynth no_mt?

I don't see a link to a sample in that post.

If I use the parameter threads = 1, don't crash anymore, but still don't decode properly some samples like this HD TV capture:

http://www.megaupload.com/?d=NSJSNFEP

With fpsnum = 25, fpsden = 1 the fps is ok but the decode is still wrong.

Works fine with DSS2-ffdshow-libavcodec.

[TheRyuu]

If I use the parameter threads = 1, don't crash anymore, but still don't decode properly some samples like this HD TV capture:

http://www.megaupload.com/?d=NSJSNFEP

With fpsnum = 25, fpsden = 1 the fps is ok but the decode is still wrong.

Works fine with DSS2-ffdshow-libavcodec.

If it's originally from a transport stream it's a known issue. As I said in a previous post on this page use demuxer=lavf in ffmsindex and specify fpsnum, fpsden, seekmode, and probably threads as well on ffvideosource and it should probably work.

This isn't a new issue, ffms2 has never played nice with h264 transport streams, especially interlaced ones.

[tebasuna51]

...
This isn't a new issue, ffms2 has never played nice with h264 transport streams, especially interlaced ones.

Yes, yes I know. Only the crash without threads = 1 is new.

I only want test the new libav version, but seems this problem is still there. Thanks.

[TheFluff]

Jesus, people, stop repeating the same thing over and over again just to have it fail every time and then act surprised that it still doesn't work when there has been no changes. Do I really have to post "interlaced h264 in ts will not work with ffms2" once every two pages?

Status of TS support in FFMS2 is as follows:
- progressive mpeg2: should work with Haali's splitter; frame accuracy is doubtful, however. Seeking most likely extremely broken with lavf unless you use seekmode=0 or -1 (that is to say, you never seek).
- interlaced mpeg2: same as above, but you may or may not get funny frame duplication issues; I haven't really tried.
- progressive h264: only 100% safe way to get this to work is demuxer="lavf" and seekmode=0 or -1 (-1 prevents wasting cpu cycles on pointless shit). Then it'll decode properly and be "frame accurate" by virtue of never seeking.
- interlaced h264: bat country. Will most likely not work properly at all no matter what you do. If you're feeling particularly adventurous you can try demuxer="lavf", seekmode=-1, threads=1 and then use the correct fpsnum/fpsden for your source, but you're still likely to get random corruption issues. Remuxing to MKV will rid you of the need to use demuxer="lavf" and seekmode=-1 but will not solve the frame duplication and you're still likely to get random corruption issues, and apparently lavc likes crashing with threads > 1 now too.
- progressive vc1: seems to work? Remux to MKV for better behavior.
- interlaced vc1: libavcodec doesn't support decoding this yet.

MPEG PS is probably mostly the same, but nobody uses PS these days except on DVD's, and there are better tools for handling those.


The next time you see someone complain about interlaced h264 you can quote what I just posted here. The status has been the same since forever (it has always been broken) and will not change until someone either fixes lavf's ts parser, or rewrites FFMS2 to use something else. Fixing lavc's h264 decoder is also likely to be necessary. I took a look at ffdshow's handling of interlaced h264 but I couldn't really find anything special so I assume clsid just patched ffmpeg as usual. Needless to say, this being open source and the problem being a) nontrivial, b) boring and c) unrelated to very old video games, none of this will probably ever get done. If it does, you will know, because there'll be a hundred people blogging endlessly about it.

[Rumbah]

I just wanted to note that threads=1 does indeed fix my problem with the ASP file.
Is this a libav problem or ffmpegsource? If it is should I post the problem anywhere?

[TheFluff]

I just wanted to note that threads=1 does indeed fix my problem with the ASP file.
Is this a libav problem or ffmpegsource? If it is should I post the problem anywhere?

If changing the number of decoding threads fixes a problem then the problem is in lavc (or possibly in pthreads or something). FFMS2 itself is single threaded.

[Rumbah]

Ah, ok, thanks. Is there a libav test application to test if it is libav or should I simply post this error on the libav mailing list (I've never used a mailing list before)?

[TheFluff]

Ah, ok, thanks. Is there a libav test application to test if it is libav or should I simply post this error on the libav mailing list (I've never used a mailing list before)?

I dunno if the libav guys renamed it, but ffmpeg has a commandline tool that transcodes stuff (it's simply called "ffmpeg"). Try that first. If it works, I'll blame TheRyuu and his pthreads voodoo.

[LoRd_MuldeR]

Nope, there still are 'ffmpeg.exe' and 'ffplay.exe' in the bundle:
http://win32.libav.org/win32/libav-win32-20110610.7z

[Rumbah]

Thank you for the direct link.
The included ffplay.exe plays the video without a crash or corruption.

[TheRyuu]

I dunno if the libav guys renamed it, but ffmpeg has a commandline tool that transcodes stuff (it's simply called "ffmpeg"). Try that first. If it works, I'll blame TheRyuu and his pthreads voodoo.

There is no pthreads voodoo (that I'm aware of) unless I specifically want to compile ffms2 x64 with msvc (which takes a lot more then just pthreads voodoo).

Thank you for the direct link.
The included ffplay.exe plays the video without a crash or corruption.

It's built with --enable-w32threads which means that frame based multithreading for h264 is not being used. You must compile it with --enable-pthreads in order to use frame based multithreading.

[Chikuzen]

I tested Rumbah's sample with libav-win32-pthreads-20110610.7z as follows.
(Luca distributes both w32threads-build and pthreads-build for 32bit Windows)

ffmpeg -threads 4 -i crashtest.avi -vcodec ffvhuff -acodec copy re_crashtest.avi
ffplay -threads 4 crashtest.avi

and ffmpeg/ffplay processed the clip without a crash.

[Rumbah]

It should be noted that the file is no H264 but H263. I don't know if libav even supports multithread decoding for ASP.

[qyot27]

I was looking at the crash I previously mentioned here:
http://forum.doom9.org/showthread.php?p=1503123#post1503123

And I found out a couple more things. Most importantly, the crash doesn't occur - even on 13MB+ files - if I specifically force it to use lavf as the demuxer. ffmsindex -m matroska causes_crash.mkv (which I assume is what is used for 'default' as well) crashes with the error from the Visual C runtime dll. Is there any off chance that the C-interface could be trying to load Haali's splitter (or there being code in the matroska demuxer that doesn't play nice with msvcrt.dll when GCC is used to compile it?), which is making the crash occur under the circumstances that it does?

I do think it may be related to the header's Segment size being read as 'unknown' (in mkvinfo) in these samples that are crashing - that with however resources are allocated to handle indexing, it having an unknown size is causing a memory leak or that it's requesting too much and crashing when it runs out of resources. This would make it crash with fairly small files on my nearly-decade-old computer, but not on setups with more resources (and especially not on 64-bit, with the raised RAM limits that provides). 13MB would be a limit of my particular hardware; for those more powerful computers, much much larger samples would be needed before it would show up. Is there any way to predict ahead of time what would be a suitable filesize on a given setup?


I did attempt to run a backtrace in gdb with builds that had debug enabled, but the only thing it got back was the address in msvcrt.dll where the crash occurs:
$ gdb ffmsindex
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from c:\Program Files\AviSynth 2.5\plugins/ffmsindex.exe...done.
(gdb) set pagination 0
(gdb) run causes_crash.mkv
Starting program: c:\Program Files\AviSynth 2.5\plugins/ffmsindex.exe causes_crash.mkv
[New Thread 2436.0xb4]
Indexing, please wait... 0%
Program received signal SIGSEGV, Segmentation fault.
0x77c3554a in msvcrt!_abnormal_termination () from C:\WINDOWS\system32\msvcrt.dll
(gdb) bt
#0 0x77c3554a in msvcrt!_abnormal_termination () from C:\WINDOWS\system32\msvcrt.dll
(gdb)

[TheRyuu]

ffms2-r473.7z (http://ffmpegsource.googlecode.com/files/ffms2-r473.7z)
ffms2-r473-avs64.7z (http://ffmpegsource.googlecode.com/files/ffms2-r473-avs64.7z)

Changes since last build:
Updated libav to b203f65.
Fixed open failures with some Vorbis files.

...snip...

I can't reproduce it. Do my compiles also have the issue? Or is it specific to your builds (if so maybe there's something wrong with your build system/chain).

[qyot27]

I can't reproduce it. Do my compiles also have the issue? Or is it specific to your builds (if so maybe there's something wrong with your build system/chain).
The 32-bit builds are all Visual Studio builds, though. Visual Studio builds don't exhibit the crash. I don't have a 64-bit Windows environment to test under, and depending on the circumstances, the file sizes would potentially need to be huge to run afoul of it (as even --preset ultrafast --tune zerolatency could generate MKVs that do this, it wouldn't be that hard to get an oversized file on better computers, but whether that would need to be a couple hundred megs or a couple dozen gigs, I don't know). I did see it happen under Wine on this computer too, but I can't remember how large my swap partition is. It didn't happen - with my builds - on a Vista-running laptop I have access to, but then it also has 6x the amount of RAM my computer does. A different computer also displayed the crash, and it has less RAM than mine does. That computer and mine both run XP.

The build system in question is constructed of the default mingw repository packages from Ubuntu (11.04), with more or less freshly-compiled versions of zlib 1.2.5, bzip2 1.0.6, and a CVS build of pthreads-w32 which is probably from late April. The MSys environment I use on Windows is mainly the prebuilt one from the CCCP Wiki, augmented with komisar's GCC builds and the aforementioned builds of zlib, bzip2, and pthreads-w32.

I did stumble my way around in the source code a couple days ago to see if I could maybe do trial-and-error alterations. I have no idea if it's connected, but in stdiostream.h, the cachesize is defined as the regular 16-bit entry of 65536 bits (8.192 in KB). My paging file's maximum limit is set to 1536 MB, and if 8.192 KB of cache is used per MB of available memory, that works out to approximately 12.6 MB, which is very close (given factors like overhead or whatnot) to that crash/no-crash threshold I was describing.

Of course, even when I raised the paging file's maximum limit to 4096 MB, it didn't stop the crash from occurring. That throws some doubt in there, unless the real key is just that it waits until it tries to use 3x the available physical RAM and then crashes, rather than anything to do with the paging file.


I tried varying up my build options (using ffmpeg's cpudetection, not passing -march, adding -lmsvcrt to FFMS2's --extra-ldflags) to see if anything changed, but that didn't work either.

The actual compilation steps I was using:
git clone git://git.videolan.org/ffmpeg.git
cd ffmpeg
./configure --prefix=$HOME/win32_build --cross-prefix=i586-mingw32msvc- --enable-gpl --enable-version3 \
--enable-postproc --enable-memalign-hack --disable-encoders --disable-muxers --disable-debug --disable-network \
--disable-hwaccels --disable-indevs --disable-outdevs --extra-cflags="-march=pentium3 -DPTW32_STATIC_LIB" \
--target-os=mingw32 --arch=x86
make
make install

cd ..
svn checkout http://ffmpegsource.googlecode.com/svn/branches/avs64 ffms2-cinterface
cd ffms2-cinterface
#if necessary:
svn merge http://ffmpegsource.googlecode.com/svn/trunk

fromdos configure
FFMPEG_LIBS="-L$HOME/win32_build/lib -lswscale -lavformat -lavcodec -lpostproc -lavutil -lavifil32" \
FFMPEG_CFLAGS="-I$HOME/win32_build/include" ./configure --prefix=$HOME/ffms2-avs --cross-prefix=i586-mingw32msvc- \
--host=i686-pc-mingw32 --enable-avs --enable-shared --enable-postproc --extra-cflags="-march=pentium3" \
--extra-ldflags="-lz -lbz2 -lpthreadGC2"
make
make install

[qyot27]

I've actually managed to compile a build that doesn't crash at all.

I'd been noticing the number of warnings issued during the compilation process itself while matroskaparser.c was being worked with. It looked like this:
gcc -O3 -Wall -march=pentium3 -std=gnu99 -s -fomit-frame-pointer -I/home/Stephen/win32_build/include -I. -Iinclude -D_FILE_OFFSET_BITS=64 -DFFMS_USE_POSTPROC -c -o src/core/matroskaparser.o src/core/matroskaparser.c
src/core/matroskaparser.c:936:13: warning: 'IsWritingApp' defined but not used [-Wunused-function]
src/core/matroskaparser.c: In function 'errorjmp':
src/core/matroskaparser.c:390:6: warning: 'll' may be used uninitialized in this function [-Wuninitialized]
src/core/matroskaparser.c:304:40: note: 'll' was declared here
src/core/matroskaparser.c:353:18: warning: 'neg' may be used uninitialized in this function [-Wuninitialized]
src/core/matroskaparser.c:304:35: note: 'neg' was declared here
src/core/matroskaparser.c:353:18: warning: 'zero' may be used uninitialized in this function [-Wuninitialized]
src/core/matroskaparser.c:304:29: note: 'zero' was declared here
src/core/matroskaparser.c:353:18: warning: 'width' may be used uninitialized in this function [-Wuninitialized]
src/core/matroskaparser.c:304:22: note: 'width' was declared here
src/core/matroskaparser.c: In function 'readFloat':
src/core/matroskaparser.c:842:3: warning: 'f.v' may be used uninitialized in this function [-Wuninitialized]
src/core/matroskaparser.c:810:11: warning: 'ui' may be used uninitialized in this function [-Wuninitialized]
src/core/matroskaparser.c: In function 'parseTrackEntry':
src/core/matroskaparser.c:1517:36: warning: 'CompScope' may be used uninitialized in this function [-Wuninitialized]
src/core/matroskaparser.c: In function 'parseBlockGroup':
src/core/matroskaparser.c:2133:15: warning: 'add_len' may be used uninitialized in this function [-Wuninitialized]
src/core/matroskaparser.c:2112:34: note: 'add_len' was declared here
src/core/matroskaparser.c:2132:15: warning: 'add_pos' may be used uninitialized in this function [-Wuninitialized]
src/core/matroskaparser.c:2112:25: note: 'add_pos' was declared here

So I decided to play around with the individual command used on that file to see if that affected those warnings. The only thing necessary was to remove -O3, because with that gone, the only warning is the first one about IsWritingApp.

With that, I went into configure and removed the references to -O3 in CXFLAGS and CXXFLAGS. I then did a normal recompile, and the crash didn't occur.

I've not tried to see if -O2 also has this problem, but as I was getting crashes under debug (and that uses -O1, from what configure seems to say), then I'm guessing all of the optimization modes will spark it.

EDIT: Running just that command on matroskaparser.c with the differing modes, yes, all of the optimization modes (apart from -O0/optimization disabled) exhibit those warnings. Those warnings are also the only difference in the compilation messages between it being enabled or disabled.


The full original log is here:
http://pastebin.com/W9XNyWjn

The log after -O3 has been removed from configure:
http://pastebin.com/8dznUGfm

[TheFluff]

With that, I went into configure and removed the references to -O3 in CXFLAGS and CXXFLAGS. I then did a normal recompile, and the crash didn't occur.

Congratulations, it seems you have found a bug in GCC. Apparently it's miscompiling stuff. Try with a different version.

The warnings are almost definitely unrelated to your problem, as is the page file stuff you were talking about in your previous post.

[Abs62]

FFMS2 r473 don't work when it compiled with libav after 603b8bc (16.06.2011). ffmsindex crash on av_open_input_file.

From libav APIchanges:
2011-06-xx - xxxxxxx - lavf 53.2.0 - avformat.h
Add avformat_open_input and avformat_write_header().
Deprecate av_open_input_stream, av_open_input_file,
AVFormatParameters and av_write_header.

[kemuri-_9]

we've just found this out for x264cli, av_open_input_file is crashing due to careless mistakes in av_open_input_file's deprecation.

stay at the revision BEFORE

Deprecate av_open_input_* and remove their uses.

Deprecate the last remaining member of AVFormatParameters.


until either ffms2 is fixed to use the new API or libav/ffmpeg have av_open_input_file stop crashing.

[JEEB]

Given problem got fixed upstream just now, after I herped a derp on #libav-devel.

This (http://git.libav.org/?p=libav.git;a=commit;h=84bd2b4bf5ca544e29c48634ac8b2899c58b0d9d) and this (http://git.libav.org/?p=libav.git;a=commit;h=dbafb0e06faa092f60e53d845957fbab7f2a3f2d) are the fixing commits.

[CruNcher]

@JEEB
it seems seeking is broken in your x264 build when outputing to .mp4 and using the mpc-hc splitter

[TheFluff]

@JEEB
it seems seeking is broken in your x264 build when outputing to .mp4 and using the mpc-hc splitter

That sure is a detailed bug report, but I don't see how it's related to ffms2...

[CruNcher]

Hehe i was just trying some other thing (related to ffms2) and accidentally found this issue too and as i found no thread about jeebs build i thought i hijack this for a moment sorry ;)

[TheRyuu]

I tested Rumbah's sample with libav-win32-pthreads-20110610.7z as follows.
(Luca distributes both w32threads-build and pthreads-build for 32bit Windows)

ffmpeg -threads 4 -i crashtest.avi -vcodec ffvhuff -acodec copy re_crashtest.avi
ffplay -threads 4 crashtest.avi

and ffmpeg/ffplay processed the clip without a crash.

It does not play it correctly. It freezes and loops some audio.

Edit:
It's cool though, booted up linux to gdb this and ffmpeg encoded it to ffvhuff without issue regardless of threading. So clearly the best thing to do is point fingers at each other and accomplish nothing productive (the issue is almost certainly ffmpeg/libav's fault) so go poke them.

[Abs62]

Ffmsindex is crashed on some files if ffms2 compiled with libav libraries with commit a26ce1e (13.06.11) and next. For example on this file (http://www.anime-sharing.com/forum/new-releases-77/re-%5Butw%5D-hidan-no-aria-09-a-10043/) (ffmsindex -t -1 ...).
ffms2-r473.7z from this thread also is crashed.

It looks like function parse_nal_units() in h264_parser.c in libav get wrong data (for example sps.bit_depth_luma=12345) and handle it without verification. It leads to heap corruption and later crash in some other function.

[TheRyuu]

Ffmsindex is crashed on some files if ffms2 compiled with libav libraries with commit a26ce1e (13.06.11) and next. For example on this file (http://www.anime-sharing.com/forum/new-releases-77/re-%5Butw%5D-hidan-no-aria-09-a-10043/) (ffmsindex -t -1 ...).
ffms2-r473.7z from this thread also is crashed.

It looks like function parse_nal_units() in h264_parser.c in libav get wrong data (for example sps.bit_depth_luma=12345) and handle it without verification. It leads to heap corruption and later crash in some other function.

The video's not the problem, it's the audio I think. Indexing it without audio works just fine.

I'll check it out a bit more later. (Also inb4rule6)

[Abs62]

The video's not the problem, it's the audio I think. Indexing it without audio works just fine.
Nope. If you reset the mentioned commit the file will be indexed without problem. I think a heap corruption in parse_nal_units() can afterwards lead to crash in any function in any place. It's a hard kind of bugs.

[kemuri-_9]

Thanks for the report, have you reported the issue to the libav/ffmpeg teams?

[Abs62]

No. I haven't contacts with these teams.

[TheRyuu]

No. I haven't contacts with these teams.

I've poked them about it.

[Myrsloik]

FFMS currently has an issue opening 10bit per component yuv files (such as those that can made with a recent x264). The cause is known and should be fixed within a week or two.

[Mini-Me]

Two questions:
Is support for YV24 (etc.) currently built into FFMS/FFMS2, or does the codebase need to be updated for that?
Now that x264 can output 4:4:4 streams and libavcodec can decode them, are the FFMS2 packagers planning on releasing updated builds that take advantage of this?

[kemuri-_9]

Two questions:
Is support for YV24 (etc.) currently built into FFMS/FFMS2, or does the codebase need to be updated for that?
Now that x264 can output 4:4:4 streams and libavcodec can decode them, are the FFMS2 packagers planning on releasing updated builds that take advantage of this?

no, ffms2 needs to be updated to support any of the new colorspaces in avs 2.6 - including YV24,
and this generally means that avs 2.6 should finish the de-baking of code to where the interface is usable again.

Edit:
I should clarify that i'm referring to the ability for the ffms2 plugin to output the streams as 4:4:4, currently they'll be decoded and then converted internally to one of the colorspaces that 2.5 supports.

[qyot27]

As long as the libav stuff it's linked against supports the colorspaces, I don't see why it couldn't (although I guess one might also need to be using 2.6 for this to work). I've been able to decode 4:4:4 with my own builds since I noticed the relevant commits on x264-devel a couple weeks ago and started doing tests with it. And I'd guess that's because 4:4:4 support in ffmpeg was already there for a day or two at the time I compiled it.

The only strange part is that ConvertToYV24 in the original script results in AviSynth outputting greyscale video to media players, but using FFMS2 to decode an already 4:4:4 H.264 file gives the correct colors in the same media players (and the player decodes the actual file correctly as well; recent ffdshow, at any rate). I suppose the colorspace actually being output when playing a 4:4:4 H.264 file uses the opposite channel mapping than YV24 does, somewhat like the whole YV12 is fine/I420 isn't stuff. Or something like that.

Now, RGB stuff is still off (as in, the channels are swapped in a way I can't figure out how to reverse), but it's better than it was a couple weeks ago when it was mostly a grey nothingness.




So the short version of all that is: it's already 'kind of' capable from what I can see, you just need to compile it against a recent libavcodec and probably also use either the AviSynth 2.6 alpha from May 2011 (which I'm currently using), or a similar trunk build like the ones JEEB posted back in January (which I was using before).

[TheRyuu]

ffms2-r484.7z (https://ffmpegsource.googlecode.com/files/ffms2-r484.7z)
ffms2-r484-avs64.7z (https://ffmpegsource.googlecode.com/files/ffms2-r484-avs64.7z)

Changes since last build:
-Updated build chain to gcc 4.6.1
-Now using msvc2010 for 32bit builds.
-Updated libav to rev. 2cb6dec
-Fixed what was known as the "parse_nal_units" segfault. It was feeding audio packets into the h264 parser.
-Fixed forcing of certain output formats

[pandy]

btw - not sure how it can be compared to GCC however some results looks very impressive

http://www.phoronix.com/scan.php?page=article&item=pathscale_ekopath4_open&num=1

[aegisofrime]

btw - not sure how it can be compared to GCC however some results looks very impressive

http://www.phoronix.com/scan.php?page=article&item=pathscale_ekopath4_open&num=1

It does look very impressive, however being only for Linux et al and not Windows, it's not exactly relevant to FFMS2 at this point.

[Blue_MiSfit]

Hi guys,

I'm having strange issues with some QuickTime wrapped DVCPro HD files. These files are in-theater trailers, and have the following strange behavior

1) In QuickTime player these MOVs are totally in sync, and begin with a usual MPAA green-band warning.

2) If I use something like x264 or ffmpeg with the lavf demuxer to transcode these into H.264, the video starts much earlier, with extra frames visible. These frames are either black, or production slates. I'm not sure how this is masked out from normal viewing in QuickTime Player. I think it has something to do with a "QuickTime EDL Cut List", but I'm not certain.

3) If I indead use FFMS2 inside of AviSynth, the video does start at the green-band, but the audio track has a lot of silence in the beginning, making the audio way out of sync. This extra silence is the same length as the production slate I see when I transcode with something that uses lavf splitter.

4) If I trim the MOV using QuickTime Pro, all this strangeness goes away, and both ffms2 and lavf produce the same results. This makes me think doing a trim, followed by a "save as" in QuickTime Pro does actually trim off the junk in the beginning

5) Manually trimming in QuickTime is a pain in the ass, so instead I use some simple scripting to make x264 transcode the video into a high birate MKV, use ffmpeg to dump a PCM WAV from the original WAV, and mux both results into an MKV. This then opens into AviSynth nicely with FFMS2, and I can set my trims in here to strip away the junk.

In conclusion, I think there's something different with how lavf and ffms2 handle MOV files. This wouldn't surprise me :)

Both behaviors are "incorrect", with "correctness" defined as "giving me the same result as QuickTime Player". FFMS2 starts the video in the proper place , but reads the audio from the beginning. lavf reads both from the beginning, and reveals content that shouldn't be visible.

I have a sample file, if someone is curious and wants to try to fix this. Apologies for the size, performing a trim is useless for the reasons I stated above. Here is the link:

http://www.mediafire.com/?n0wwl5adwuepm

Hopefully somebody cares :devil:! As always, thanks for all the hard work on this awesome piece of software!!

Thanks,
Derek

[TheFluff]

Interesting problem, I'll have a look. What audio delay mode were you using with ffaudiosource?

[Blue_MiSfit]

Hmm... the default? :)

Thanks for your time!

[TheRyuu]

Hmm... the default? :)

Thanks for your time!

From the documentation:

FFAudioSource

FFAudioSource(string source, int track = -1, bool cache = true,
string cachefile = source + ".ffindex", int adjustdelay = -1, bool utf8 = false)


Opens audio. Invokes indexing of all tracks if no valid index file is found, or if the requested track isn't present in the index.

Arguments
Are exactly the same as to FFVideoSource, with one exception:

int adjustdelay = -1
Controls how audio delay is handled, i.e. what happens if the first audio sample in the file doesn't have a timestamp of zero. The following arguments are valid:

-3: No adjustment is made; the first decodable audio sample becomes the first sample in the output.
-2: Samples are created (with silence) or discarded so that sample 0 in the decoded audio starts at time zero.
-1: Samples are created (with silence) or discarded so that sample 0 in the decoded audio starts at the same time as frame 0 of the first video track. This is the default, and probably what most people want.
Any integer >= 0: Same as -1, but adjust relative to the video track with the given track number instead. If the provided track number isn't a video track, an error is raised.

-2 obviously does the same thing as -1 if the first video frame of the first video track starts at time zero. In some containers this will always be the case, in others (most notably 188-byte MPEG TS) it will almost never happen.

[Mini-Me]

ffms2-r484.7z (https://ffmpegsource.googlecode.com/files/ffms2-r484.7z)
ffms2-r484-avs64.7z (https://ffmpegsource.googlecode.com/files/ffms2-r484-avs64.7z)

Changes since last build:
-Updated build chain to gcc 4.6.1
-Now using msvc2010 for 32bit builds.
-Updated libav to rev. 2cb6dec
-Fixed what was known as the "parse_nal_units" segfault. It was feeding audio packets into the h264 parser.
-Fixed forcing of certain output formats

Thanks for the responses, kemuri-_9 and qyot27! Keeping your replies in mind, I just tried with the new build in the quoted message (thank you, TheRyuu!). While FFVideoSource still does not output YV24, it will now read 4:4:4 H.264 video. As a consequence, we can now get genuine 4:2:2 output from a 4:4:4 file by setting "colorspace" to "YUY2" in the FFVideoSource parameters.

In other words, we can convert YUY2 to YV24, encode with x264 as 4:4:4, and load it back into Avisynth without ever having to go through YV12 (resolution reduction). Encoding 4:2:2 as 4:4:4 may be somewhat wasteful, but doing exactly that and using a higher quantizer for chroma (to get the same filesize as YV12 encodes) is now a pretty viable option now for archiving YUY2 captures. For the same filesize, I'm getting basically equivalent luma but chroma that is much more faithful to the source. (I'm using extremely high bitrates though, so it might be a different story with "regular" bitrates.)

[TheRyuu]

ffms2-r494.7z (https://ffmpegsource.googlecode.com/files/ffms2-r494.7z)
ffms2-r494-avs64.7z (https://ffmpegsource.googlecode.com/files/ffms2-r494-avs64.7z)

Changes since last build:
-Not much...
-Updated libav to rev. e3bc07f

[Plorkyeran]

Audio delay mode -2 appears to give the correct result, but it's sort of hard to tell if it's perfectly synced as it doesn't quite play in real time on my machine.

[TheFluff]

Thanks for the responses, kemuri-_9 and qyot27! Keeping your replies in mind, I just tried with the new build in the quoted message (thank you, TheRyuu!). While FFVideoSource still does not output YV24, it will now read 4:4:4 H.264 video. As a consequence, we can now get genuine 4:2:2 output from a 4:4:4 file by setting "colorspace" to "YUY2" in the FFVideoSource parameters.

FFMS2 can't output YV24 because Avisynth (2.5) doesn't support it. Avisynth 2.6 does, but so far I haven't looked into what needs to be done on FFMS2's side to make it a working 2.6 plugin. If you want the support like RIGHT NOW you need to write a patch yourself (any contributions are welcome), but if you're okay with waiting we'll get around to it eventually.

[forclip]

Hi. Just wondering, is it normal that FFVideoSource produces an error "No suitable output format found" when I trying to open a 10-bit depth samples with "default call"? Is it possible to auto choose the most suitable output format that can be supported (by FFMS2 and AviSynth) without explicity specifying it with "colorspace" key?

[Myrsloik]

Hi. Just wondering, is it normal that FFVideoSource produces an error "No suitable output format found" when I trying to open a 10-bit depth samples with "default call"? Is it possible to auto choose the most suitable output format that can be supported (by FFMS2 and AviSynth) without explicity specifying it with "colorspace" key?

I've said it before and I'll say it again. This is a bug in libav/ffmpeg. The bug report is here:
http://bugzilla.libav.org/show_bug.cgi?id=10
I'm however very close to copying that function out of libav and fixing it just to work around this bug.

[Myrsloik]

Thanks for the responses, kemuri-_9 and qyot27! Keeping your replies in mind, I just tried with the new build in the quoted message (thank you, TheRyuu!). While FFVideoSource still does not output YV24, it will now read 4:4:4 H.264 video. As a consequence, we can now get genuine 4:2:2 output from a 4:4:4 file by setting "colorspace" to "YUY2" in the FFVideoSource parameters.

Blah blah blah...

Since colorspace conversion is done at the same time as scaling internally you can double the width of the video to get full resolution chroma information too. (kinda hackish but that's one of the reason the output dimensions and colorspace can be specified)

[forclip]

Myrsloik
OK, thanks for the clarification.

[Mini-Me]

FFMS2 can't output YV24 because Avisynth (2.5) doesn't support it. Avisynth 2.6 does, but so far I haven't looked into what needs to be done on FFMS2's side to make it a working 2.6 plugin. If you want the support like RIGHT NOW you need to write a patch yourself (any contributions are welcome), but if you're okay with waiting we'll get around to it eventually.

Actually, the only reason I personally wanted 4:4:4 was so I could get 4:2:2. :D Once I realized FFMS2 could read 4:4:4 files and output in the YUY2 colorspace, I knew I was set.

I just wanted to point out to others that this is a viable option for archiving analog captures now: Interlaced YUY2 is a common capture format for analog video, and downsizing to interlaced YV12 is suboptimal (without motion-adaptive upsampling on playback, it creates artifacts). Now that x264 has 4:4:4 input/output, it's now viable to just upsize YUY2 to YV24, encode as 4:4:4, and increase the chroma quantizer to keep the filesize down. I was originally afraid that FFMS2 would drag everything through YV12 and I wouldn't be able to compare the two encodes (4:2:0 vs. 4:4:4), but that is thankfully not the case. :)

Since colorspace conversion is done at the same time as scaling internally you can double the width of the video to get full resolution chroma information too. (kinda hackish but that's one of the reason the output dimensions and colorspace can be specified)

Although I don't need true 4:4:4, this is actually a really good point for those who do!

[kemuri-_9]

FFMS2 can't output YV24 because Avisynth (2.5) doesn't support it. Avisynth 2.6 does, but so far I haven't looked into what needs to be done on FFMS2's side to make it a working 2.6 plugin. If you want the support like RIGHT NOW you need to write a patch yourself (any contributions are welcome), but if you're okay with waiting we'll get around to it eventually.

due to how broken/incomplete the avisynth 2.6 interface is right now, you'd have to not only take the avisynth.h but also the implementation code behind it (i think it was interface.cpp) to get any 2.6 plugins to compile atm.

this will, as a by-product, be likely to break backwards compatibility, preventing use in 2.5.

[IanB]

Yes it was never the intention for 2.6 plugins to work in 2.5.

Cunning plugin authors may crib and allow this to work for their plugin, but in general it should not be expected.


Note: 2.5 plugins are intended to be fully supported in 2.6 within the constraints of the 2.5 framework.

[TheFluff]

Yes it was never the intention for 2.6 plugins to work in 2.5.

Cunning plugin authors may crib and allow this to work for their plugin, but in general it should not be expected.

That's really annoying. I really don't want to maintain two separate interfaces (three, if you count the avs64 C interface that kemuri-_9 maintains). How much clever ifdeffing is required, really?

[TheRyuu]

ffms2-r507.7z (https://ffmpegsource.googlecode.com/files/ffms2-r507.7z)
ffms2-r507-x64.7z (https://ffmpegsource.googlecode.com/files/ffms2-r507-x64.7z)

64-bit binary no longer requires LoadCPlugin. It's just a regular avisynth plugin now.
I changed the name slightly to try and reflect this. My compiles will no longer require LoadCPlugin (obviously all old avs64 compiles will) but archives labeled as "x64" will be regular plugins.

LoadPlugin(X:\path\to\ffms2.dll")
For both 32 and 64-bit binaries.

Changes since last build:
-Updated libav to rev. b4cfb82.
-Update project files in svn to msvc2010.
-x64 target in msvc.
-Auto-detect number of threads if threads < 1. (The avisynth plugin already did this, this functionality is now extended to those using the api as well).

Now, msvc x64 and mingw-w64 don't exactly play nice now, but they play together well enough to make the builds possible now. :)

Also now included with the builds is some stuff for devs (.lib for linking, ffms.h header file, and pdb's for debugging).

[TheFluff]

64-bit binary no longer requires LoadCPlugin. It's just a regular avisynth plugin now.

Wrong. It depends on who compiled it and with what compiler.

[TheRyuu]

Wrong. It depends on who compiled it and with what compiler.

Edited post to better announce this fact. Although you have to be pretty retarded to not realize it.

Also for future releases I'm going to do a separate 'SDK' package or something which contains release/debug builds and associated libs/headers etc...

[kemuri-_9]

shenanigans mentioned here (http://doom10.org/index.php?topic=25.240) are now committed, enjoy (and report found bugs).

I've also renamed the avs64 branch to c_plugin in a preemptive to avoid arguments like the above.

[qyot27]

Is there some difference between the way the MSVC and C-plugin builds handle pthreads? Because any time I try to use the C-plugin with more than one thread (of which I mean 'leave it at the defaults', but as I'm using it on a Core 2 Duo...), HCenc crashes almost immediately. If I use the distributed MSVC builds, make the C-plugin use threads=1, or if I compile with win32threads, the crash doesn't happen. If there isn't really a difference, then I'll know it's an HCenc-side issue.

[TheFluff]

Is there some difference between the way the MSVC and C-plugin builds handle pthreads? Because any time I try to use the C-plugin with more than one thread (of which I mean 'leave it at the defaults', but as I'm using it on a Core 2 Duo...), HCenc crashes almost immediately. If I use the distributed MSVC builds, make the C-plugin use threads=1, or if I compile with win32threads, the crash doesn't happen. If there isn't really a difference, then I'll know it's an HCenc-side issue.

The handling on FFMS2's side isn't different but the two variants are compiled by different people with different compiler versions in different ways, so it's not at all impossible that kemuri-_9's pthreads compile has some funny issue while TheRyuu's does not. I leave further investigation to kemuri-_9 since the c-plugin is his playground.

[kemuri-_9]

I actually never build ffmpegsource against an ffmpeg that was built with pthreads on windows.

so I can't say the c plugin is very much tested in that regards, though like TheFluff has stated, it shouldn't really have a weird issue like that.

Though, this is reminding me of an issue i've seen previously with pthreads crashing x264 when built with msvc (though this was x86_64 specific).

file a bug in googlecode for it to track this, and i'll try and find time to investigate (and temporarily put aside my distaste in requiring to build ffmpeg against pthreads for the full mt support)

[qyot27]

Would it possibly be entirely up to the version of pthreads, though? Mainly because x264 doesn't exhibit the issue, even with the C-plugin using pthreads and calling more than 1 thread. Then again, x264 is built against the same version of pthreads that ffmpeg was. That was partially why I thought it might actually be something about HCenc interacting with it in some way, except it still seems isolated to when I'm using the C-plugin.

I suppose if I rolled back to a much older revision of pthreads and the crash doesn't occur, that would show it's somewhere in there, right? It was happening with stuff built against a pthreads from April 30th, 2011, and also with the current CVS version as of this past week. I used to use a build from October 2009, and I think I might do a test with it built against that one to see if the crash still happens. My memory's not good enough to recall if the builds I used to do against that one also crashed in this manner.

[kemuri-_9]

It could be the version of pthreads.

I base this on the fact that the pthread issue i previously mentioned was only for a newer version, whereas an older verison did not exhibit the issue (i think the major difference for my issue was whether that autostatic stuff was there or not).
ffmpegsource nor ffmpeg handle static-but-not-non-autostatic pthread-win32 correctly, however, so you probably can't go back before that if you want to link pthread-win32 statically.
you could try using the shared lib version of pthread-win32 if you need to go back before that addition though.
in fact, trying the share lib version may be a helpful test overall...

[qyot27]

Well, the build from October 2009 caused an error during the compile process, even though it is an autostatic build (autostatic with the old patch that added it, rather than as part of the trunk CVS code); it just must be too old now to compile a current ffmpeg against. I'll have to see about building it against a shared version.

[kemuri-_9]

i would also like to point out that TheRyuu does not typically use the standard pthread-win32 when he builds.
he generally uses a version that's based off the win32 thread support i wrote for x264, which is available here (https://github.com/TheRyuu/pw32threads)

could also trying to see if this version causes a crash or not.

[TheRyuu]

i would also like to point out that TheRyuu does not typically use the standard pthread-win32 when he builds.
he generally uses a version that's based off the win32 thread support i wrote for x264, which is available here (https://github.com/TheRyuu/pw32threads)

could also trying to see if this version causes a crash or not.

Incorrect, of all the builds I've done: 32bit builds all have standard pthreads-w32. 64bit c-plugin builds all have standard pthreads-w32.
Only 64bit msvc builds (which I've posted one build ever, as of this post) have the version based off of win32 threads to avoid some weird linker issues with standard pthreads.

All of the above have and use autostatic for libav.

ffms2-r517.7z (https://ffmpegsource.googlecode.com/files/ffms2-r517.7z)

Changes:
Built with libav rev. 62ee0e6
Implement a working version of avcodec_find_best_pix_fmt. This should fix all automatic selection of output colorspace in avisynth.
Make FFMS_Index reference counted and shared between sources instead of partially copied.
Fix deprecation in libavformat usage. Replace av_find_stream_info with avformat_find_stream_info.

[qyot27]

I wasn't able to get to testing with the different pthreads builds until today, but the results are below.

Static pthreads-win32 (July 2011) crashes HCenc (at 3%) on sampling pass
Shared pthreads-win32 crashes HCenc (at 3%) on sampling pass with both:
The pthreadGC2.dll that matched with the version of the library (July 2011) FFMS2 was built against.
A pthreadGC2.dll from 2008 that was laying around in C:\Windows\system32
pw32threads crashes HCenc (at 3%) on sampling pass
The initial stuff as well:
w32threads = no crash
pthreads-win32 (July 2011) with threading disabled (threads=1) = no crash




As a different test, I decided to use a different file. With the static pthreads-win32 build of r512 (C-plugin).

It crashed at 7% in the sampling pass, because I think the issue has to do with the length of the file and where the threading would actually divvy up the frames.

However, I then remuxed the file from FLV to MKV using ffmpeg and reran the test. No crash with the MKV remux.

I'd overlooked the fact that the MSVC test I'd run earlier was with an MKV remux, so I reran it with the FLV instead. MSVC (r517, as distributed on googlecode) crashed on the FLV at 7%, just like the C-plugin did. As already stated, no crash with the MKV.

It would seem that it's an issue with the FLV demuxer (I'd guess FLV just uses libavformat, since using -m lavf when indexing still resulted in HCenc crashing at 7%) choking with pthreads-win32 when using more than one thread, but it still only happens with HCenc; x264 seems completely unaffected by it, which I wouldn't think would happen if it was something intrinsic to libavformat.

In all cases the video and audio were H.264 and AAC.

[TheFluff]

http://code.google.com/p/ffmpegsource/issues/detail?id=50

Possibly the same issue. Can you redo the test with r518 and see if you get a nice error message instead of a crash?

[kemuri-_9]

huh, i guess it's not surprising that w32threads does not exhibit the issue, as w32threads with ffmpeg still do not allow full mt support like building with pthreads.

[qyot27]

r518 still crashes HCenc at 7%, no inkling of an error message during playback of the script with MPC when it passes the 7% mark.



As an aside, I normally do an svn merge in those times between the C-plugin's HEAD updates, but doing a plain merge currently fails due to the recent revisions concerning MSVC x64. Readout below:
svn merge http://ffmpegsource.googlecode.com/svn/trunk
--- Merging r506 into '.':
C build-msvc/ffms2_include_dirs.props
C build-msvc/ffmsindex.vcxproj.filters
C build-msvc/ffms2.vcxproj
C build-msvc/ffms2.sln
C build-msvc/ffmsindex.vcxproj
C build-msvc/ffms2.vcxproj.filters
D build-msvc/ffms2_include_dirs.vsprops
C build-msvc/ffms2.vcproj
C build-msvc/ffmsindex.vcproj
svn: Attempt to add tree conflict that already exists at 'build-msvc/ffmsindex.vcxproj'
svn: Error reading spooled REPORT request response

I can work around that by specifying the revisions with -r, but if left alone it wants to merge from back at r506 instead of starting at the last C-plugin revision.

[TheFluff]

Okay, then I guess we get to do this the hard way.

It would seem that it's an issue with the FLV demuxer (I'd guess FLV just uses libavformat, since using -m lavf when indexing still resulted in HCenc crashing at 7%)

FLV uses libavformat, yes. We don't have a special demuxer for it.

So, let me sum up what you're saying to see if I got it right:

The crash only affects HCenc; not x264 or MPC
The crash only appears if you use a FFMS2 compiled with pthreads, and only if you're actually using threads >1
It only affects FLV; remuxing to MKV makes the problem disappear
The crash happens with both the native and the C-style plugins


When you tested with r518, are you sure you actually merged in the changes from r518 in trunk to the C-plugin branch?

Also, do you have Visual Studio installed? If you do, compile FFMS2 in debug mode (or at least get ahold of a .pdb file somewhere and stick it with the .dll) and try attaching Visual Studio to the HCenc process and see if you can get a stack trace when it crashes.

[qyot27]

So, let me sum up what you're saying to see if I got it right:

The crash only affects HCenc; not x264 or MPC
The crash only appears if you use a FFMS2 compiled with pthreads, and only if you're actually using threads >1
It only affects FLV; remuxing to MKV makes the problem disappear
The crash happens with both the native and the C-style plugins

Correct.

When you tested with r518, are you sure you actually merged in the changes from r518 in trunk to the C-plugin branch?
The method used for the merge was:
svn checkout http://ffmpegsource.googlecode.com/svn/branches/c_plugin ffms2-cinterface
cd ffms2-cinterface
svn merge -r 512:518 http://ffmpegsource.googlecode.com/svn/trunk
I also compared videosource.cpp in r519 with the one from the merge operation and from trunk. The relevant section of code was the same (and so were the files' checksums).

Also, do you have Visual Studio installed? If you do, compile FFMS2 in debug mode (or at least get ahold of a .pdb file somewhere and stick it with the .dll) and try attaching Visual Studio to the HCenc process and see if you can get a stack trace when it crashes.
VS Express 2008, yes.




However, I just tried something else (with a smaller file I'd meant to use as a sample if it came to that), and I'm now pretty convinced that the issue is squarely on HCenc's side, specifically in the 1-pass mode's sampling pass routine, and if anything, the method used for the sampling pass must be exposing something in the way libavformat handles FLV demuxing that it doesn't like. Using 2-pass mode averts the issue entirely, with the same file and same FFMS2 build, even where that combination would make it crash during 1-pass mode's sampling pass at ~24%. I can still attempt building a debug version through VSE2008, even if only for completeness' sake.

[qyot27]

VSE2008 seems to have miscompiled the plugin, because ffmsindex crashes immediately. I used the following steps:

Build FFmpeg as usual with MinGW

Open build-msvc/ffms2_2008.sln

Select ffms2 Project from Solution Explorer

Options->Projects and Solutions->VC++ Directories

Library files directories. Add the following to the end of the list:
C:\MinGW\cross-mingw.gcc446.generic.20101013\lib\gcc\i686-pc-mingw32\4.4.6
C:\MinGW\cross-mingw.gcc446.generic.20101013\i686-pc-mingw32\lib
[FFmpeg install directory /lib folder]

Include files directories. Add the following to the end of the list:
C:\MinGW\msinttypes
C:\MinGW\cross-mingw.gcc446.generic.20101013\lib\gcc\i686-pc-mingw32\4.4.6\include
C:\MinGW\cross-mingw.gcc446.generic.20101013\i686-pc-mingw32\include
[FFmpeg install directory /include folder]

Leave configuration as Debug

Configuration Properties->C/C++->Preprocessor
Under 'Preprocessor Definitions', remove HAALISOURCE

Configuration Properties->Linker
Under 'Additional Dependencies' add:
vfw32.lib
libgcc.a
libmingwex.a
libcoldname.a
libz.a
libbz2.a
libpthreadGC2.a


Right-click on ffms2 Project in Solution Explorer. Select Build.

After it finishes, right-click on ffmsindex Project. Select Build.

[TheFluff]

That looks mostly correct to me, but you shouldn't need to add the extra libs to the additional dependencies like that; they should be autoadded via libs.cpp (except libbz2.a, which is not in there). What do you need vfw32.lib for anyway? Also, I think you should use libmoldname.a and not libcoldname.a.

[TheRyuu]

However, I just tried something else (with a smaller file I'd meant to use as a sample

Can you upload the sample anyway?

Edit:
If you can't compile ffms2, here's a debug build for you: http://warpsharp.info/ffms2/ffms2-r519-debug.7z

[qyot27]

The sample and the HCenc profile used: http://www.mediafire.com/?95ngx1h5nl2znat

It can be seen with HCenc 0.25 or 0.26 beta.

ffmsindex test.flv
echo FFVideoSource("test.flv",fpsnum=30000,fpsden=1001).BilinearResize(720,480)>test.avs
hcenc_026 -i test.avs -o test.m2v -ini "testprof.ini"

[zerowalker]

Can you use this, to decode Fraps files correctly?
I have tried, it becomes YV12 (but it should be Yuy2 as far as i know), and it takes alot of time, as with avisource it takes a sec, but it decodes to RGB32 thanks to Fraps Decoder,

[Myrsloik]

Can you use this, to decode Fraps files correctly?
I have tried, it becomes YV12 (but it should be Yuy2 as far as i know), and it takes alot of time, as with avisource it takes a sec, but it decodes to RGB32 thanks to Fraps Decoder,

Which version of ffms2 did you use? Can you make a short sample and upload somewhere that shows the same behavior?

[zerowalker]

i downloaded from the google project site, so probably latest, was made the 3rd i think.
Well don´t think i need to send a sample, just fraps anyting;P
But isn´t it supposed to be in Yuy2, cause everyone i asked told me it should be, and i read that FFVideoSource was suppose to decode it right, without the upsampling that the fraps decoder do.
But when i use FFvideosource("fraps") it becomes YV12, atleast Avspmod tells me so, and RGB32 with AviSource.

[Myrsloik]

Fraps is only YV12 or RGB24, do your homework next time.

...and don't ask whoever you asked ever again about video related things.

[zerowalker]

Okay, hmm, can i ask how you are sure about it?
Cause i can´t find and definite answer except for believing what people are saying.
You say YV12 or RGB24, and the ones in CCCP forum and another place att sourceforge said Yuy2.
I also read it´s YV12 Full Range, which i why i convert from RGB32 (with avisource) to .ConvertToYV12(matrix="Rec709").

Sorry didn´t want to Hijack this thread or anything, but as you seems to know about it, it would be nice to be done with it.

[Myrsloik]

Okay, hmm, can i ask how you are sure about it?
Cause i can´t find and definite answer except for believing what people are saying.
You say YV12 or RGB24, and the ones in CCCP forum and another place att sourceforge said Yuy2.
I also read it´s YV12 Full Range, which i why i convert from RGB32 (with avisource) to .ConvertToYV12(matrix="Rec709").

Sorry didn´t want to Hijack this thread or anything, but as you seems to know about it, it would be nice to be done with it.

All I did was read the source for the libav decoder, which only support full range yv12 and rgb24 output... and that must be right since it decodes properly

(note: you can't really trust what vfw decoders output, they have a tendency to pick a different output format than what the actual contents are in)

[zerowalker]

Sorry but what is VFW decoder, i heard of it, but which one is it?
The fraps or the FFVideo?
Thanks for helping out:)

EDIT: and why does it take a year for FFVideoSource to load the fraps movie when AviSource take a sec?

[Plorkyeran]

FFVideoSource indexes the file, which requires reading the entire video from disk, while AviSource trusts the index in the file.

[zerowalker]

Ah i see, thanks.
Is there a way to prevent the indexing?

And found out that FFVS makes the Fraps movies alot darker (all decoders except fraps does that i think), so i guess i have to do with the upsampling and downsampling anyhow.

[Rumbah]

It's because Fraps uses full range but your players/encoders expect tv range. You can change it with e.g. Colormatrix.

[Myrsloik]

Ah i see, thanks.
Is there a way to prevent the indexing?


No. That is the whole point of ffms2.

If indexing bothers you so much just go use the official fraps vfw decoder or ffdshow's vfw decoder.

[zerowalker]

No. That is the whole point of ffms2.

If indexing bothers you so much just go use the official fraps vfw decoder or ffdshow's vfw decoder.

Oh didn´t know that, soz:)

And i see, will try with colormatrix:)

But is there anyway to speed indexing upp, cause if i take many videos, let´s say 15. It takes a Really long time, so if there is a way to reduce the time, please tell.

Thanks for the help guys:)!

[Myrsloik]

Oh didn´t know that, soz:)

And i see, will try with colormatrix:)

But is there anyway to speed indexing upp, cause if i take many videos, let´s say 15. It takes a Really long time, so if there is a way to reduce the time, please tell.

Thanks for the help guys:)!

May I suggest buying an SSD or maybe a bit of RAID?

[zerowalker]

Ah, if it´s can´t be reduced by software or how to put it, i will just go with it as it is:)
Didn´t mean to be rude against the plugin or what to say or anything, i am just not to good with this things.
But thank you all for helping out, appreciate it:)

[Dogway]

Is it normal the green color cast when resizing with ffvideosource?

[LigH]

Details, please: Color format, scaling function, source and target rectangles ... ?

[TheRyuu]

Is it normal the green color cast when resizing with ffvideosource?

I think without any context (unless I missed something) all I see in this post is a fail attempt at a question in fairly mangled english that I really don't understand.

[Dogway]

for the record:
I think without any context (unless I missed something) all I see in this post is a fail attempt at a question in fairly mangled english that I really don't understand.
@TheRyuu: You can also read it as "I observed a green color cast when resizing with ffvideosource, is this normal?" c'mon it's not that hard ; )

LigH, I didn't post any details because it happens with different sources, so its more likely to be a ffms2 issue. None the less I can show some examples for skepticals.

You can use a video of your own, or use my example.
http://www.mediafire.com/?h12ccly94edg249
Frame 6:

setmtmode(5,2)
ffvideosource("VTS_02_0.demuxed.m2v",width=360,height=240,resizer="SPLINE")
#~ setmtmode(2,2)
#~ Spline36Resize(width/2,height/2)

and yes I'm aware SPLINE is not Spline36 :)

http://i212.photobucket.com/albums/cc35/Dogway/Misc/th_source.png (http://i212.photobucket.com/albums/cc35/Dogway/Misc/source.png)http://i212.photobucket.com/albums/cc35/Dogway/Misc/th_Spline36.png (http://i212.photobucket.com/albums/cc35/Dogway/Misc/Spline36.png)http://i212.photobucket.com/albums/cc35/Dogway/Misc/th_FFSPLINE.png (http://i212.photobucket.com/albums/cc35/Dogway/Misc/FFSPLINE.png)

[kemuri-_9]

does it still occur if you split the resizing out of FFVideoSource directly and use SWScale to resize with instead?

[Dogway]

I don't use that resizer, so I don't know, but if it helps it also occurs using lanczos in ffvideosource.
Now this is sounding like I am the only one with this problem? Tell me so I can search what is causing it...

[TheFluff]

I can reproduce the problem, and it's a bug in libswscale's spline and lanczos resizers. The more you downsize an image with either of them, the greener it gets. Try something like bicubicresize(width*4,height*4).swscale(320,240,"SPLINE") for hilarious results.

As a workaround, either use Avisynth's resizers, or use swscale's bicubic resizer (which doesn't have the problem).

[Dogway]

I also wouldn't expect an unconstructive reply as I had above. Im resizing from 1080p to 480p and it takes time so I expected to gain some speed resizing inside ffms2, I will have a look at swscale (never used) but these days I'm busy and I thought the developers would be more thankful than annoyed when someone reports a bug of their tools. I will check whether spline36/16 is fast enough for my task.

[henryho_hk]

Unless it is a 24fps or 23.976fps "film" footage, I would say 99% of the chance you need deinterlacing (or, rarely for bluray, ITVC) before resize. And since you are downsizing from 1080p to 480p, ffmpeg's builtin 5-tap-low-pass or ffmpeg-deint should work pretty well.

And would ppls please mind your net manner.

[kemuri-_9]

I also wouldn't expect an unconstructive reply as I had above. Im resizing from 1080p to 480p and it takes time so I expected to gain some speed resizing inside ffms2, I will have a look at swscale (never used) but these days I'm busy and I thought the developers would be more thankful than annoyed when someone reports a bug of their tools. I will check whether spline36/16 is fast enough for my task.


We can't magically fix serious problems in ffmpeg.
If you want these types of problems fixed you need to file bug reports against ffmpeg.
And as TheFluff indicates, the problem is a serious bug in ffmpeg - specifically libswscale, its not in an area we have to fix.

With the bug being in libswscale's resizers itself, SWScale is equally bugged - as it's just libswscale exposed as an avisynth filter, so don't use it either.

[Dogway]

nono, I'm ok by just being aware, I don't want you to fix them, that's ffmpeg business (right?), but by allowing ffms2 to use bugged features I understand it also supports them, you know...

[cretindesalpes]

I tried to replace the r473 I was successfully using with r517 but FFVideoSource seems to have now random crashes in its destructor. It's not a huge problem because x264 seems to finalize the output file before deleting the avisynth instance so nothing is lost, but it gets stuck with debugging dialogs which is a more serious issue if you let your computer do a batch processing overnight.

I tried with avisynth 2.5.8 MT, with and without activating the MT modes. It occured with different scripts so I don't think it's caused by a rotten plugin. I also tried with threads=1 in FFVideoSource but to no avail. The read files were lossless AVC MP4 produced with x264. I'll try to do more testing later to make this bug as reproducible as possible.

[TheRyuu]

The read files were lossless AVC MP4 produced with x264. I'll try to do more testing later to make this bug as reproducible as possible.

Why are you using mp4 for h264 lossless that you're just going to read in with ffms2 anyway?

[cretindesalpes]

Why not? Is there a contraindication?

[TheRyuu]

Why not? Is there a contraindication?

There's no reason no to use mkv, which means you should use mkv.

[cretindesalpes]

Well, does that mean you're not interested in this issue?

[TheFluff]

nono, I'm ok by just being aware, I don't want you to fix them, that's ffmpeg business (right?), but by allowing ffms2 to use bugged features I understand it also supports them, you know...

I wasn't aware of the issue until you reported it. I filed a bug report (https://bugzilla.libav.org/show_bug.cgi?id=33) with libav, that's pretty much all I can do right now. I suggested two possible workarounds for you until the libav devs can fix the issue.


I tried to replace the r473 I was successfully using with r517 but FFVideoSource seems to have now random crashes in its destructor. It's not a huge problem because x264 seems to finalize the output file before deleting the avisynth instance so nothing is lost, but it gets stuck with debugging dialogs which is a more serious issue if you let your computer do a batch processing overnight.

I tried with avisynth 2.5.8 MT, with and without activating the MT modes. It occured with different scripts so I don't think it's caused by a rotten plugin. I also tried with threads=1 in FFVideoSource but to no avail. The read files were lossless AVC MP4 produced with x264. I'll try to do more testing later to make this bug as reproducible as possible.
What is a "random crash"? Does it mean it only crashes sometimes? If you have a sample file that always crashes, please upload it and we'll take a look.

[cretindesalpes]

Does it mean it only crashes sometimes?
Yes, from very rarely to always, depending on the script and the loaded files.

I found a configuration crashing almost always (on my computer at least) and put it here:
http://dl.free.fr/kHxsHUKoR

f = "crash-clip.mp4" # 100 frames
a = FFVideoSource (f)
b = FFVideoSource (f)
c = FFVideoSource (f)
l = a.FrameCount ()
b + a + c
Trim (l, -10) + last.BlankClip (length=1500-20) + Trim (l*2-10, -10)

EDIT:

I also tried with
- ffms2-r519-jeeb.7z: crash with ffms2-ffmpeg.dll and ffms2-libav.dll
- ffms2-r519-debug.7z: no crash
- ffms2-r507.7z: no crash
- ffms2-r494.7z: no crash

[TheFluff]

Yes, from very rarely to always, depending on the script and the loaded files.

I found a configuration crashing almost always (on my computer at least) and put it here:
http://dl.free.fr/kHxsHUKoR

f = "crash-clip.mp4" # 100 frames
a = FFVideoSource (f)
b = FFVideoSource (f)
c = FFVideoSource (f)
l = a.FrameCount ()
b + a + c
Trim (l, -10) + last.BlankClip (length=1500-20) + Trim (l*2-10, -10)

EDIT:

I also tried with
- ffms2-r519-jeeb.7z: crash with ffms2-ffmpeg.dll and ffms2-libav.dll
- ffms2-r519-debug.7z: no crash
- ffms2-r507.7z: no crash
- ffms2-r494.7z: no crash

I can reproduce the issue, and with Myrsloik's assistance I think I have fixed it. You can try this build (http://mod16.org/ffms2/ffms2-r526.7z) if you want to test it yourself.

Furthermore, I wish very much everyone was as good as you are at reporting bugs. Your detailed report and test case made it very easy to find the bug.

[cretindesalpes]

I can reproduce the issue, and with Myrsloik's assistance I think I have fixed it. You can try this build (http://mod16.org/ffms2/ffms2-r526.7z) if you want to test it yourself.
Thank you very much, I did a few tests with this new version and had no problem so far. I notice ffmsindex.exe is missing from this package, shall I take the one contained in r517?

[TheFluff]

Thank you very much, I did a few tests with this new version and had no problem so far. I notice ffmsindex.exe is missing from this package, shall I take the one contained in r517?

Whoops, I missed including it. But yes, the one from r517 should work fine with this version too. There have been no API/ABI changes nor any changes to ffmsindex itself.

[TheFluff]

New test build: ffms2-r532.7z (http://mod16.org/ffms2/ffms2-r532.7z)
Edit: now with 100% more pthreads thanks to Myrsloik.

We're slowly working on trying to fix enough bugs to motivate a release of 2.16, so test everything, submit all your weirdest sample files and win a prize if it causes a reproducible crash. Test audio in particular since we've been messing around with that a lot lately.

[TheRyuu]

Yet another new test build: ffms2-r533.7z (https://ffmpegsource.googlecode.com/files/ffms2-r533.7z)

All of the above plus this should fix the invalid postprocess bug (for good). Go forth and test.

[TheFluff]

FFMS 2.16 has been released. It is mostly a bugfix release, but it adds a few features as well; most importantly full support for YUV 4:4:4 as well as high bitdepth YUV.

The following downloads are now available:

ffms-2.16.7z (http://code.google.com/p/ffmpegsource/downloads/detail?name=ffms-2.16.7z) - the usual binary. Includes multithreaded decoding functionality; you do no longer need a special -mt version.
ffms-2.16-x64.7z (http://code.google.com/p/ffmpegsource/downloads/detail?name=ffms-2.16-x64.7z) - 64-bit version, for use with avs64. Note that it is a native Avisynth plugin now; no need for LoadCPlugin or LoadStdcallPlugin.
ffms-2.16-src.tar.bz2 (http://code.google.com/p/ffmpegsource/downloads/detail?name=ffms-2.16-src.tar.bz2) - source code.
ffms-2.16_SDK.7z (http://code.google.com/p/ffmpegsource/downloads/detail?name=ffms-2.16_SDK.7z) - package for Windows developers who want to develop programs that use FFMS2 but don't want to deal with MinGW.


Full changelog since 2.15:

Reimplemented output colorspace selection, this should fix all issues with the avisynth plugin when opening yuv420p10 or yuv444 material plus several other less common cases. (Myrsloik)
Added FFMS_SetOutputFormatV2 to the API. This function allows you to specify PixelFormats >= 64 for use as output. (Myrsloik)
Fixed a serious bug that could cause crashes and completely useless index files with h264 in matroska. (Myrsloik)
Automatically detect number of decoding threads. The avisynth video source funtion already did this, now moved so the api can use it as well. (TheRyuu)
Re-add the ability to target x64 with msvc since it's a bit more sane now. (TheRyuu)
Fixed a bug that could cause crashes when reading audio if FFMS2 was compiled with GCC. (Myrsloik)
ffmsindex will no longer crash if it cannot open the file given to it for indexing. (TheFluff)
FFMS2 will no longer crash if the video decoder feeds it an empty frame (can sometimes happen when using lots of decoder threads); you'll get a nice error message instead. (TheFluff)
The C-plugin can now act as both an Avisynth 2.6 plugin (including support for new colorspaces) as well as an Avisynth 2.5 one, in the same binary. (kemuri_-9)
Fixed an issue that could cause opening Vorbis audio to fail because FFMS2 couldn't find an initial valid PTS. (TheFluff)
FFMS2 will no longer crash if forced or tricked into using an index file generated by a FFMS2 version compiled for a different architecture. (TheRyuu)
Fixed a crash when the last frame was requested using the Avisynth plugin's forced CFR mode. (Plorkyeran)
Fixed various issues with decoding audio from the Ogg container without Haali's splitter. (Myrsloik, TheFluff)
Fixed the "invalid postprocessing settings"; they were caused by a parsing bug in libpostproc, and a workaround has been added. (Myrsloik)
Tinkered a bit with the non-MSVS build system. (Daemon404, Kovensky)


Important notice for postprocessing users:
Support for postprocessing in FFMS2 will be dropped in the next release. The reason is that both libav is dropping the libpostproc library from their own releases, and so we cannot continue supporting it.

[TheRyuu]

Could you also upload an x64 version? I use it to mix video clips, but a 32-bit version of Avisynth cannot be used - no memory...

I'll probably get to it later today or tomorrow.

[chipzoller]

I'm not sure if this thread also doubles as the "official" support thread and so hate to cross-post, but I'm having an issue with 2.16 throwing "decoder returned an empty frame". Original thread is here and will gladly merge/delete if desired: http://forum.doom9.org/showthread.php?t=162391

[TheFluff]

I'm not sure if this thread also doubles as the "official" support thread and so hate to cross-post, but I'm having an issue with 2.16 throwing "decoder returned an empty frame". Original thread is here and will gladly merge/delete if desired: http://forum.doom9.org/showthread.php?t=162391

This thread isn't the officially designated anything, really, but if you want to be sure your questions are seen by one of the devs this is the place to post (most of us do prowl the rest of the forums from time to time as well, though). You can chill here as much as you want and ask about whatever you like, as long as you take off your shoes before entering and don't act like a dick.

As for your problem: as I posted in the other thread, it turns out libavcodec doesn't support interlaced VC-1 at all (yet), so unfortunately we cannot help you. You'll have to turn to some other source plugin.

[qyot27]

When cross-compiling the C plugin, the recent version.sh-related changes result in the .dll being built as ffms.dll instead of ffms2.dll. On Windows this isn't an issue, because of MSys' bash quirks or file permissions for NTFS always being executable or something.

This is the problematic section:
version=`version.sh`
API=$(echo $version | cut -f 1 -d '.')
On Linux, this results in version.sh not being found when configure gets called (so the version info is left blank and the '2' isn't inserted into the filename of the .dll), and even when having used chmod +x on version.sh, it seems to still not want to add it as an environment variable.

I managed to fix it (and have it work on both Windows and Linux), by commenting out the version ENV line and adjusting the API variable to use version.sh's filename directly:
#version=`version.sh`
API=$(echo $(./version.sh) | cut -f 1 -d '.')

[kemuri-_9]

oops -> fixed

[henryho_hk]

why not simply

API=$(./version.sh | /bin/cut -f 1 -d '.')

[Chumbo]

I'll probably get to it later today or tomorrow.
Thank you.

[TheRyuu]

ffms-2.16-x64.7z (http://code.google.com/p/ffmpegsource/downloads/detail?name=ffms-2.16-x64.7z) - 64-bit version, for use with avs64. Note that it is a native Avisynth plugin now; no need for LoadCPlugin or LoadStdcallPlugin
ffms-2.16_SDK.7z (http://code.google.com/p/ffmpegsource/downloads/detail?name=ffms-2.16_SDK.7z) - updated to now include the 64-bit stuff.

Little late.
Have at it.

[Chumbo]

ffms-2.16-x64.7z (http://code.google.com/p/ffmpegsource/downloads/detail?name=ffms-2.16-x64.7z) - 64-bit version, for use with avs64. Note that it is a native Avisynth plugin now; no need for LoadCPlugin or LoadStdcallPlugin
ffms-2.16_SDK.7z (http://code.google.com/p/ffmpegsource/downloads/detail?name=ffms-2.16_SDK.7z) - updated to now include the 64-bit stuff.

Have at it.
Very much appreciated.

[Chumbo]

It seams, a 64-bit version creates incorrect indexes. I get audio position error messages or program response lost (most cases) using VirtualDub. My videos are x264-10bit encoded .mkv with a pcm audio ~ 15-30 minutes and joined using v1++v2++v3++v4... I cannot change a view position in all cases. Deleting of index files do not resolve the situation - seems indexes are not valid.

A x86 version works as charm. Also in some cases a 64 bit version uses a 32-bit-generated index files. Also switching an edition produces every reindex. It is very bad, because eats a time. Please do not overwrite existing indexes, if they are exist and creates by a wrong edition. Create a new one with a different extension or save a new portion in the same file. Or (the best solution) - use the same file format for x64 and x86 edition.

So, I returned to x86 with temp lossless files :(
It shouldn't overwrite an existing index file unless you're using the -f switch.

[TheRyuu]

Also in some cases a 64 bit version uses a 32-bit-generated index files.
Are you sure about this? It should never happen (it will detect the incompatibility and reindex).

use the same file format for x64 and x86 edition.
Indeed. It's been suggested before but no real work has been done on it yet.

It shouldn't overwrite an existing index file unless you're using the -f switch.
If you directly use ffvideosource it will overwrite without asking.

[TheFluff]

It seams, a 64-bit version creates incorrect indexes. I get audio position error messages or program response lost (most cases) using VirtualDub. My videos are x264-10bit encoded .mkv with a pcm audio ~ 15-30 minutes and joined using v1++v2++v3++v4... I cannot change a view position in all cases. Deleting of index files do not resolve the situation - seems indexes are not valid.

A x86 version works as charm. Also in some cases a 64 bit version uses a 32-bit-generated index files. Also switching an edition produces every reindex. It is very bad, because eats a time. Please do not overwrite existing indexes, if they are exist and creates by a wrong edition. Create a new one with a different extension or save a new portion in the same file. Or (the best solution) - use the same file format for x64 and x86 edition.

So, I returned to x86 with temp lossless files :(

Provide a sample file.

Regarding indexes: neither the Avisynth plugin nor ffmsindex.exe will treat an index file that was created with a different architecture as valid. As far as they are concerned the index file might as well never have existed at all. Thus, such an index file will always be silently overwritten.
Valid index files that were created with the same version of FFMS2 as the one doing the reading do have some degree of protection, but only if you specified the filename for the index file explicitly. Otherwise they too will be overwritten if they don't match the media file.

[TheFluff]

I have catched this bug on a simple x264-encoded file. Instructions, scripts, files, versions, screenshots are here: http://media.namerenie.info/bug/
It is my home PC, so please download them within these days.

Also please look at the bug with my file from a Sony NEX-5 (rewrapped to mkv). I cannot open it at all using ffms2.

Sorry for the big files.

I've downloaded the files but I won't have time to investigate until Sunday. I'll get back to you if nobody else has found the bug by then.

[Chumbo]

...
Indeed. It's been suggested before but no real work has been done on it yet.
...
+1 to use the same file format for both x86/x64 please.
If you directly use ffvideosource it will overwrite without asking.
Would you kindly add this to the "wish list" to change please so ffvideosource would not recreate the index file automatically? So right now there's no point to use the CLI if using ffvideosource. Maybe add an input parameter to ffvideosource force recreating the index which defaults to not doing so if the file already exists. Thank you.

[Myrsloik]

+1 to use the same file format for both x86/x64 please.

Would you kindly add this to the "wish list" to change please so ffvideosource would not recreate the index file automatically? So right now there's no point to use the CLI if using ffvideosource. Maybe add an input parameter to ffvideosource force recreating the index which defaults to not doing so if the file already exists. Thank you.

Hint: just specify the index name if you really have to mix stuff like that

Also, x86/x64 will probably never use the same index format or at least the work for doing so would require reading piles of libav code to check so it really does behave identically

[TheFluff]

Another bug. I use my function FF_Clip() from my previous bugreport with an x86 version.
I get "FFVideoSource: Insanity detected: decoder returned an empty frame" after this code:

SelectRangeEvery(50, 1, 0, false)

and some processing time on every my h264 source.

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.

edit: since you're already wrapping ffvideosource() etc and are dynamically loading ffms2.dll, it'd be pretty simple for you to add a global "is_x64" variable and add an arch-specific filename suffix to the index files based on that. That'd at least solve your problems with index files overwriting each other.

[TheFluff]

But they are really exist. I able to point to the bug-catched fame by direct point in vdub using a timeline. This message is only when I process frames from one to one.

I don't doubt that you're having the issue, I'm just saying that the bug is probably inside libavcodec, not in FFMS2 itself. Try with threads=1 as I suggested and see if the issue is still there.

I haven't had time to look at your samples yet, but I'll do that Soon(tm).

[TheRyuu]

ffms2-r555.7z (http://ffmpegsource.googlecode.com/files/ffms2-r555.7z)

Libav 273aab9
Most notable change is a fix in libav for unbreaking certain VC1 decoding.

[Midzuki]

ffms2-r555.7z (http://ffmpegsource.googlecode.com/files/ffms2-r555.7z)

Libav 273aab9
Most notable change is a fix in libav for unbreaking certain VC1 decoding.

:goodpost:

and

:thanks: :thanks: :thanks:

[TheRyuu]

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

This is the cplugin version of ffms 2.16.
LoadCPlugin(X:\path\to\ffms2.dll")

This archive contains BOTH 32-bit and 64-bit binaries. The primary use for this is access to the new colorspaces provided by avisynth 2.6. This plugin is also compatible with 2.5x.

[TheRyuu]

ffms2-r559.7z (http://ffmpegsource.googlecode.com/files/ffms2-r559.7z)

Libav 3a78fb5

More correct handling of colorspace/range flags. No longer rescales fullrange to limited range.

[TheFluff]

I have catched this bug on a simple x264-encoded file. Instructions, scripts, files, versions, screenshots are here: http://media.namerenie.info/bug/
It is my home PC, so please download them within these days.

Also please look at the bug with my file from a Sony NEX-5 (rewrapped to mkv). I cannot open it at all using ffms2.

Sorry for the big files.

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.

[Chumbo]

ffms2-r559.7z (http://ffmpegsource.googlecode.com/files/ffms2-r559.7z)

Libav 3a78fb5

More correct handling of colorspace/range flags. No longer rescales fullrange to limited range.
Is a 64bit version available? Thanks.

[TheFluff]

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

Note that this stuff isn't officially supported; it will not be committed to SVN and will not be in official releases. All of the FFMS developers agree that such hacks are not the way to go. If you want to go further with this, the 7z contains a patch for the FFMS2 source code so you can create your own fork if you enjoy this sort of stuff.

[jmac698]

@fluff
Hey, thanks! Saves me some time, I was going to try to compile that but was busy.
Anyhow, it turns out that a straight 16bit word is quite acceptable, I found out recently. To quote chikuzen,

cd /d d:\sintel_rgb48
ffmpeg -f image2 -i %08d.png -pix_fmt yuv444p16le -vcodec rawvideo -an -f rawvideo d:\sintel_raw_yuv\yuv444p16le.yuv

#read_16bit_yuv.avs
LoadPlugin("RawSource26.dll")
LoadPlugin("flash3kyuu_deband.dll")
RawSource("d:\sintel_raw_yuv\yuv444p16le.yuv", width=2048, height=436, fpsnum=24, fpsden=1, pixel_type="i444")
f3kdb_dither(stacked=false)

I like your method though because we can use 2.58 (I've been told 2.6 isn't ready for production; anyhow I put a lot of work into verifying the operations for my very accurate scientific work).

[mp3dom]

RawSource 2.6 is for AviSynth 2.6.
The version for AviSynth 2.58 is here: http://www.mediafire.com/?3bmwyi1lztt4h1j

[kolak]

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

Note that this stuff isn't officially supported; it will not be committed to SVN and will not be in official releases. All of the FFMS developers agree that such hacks are not the way to go. If you want to go further with this, the 7z contains a patch for the FFMS2 source code so you can create your own fork if you enjoy this sort of stuff.


It looks like it's always only 8bit. Should it work with v210 mov?

[TheFluff]

It looks like it's always only 8bit. Should it work with v210 mov?

If outputs something that isn't 8-bit it should be immediately obvious to you because it'll be double height and the lower half will be full of LSD hallucinations. On the flip side, if it outputs 8-bit it's because you didn't explicitly set the colorspace correctly. Read my post again. On a side note it would be great if you could learn to edit posts instead of posting five times in a row.

Now, please take the unrelated rawsource and high bitdepth general discussion out of this thread and somewhere else, as it isn't related to FFMS2.

[mp3dom]

Is it normal that this hacked version of FFMS outputs different LSB than the ReadV210mod method? In FFMS the LSB is anyway 'visible' (hallucinated colors, but the image is 'identified') while the ReadV210mod outputs generally all green (similar to component 'green' tint) and some unrecognized patterns. Shouldn't both produce the same output? (For reference the input was a V210 file)

[kolak]

If outputs something that isn't 8-bit it should be immediately obvious to you because it'll be double height and the lower half will be full of LSD hallucinations. On the flip side, if it outputs 8-bit it's because you didn't explicitly set the colorspace correctly. Read my post again. On a side note it would be great if you could learn to edit posts instead of posting five times in a row.

Now, please take the unrelated rawsource and high bitdepth general discussion out of this thread and somewhere else, as it isn't related to FFMS2.

I prefer to write new post if it provides bit different information than original ( I deleted useless posts).

Hmmm- I just downloaded your moded version and used your cmd line with v210 mov. I could see normal video, but not really :) Rest was not seen because my laptop has to small resolution- had to change preview in Vdub to 25%- sorry :)

So now I can confirm that it does work with v210 mov or at least it shows something in low bits.

Does ffvideosource support ProRes and DNxHD 10bit decoding, so I can use it to pass 10bit to dither directly in avisynth?


update: it produces output with banding, so not sure if it works.

Thanks,
Andrew

[TheFluff]

Is it normal that this hacked version of FFMS outputs different LSB than the ReadV210mod method? In FFMS the LSB is anyway 'visible' (hallucinated colors, but the image is 'identified') while the ReadV210mod outputs generally all green (similar to component 'green' tint) and some unrecognized patterns. Shouldn't both produce the same output? (For reference the input was a V210 file)

It's entirely possible that it's a bug. I'm not completely sure the code that gets the LSB part is correct. I will not maintain this patch however, so if you want it investigated you'll have to do it yourself. The relevant code is on line 61 of the included patch; I think I got the LSB case wrong and the Right Thing would be to shift away the MSB before casting to uint8_t.

Does ffvideosource support ProRes and DNxHD 10bit decoding, so I can use it to pass 10bit to dither directly in avisynth?
It should support both ProRes and DNxHD. 10-bit ProRes should be supported but I dunno about DNxHD, try it and find out I guess. If it produces banding that's probably a result of swscale being retarded.

[kolak]

It's entirely possible that it's a bug. I'm not completely sure the code that gets the LSB part is correct. I will not maintain this patch however, so if you want it investigated you'll have to do it yourself. The relevant code is on line 61 of the included patch; I think I got the LSB case wrong and the Right Thing would be to shift away the MSB before casting to uint8_t.


It should support both ProRes and DNxHD. 10-bit ProRes should be supported but I dunno about DNxHD, try it and find out I guess. If it produces banding that's probably a result of swscale being retarded.

Something is not right. You can see difference here:

http://forum.doom9.org/showthread.php?p=1528674#post1528674

My laptop screen is so crap- need to see it at work on proper monitor :)

10bit DNxHD decoding/encoding is supported in latest ffmpeg/ffmbc. ProRes 10bit decoding seams to be also stable- tested on few different files.


Andrew

[cretindesalpes]

Suggested modification, just by looking at the patch code. I not even tried to compile it:
// we need to iterate over the source buffer twice; once to get the MSB and once to get the LSB.
//for (int i = 1; i >= 0; i--) {
uint16_t *SrcP = (uint16_t*)Frame->Data[p];
int height = (p == 0) ? Frame->ScaledHeight : Frame->ScaledHeight / 2; // remember UV planes are half height
const int lsb_offset = height * DstPitch;
for (int y = 0; y < height; y++) {
for (int x = 0; x < (Frame->Linesize[p] / 2); x++) { // assume 2 bytes per pixel
// wouldn't it have been nice if we could just use Env->BitBlt()...?
if (x >= DstPitch) {
*SrcP++; // advance the source pointer until we hit the next line
continue;
}
// I sure hope a shift by 0 gets optimized away by the compiler...
// *DstP++ = (uint8_t)(*SrcP++ >> (2*i)); // yuv420p10le uses the 10 least significant bits. shift right by 2 to get the 8 most significant ones.
const int data10 = *SrcP++;
*DstP = (uint8_t)(data10 >> 2);
DstP [lsb_offset] = (uint8_t)(data10 << 6);
++ DstP;
}
}
//}

Actually I'm not sure if Frame->ScaledHeight always equals VI.height / 2, but I supposed it does. If not, lsb_offset calculation has to be changed.

[TheFluff]

Suggested modification, just by looking at the patch code. I not even tried to compile it:
// we need to iterate over the source buffer twice; once to get the MSB and once to get the LSB.
//for (int i = 1; i >= 0; i--) {
uint16_t *SrcP = (uint16_t*)Frame->Data[p];
int height = (p == 0) ? Frame->ScaledHeight : Frame->ScaledHeight / 2; // remember UV planes are half height
const int lsb_offset = height * DstPitch;
for (int y = 0; y < height; y++) {
for (int x = 0; x < (Frame->Linesize[p] / 2); x++) { // assume 2 bytes per pixel
// wouldn't it have been nice if we could just use Env->BitBlt()...?
if (x >= DstPitch) {
*SrcP++; // advance the source pointer until we hit the next line
continue;
}
// I sure hope a shift by 0 gets optimized away by the compiler...
// *DstP++ = (uint8_t)(*SrcP++ >> (2*i)); // yuv420p10le uses the 10 least significant bits. shift right by 2 to get the 8 most significant ones.
const int data10 = *SrcP++;
*DstP = (uint8_t)(data10 >> 2);
DstP [lsb_offset] = (uint8_t)(data10 << 6);
++ DstP;
}
}
//}

Actually I'm not sure if Frame->ScaledHeight always equals VI.height / 2, but I supposed it does. If not, lsb_offset calculation has to be changed.

Yes, that does the LSB part right, I think. I'm not sure if it's faster though, since you do the extra step of assigning the result to a temporary variable. On the other hand, maybe the compiler is smart enough to optimize that out.

[kolak]

Can you compile it with these fixes, please.

Thanks,
Andrew

[jmac698]

Kolak, I made a new readv210.

[kolak]

Where :)?
Saw one but it was only for grayscale not?

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

[TheFluff]

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.

FFMS2 does not support any channel mixing operations at all, because libavcodec doesn't support that sort of stuff either. Adding some simple audio processing options such as resampling, bitdepth conversion and channel mixing (either via an external library or via our own code) has been on the todo list for a long time. The reason we support colorspace conversion and resizing is that ffmpeg comes with libswscale.

Video postprocessing is mostly the same thing, it's provided via libpostproc and we don't have any control over what features it supports. Not that it matters, because the ffmpeg devs hate it and are going to remove it, and thus so are we.

[TheFluff]

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.

If that's supposed to be a bug report I'll have to say it's a remarkably bad one. At least have the decency to include a sample file and a screenshot.

That being said, AFAIK MPEG2 decoders are not required to have bit-exact output so it's not entirely surprising that two different decoders could have subtly different outputs.

[MatLz]

If that's supposed to be a bug report I'll have to say it's a remarkably bad one. At least have the decency to include a sample file and a screenshot.
On all mpeg2 I can have (dvd rips, dvb recordings, fresh HCEnc encodes...)


That being said, AFAIK MPEG2 decoders are not required to have bit-exact output so it's not entirely surprising that two different decoders could have subtly different outputs.Dunno... I thought they should output identical thing, like avc ones do.

[TheRyuu]

Dunno... I thought they should output identical thing, like avc ones do.

iDCT bro.

[TheFluff]

Dunno... I thought they should output identical thing, like avc ones do.

MPEG2 does not specify exactly how the IDCT algorithm should work. Bit-exact decoding is not required. Ever noticed how you can choose between like five different IDCT algorithms in DVD2AVI? Yeah, all of those give different outputs.

See also http://guru.multimedia.cx/the-mpeg124-and-h26123-idct/

[LigH]

Something similar (but not related to iDCT) happened between DivX 5.02 and 5.03 too, probably a change in the rounding (Oct. 2003 (http://forum.doom9.org/showthread.php?p=384974#post384974)). That resulted in what I called "orange-blue bug". But quite soon after I reported it (March 2004 (http://forum.doom9.org/showthread.php?p=458322#post458322)), ffdshow was able to adapt its decoding.

[TheFluff]

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 don't think you ever got an official reply to this, but Chikuzen is correct; FFMS2 does not support uncompressed formats (because libavcodec handles them weirdly). Crashes are possible. Indexing such files should work just fine, but when I checked the MeGUI threa I did not see any indications that it's the indexing process itself that is crashing.

[TheFluff]

Something similar (but not related to iDCT) happened between DivX 5.02 and 5.03 too, probably a change in the rounding (Oct. 2003 (http://forum.doom9.org/showthread.php?p=384974#post384974)). That resulted in what I called "orange-blue bug". But quite soon after I reported it (March 2004 (http://forum.doom9.org/showthread.php?p=458322#post458322)), ffdshow was able to adapt its decoding.

Since you apparently need histogram("luma") to even see the differences MatLz is speaking of, it does not appear to be an issue of anywhere near that magnitude.

[MatLz]

The real visible things without enhancing the luma differences are mostly in flat areas.

Thx for the explanations.

Btw, could be possible to easily implement the ffms2 idct algorithm in mpeg2source ?
Using 1 thread (to be fair) does show it is 20% faster.

[TheRyuu]

The real visible things without enhancing the luma differences are mostly in flat areas.

Thx for the explanations.

Btw, could be possible to easily implement the ffms2 idct algorithm in mpeg2source ?
Using 1 thread (to be fair) does show it is 20% faster.

DGDecode or Mpeg2Dec3 are the recommended methods for sourcing mpeg2 material. For VOBS and transport streams I would trust them more than ffms2.

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.

Mpeg2Dec3 is normally faster than DGDecode especially when seeking. I prefer DVD2AVI's default choice (with mpeg2dec3) for all things mpeg2. YMMV and opinions also.

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

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

Cannot reproduce (http://puu.sh/82Iq) with r579 or one which was just compiled (which would have an updated libav).

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]

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]

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/svn/trunk/doc/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]

Another bug. I use my function FF_Clip() from my previous bugreport with an x86 version.
I get "FFVideoSource: Insanity detected: decoder returned an empty frame" after this code:

SelectRangeEvery(50, 1, 0, false)

and some processing time on every my h264 source.

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=commit;h=c10731e78b3ed89090b808b0919947f5729841c3
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.

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]

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

That sounds like it, yep.

[TheRyuu]

Fixed in r584 (http://code.google.com/p/ffmpegsource/source/detail?r=584).

[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 (http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=26ae9a5d7c448a3eb42641b546ee8d585ab716e6), 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 (http://git.libav.org/?p=libav.git;a=commit;h=0945eddec09d1c2b69643afc70377d86febc0591) 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).
http://thumbnails33.imagebam.com/16083/c666cf160825811.jpg (http://www.imagebam.com/image/c666cf160825811) http://thumbnails62.imagebam.com/16083/36824c160825846.jpg (http://www.imagebam.com/image/36824c160825846) http://thumbnails46.imagebam.com/16083/9740cb160825873.jpg (http://www.imagebam.com/image/9740cb160825873) http://thumbnails61.imagebam.com/16083/27b4c1160825933.jpg (http://www.imagebam.com/image/27b4c1160825933) http://thumbnails33.imagebam.com/16083/a16ffb160825974.jpg (http://www.imagebam.com/image/a16ffb160825974)
http://thumbnails22.imagebam.com/16083/8dff91160826010.jpg (http://www.imagebam.com/image/8dff91160826010) http://thumbnails50.imagebam.com/16083/a90217160826045.jpg (http://www.imagebam.com/image/a90217160826045) http://thumbnails33.imagebam.com/16083/fe0295160826098.jpg (http://www.imagebam.com/image/fe0295160826098) http://thumbnails27.imagebam.com/16083/bfcafc160826140.jpg (http://www.imagebam.com/image/bfcafc160826140) http://thumbnails47.imagebam.com/16083/4cd064160826173.jpg (http://www.imagebam.com/image/4cd064160826173)

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

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 (http://code.google.com/p/ffmpegsource/source/detail?r=588).

ffms2-r588.7z (http://code.google.com/p/ffmpegsource/downloads/detail?name=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 (http://git.libav.org/?p=libav.git;a=commit;h=0945eddec09d1c2b69643afc70377d86febc0591) 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.

[the_weirdo]

Thanks for the fix :thanks:

[TheRyuu]

Thanks for the fix :thanks:

It's not really fixed so consider it still broken! :D

[qyot27]

I've been working around this for a while now, but including r583 in a merge causes the C plugin to fail compilation. Leaving it out sidesteps the error and allows it to finish successfully.

svn merge http://ffmpegsource.googlecode.com/svn/trunk
C plugin compilation fails.

svn merge -r 583:head http://ffmpegsource.googlecode.com/svn/trunk
C plugin compilation succeeds.

[TheRyuu]

I've been working around this for a while now, but including r583 in a merge causes the C plugin to fail compilation. Leaving it out sidesteps the error and allows it to finish successfully.

svn merge http://ffmpegsource.googlecode.com/svn/trunk
C plugin compilation fails.

svn merge -r 583:head http://ffmpegsource.googlecode.com/svn/trunk
C plugin compilation succeeds.

Feel free to just keep it reverted locally, the problem which it was designed to fix only affects shared libs on linux as far as I know.

[qyot27]

Turns out the compilation error I was seeing was due to codectype.cpp not getting inserted into the Makefile, and so it was screwing up during the linking phase. Once I did that, it actually matched Issue 64 and so I just ifdeffed around UTVIDEO and it finished without errors. I'll need to use a fresh set of libs and see if that's still needed; the ones I used for the test were lying around from September, so it's no real wonder that Ut Video would be an issue for it.

[redfordxx]

Hi, according to my observation, there seems to be problem with pp="hb/vb:10:60" on non mod16 files.
My source was 712x360.x264.mkv (it shows wrong colors on left side, seems to be 8 pixels width...surprisingly)

Or is it only me?

But besides that, thank you for the fabulous tool.

[TheFluff]

Postprocessing is deprecated and will be removed in a future release (probably 2.18). Even if it wasn't, it's not our code so you'd have to complain to the FFmpeg people. They're going to remove libpostproc though, which is why we are deprecating it in the first place.

[redfordxx]

Too bad ... afaik FF makes deblocking based on info about quantization of the block, which is not possible later in the script.
So there will be no deblocking anymore? I thought the deblocking is part of the codec in case of AVC...

[kemuri-_9]

libpostproc is a completely independent framework of any decoder, therefore it has no information that a decoder could possibly offer to 'make the processing better'.

As such, libpostproc's deblocking and the deblocking within the h264 standard are distinct.

[burfadel]

Any new builds? :)

[TheFluff]

Any new builds? :)

Not at this very moment, but 2.17 is going to be released Real Soon Now.

[redfordxx]

libpostproc is a completely independent framework of any decoder

I see, so I thought it wrong all the time and it is not like MPEG2Source(cpu=4). I hope at least in that MPEG2 case I am correct when saying the deblocking is based on the quant information ;-)

[TheFluff]

I see, so I thought it wrong all the time and it is not like MPEG2Source(cpu=4). I hope at least in that MPEG2 case I am correct when saying the deblocking is based on the quant information ;-)

kemuri_-9 is at least partially wrong; while libpostproc is completely standalone, the pp_postprocess() function has parameters for passing in quantizer info, and FFMS2 does pass that information on from the decoder if it's available. I'm not sure exactly which decoders fill the quantizer tables in, but I'm pretty sure MPEG2 does, at least. So libpostproc can do quantizer-based deblocking for some codecs, just like MPEG2Source.

The h.264 inloop deblocking filter is a completely unrelated thing though, it's actually part of the decoding process and is implemented inside the decoder itself. Skipping it is technically a violation of the specification.

[TheRyuu]

ffms2-r624.7z (http://ffmpegsource.googlecode.com/files/ffms2-r624.7z)

It's the first proper build since 2.16 (proper meaning non-broken) and it's some what of a release candidate for 2.17 so all it really needs is a few days of testing by the masses. Built with libav rev. cf53a21.

Some changes to look forward to:

Reworked colormatrix and color range handling a bit, which fixed a bug that could cause FFMS2 to always output TV range even if the input was fullrange. (TheFluff)
The autotools build system can now create debug builds properly. (Daemon404)
Deprecated parts of the API will now cause compiler warnings when you use them. (TheFluff)
Added a FFMS_GetVersion function to the API (lets library users get the version number at runtime) and exposed it in Avisynth as FFGetVersion. (TheRyuu, TheFluff)
Added a variable prefix option to the Avisynth functions. Its primary purpose is to get subsequent calls to source functions from overwriting variables from earlier calls. (TheFluff)
Make it possible to open single-frame videos without explicitly setting seekmode to -1 for you weird people who want to open images with ffms (Plorkyeran)
Fixed bug where indicies would sometimes be incorrectly considered valid (TheRyuu)
Add support for recent versions of libav/ffmpeg built as shared libraries (Plorkyeran, TheRyuu, Kovensky)
When possible, non-API symbols are no longer exported (Daemon404)
Deprecate postproc support. Libav and FFmpeg will probably kill it at some point in the future and it's really not very useful.
Fix the pkg-config version on OS X (Plorkyeran).
General bitrot fixes to deal with changes in Libav/FFmpeg
Bump minimum required version of FFmpeg to 0.6.


Additionally there is some internal reworking of the way CodecID's work (now stored at indexing instead of the whole table shenanigans) and also the major threading problems caused by changes in libav and ffmpeg have been addressed so ffmpegsource should now work correctly with more recent versions. Plus the usual couple hundred bug fixes and what not.

[Yellow_]

I have a query which relates a little to the first entry, "Reworked colormatrix and color range handling a bit..."

Following that 'discussion' on a thread recently about lossless codecs and problems with ffmpeg on the CLI transcoding full range h264 in a mov to restricted range in other codecs including lossless codecs because ffmpeg treats the mov's a yuvj420p, is there anything to be concerned about with ffmpegsource2 in this regard?

Omitting v2.16 as that does the TV thing, 2.15 not so.

[TheFluff]

I have a query which relates a little to the first entry, "Reworked colormatrix and color range handling a bit..."

Following that 'discussion' on a thread recently about lossless codecs and problems with ffmpeg on the CLI transcoding full range h264 in a mov to restricted range in other codecs including lossless codecs because ffmpeg treats the mov's a yuvj420p, is there anything to be concerned about with ffmpegsource2 in this regard?

Omitting v2.16 as that does the TV thing, 2.15 not so.

Don't know, test it and find out. If it doesn't work file a bug report.

[Yellow_]

Ok, will do. :-)

Are you aware of anything that could occur with IQ incorrectly interpreting yuv420P as yuvj420P?

[TheFluff]

Ok, will do. :-)

Are you aware of anything that could occur with IQ incorrectly interpreting yuv420P as yuvj420P?

What do you mean by "IQ"? I think I've fixed the handling in FFMS2 so it should always give correct results now, but as I said, please test any funny files you might have.

Edit: for reference, FFMS2 now behaves like this: if the input pixel format is one of the YUVJ* ones, the video is assumed to be fullrange, regardless of what the CodecContext->color_range metadata flag might say. For all other pixel formats, FFMS2 uses whatever the CodecContext->color_range flag says. If that's unspecified, limited range is assumed.

[burfadel]

Build r624 seems to not like certain .mkv files whereas r588 has no issues... When remuxed the offending .mkv files with mkvtoolnix v5.2.1 r309 they worked with r624, but I ommitted the subtitle and chapter info...

[TheFluff]

Build r624 seems to not like certain .mkv files whereas r588 has no issues... When remuxed the offending .mkv files with mkvtoolnix v5.2.1 r309 they worked with r624, but I ommitted the subtitle and chapter info...

What exactly do you mean by "not like"? What happens? Can you provide a sample file?

[hello_hello]

I can confirm this bug, although I haven't got an idea as to the exact cause. The first MKV file I attempted to index using MeGUI caused ffmsindex to crash. It'll demux the audio stream, but it won't index.
I also tried using a basic script (because that's all I know) but it refused to index the file.

LoadPlugin("C:\Program Files\ffms2\ffms2.dll")
FFVideoSource("E:\video.mkv")

Normally just opening the above script would cause the file to be indexed, but instead when opening it with MPC-HC I got:

Evaluate: System Exception - Access Violation
E:\script.avs, line 2

The MKV file contains AVC video, DTS audio and srt subtitles. Removing the subtitles when remuxing fixed the problem (I don't think removing the audio made any difference). Remuxing the MKV while retaining all three streams still caused ffmsindex to crash. Reverting to the previous ffms version used by MeGUI (seems to be r588) returned everything to normal.

Here's a sample (http://wikisend.com/download/802382/video.mkv).

[TheFluff]

Bug reproduced and fixed, thanks for the sample.
(it was TheRyuu's fault)

[burfadel]

Thats good :) was just about to get back to you on that! (late I know)

[Atak_Snajpera]

Image corruption in VC-1 (.m2ts remuxed to .mkv using eac3to)
http://i.imgur.com/Gv1Uc.jpg

Script
LoadPlugin("..\ffms2.dll") #rev624
FFVideoSource("..\video.mkv",threads=1) #seekmode=0 and -1 do not help either

Trim(240,240)

sample -> http://www.mediafire.com/?wg81zwe1cu1pv7u

[Sparktank]

Image corruption in VC-1 (.m2ts remuxed to .mkv using eac3to)
http://i.imgur.com/Gv1Ucl.jpg

Script
LoadPlugin("..\ffms2.dll") #rev624
FFVideoSource("..\video.mkv",threads=1) #seekmode=0 and -1 do not help either

Trim(240,240)

sample -> http://www.mediafire.com/?wg81zwe1cu1pv7u

I downloaded your sample and did an encode using the latest "eperimental" version of VirualDub (Virtualdub 1.9.11/1.10.1 experimental (December 24, 2011)).
I loaded the source mkv into VDub with ffms2 rev624.
Exact script you posted.

While it does show that the invidual frame is corrupted as you posted.
I decided to encode to x264.

The resulting encode turned out perfectly without any corruptions, especially in frame 240.

Frame 240 after encoding to x264
http://i.imgur.com/GTwWql.jpg

x264 codec via Vdub 1.9.11/1.10.1 experimental (December 24, 2011)
http://i.imgur.com/1v5E0l.png

x264 settings
http://i.imgur.com/GDhVSl.png

I'm not entirely sure, but it just maybe the program having a hiccup when displaying the video.

Resulting Test:
http://www.mediafire.com/download.php?xw8vwdsfv7nau09

[Atak_Snajpera]

could you try with x264 cli?

[Sparktank]

could you try with x264 cli?

I did with a very simple function.
(x264 build: x264 core:120 r2120 0c7dab9(from http://x264.nl/))

x264 --crf 19 -o "E:\Work\test_cli.mkv" E:\Work\video.mkv"

D:\App Bin\x264\32bit 8bit-depth>x264 --crf 19 -o "E:\Work\test_cli.mkv" E:\Work\video.mkv"
ffms [info]: 1920x1080p 1:1 @ 24000/1001 fps (vfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow SlowCTZ
x264 [info]: profile High, level 4.0
x264 [info]: frame I:12 Avg QP: 9.09 size: 56780
x264 [info]: frame P:865 Avg QP:18.32 size: 38949
x264 [info]: frame B:720 Avg QP:23.24 size: 5039
x264 [info]: consecutive B-frames: 35.1% 13.1% 3.9% 47.8%
x264 [info]: mb I I16..4: 61.0% 30.5% 8.5%
x264 [info]: mb P I16..4: 4.7% 6.2% 1.2% P16..4: 25.3% 10.3% 5.4% 0.0% 0.0% skip:47.0%
x264 [info]: mb B I16..4: 0.3% 0.1% 0.0% B16..8: 8.9% 1.4% 0.4% direct: 1.2% skip:87.7% L0:32.8% L1:48.0% BI:19.2%
x264 [info]: 8x8 transform intra:48.8% inter:67.8%
x264 [info]: coded y,uvDC,uvAC intra: 43.6% 47.6% 22.8% inter: 12.9% 11.1% 1.7%
x264 [info]: i16 v,h,dc,p: 72% 13% 4% 11%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 13% 32% 6% 8% 8% 5% 5% 8%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19% 21% 25% 6% 7% 6% 6% 4% 6%
x264 [info]: i8c dc,h,v,p: 64% 16% 17% 3%
x264 [info]: Weighted P-Frames: Y:15.3% UV:9.1%
x264 [info]: ref P L0: 65.8% 16.8% 12.5% 4.6% 0.3%
x264 [info]: ref B L0: 87.8% 10.2% 2.0%
x264 [info]: ref B L1: 96.7% 3.3%
x264 [info]: kb/s:4563.98

encoded 1597 frames, 3.88 fps, 4564.06 kb/s

Media Info of resulting CLI encode:
General
Complete name : E:\Work\test_cli.mkv
Format : Matroska
Format version : Version 2
File size : 36.3 MiB
Duration : 1mn 6s
Overall bit rate : 4 568 Kbps
Writing application : x264 r2120 0c7dab9
Writing library : Haali Matroska Writer b0

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 1mn 6s
Bit rate : 4 478 Kbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 1.199 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 1.801
Stream size : 35.6 MiB (98%)
Writing library : x264 core 120 r2120 0c7dab9
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=19.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Language : English
Default : Yes
Forced : No

Although it does not load the resulting MKV in VDub, it gives an error that there is "no video". I'm not sure about that, will have to investigate that.

But eac3to was able demux the resulting video to elementary stream of x264.
I loaded the ES x264 into "DGAVCIndex" and saved the project.
However... http://i.imgur.com/02MFa.gif
The fps turned out to be a constant 25fps...

Stream Type: AVC Elementary
Profile: High
Level: 4
Frame Size: 1920x1080
SAR: 1:1
Display Size: 1920x1080
Frame Rate: 25.000000 fps
Colorimetry: BT.709* [2]
Frame Structure: Frame
Frame Type: not yet
Coded Number: 250
Playback Number: 250
Frame Repeats: 0
Field Repeats: 0
Bitrate: 10.391
Bitrate (Avg): 6.519
Bitrate (Max): 11.388
Elapsed: 0:00:00
Remain: 0:00:00
FPS:
Info: Finished!

I've never really used the CLI before on its own.
I usually use Vdub or other with it ^_____^

Here's the resulting video in MKV format, using x264 (core:120 r2120 0c7dab9)...

deleted, uploading proper converted file

[Abradoks]

While it does show that the invidual frame is corrupted as you posted.
I decided to encode to x264.

Yes, linear decoding works fine. But VC-1 seeking is still broken.

BTW, has anyone considered using Intel Media SDK software decoder inside FFMS? It would be a nice solution for interlaced VC-1 decoding.

[Atak_Snajpera]

@Sparktank
you were supposed to encode my script not video.mkv !

[Sparktank]

@Sparktank
you were supposed to encode my script not video.mkv !

>.< Fixed.

x264 log:
D:\App Bin\x264\32bit 8bit-depth>x264 --crf 19 -o "E:\Work\test_cli.mkv" E:\Work\ffms_test.avs"
avs [info]: 1920x1080p 0:0 @ 24000/1001 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Slow SlowCTZ
x264 [info]: profile High, level 4.0
x264 [info]: frame I:12 Avg QP: 9.09 size: 56786
x264 [info]: frame P:865 Avg QP:18.30 size: 38968
x264 [info]: frame B:720 Avg QP:23.28 size: 5030
x264 [info]: consecutive B-frames: 35.1% 13.1% 3.9% 47.8%
x264 [info]: mb I I16..4: 60.9% 30.5% 8.5%
x264 [info]: mb P I16..4: 4.6% 6.2% 1.2% P16..4: 25.3% 10.3% 5.4% 0.0% 0.0% skip:47.0%
x264 [info]: mb B I16..4: 0.3% 0.1% 0.0% B16..8: 8.8% 1.4% 0.4% direct: 1.2% skip:87.8% L0:32.6% L1:48.1% BI:19.4%
x264 [info]: 8x8 transform intra:48.8% inter:67.7%
x264 [info]: coded y,uvDC,uvAC intra: 43.6% 47.6% 22.7% inter: 12.9% 11.1% 1.7%
x264 [info]: i16 v,h,dc,p: 72% 13% 4% 11%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 13% 32% 6% 8% 8% 5% 6% 8%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 19% 21% 25% 6% 7% 6% 6% 4% 6%
x264 [info]: i8c dc,h,v,p: 64% 16% 17% 3%
x264 [info]: Weighted P-Frames: Y:15.3% UV:9.1%
x264 [info]: ref P L0: 65.8% 16.8% 12.5% 4.7% 0.3%
x264 [info]: ref B L0: 87.8% 10.2% 2.0%
x264 [info]: ref B L1: 96.7% 3.3%
x264 [info]: kb/s:4565.26

encoded 1597 frames, 3.81 fps, 4565.35 kb/s

And it turned out the same, no corruption.

New conversion with AVS, new upload, same name.
http://www.mediafire.com/download.php?1ag4lcvbpqdu5jd

[Atak_Snajpera]

wrong again! you encoded whole file without trim!

[TheRyuu]

wrong again! you encoded whole file without trim!

Like I said on the bug tracker it works if it's accessed linearly. Doing trim(x,y) (where x isn't 0) counts as seeking. I don't know why there is corruption when seeking. Threads > 1 also appears to work correctly if accessed linearly.

[Atak_Snajpera]

maybe this is just a coincident but with trim(242,...) frame is not corrupted. according to mkvinfo frame 242 (10.082s) is a location of next cluster timecode. btw how to get list of keyframes with ffindex.exe?

[Atak_Snajpera]

Another example that there is seriously something wrong with VC-1 decoding while seeking
Now We have frame 1 mixed with frame 968 plus nice blocks. Probably the same happens with my previous example!

http://i.imgur.com/o3qjI.jpg

Script
LoadPlugin("..\ffms2.dll")
FFVideoSource("..\video.mkv",threads=1)

Trim(967,967)

Sample -> http://www.mediafire.com/?dh86soca2m66n6b

[may24]

Hi everyone,

A friend recorded some 'ITV HD' stream in 1080i and now wants to process it further.
I recommend him to use the latest ffms2 release 624. But parsing the file throws error: Insanity detected: Decoder returned an empty frame

Here is a snipp of his recording -> http://www.megaupload.com/?d=S7719U3P

I hope you guys could have a look at.

I was able to open and index/demux it with DGAVCdecode ...

[TheFluff]

MPEG TS support is even more broken than usual in r624, due to a regression introduced in r615. We're working on it. In the meantime you can remux the file to MKV with eac3to or just use 2.16.

[jmac698]

Really, I could serve avc interlaced properly if it's in mkv? With random access too?

[TheFluff]

Really, I could serve avc interlaced properly if it's in mkv? With random access too?

No, you still get various breakage on interlaced h264 in mkv for some reason, especially if it's remuxed from (M2)TS.

[moviefan]

I'm trying to compile the latest FFMS2 revision against the latest FFmpeg revision, but I keep getting the following error in the ./configure-phase.


checking for LIBAV... yes
checking whether linking with FFmpeg or Libav... FFmpeg
checking whether FFmpeg works... no
configure: error: in `/home/<user>/tmp/ffms2':
configure: error: cannot link with FFmpeg


I compile FFmpeg with


./configure --disable-everything --enable-gpl --enable-postproc --enable-protocols --enable-demuxer=matroska,ogg,avi,h264,mov,m4v,mpegts,mpegvideo --enable-decoder=h264,vc1,wmv*,mpeg2video,mpeg1video,mpeg4,theora,vp8 --enable-parser=h264,mpeg4video,mpegvideo,vc1,vp8 --prefix=/home/<user>/build
make
make install


and FFMS2 with


LIBAV_CFLAGS=-I/home/<user>/build/include LIBAV_LIBS=-L/home/<user>/build/lib ./configure --prefix=/home/<user>/build
make
make install


Can anyone tell me why this is happening?

[TheFluff]

I'm trying to compile the latest FFMS2 revision against the latest FFmpeg revision, but I keep getting the following error in the ./configure-phase.


checking for LIBAV... yes
checking whether linking with FFmpeg or Libav... FFmpeg
checking whether FFmpeg works... no
configure: error: in `/home/<user>/tmp/ffms2':
configure: error: cannot link with FFmpeg


I compile FFmpeg with


./configure --disable-everything --enable-gpl --enable-postproc --enable-protocols --enable-demuxer=matroska,ogg,avi,h264,mov,m4v,mpegts,mpegvideo --enable-decoder=h264,vc1,wmv*,mpeg2video,mpeg1video,mpeg4,theora,vp8 --enable-parser=h264,mpeg4video,mpegvideo,vc1,vp8 --prefix=/home/<user>/build
make
make install


and FFMS2 with


LIBAV_CFLAGS=-I/home/<user>/build/include LIBAV_LIBS=-L/home/<user>/build/lib ./configure --prefix=/home/<user>/build
make
make install


Can anyone tell me why this is happening?

Post your config.log.

[moviefan]

http://pastebin.com/GjCqakCE

[TheFluff]

You need to compile FFmpeg with swscale (--enable-swscale), but I think there might also be something funky going on with our autodetection of FFmpeg versus libav. Which one are you using?

[moviefan]

I downloaded the latest FFmpeg snapshot so I guess I'm using FFmpeg, right?

Edit: Compiling FFmpeg with swscale does not solve the problem.

[TheFluff]

I downloaded the latest FFmpeg snapshot so I guess I'm using FFmpeg, right?

Edit: Compiling FFmpeg with swscale does not solve the problem.

You're setting LIBAV_LIBS wrong. Consider using pkg-config in order to get it right automatically (by setting PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig, where $PREFIX is the prefix you built ffmpeg with), or if you can't or don't want to do that, check the libav*.pc file to see what -l flags you should be using.

[moviefan]

Where do I insert the -l flags? Like this? LIBAV_LIBS="-L..... -lavcodec -lavfilter ..."?

[komisar]

moviefan, try this:
LIBS="-lswscale -lavformat -lavcodec -lavutil -lpsapi [-lz -lbz2 -lpthreadGC2]" \
CFLAGS="-I/where/you/libav/include" \
LDFLAGS="-L/where/you/libav/lib" \
configure --you-libav-configure-options

"[-lz -lbz2 -lpthreadGC2]" if need...

TheFluff, why in current ffmpegsource changed FFMPEG_LIBS to LIBS in configure?

[TheFluff]

FFMS 2.17 has been released.
Again, this is mostly a bugfix and maintenance release; no major new features have been added. There are, however, two minor features that might be relevant to Avisynth users. First, you can now get the FFMS version by calling FFGetVersion(), which returns a string on the form "2.17.0.0", where the last two numbers are mostly relevant for API users. Second, all exported metadata variables can now have their names prefixed with a string of your choice, which prevents two or more subsequent calls to FFVideo/AudioSource from overwriting each other's variables. Oh, and for the three people who care (hello there, tebasuna51), the audio channel layout is now exported as a dwChannelMask-compatible integer, in the variable FFCHANNEL_LAYOUT.

Downloads

ffms-2.17.7z (http://code.google.com/p/ffmpegsource/downloads/detail?name=ffms-2.17.7z) - plain old 32-bit version
ffms-2.17-x64.7z (http://code.google.com/p/ffmpegsource/downloads/detail?name=ffms-2.17-x64.7z) - for use with 64-bit Avisynth
ffms-2.17-sdk.7z (http://code.google.com/p/ffmpegsource/downloads/detail?name=ffms-2.17-sdk.7z) - Software Development Kit, for people who want to develop Windows applications that depend on FFMS2, using Microsoft Visual Studio 2008 or later
ffms-2.17-src.tar.bz2 (http://code.google.com/p/ffmpegsource/downloads/detail?name=ffms-2.17-src.tar.bz2) - full source code


Full changelog since 2.16

Reworked color matrix and color range handling a bit, which fixed a bug that could cause FFMS2 to always output TV range even if the input was full range. (TheFluff)
The autotools build system can now create debug builds properly. (Daemon404)
Deprecated parts of the API will now cause compiler warnings when you use them. (TheFluff)
Added a FFMS_GetVersion function to the API (lets library users get the version number at runtime) and exposed it in Avisynth as FFGetVersion. (TheRyuu, TheFluff)
Added a variable prefix option to the Avisynth functions. Its primary purpose is to get subsequent calls to source functions from overwriting variables from earlier calls. (TheFluff)
Make it possible to open single-frame videos without explicitly setting seekmode to -1 for you weird people who want to open images with ffms (Plorkyeran)
Fixed bug where indices would sometimes be incorrectly considered valid (TheRyuu)
Add support for recent versions of Libav/FFmpeg built as shared libraries (Plorkyeran, TheRyuu, Kovensky)
When possible, non-API symbols are no longer exported (Daemon404, TheFluff)
Deprecate postprocessing support. Libav and FFmpeg are planning on removing it at some point in the near future and it's really not very useful.
Fix the pkg-config version on OS X (Plorkyeran).
Fixed a bug that could cause the FFmpegSource2() Avisynth function to not use UTF8 filenames even when told to do so. (pandv2)
Fixed a few minor memory leaks. (Plorkyeran)
Adjusting audio delay relative to the first video track should now work properly again (was broken in 2.16). (Plorkyeran)
General bitrot fixes to deal with changes in Libav/FFmpeg (everyone)
Corrected handling of codec private data when using a non-libavformat parser. Fixes decoding of FFV1 and UTVideo in MKV, among other things. (TheFluff)
Bump minimum required version of FFmpeg to 0.6.


Other notes
The VC-1 decoding issue is not fixed, but since it's been there since forever and is extremely mysterious and hard to debug, we've decided to release 2.17 anyway. We haven't given up on it, though.

We'd also like to again remind postprocessing users that postprocessing support is deprecated and will be removed in 2.18. The reason for this is that both libav and FFmpeg are planning on removing the library we use (libpostproc).

[TheFluff]

TheFluff, why in current ffmpegsource changed FFMPEG_LIBS to LIBS in configure?

I don't know, I don't maintain the Unix buildsystem. I'll pass the question along to the concerned parties, though.

[tebasuna51]

FFMS 2.17 has been released.
... Oh, and for the three people who care (hello there, tebasuna51), the audio channel layout is now exported as a dwChannelMask-compatible integer, in the variable FFCHANNEL_LAYOUT.

Thanks. I will test that.

[mastrboy]

FFMS 2.17 has been released.

Much appreciated :)

[aufkrawall]

It doesn't work for me with AviSynth 2.6 32bit, programs abort with error saying they can't open the avs files. :(
The plugin load command is correct.

But ffms-2.17.7z really is for AviSynth?

[LigH]

There are two distinct functions to load plugins, and it depends on the plugin code which of them are supported:

a) LoadPlugin()
b) LoadCPlugin() / Load_StdCall_Plugin()

FFMS2 supports both calling conventions; but using FFMS2 in AviSynth 2.6 requires the second style to access new colorspaces. To avoid issues with the plugin already loaded automatically using the first style, you should keep FFMS2 out of the autoload folder (AviSynth 2.5\plugins), but place it in a subdirectory instead and always load it explicitly.

[TheRyuu]

There are two distinct functions to load plugins, and it depends on the plugin code which of them are supported:

a) LoadPlugin()
b) LoadCPlugin() / Load_StdCall_Plugin()

FFMS2 supports both calling conventions; but using FFMS2 in AviSynth 2.6 requires the second style to access new colorspaces.

You can only load ffms2 with:
LoadPlugin("X:\path\to\ffms2.dll")

The cplugin builds are marked as such and are different.

To avoid issues with the plugin already loaded automatically using the first style, you should keep FFMS2 out of the autoload folder (AviSynth 2.5\plugins), but place it in a subdirectory instead and always load it explicitly.

Can we please stop using autoload. It's one of the major causes of avisynth related problems.

[aufkrawall]

Thank you, using the non-c load command did the trick. :)

[LigH]

Sorry then, I must have misunderstood... So it seems that C calling is no requirement for AviSynth 2.6; but then was it useful for x64 instead?

[TheFluff]

Sorry then, I must have misunderstood... So it seems that C calling is no requirement for AviSynth 2.6; but then was it useful for x64 instead?

I will try to explain the situation. It's a bit messy, and I'm going to explain a bit more than strictly necessary, but bear with me.

FFMS2 is a library that interacts with FFmpeg. You can use this library from C or C++ programs (and programs written in other languages too), but in itself it doesn't really do anything. You cannot use this library directly from Avisynth.

In order to interact with Avisynth, we have written two different Avisynth plugins. These two don't do very much work on their own; they just call the FFMS2 library and ask it to retrieve video and audio for them. Because we don't like DLL hell, these plugin interfaces normally reside in the same .dll file as the FFMS2 library, and thus for most end users the FFMS2 library is the same thing as the Avisynth plugin.

One of these two plugins is written in C++ and uses the Avisynth 2.5 interface. This is the ordinary plugin that most of you use; it is loaded with LoadPlugin. It can be compiled in either 32- or 64-bit mode and will work with both Avisynth 2.5 and 2.6, but in 2.6 it will not be able to handle the new colorspaces, since it uses the 2.5 interface that doesn't have those yet. If it had been written using the 2.6 interface, you would not have been able to load it in Avisynth 2.5.

The other plugin is written in C (by kemuri_-9) and uses the Avisynth C interface. It is loaded with LoadCPlugin/LoadStdCallPlugin, and just like the ordinary plugin it can be compiled in either 32- or 64-bit mode. Because the Avisynth C interface is a bit special, kemuri_-9 managed to hack this plugin up so it can be loaded in both Avisynth 2.5 and Avisynth 2.6 and still have access to the new colorspaces when loaded in Avisynth 2.6. The ordinary C++ plugin cannot do this.

Because there is no easy way for end users to tell the difference between a ffms2.dll that contains the C-plugin interface and one that contains the 2.5 C++ interface, we usually mark 7z archives that contain the C-plugin with -avs-cplugin. All other archives can be assumed to either contain the C++ plugin or just the library itself, without any Avisynth interfaces (although I don't think there's anyone building it that way right now; all DLL's most likely contain one of the Avisynth interfaces).

We have not yet posted a 2.17 build of the C-plugin. Harass TheRyuu if you want it.

End of tl;dr.

[Gavino]

Can we please stop using autoload. It's one of the major causes of avisynth related problems.
Why is that? (in the case of ffms2)

[TheFluff]

Why is that? (in the case of ffms2)

When someone is having bizarre and inexplicable Avisynth problems, such as odd crashes and mysterious failures of various kinds, odds are usually very good that it's related to some broken plugin being autoloaded. Therefore, TheRyuu thinks it's usually a good idea to keep your autoload directory clean. The C++ version of FFMS2 should be safe to autoload though.

[LigH]

:goodpost: :thanks:

That helped me understanding the relations better.
__

Crash reasons I remember from own experience were e.g. AviSynth 2.0 plugins, the LoadPluginEx() plugin, and plugin variants optimized for unsupported CPU instructions (e.g. RemoveGrain_SSE3 on Athlon XP).

[aufkrawall]

I encounter a problem with FFMS 2.17 that wasn't there with 2.16 cbuild: It seems that it doesn't convert range from PC to TV correctly.
I used the following script:
LoadPlugin("C:\Program Files (x86)\AviSynth 2.6\plugins\ffms2.dll")
FFVideoSource("alt.avi")
AssumeFPS(30.0)
ConvertToYV12(matrix="Rec709")
Source was FRAPS I420.
With 2.16 the x264 result looked like this:
http://www.ld-host.de/uploads/thumbnails/0e1983f8ae6fcdc52469cc8cdd7da85d.png (http://www.ld-host.de/show/0e1983f8ae6fcdc52469cc8cdd7da85d.png)
2.17 (too dark):
http://www.ld-host.de/uploads/thumbnails/3e0e91f92754d80b5c20a778ba45a4c3.png (http://www.ld-host.de/show/3e0e91f92754d80b5c20a778ba45a4c3.png)

[TheFluff]

I encounter a problem with FFMS 2.17 that wasn't there with 2.16 cbuild: It seems that it doesn't convert range from PC to TV correctly.
I used the following script:
LoadPlugin("C:\Program Files (x86)\AviSynth 2.6\plugins\ffms2.dll")
FFVideoSource("alt.avi")
AssumeFPS(30.0)
ConvertToYV12(matrix="Rec709")
Source was FRAPS I420.
With 2.16 the x264 result looked like this:
http://www.ld-host.de/uploads/thumbnails/0e1983f8ae6fcdc52469cc8cdd7da85d.png (http://www.ld-host.de/show/0e1983f8ae6fcdc52469cc8cdd7da85d.png)
2.17 (too dark):
http://www.ld-host.de/uploads/thumbnails/3e0e91f92754d80b5c20a778ba45a4c3.png (http://www.ld-host.de/show/3e0e91f92754d80b5c20a778ba45a4c3.png)

2.17 looks more correct to me, and I know Fraps has some super mysterious color matrix magic going on, but I can take a look anyway. Post a sample.

Your Avisynth script doesn't convert to RGB either, so that conversion happens elsewhere. What colorspace is FFMS2 outputting?

[aufkrawall]

2.17 looks more correct to me, and I know Fraps has some super mysterious color matrix magic going on, but I can take a look anyway.

The 2.16 screenshot looks exactly like the original FRAPS source.
2.17 really is too dark, details get lost in darkness.


Post a sample.

http://ht4u.net/images/reviews/2011/amd_radeon_hd_7900_southern_island_test/witcher_gtx580hq_neu.avi
Thanks for taking a look at it. :)


Your Avisynth script doesn't convert to RGB either, so that conversion happens elsewhere. What colorspace is FFMS2 outputting?
I assume it just outputs YV12/I420, just like the CSP of the source is.
x264's range conversion doesn't work (colors look slightly wrong), that's why I used Rec709 (I don't know why FRAPS keeps PC range in I420 mode...).
Here's the encoded video with ffmpegsource 2.16:
http://www.mediafire.com/?h2nsa7qtt6f56as

[TheFluff]

Took a look at the sample file. FFMS2 correctly detects the input as PC range I420 and does no conversions at all. Your ConvertToYV12() line does nothing since the input already is YV12 (I420 is the same thing as YV12 but with the chroma plane order swapped; Avisynth considers the two formats the same for most purposes). I assume that when VirtualDub (or whatever you're screenshotting with) converts the YV12 input to RGB for display, it does so while incorrectly assuming TV range. I added ConvertToRGB32(matrix="PC.709") to the end of the script and then I got mostly the same results as in your 2.16 screenshot (didn't compare exactly but it looks very similar at least). FFVideoSource(..., colorspace="RGB32") gives the same results as well.

If the same script worked in 2.16, what happened there was that you were a victim of that bug I fixed; FFMS2 internally scaled the PC range input to TV range, and by pure chance the rest of your encoding/playback chain happened to assume the input was TV range and thus rescaled it to PC range again for display.

Keep in mind that when you encode with x264 and the input is an Avisynth script, x264 cannot automatically detect the color range. You'll have to tell it to set the fullrange flag appropriately.

[henryho_hk]

I presume that x86 and x64 versions cannot share ffindex files. Hence, could FFGetVersion() include such info too?

[TheFluff]

I presume that x86 and x64 versions cannot share ffindex files. Hence, could FFGetVersion() include such info too?

Indeed, they cannot. FFGetVersion() could return that, yes.

[kemuri-_9]

Because there is no easy way for end users to tell the difference between a ffms2.dll that contains the C-plugin interface and one that contains the 2.5 C++ interface.

I've gone ahead and added version information to the dll when built within the c branch so you can better indicate what it is/what it can do, etc.

ex:
http://kemuri9.net/forumpics/ffms_dll_info.png

[aufkrawall]

Took a look at the sample file. FFMS2 correctly detects the input as PC range I420 and does no conversions at all. Your ConvertToYV12() line does nothing since the input already is YV12 (I420 is the same thing as YV12 but with the chroma plane order swapped; Avisynth considers the two formats the same for most purposes). I assume that when VirtualDub (or whatever you're screenshotting with) converts the YV12 input to RGB for display, it does so while incorrectly assuming TV range. I added ConvertToRGB32(matrix="PC.709") to the end of the script and then I got mostly the same results as in your 2.16 screenshot (didn't compare exactly but it looks very similar at least). FFVideoSource(..., colorspace="RGB32") gives the same results as well.

But the result isn't right, colors are wrong. For example red turns more orange:
http://www.ld-host.de/uploads/thumbnails/67a2cdd861f645208dad2fcef097f3f4.png (http://www.ld-host.de/show/67a2cdd861f645208dad2fcef097f3f4.png) http://www.ld-host.de/uploads/thumbnails/f795ce8061a6b748e15fa823665ed78b.png (http://www.ld-host.de/show/f795ce8061a6b748e15fa823665ed78b.png)


If the same script worked in 2.16, what happened there was that you were a victim of that bug I fixed; FFMS2 internally scaled the PC range input to TV range, and by pure chance the rest of your encoding/playback chain happened to assume the input was TV range and thus rescaled it to PC range again for display.

I liked this bug, it served me well. :p
With it I could convert from PC to TV range without visual quality loss.
With 2.17 it even looks wrong with PC range. :(

[LigH]

A change in the hue rather sounds like different colorimetrics?!

[aufkrawall]

A change in the hue rather sounds like different colorimetrics?!
The same happens when I let x264 convert range from PC to TV with FRAPS I420 videos.
The range conversion of AviSynth/ffms 2.16 is the only thing that works.

Range of the output file has to be TV because most decoders can't deal right with non-RGB video with PC range.

[Rumbah]

If I remember correctly Fraps does not use standard colorimetrics. That's why the normal Fraps decoder outputs RGB so it can do the correct conversion.
I did some tests a year ago and then the only way to get correct colours was to either use the normal Fraps decoder and then convert to YV12 or just capture in RGB. Else I got hue shifts in red and green (WoW chat text colours ;) ).

[the_weirdo]

The same happens when I let x264 convert range from PC to TV with FRAPS I420 videos.
The range conversion of AviSynth/ffms 2.16 is the only thing that works.

Range of the output file has to be TV because most decoders can't deal right with non-RGB video with PC range.

Maybe there're flaws from your workflow. How about replace ConvertTo... line with ColorYUV(level="PC->TV")? What is your x264 command line? Which method you're using to take those screenshots?

[TheFluff]

I think FFMS 2.16 actually had another bug too that made it output RGB32. ConvertToYV12(matrix="foo") on YV12 material throws an error, so if that worked in your 2.16 script then FFMS2 definitely wasn't outputting YV12. Try this:
FFVideoSource("derp.avi", colorspace="RGB32")
ConvertToYV12(matrix="Rec709")

When I open that in VirtualDub, I get an image that matches your 2.16 screenshot on the reds, but on the other hand it looks less greenish overall. What did you screenshot with?

But yes, in the end I think Fraps does use its own color matrix that doesn't match Rec 709 perfectly.

[aufkrawall]

I think FFMS 2.16 actually had another bug too that made it output RGB32. ConvertToYV12(matrix="foo") on YV12 material throws an error, so if that worked in your 2.16 script then FFMS2 definitely wasn't outputting YV12. Try this:
FFVideoSource("derp.avi", colorspace="RGB32")
ConvertToYV12(matrix="Rec709")

Your script works perfectly, thank you very much. :goodpost:
It also works great with little adjustment when converting FRAPS RGB source to I444.
Original FRAPS video and FRAPS decoder:
http://www.ld-host.de/uploads/thumbnails/e42ca54250a8da426c52d5ce178b4429.png (http://www.ld-host.de/show/e42ca54250a8da426c52d5ce178b4429.png)

LAV x264:
http://www.ld-host.de/uploads/thumbnails/9a9135b11432c3d8b90bacea7f844f0e.png (http://www.ld-host.de/show/9a9135b11432c3d8b90bacea7f844f0e.png)

Windows Media Player x264:
http://www.ld-host.de/uploads/thumbnails/83d14533886a71ca7d204eeaec081d72.png (http://www.ld-host.de/show/83d14533886a71ca7d204eeaec081d72.png)

All three look almost identical (I guess WMP has some sharpening filter active *sigh*).


When I open that in VirtualDub, I get an image that matches your 2.16 screenshot on the reds, but on the other hand it looks less greenish overall. What did you screenshot with?

I also got some weird results with VirtualDub, hence I used the save picture function of MPC HC (it extracts the source's frame).
Another advantage is that the screenshot matches the real picture drawed by the renderer to 100% in any case. :)
For WMP I had to make a capture of the whole screen. :D

[Pat357]

It would be really, really very nice if we could have the C version of this plugin soon : something like FFMS2-2.17-avs-cplugin.7z :D
Any idea when it will be available on the download area ?

Not that I'm looking for it, but why has there not been a 64bit version from the C plugin ? Was the "avisynth-interface" never made for x64 use ? Just curious...

Keep up the great work guys ! :thanks:

[TheRyuu]

It would be really, really very nice if we could have the C version of this plugin soon : something like FFMS2-2.17-avs-cplugin.7z :D
Any idea when it will be available on the download area ?

Not that I'm looking for it, but why has there not been a 64bit version from the C plugin ? Was the "avisynth-interface" never made for x64 use ? Just curious...

Keep up the great work guys ! :thanks:

ffms-2.17-cplugin.7z (http://code.google.com/p/ffmpegsource/downloads/detail?name=ffms-2.17-cplugin.7z)

Archive contains both 32-bit and 64-bit versions.
Primary use of the cplugin version is for those who want access to the extra colorspaces provided in Avisynth 2.6 (it is backward compatible with 2.5).

[bencahill]

This is really awesome, except that I'm getting artifacts on my Canon T2i footage in moving areas. (H.264 MOV)

Source:
http://ompldr.org/tY2lldA (http://ompldr.org/vY2lldA)
FFMS:
http://ompldr.org/tY2lldg (http://ompldr.org/vY2lldg)

I'd love to use this because it's fast and doesn't take up space (e.g. demuxing the h.264 stream), but because of this I'm using MPEGAutoIndexSource() for the time being (which is slower and takes space).

Any idea as to why this is happening? If you need me to test more, just let me know.

Thanks!

P.S. I searched, but couldn't find anything on this issue. If it's already been discussed, my apologies.

[TheFluff]

H.264 in MOV should work, AFAIK. Post sample (it doesn't need to be big, ~50MB is more than enough) and I'll take a look.

[Yellow_]

No problems with 2.17 32bit from #1438 http://forum.doom9.org/showthread.php?p=1553391#post1553391 with Canon 550D/T2i MOVs, well at least not 1920x1088 25p.

[bencahill]

Oh yes, I forgot to mention: that clip was obtained here (http://movies.dpreview.com.s3.amazonaws.com/canon_eos550d/Bus.MOV), so you can test it also.

It's 720p25, but I was getting the same with my 1080p30, and also with H.264 video from a Kodak Zi8. I'm guessing it's something with my setup?

I've used Avisynth 2.5.8 ST, and 2.6 MT (http://forum.doom9.org/showthread.php?t=148782). Using latest FFMS (2.17 with no suffix) on WinXP Home SP3 32-bit.

Thanks for your time. :)

[TheFluff]

File breaks ffmpeg/avconv too so it's not our fault this time. Remuxing with mkvmerge gives this warning:
Warning: 'E:\ffms2testclips\Bus h264 canon t2i.MOV' track 0: The AVC video track is missing the 'CTTS' atom for frame timecode offsets. However, AVC/h.264 allows frames to have more than the traditional one (for P frames) or two (for B frames) references to other frames. The timecodes for such frames will be out-of-order, and the 'CTTS' atom is needed for getting the timecodes right. As it is missing the timecodes for this track might be wrong. You should watch the resulting file and make sure that it looks like you expected it to.
Resulting file has the same issue.

I think you should open a bugreport with ffmpeg.

[Yellow_]

MKVMerge has said that for as long as I remember whenever I've used it, however remuxing to mkv via ffmpeg on the CLI gives no such warning, so might be a MKVMerge thing possibly.

In the years I've had a Canon video shooting DSLR and last three major releases of ffmpeg I've never seen artifacts like that nor from numerous h264 shooting compacts.

What are you opening the avs files with? AVSPmod for example I see no problems with my sources or the bus.MOV off the dpreview site in the link above, it's fine.

I think it's your setup.

[TheFluff]

MKVMerge has said that for as long as I remember whenever I've used it, however remuxing to mkv via ffmpeg on the CLI gives no such warning, so might be a MKVMerge thing possibly.

In the years I've had a Canon video shooting DSLR and last three major releases of ffmpeg I've never seen artifacts like that nor from numerous h264 shooting compacts.

What are you opening the avs files with? AVSPmod for example I see no problems with my sources or the bus.MOV off the dpreview site in the link above, it's fine.

I think it's your setup.

I could reproduce the issue with FFMS2 in debug mode yesterday; it's interesting that you can't. Are you using 2.17?

[Yellow_]

Yes, 2.17 for a few days, 2.15 before that. Just checked with 2.15 and no problem there either with the bus.MOV source.

**EDIT**

Another test, some h264AVC at 1920x1080 29.971 fps off a Samsung Compact in a mp4 no problem, even jumping about the stream no decoding errors.

[bencahill]

What are you opening the avs files with? AVSPmod for example I see no problems with my sources or the bus.MOV off the dpreview site in the link above, it's fine.

I'm using VirtualDub 1.8.8 (portable version from portableapps.com).

[Yellow_]

Portable version? I guess you have good reason to use it from there but Virtualdub's portable anyway, no install necessary, can just download from the authors site put it on a memory stick and run the .exe from anywhere?

Same with Gimp, VLC, mplayer, etc have them all on a memory stick.

I'd try it out from there but I don't understand why I have to install Virtualdub to use it, in fact refuse to, never done that in 10yrs of using it :-)

Have you tried AVSPmod or Virtualdub from the authors site as an alternative?

[StainlessS]

One of the main ideas behind PortableApps is that the app should leave no trace of ever
being used on a machine and not interfere with the owners settings in the
registry if that app is already installed on that system.
EDIT: In reality, the apps do not always conform to the ideal.

[TheFluff]

It's not related to the VDub version, it's a lavc decoding error. It prints a ton of junk to the console, like
[h264 @ 042117A0]missing picture in access unit
[h264 @ 04814BC0]concealing 8160 DC, 8160 AC, 8160 MV errors
[h264 @ 04813AA0]concealing 8160 DC, 8160 AC, 8160 MV errors
[h264 @ 00999C80]negative number of zero coeffs at 119 67
[h264 @ 00999C80]error while decoding MB 119 67
[h264 @ 00999C80]concealing 50 DC, 50 AC, 50 MV errors
[h264 @ 04814BC0]Invalid level prefix
[h264 @ 04814BC0]error while decoding MB 119 67
[h264 @ 04814BC0]concealing 50 DC, 50 AC, 50 MV errors

etc etc.

But I figured out why it works for Yellow_ but not for me or bencahill; it turns out it's lavc's multithreaded decoding that's broken on this file (what a surprise). ffvideosource("derp.mov",threads=1) works fine.

[the_weirdo]

It seems that decoding error has been fixed in latest FFmpeg git master (don't know about Libav). I tested that clip with my own FFMS2 build (compile against ffmpeg's libs) and didn't get any broken frames.

[Yellow_]

StainlesS thanks for explanation.

re. lavc yes I'm running all Windows apps on Linux through Wine and don't use multithreading although I'm sure others may be doing so via Wine. I kinda keep things simple out of ignorance rather than try getting more out of performance. If it works simple then I stick with it. :-)

[Chikuzen]

File breaks ffmpeg/avconv too so it's not our fault this time. Remuxing with mkvmerge gives this warning:


Using CTTS with Baseline profile is a spec violation.
I think you should open a bugreport with MKVToolNix :p

[Snowknight26]

FFMS returns an error along the lines of "Insanity detected: decoder returned an empty frame" for this (http://stfcc.org/misc/ffmpegsource.empty.frame.mkv) sample. ffmpeg/ffplay/everything else based off ffmpeg/libav plays it fine.

On a related note, FFMS returns mangled timestamps for this (http://stfcc.org/misc/ffmpegsource.mangled.timestamps.ts) sample. The timecode file ffindex writes shows that multiple frames are displayed at the same time, which x264 doesn't seem to like.

[pandv2]

What's the correct method to deduce the display dimensions for a video?.

mplayer displays a video with 1280*720. MediaInfo reports it 960*720 with a Display ratio of 16:9.

FFMS (last stable version) returns (I get the frame 0):

FFMS_Frame.EncodedWidth = 960
FFMS_Frame.EncodedHeight = 720
FFMS_Frame.ScaledWidth = -1 (960 after the call to FFMS_SetOutputFormatV2)
FFMS_Frame.ScaledWidth = -1 (720 after the call to FFMS_SetOutputFormatV2)
FFMS_VideoProperties.SARDen = 691200
FFMS_VideoProperties.SARNum = 921600

I can't find the system to deduce 1280*720 (or another numbers with the same ratio) from the information obtained from FFMS.

[LigH]

Well, it was encoded with 960 pixels width; but it was given an SAR which is not 1:1, therefore the displayed dimensions won't match the encoded dimensions. 1280 pixels width is probably correct then.

[TheFluff]

SARNum and SARDen are the numerator and denominator of a fractional number that defines the Sample Aspect Ratio, i.e. the ratio between the width and the height of a single pixel.

Use the following relation to calculate the Display Aspect Ratio (DAR; the familiar 4:3 or 16:9 ratios) and/or the corresponding width/height:

SARNum DARNum * encoded_height
------ = -----------------------
SARDen DARDen * encoded_width


In your case, the SAR and encoded width/height are known but you want to know the DAR. We multiply both sides of the equation with the reciprocal of encoded_height/encoded_width:

SARNum * encoded_width DARNum
----------------------- = ------
SARDen * encoded_height DARDen

Fill in the numbers and we get:

921600 * 960 884736000
------------ = ---------
691200 * 720 497664000

884736000/497664000 is not a very nice-looking number, but simplify it (by getting rid of all the zeroes and then dividing both numerator and denominator by 55296) and you get the nice and friendly fraction 16:9. That's the Display Aspect Ratio, the width/height relation for the entire image. Multiply the encoded width (960) by 16/9 and you get 1280. 1280x720 is the intended display resolution.

[pandv2]

Thanks TheFluff for you explanation.

I learned this concepts in the DVD world and I confused SAR (Sample Aspect Ratio) in MPEG4, with SAR (Store Aspect Ratio, encoded width/encoded height) in MPEG2. In MPEG2 is PAR (Pixel Aspect Ratio) the equivalent to MPEG4 SAR.

Your explanation has a little typo. The last sentence has to be:

Multiply the encoded height (720) by 16/9 and you get 1280. 1280x720 is the intended display resolution.

[Chumbo]

...- interlaced h264: bat country. Will most likely not work properly at all no matter what you do. If you're feeling particularly adventurous you can try demuxer="lavf", seekmode=-1, threads=1 and then use the correct fpsnum/fpsden for your source, but you're still likely to get random corruption issues. Remuxing to MKV will rid you of the need to use demuxer="lavf" and seekmode=-1 but will not solve the frame duplication and you're still likely to get random corruption issues, and apparently lavc likes crashing with threads > 1 now too.
...
Do you happen to know if the status on this changed at all in the last 7 months?

[mbcd]

I dont think so, I had an interlaced vc1 yesterday and stumpled over this problem. Even with actual 2.17 there are only corrupted frames (on vc1, not h264). I think that interlaced material has no high priority on ffmpegSource.

My workaround is: Convert to AVI (for vc1) and open with DirectShow, thats the only way I found. Maybee you get a workaround for h264 too.

[TheFluff]

FFmpeg's VC-1 decoder doesn't fully support interlaced material yet, there's nothing we can do about that. There are also some mysterious issues with progressive VC-1 that I'm not sure if they're our fault or not.

H.264 is an entirely different problem, but no, it still doesn't work reliably as far as I know. Haali's parser causes funny issues and lavf's is so terrible at seeking it's entirely useless. Reading linearly (seekmode 0 or -1) with lavf (ffindex(demuxer="lavf")) might "work" though.

[Chumbo]

I'm using directshowsource now with ffdshow decoder set to deinterlace so I don't have to it in the script, but DS is just so slow. Do you have any recommendations for faster method that doesn't use ffms2? Being on Win7 64bit can be such a pain with the limited filters. I can't even use DGAVCDecode since that version is not available for 64bit.

[TheRyuu]

I can't even use DGAVCDecode since that version is not available for 64bit.

You know not using 64-bit is an acceptable solution. What about DGDecodeDI or DGDecodeNV (the latter even supports vc1)? You do know that you can run 32-bit applications on a 64-bit copy of Windows right?

I also doubt that the ffdshow deinterlacers are any good (other than yadif which can be used from avisynth as well).

[LoRd_MuldeR]

@Chumbo:
Depending on what you are doing, running Avisynth in a 32-Bit process and processing the video in a separate 64-Bit process (e.g. x264) may be a feasible solution.

[LigH]

Is FFIndex (either in ffms2.dll or via ffmsindex.exe) able to support a list of VOB segments as source (like DGMPGDec does), if not even an IFO (ideally with a PGC/angle definition, or at least a PGC/angle VOB set stripped by the ripper in IFO/movie mode or PGCDemux), and an MPLS Blu-ray playlist?

If not yet ... where is the recommendable place to add such a feature request?
__

P.S.: Exists already... (http://code.google.com/p/ffmpegsource/issues/detail?id=78)

[Chumbo]

You know not using 64-bit is an acceptable solution. What about DGDecodeDI or DGDecodeNV (the latter even supports vc1)? You do know that you can run 32-bit applications on a 64-bit copy of Windows right?

I also doubt that the ffdshow deinterlacers are any good (other than yadif which can be used from avisynth as well).
Yep, I do know that. Unfortunately, when I run it that way, the components crash all the time, e.g., x264 successfully encodes pass1 and then crashes. This means I have to manually intervene constantly for every component that crashes. I'm an ATI shop so I can't use DGDecodeNV but did NOT know about DGDecodeDI so I'll definitely look that up. Thanks for the heads up. BTW, my source is AVC so I would need DGAVCDecode for 64bit.

I much prefer to use yadif which is what I was using in my scripts but with the problems with encoding these interlaced files with ffms2 I've been trying to find an alternative solution that is still free.

@Chumbo:
Depending on what you are doing, running Avisynth in a 32-Bit process and processing the video in a separate 64-Bit process (e.g. x264) may be a feasible solution.
Yep and per what I stated above, I actually started down that road initially but ran into the problems where the 32bit apps were essentially crashing at the end of their run which required constant manual intervention to my automated processes. Unless I'm missing something in how I'm running these? I have tried several different compatibility modes but got the same results.

The only way I was able to do this was to create a virtual machine running Windows 32bit but it's really slow to do this inside a VM.

[TheFluff]

Is FFIndex (either in ffms2.dll or via ffmsindex.exe) able to support a list of VOB segments as source (like DGMPGDec does), if not even an IFO (ideally with a PGC/angle definition, or at least a PGC/angle VOB set stripped by the ripper in IFO/movie mode or PGCDemux), and an MPLS Blu-ray playlist?

If not yet ... where is the recommendable place to add such a feature request?
__

P.S.: Exists already... (http://code.google.com/p/ffmpegsource/issues/detail?id=78)

It's been on the todo list for ages, issue #33 (http://code.google.com/p/ffmpegsource/issues/detail?id=33) is an even older feature request for the same thing.

[Chumbo]

...I can't even use DGAVCDecode since that version is not available for 64bit.
Let me clarify what I said here. I CAN use dgdecode to produce the dga file. What I CANNOT do is load the DLL and use AVCSource in the script.

[TheRyuu]

This is getting fairly off topic but it obviously shouldn't be crashing so you should probably look into why it is. Using 64-bit avisynth really is not an acceptable solution considering it's basically one giant hack.

[Chumbo]

I agree, so back on topic. I think I found a working solution using ffms2. I've encoded around 15 files so far and they all good. Here's my script:LoadPlugin("C:\megui64\tools\ffms\ffms2.dll")
FFVideoSource("file.ts", threads=1)
LoadPlugin("C:\megui64\tools\avisynth_plugin\TIVTC.dll")
telecide(guide=1,order=1,hints=true,post=1)
Load_Stdcall_Plugin("C:\megui64\tools\yadif\yadif.dll")
Yadif(mode=0, order=1)
converttoyv12()
My sources are all AVC interlaced at 30fps (30i and 60i) and 29.976fps. I am doing 2-pass and doing this linearly but did not specifically set seekmode nor using lavf for demuxer. So far so good.

[Atak_Snajpera]

Can I ask somebody to compile r644 for me?

[TheRyuu]

Can I ask somebody to compile r644 for me?

ffms2-r644.7z (http://ffmpegsource.googlecode.com/files/ffms2-r644.7z)

[Atak_Snajpera]

Thank you!

[burfadel]

Thanks + 1!

[Chumbo]

Thanks + 1!
me2...

[Atak_Snajpera]

sample -> http://forum.doom9.org/showthread.php?p=1551814#post1551814

keyframe locations detected by ffindex
# keyframe format v1
fps 0
0
14
15
28
42
56
70
84
98
112
126
140
154
168
182
196
210
224
238
252
266
280
294
308
322
336
350
364
378
392
406
420
434
448
462
476
490
504
518
532
546
560
574
588
602
616
630
644
658
672
686
700
714
728
742
756
770
784
798
812
826
840
854
868
882
896
910
924
938
952
966
980
994
1008
1022
1036
1050
1064
1078
1092
1106
1120
1134
1148
1162
1176
1190
1204
1218
1232
1246
1260
1274
1288
1302
1316
1330
1344
1358


However if I ask for key frame (let's say 238) video starts from corrupted frame
FFVideoSource("..\video.mkv",threads=1)
Trim(238,1358)


but if use Trim(237,...) everything is ok!

I suspect that ffmpeg has some bug that it adds one frame to requested frame
Example: In order to start from keyframe you always must use Trim(detected_keyframe - 1, ...)

I tested with many BD VC-1 sources and above rule is always valid!

Maybe this a reason why corruption occurs while random seeking in VC-1 .

For mpeg2 and AVC keyframe is always correctly returned.

[TheFluff]

FFMS returns an error along the lines of "Insanity detected: decoder returned an empty frame" for this (http://stfcc.org/misc/ffmpegsource.empty.frame.mkv) sample. ffmpeg/ffplay/everything else based off ffmpeg/libav plays it fine.

I don't get that message with threads=1, but the file exhibits the usual interlaced h264 shenanigans and also features significant corruption. MPC-HC plays it with some minor corruptions as well.

On a related note, FFMS returns mangled timestamps for this (http://stfcc.org/misc/ffmpegsource.mangled.timestamps.ts) sample. The timecode file ffindex writes shows that multiple frames are displayed at the same time, which x264 doesn't seem to like.

Haali's parser returns the same PTS twice or more in certain places in this stream. Not sure why, I haven't investigated deeper yet.

Edit: it seems to be because the stream is a mix of progressive and interlaced coded frames and Haali's parser returns one packet per field in some cases, and then both fields have the same PTS. While meditating on this I think I also might have discovered why we're getting those annoying frame duplication issues with interlaced h264. I'll return to this later.

[TheFluff]

If you desperately need to open H.264 files using the RGB-hidden-in-YUV444 trick, here's a patched build that might do what you want: http://mod16.org/ffms2/ffms2-r654-gbrphack.7z

This is needed because vanilla builds of FFMS2 currently suffer from a bug in SWScale that makes such files take a roundtrip via YUV and also clamps the output to TV range. It's really a pretty ugly hack though and will not be committed to SVN; the SWScale maintainer is aware of the issue and is going to fix it Soon(tm).

Patch is in the archive.

[LigH]

How can I avoid FFMS2 "going insane" and returning empty frames at tiny little video stream errors another VfW codec or DirectShow decoder survives?

[Gser]

How can I avoid FFMS2 "going insane" and returning empty frames at tiny little video stream errors another VfW codec or DirectShow decoder survives?

By not using FFMS2, not multithreading it also helps sometimes.

[LigH]

not multithreading it also helps sometimes.

:o That was the key I should have known already but forgot to remember.

Now I have a blue range there, that's indeed way better than a crash.

[TheFluff]

How can I avoid FFMS2 "going insane" and returning empty frames at tiny little video stream errors another VfW codec or DirectShow decoder survives?

A lot of the empty frame errors are probably caused by a bug in the frame delay calculation in FFMS2, in turn sorta caused by ffmpeg changing the definition of has_b_frames. We're working on it.

[horrormaster34]

Is it just me or do none of the FFIndex options work? I've tried to use "source", but it says that it can't open it. If I leave out "source" and call the file then it works. If I use "indexmask=-1" it uses that as the index file name. If I try to set the index file name using "cachefile" it again uses that as the index file name.

ex: ffmsindex64.exe D:\inputfile.mkv cachefile=D:\output.mkv.ffindex

that returns the index file as a literal cachefile=D:\output.mkv.ffindex instead of simply output.mkv.ffindex.

If I try to use any of the other options it just shows a message that it's unrecognized.

[TheFluff]

Is it just me or do none of the FFIndex options work? I've tried to use "source", but it says that it can't open it. If I leave out "source" and call the file then it works. If I use "indexmask=-1" it uses that as the index file name. If I try to set the index file name using "cachefile" it again uses that as the index file name.

ex: ffmsindex64.exe D:\inputfile.mkv cachefile=D:\output.mkv.ffindex

that returns the index file as a literal cachefile=D:\output.mkv.ffindex instead of simply output.mkv.ffindex.

If I try to use any of the other options it just shows a message that it's unrecognized.

Looks like you're using the parameters intended for FFIndex() the avisynth function, not the commandline parameters to ffmsindex.exe. Those aren't in the documentation, by the way, so don't bother looking; just run ffmsindex.exe without any parameters at all and it'll tell you how to use it.

edit: like so:
C:\> ffmsindex
FFmpegSource2 indexing app
Usage: ffmsindex [options] inputfile [outputfile]
If no output filename is specified, inputfile.ffindex will be used.

Options:
-f Force overwriting of existing index file, if any (default: no)
-v Set FFmpeg verbosity level. Can be repeated for more verbosity. (default: no messages printed)
-p Disable progress reporting. (default: progress reporting on)
-c Write timecodes for all video tracks to outputfile_track00.tc.txt (default: no)
-k Write keyframes for all video tracks to outputfile_track00.kf.txt (default: no)
-t N Set the audio indexing mask to N (-1 means index all tracks, 0 means index none, default: 0)
-d N Set the audio decoding mask to N (mask syntax same as -t, default: 0)
-a NAME Set the audio output base filename to NAME (default: input filename)
-s N Set audio decoding error handling. See the documentation for details. (default: 0)
-m NAME Force the use of demuxer NAME (default, lavf, matroska, haalimpeg, haaliogg)

[horrormaster34]

Wow, don't I feel stupid. Thanks for that TheFluff

[Selur]

btw. would be nice to have something like -kc which would output the keyframe and the time belonging to it to an output file,.. ;)

[Atak_Snajpera]

btw. would be nice to have something like -kc which would output the keyframe and the time belonging to it to an output file,.. ;)

key_frame_number/fps

[kemuri-_9]

key_frame_number/fps

that isn't guaranteed to work when the content is VFR.

[TheFluff]

btw. would be nice to have something like -kc which would output the keyframe and the time belonging to it to an output file,.. ;)

You get both the keyframes and the timecodes for all frames, it should be trivial to combine them.

[Selur]

Can someone explain how to get the time codes (through the API) without having to write a timecode file to hdd (by using FFMS_WriteTimecodes) ?

[TheFluff]

Assuming the video track has track number 0 (use FFMS_GetFirstIndexedTrackOfType if unsure), that you have indexed the file and have the index object handy (if you have already opened the video, just use FFMS_GetTrackFromVideo instead of FFMS_GetTrackFromIndex):

FFMS_Track *track = FFMS_GetTrackFromIndex(index, 0);
const FFMS_TrackTimeBase *timebase = FFMS_GetTimeBase(track);
const FFMS_FrameInfo *current_frame;
std::vector<int> timecodes;
int num_frames = FFMS_GetNumFrames(track);

for (int i = 0; i < num_frames; i++) {
current_frame = FFMS_GetFrameInfo(track, i);
if (current_frame->KeyFrame) {
// true if frame is a keyframe.
// do something?
}
int timestamp = (int)((current_frame->PTS * timebase->Num) / timebase->Den); // wallclock milliseconds
timecodes.push_back(timestamp);
}


Naturally you should always check the return value of all functions against NULL to see if they failed. I skipped that here, for brevity. Note that FFMS_GetNumFrames will return 0 for an unindexed track. That should probably never happen with a video track, but I'm just sayin'.

Of course you can use any data structure of your liking to store the list of integer timestamps, I just used a std::vector for this example. You could also store the timestamps as floats or doubles if you wanted to.

[Selur]

Nice thanks !

[Selur]

while at it is there a way to get the frame type this way too or does it require a GetFrame (GetFrameInfo is way faster ;)) ?

[Myrsloik]

while at it is there a way to get the frame type this way too or does it require a GetFrame (GetFrameInfo is way faster ;)) ?

GetFrame() is the only way to get that. Containers only contain keyframe flags and nothing else so full decoding is always needed.

[bencahill]

But I figured out why it works for Yellow_ but not for me or bencahill; it turns out it's lavc's multithreaded decoding that's broken on this file (what a surprise). ffvideosource("derp.mov",threads=1) works fine.

Thank you, this fixed it for me. I know I haven't posted in a while, just busy with school. :-)

The only problem with this is that my computer can play 1080p through FFVideoSource, but not with threads=1 (it gets probably 15-20fps), which means I'll still have to switch back and forth to have realtime playback during editing and quality video during encoding. This is still much better than the alternative, using FFMS for editing and MPEGAutoIndex for encoding (it also is not fast enough for realtime on my computer), and therefore index/whatever files specific to both, and more script lines.

Thanks again. :-)

[Atak_Snajpera]

again i would like to ask someone to compile r666 for me (nice number btw :)
TGOYNE seems to fixed corrupted frames in mkv with vc1.

[burfadel]

Yes, a new build would be good!

[JEEB]

Built a standard ffms2 with Release configuration. Available here (http://x264.fushizen.eu/builds/ffms2/ffms2-r666-libav-git90e5b58.7z).
ffms2: r666, libav: git-90e5b58

libav configuration:
--prefix=/ffms --enable-gpl --disable-network --disable-encoders --disable-muxers --disable-hwaccels --disable-indevs --disable-outdevs --extra-cflags='-U__STRICT_ANSI__' --extra-cflags='-DPTW32_STATIC_LIB' --disable-debug --enable-runtime-cpudetect

Works fine with Aegisub for me after testing it with a couple of files :)

Edit: iFail -- I had two ffms source code folders and I had run svn up on the wrong one >_> Compiling anew.
Edit2: File replaced, now this should really be r666.

[Atak_Snajpera]

Thanks JEEB!!!

[sneaker_ger]

The following interlaced H.264 sample will not work correctly in ffms2 (tested 2.17, r644, r666):
http://www.mediafire.com/?ubxfydr4owr2rmo

Multi-threaded: insanity, decoder delivers empty frame after first(?) frame
1 thread: jumping back and forth

[jmac698]

I have that same problem, apparently ffms doesn't work on interlaced h264 at all. It's a bug still in libav I think.

[sneaker_ger]

Yes, you're probably correct:
http://forum.doom9.org/showthread.php?p=1558212#post1558212

So I presume the problem is already known and we have to be patient.

[jmac698]

The only solution now is to buy dgnv or whatever it's called.

[burfadel]

Built a standard ffms2 with Release configuration. Available here (http://x264.fushizen.eu/builds/ffms2/ffms2-r666-libav-git90e5b58.7z).
.

Thanks! very much appreciated :)

[TheFluff]

Yes, you're probably correct:
http://forum.doom9.org/showthread.php?p=1558212#post1558212

So I presume the problem is already known and we have to be patient.

Yes, it's the same problem that has been known since forever; we only recently figured out the root cause. There's no fix yet, though.

[qyot27]

Revisiting the crash issue with certain MKV files, it seems to be related specifically to the way MinGW handles (or rather, mangles) setjmp and longjmp in matroskaparser.c when any sort of optimizations in gcc are used (as there are a couple of optimizations I saw listed in gcc's docs that seemed to do something to -jmp calls), and that files that lack certain information in their metadata or headers or whatever happen to be what can set it off, probably because those files need those calls to not be broken by MinGW, and that's only true when optimizations are turned off. It also now happens with trunk builds linked into x264, not just the C-interface AviSynth plugin, but only when built with MinGW. Cygwin and native Linux builds are wholly unaffected.

I did manage to get a backtrace a couple of weeks ago, below:
$ gdb ffmsindex.exe
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from c:\dap\vid\Incoming Files\ffms2-avs_r658-optdebug\ffmsindex.exe...done.

(gdb) r -t -1 ffms2crashtest.mkv
Starting program: c:\dap\vid\Incoming Files\ffms2-avs_r658-optdebug\ffmsindex.exe -t -1 ffms2crashtest.mkv
[New Thread 3956.0xf78]
Indexing, please wait... 0%
Program received signal SIGSEGV, Segmentation fault.
0x77c3554a in msvcrt!_abnormal_termination ()
from C:\WINDOWS\system32\msvcrt.dll

(gdb) bt
#0 0x77c3554a in msvcrt!_abnormal_termination ()
from C:\WINDOWS\system32\msvcrt.dll

(gdb) disass $pc-32,$pc+32
Dump of assembler code from 0x77c3552a to 0x77c3556a:
0x77c3552a <msvcrt!_abnormal_termination+19>: push %ecx
0x77c3552b <msvcrt!_abnormal_termination+20>: or $0x8b,%al
0x77c3552d <msvcrt!_abnormal_termination+22>: push %edx
0x77c3552e <msvcrt!_abnormal_termination+23>: or $0x39,%al
0x77c35530 <msvcrt!_abnormal_termination+25>: push %ecx
0x77c35531 <msvcrt!_abnormal_termination+26>: or %dh,0x5(%ebp)
0x77c35534 <msvcrt!_abnormal_termination+29>: mov $0x1,%eax
0x77c35539 <msvcrt!_abnormal_termination+34>: ret
0x77c3553a <msvcrt!_abnormal_termination+35>: push %ebx
0x77c3553b <msvcrt!_abnormal_termination+36>: push %ecx
0x77c3553c <msvcrt!_abnormal_termination+37>: mov $0x77c5f990,%ebx
0x77c35541 <msvcrt!_abnormal_termination+42>: jmp 0x77c3554d <msvcrt!_abnormal_termination+54>
0x77c35543 <msvcrt!_abnormal_termination+44>: push %ebx
0x77c35544 <msvcrt!_abnormal_termination+45>: push %ecx
0x77c35545 <msvcrt!_abnormal_termination+46>: mov $0x77c5f990,%ebx
=> 0x77c3554a <msvcrt!_abnormal_termination+51>: mov 0x8(%ebp),%ecx
0x77c3554d <msvcrt!_abnormal_termination+54>: mov %ecx,0x8(%ebx)
0x77c35550 <msvcrt!_abnormal_termination+57>: mov %eax,0x4(%ebx)
0x77c35553 <msvcrt!_abnormal_termination+60>: mov %ebp,0xc(%ebx)
0x77c35556 <msvcrt!_abnormal_termination+63>: push %ebp
0x77c35557 <msvcrt!_abnormal_termination+64>: push %ecx
0x77c35558 <msvcrt!_abnormal_termination+65>: push %eax
0x77c35559 <msvcrt!_abnormal_termination+66>: pop %eax
0x77c3555a <msvcrt!_abnormal_termination+67>: pop %ecx
0x77c3555b <msvcrt!_abnormal_termination+68>: pop %ebp
0x77c3555c <msvcrt!_abnormal_termination+69>: pop %ecx
0x77c3555d <msvcrt!_abnormal_termination+70>: pop %ebx
0x77c3555e <msvcrt!_abnormal_termination+71>: ret $0x4
0x77c35561 <msvcrt!_abnormal_termination+74>: int3
0x77c35562 <msvcrt!_abnormal_termination+75>: int3
0x77c35563 <msvcrt!_abnormal_termination+76>: int3
0x77c35564 <msvcrt!_abnormal_termination+77>: int3
0x77c35565 <msvcrt!_abnormal_termination+78>: int3
0x77c35566 <msvcrt!_assert+0>: mov %edi,%edi
0x77c35568 <msvcrt!_assert+2>: push %ebp
0x77c35569 <msvcrt!_assert+3>: mov %esp,%ebp
End of assembler dump.

(gdb) info all-registers
eax 0x6ed86b2e 1859676974
ecx 0x77c39bc6 2009308102
edx 0xffffff01 -255
ebx 0x77c5f990 2009463184
esp 0x22f24c 0x22f24c
ebp 0x0 0x0
esi 0x22ffe0 2293728
edi 0x0 0
eip 0x77c3554a 0x77c3554a <msvcrt!_abnormal_termination+51>
eflags 0x10246 [ PF ZF IF RF ]
cs 0x1b 27
ss 0x23 35
ds 0x23 35
es 0x23 35
fs 0x3b 59
gs 0x0 0
st0 0 (raw 0x00000000000000000000)
st1 0 (raw 0x00000000000000000000)
st2 <invalid float value> (raw 0x022200f6a7e800618c9c)
st3 -1 (raw 0xbfff8000000000000000)
st4 -1 (raw 0xbfff8000000000000000)
st5 9.9999999999999995e-021 (raw 0x3fbcbce5086492111aeb)
st6 23.976024167640553 (raw 0x4003bfcee5c240f97000)
st7 3.455309232230784e+018 (raw 0x403cbfcee5c240f97002)
fctrl 0xffff037f -64641
fstat 0xffff0420 -64480
ftag 0xffffffff -1
fiseg 0x1b 27
fioff 0x6f2f05c6 1865352646
foseg 0xffff0023 -65501
fooff 0x22f428 2290728
fop 0x77c 1916
xmm0 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x3, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xff, 0x0, 0x0, 0x0,
0x70, 0xf8, 0x22, 0x0}, v8_int16 = {0x103, 0x0, 0x0, 0x0, 0xff, 0x0,
0xf870, 0x22}, v4_int32 = {0x103, 0x0, 0xff, 0x22f870}, v2_int64 = {
0x103, 0x22f870000000ff}, uint128 = 0x0022f870000000ff0000000000000103}
xmm1 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x3, 0x1, 0x0, 0x0, 0x3b, 0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0,
0x6c, 0xf0, 0x22, 0x0}, v8_int16 = {0x103, 0x0, 0x3b, 0x0, 0x1, 0x0,
0xf06c, 0x22}, v4_int32 = {0x103, 0x3b, 0x1, 0x22f06c}, v2_int64 = {
0x3b00000103, 0x22f06c00000001},
uint128 = 0x0022f06c000000010000003b00000103}
xmm2 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x3c, 0xa3, 0x61, 0x0, 0x98, 0xe4, 0x22, 0x0, 0x0, 0x1, 0x0,
0x0, 0xe0, 0xff, 0x22, 0x0}, v8_int16 = {0xa33c, 0x61, 0xe498, 0x22,
0x100, 0x0, 0xffe0, 0x22}, v4_int32 = {0x61a33c, 0x22e498, 0x100,
0x22ffe0}, v2_int64 = {0x22e4980061a33c, 0x22ffe000000100},
uint128 = 0x0022ffe0000001000022e4980061a33c}
xmm3 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x2c, 0xed, 0x22, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0xdc, 0xf0, 0x22, 0x0}, v8_int16 = {0xed2c, 0x22, 0x0, 0x0, 0x0, 0x0,
0xf0dc, 0x22}, v4_int32 = {0x22ed2c, 0x0, 0x0, 0x22f0dc}, v2_int64 = {
0x22ed2c, 0x22f0dc00000000}, uint128 = 0x0022f0dc00000000000000000022ed2c}
xmm4 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x9c, 0x8c, 0x61, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0xd4, 0xee, 0x22, 0x0}, v8_int16 = {0x8c9c, 0x61, 0x0, 0x0, 0x0, 0x0,
0xeed4, 0x22}, v4_int32 = {0x618c9c, 0x0, 0x0, 0x22eed4}, v2_int64 = {
0x618c9c, 0x22eed400000000}, uint128 = 0x0022eed4000000000000000000618c9c}
xmm5 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0,
0x8000000000000000}, v16_int8 = {0x47, 0x95, 0x61, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x20, 0xe9, 0x90, 0x7c}, v8_int16 = {0x9547,
0x61, 0x0, 0x0, 0x0, 0x0, 0xe920, 0x7c90}, v4_int32 = {0x619547, 0x0,
0x0, 0x7c90e920}, v2_int64 = {0x619547, 0x7c90e92000000000},
uint128 = 0x7c90e920000000000000000000619547}
xmm6 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x3, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0xf0, 0xf0, 0x22, 0x0}, v8_int16 = {0x103, 0x0, 0x0, 0x0, 0x0, 0x0,
0xf0f0, 0x22}, v4_int32 = {0x103, 0x0, 0x0, 0x22f0f0}, v2_int64 = {0x103,
0x22f0f000000000}, uint128 = 0x0022f0f0000000000000000000000103}
xmm7 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x9c, 0x8c, 0x61, 0x0, 0x0, 0x0, 0x0, 0x0, 0xff, 0x0, 0x0, 0x0,
0x70, 0xf8, 0x22, 0x0}, v8_int16 = {0x8c9c, 0x61, 0x0, 0x0, 0xff, 0x0,
0xf870, 0x22}, v4_int32 = {0x618c9c, 0x0, 0xff, 0x22f870}, v2_int64 = {
0x618c9c, 0x22f870000000ff}, uint128 = 0x0022f870000000ff0000000000618c9c}
mxcsr 0x1f80 [ IM DM ZM OM UM PM ]
mm0 {uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0,
0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}
mm1 {uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0,
0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}
mm2 {uint64 = 0xf6a7e800618c9c, v2_int32 = {0x618c9c, 0xf6a7e8},
v4_int16 = {0x8c9c, 0x61, 0xa7e8, 0xf6}, v8_int8 = {0x9c, 0x8c, 0x61, 0x0,
0xe8, 0xa7, 0xf6, 0x0}}
mm3 {uint64 = 0x8000000000000000, v2_int32 = {0x0, 0x80000000},
v4_int16 = {0x0, 0x0, 0x0, 0x8000}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x80}}
mm4 {uint64 = 0x8000000000000000, v2_int32 = {0x0, 0x80000000},
v4_int16 = {0x0, 0x0, 0x0, 0x8000}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x80}}
mm5 {uint64 = 0xbce5086492111aeb, v2_int32 = {0x92111aeb,
0xbce50864}, v4_int16 = {0x1aeb, 0x9211, 0x864, 0xbce5}, v8_int8 = {0xeb,
0x1a, 0x11, 0x92, 0x64, 0x8, 0xe5, 0xbc}}
mm6 {uint64 = 0xbfcee5c240f97000, v2_int32 = {0x40f97000,
0xbfcee5c2}, v4_int16 = {0x7000, 0x40f9, 0xe5c2, 0xbfce}, v8_int8 = {0x0,
0x70, 0xf9, 0x40, 0xc2, 0xe5, 0xce, 0xbf}}
mm7 {uint64 = 0xbfcee5c240f97002, v2_int32 = {0x40f97002,
0xbfcee5c2}, v4_int16 = {0x7002, 0x40f9, 0xe5c2, 0xbfce}, v8_int8 = {0x2,
0x70, 0xf9, 0x40, 0xc2, 0xe5, 0xce, 0xbf}}

(gdb)

A comparison between files using mkvinfo -v, stuff written by x264 (files that cause the crash) lack Segment size information (as 'size unknown'), Seek head, EbmlVoid data, and the final Cues entry. Both the mkvmerge and libavformat test files (which work correctly) have those entries intact and the Segment size actually contains a numeric value.



On a partially related note, a patch that I cobbled together for the C plugin that allows the user to more easily select the optimization level during configure.
https://github.com/qyot27/ffms2-cinterface/commit/d472e682c4300956b3bc30b048923d369af65fca

[cjplay]

Just a quick thank you. I downloaded the build for 666 from a few posts up and wish to thank the developers for fixing an issue I've been having with ProResHQ 10-bit decoding. I don't know which build it was, but it was after 644, so thank you.

-CJ

PS - Sign of the beast is the build that works??? Holy :devil:!

[JEEB]

For the RGB-in-H.264 folk another build. Available here (http://x264.fushizen.eu/builds/ffms2/ffms2-r671-libav-git0aaa45e.7z).
ffms2: r671, libav: git-0aaa45e with D404's related backport (http://patches.libav.org/patch/19830/mbox/) (web view (http://patches.libav.org/patch/19830/)).

libav configuration:
--prefix=/ffms --disable-network --disable-encoders --disable-muxers --disable-hwaccels --disable-indevs --disable-outdevs --extra-cflags='-U__STRICT_ANSI__' --disable-debug --enable-runtime-cpudetect

If this backport doesn't get into mainline libav soon enough I will herp a derp.

[Yellow_]

Edit: for reference, FFMS2 now behaves like this: if the input pixel format is one of the YUVJ* ones, the video is assumed to be fullrange, regardless of what the CodecContext->color_range metadata flag might say. For all other pixel formats, FFMS2 uses whatever the CodecContext->color_range flag says. If that's unspecified, limited range is assumed.

What are the characteristics of a yuvj420p source compared to yuv420p? Is yuvj JFIF? Is chroma placement different? Is chroma normalised over 0 - 255 along with luma? I'm struggling to find any decent info on what yuvj is.

If yuvj420p is simply deemed full range luma 4:2:0 progressive because it's flagged 'fullrange' so then is it no different from yuv420p with full luma unflagged that makes up a big proportion of YCC certainly video off cameras. Is it just suggested differing handling for playback, if the flag's honoured at all.

The result I see importing flagged full range YCC into an NLE's for example is it treats it as 0 - 255 levels, scale luma to 16 - 235 so it can then expand again to 0 - 255 RGB for color processing.

For avisynth if it's just a luma thing then makes no difference if it's yuvj420p or yuv420p as long as it's not scaled at decompression? Am I correct in thinking that?

[kemuri-_9]

my understanding is that the J stands for "JPEG" which uses pc/full range in comparison to the standard ones which are tv/limited range.

you seem to be thinking that the range of values only applies to luma, but it actually applies to chroma as well...

[Yellow_]

my understanding is that the J stands for "JPEG" which uses pc/full range in comparison to the standard ones which are tv/limited range.

Yes, that's my understanding too, but only with regard to playback handling, surely unless specifically requested there should be no messing with levels just transcoding but there is. We've all seen sources with levels outside of 16 - 235/240. XDCAM off a $20,000 Canon C300 for example. It's not flagged as such it's not h264. ffmpeg / CS5 treat the XDCAM as yuv420p but it still has full luma, 16 -240 chroma.

An example, this native Canon DSLR source file to me is just YCbCr 4:2:0, it uses a BT601 color matrix and BT709 transfer. It has luma that goes above 235 and chroma that stays well inside 16 - 240 even as saturated yellow/gold as it is:

http://www.yellowspace.webspace.virginmedia.com/Gold.aMOV

ffmpeg gives it a pixel format of yuvj420p. Adobe Premiere CS5 treats it as full range so scales luma on decompression for the YCC to RGB conversion. But the chroma is 16 - 240 so can it still be jpeg / JFIF, can chroma be normalised this way so it appears to be just typical yuv420p?.

If I remux the Gold.MOV above with komisars patched build of MP4Box and turn off the fullrange flag it's handled by CS5 and ffmpeg as yuv420p not yuvj. The files histogram look better in the conversion to RGB treated as yuv420p and forcing ffmpeg to use full luma than it does just as yuvj420p or as yuvj420p and forcing full luma.

So this is my query, am I missing something, is chroma placement different ie: centre for jpeg vs left for mpeg or simply is it because it's flagged fullrange in the h264 VUI Option? By the camera firmware simply to suggest playback handling as it's perhaps considered a 'consumer' camera and h264 gives possibility to flag it.

you seem to be thinking that the range of values only applies to luma, but it actually applies to chroma as well...

Actually no I'm not under that impression. I'm aware of it, for example xvYCC is over full luma and chroma and JFIF has luma and chroma normalised over full range if I understand correctly, this is my point I think, why yuvj420p if the source files are not full chroma, even well saturated. ColorYUV(analyze=true) gives no chroma outside 16 - 240 with any of my yuvj420p deemed source files, that's using ffmpegsource2 or QTInput. Is this some dumb ffmpeg behaviour over the use of the fullrange flag?

Or I have I misinterpreted you answer, do you mean chroma is scaled as well as luma when decompressing yuvj?

Thanks for the reply.

[qyot27]

Using komisar's gcc 4.6.2 package or the i686-w64-mingw32-gcc 4.6.3 provided by Ubuntu 12.04 results in the C plugin being utterly broken. It probably affects distributions of MinGW-w64's gcc by other sources, and I wouldn't be at all surprised if it has to do with how gcc itself was compiled, but trying to work around this is driving me batty. The 4.6.1 in 11.10 didn't have any of this mess. On that same token, FFmpeg and x264 also get wonky with >4.6.1, but that can be adjusted with much of the same method (I physically moved all *.dll.a files in /usr/lib/gcc/i686-w64-mingw32/4.6 to a subdirectory so it wouldn't try to use them). The trunk seems to be entirely unaffected, as it loaded video fine as part of x264, provided the aforementioned moving of *.dll.a stuff first so that those builds don't require extra .dlls.

With komisar's 4.6.2, it can be fairly easily circumvented by passing -static-libgcc -static-libstdc++ to --extra-ldflags, and seems to work fine. Unfortunately, my attempts on Ubuntu at inserting a version check into configure that ensures these options are used for gcc >=4.6 resulted in getting ffmsindex-related link errors when both options were specified together (the library seemed to build right, except that I didn't actually test whether it worked; it compiled, which was as far as I went). The check seemed to be okay, but ffmsindex did not like the use of -static-libstdc++ - leaving it out isn't an option, though, since it causes annoying external dependency issues and if those are accounted for, I still ran into it causing Access Violation errors in AviSynth when trying to load scripts using the plugin. I didn't try to dig enough into how to get -static-libstdc++ to be used for the library only, and omitted from ffmsindex's link step.

EDIT: Yeah, so I screwed that description up. It's -static-libgcc that ffmsindex doesn't like, not static-libstdc++.

EDIT 2012-05-21: Finally resolved by recompiling the MinGW-w64 environment with Zeranoe's build script. It also confirmed that it was the shared crap that was screwing up the repo versions, as I made sure to have it build fully static. The resultant builds were fine, just like they were before. And it only took 6 hours to get set up.

[JEEB]

There've been some additional commits over at ffms2, so a new build (also the RGB-in-H.264 stuff got put into libav as well quite some time ago). Available here (http://x264.fushizen.eu/builds/ffms2/ffms2-r680-libav-gitf132248.7z).
ffms2: r680, libav: git-f132248

libav configuration:
--prefix=/ffms --disable-network --disable-encoders --disable-muxers --disable-hwaccels --disable-indevs --disable-outdevs --extra-cflags='-U__STRICT_ANSI__' --disable-debug --enable-runtime-cpudetect

[Reel.Deel]

Thank you very much JEEB!

[jmac698]

Did interlaced h.264 get fixed yet?

[JEEB]

Did interlaced h.264 get fixed yet?

I don't think anything has gotten fixed in relation to interlaced H.264 in ffms, but when I tested my build in Aegisub with a random "interlaced H.264 in m2ts" clip, I seem to get a very "stable/slow" way of seeking at least (seems to be gradually decoded from the beginning to the frame I asked), and the output seems to be fine :)

Your Mileage May Vary

[tebasuna51]

Did interlaced h.264 get fixed yet?

Same problem with this sample:

The following interlaced H.264 sample will not work correctly in ffms2 (tested 2.17, r644, r666):
http://www.mediafire.com/?ubxfydr4owr2rmo

1 thread: jumping back and forth

[burfadel]

There've been some additional commits over at ffms2, so a new build (also the RGB-in-H.264 stuff got put into libav as well quite some time ago). Available here (http://x264.fushizen.eu/builds/ffms2/ffms2-r680-libav-gitf132248.7z).

Thanks for the new build, much appreciated!

[Skauneboy]

Could any kind soul please compile a x64 build? Thanks!

[rogerdpack]

I assume FFMS2 can't be used for live unindexed capture sources, like
FFVideoSource("-f dshow -i video=screen-capture-recorder")
If it could some day that would might be kind :)
Thanks much.
-roger-

[Plorkyeran]

Why not just use DirectShowSource there? There are potential usecases for FFMS with no index and no seeking allowed, but that doesn't appear to be one of them.

[rogerdpack]

I am not a pro at it, but it appears DirectShowSource your only option is a .grf file, and I don't know how to easily make a .grf file specify "which size and color format" you want out of the pins, etc. But I haven't looked into it too closely yet.

[TheRyuu]

Could any kind soul please compile a x64 build? Thanks!
ffms2-r683.7z (https://ffmpegsource.googlecode.com/files/ffms2-r683.7z)

Built with ffmpeg rev. d1384c0
Contains both 32 and 64-bit binaries.

[Mug Funky]

roger: unless i'm misunderstanding your needs, you could use avisynth in ffdshow if you needed to work off something live.

this works rather well for realtime waveform and vectorscopes on a geurilla filmmaker setup.

[rogerdpack]

roger: unless i'm misunderstanding your needs, you could use avisynth in ffdshow if you needed to work off something live.

this works rather well for realtime waveform and vectorscopes on a geurilla filmmaker setup.

I assume you just use graphedit files for your input to avisynth then? Or, rather, how do you get live input to your avisynth per se?
Thanks1
-roger-

[hello_hello]

I assume you just use graphedit files for your input to avisynth then? Or, rather, how do you get live input to your avisynth per se?
Thanks1
-roger-

ffdshow has an AVISynth filter. Enable it and copy and paste your AVISynth script into the filter's text area. Also make sure the "Add ffdshow video source" checkbox is ticked.

If memory serves me correctly, ffdshow installs optional AVISynth plugins in order for it's AVISynth filter to work. If they're not in the AVISynth plugins folder (ffavisynth.avsi and ffavisynth.dll) then re-installing ffdshow while selecting the option to install them should fix that.

From there as long as you're decoding via DirectShow when encoding, and as long as ffdshow is doing the decoding, the script you added to ffdshow's AVISynth filter should run.

[rogerdpack]

Oh wow thanks hello_hello that is fascinating news. The question kind of still remains as to how to get "live" input into your avisynth script, but I have a kludgey work around in the form of the graphedit files...

[TheFluff]

Avisynth isn't really suited to processing streaming inputs, since it requires the length of the input to be known when the script is opened.

[rogerdpack]

I've had "reasonably good luck" by using it to play an incoming graphedit file source, and just specifying frames as 1 million. Obviously this is non optimal but hey, at least it tries.

[Gavino]

If memory serves me correctly, ffdshow installs optional AVISynth plugins in order for it's AVISynth filter to work. If they're not in the AVISynth plugins folder (ffavisynth.avsi and ffavisynth.dll) then re-installing ffdshow while selecting the option to install them should fix that.
ffavisynth.avsi and ffavisynth.dll are not required in order to use the Avisynth filter inside ffdshow.
They are for a different purpose, allowing you to use ffdshow's own filters inside Avisynth.

http://forum.doom9.org/showthread.php?t=85447

[qyot27]

Seems that r686 breaks C-plugin compilation. r684 compiles without a hitch.

gcc -Wall -march=pentium3 -mtune=pentium3 -std=gnu99 -s -fomit-frame-pointer -I/home/Stephen/win32_build/include -I. -Iinclude -D_FILE_OFFSET_BITS=64 -DFFMS_USE_FFMPEG_COMPAT -c -o src/avisynth_c/avisynth.o src/avisynth_c/avisynth.c
In file included from src/avisynth_c/avisynth.c:21:0:
include/ffms.h:333:1: warning: type defaults to 'int' in declaration of 'FFMS_IndexErrorHandling' [enabled by default]
include/ffms.h:333:1: warning: '__stdcall__' attribute only applies to function types [-Wattributes]
include/ffms.h:333:35: error: expected ',' or ';' before 'FFMS_GetErrorHandling'

make: *** [src/avisynth_c/avisynth.o] Error 1
Full build log on pastebin (http://pastebin.com/huG4hNzM)


or the slightly more verbose output from gcc 4.8.0:
i686-w64-mingw32-gcc -Wall -march=pentium3 -mtune=pentium3 -std=gnu99 -s -fomit-frame-pointer -I/home/qyot27/win32_build/include -I. -Iinclude -D_FILE_OFFSET_BITS=64 -DFFMS_USE_FFMPEG_COMPAT -c -o src/avisynth_c/avisynth.o src/avisynth_c/avisynth.c
In file included from src/avisynth_c/avisynth.c:21:0:
include/ffms.h:333:10: warning: type defaults to 'int' in declaration of 'FFMS_IndexErrorHandling' [enabled by default]
FFMS_API(FFMS_IndexErrorHandling) FFMS_GetErrorHandling(FFMS_Index *Index);
^
include/ffms.h:78:77: note: in definition of macro 'FFMS_API'
# define FFMS_API(ret) FFMS_EXTERN_C __attribute__((visibility("default"))) ret FFMS_CC
^
In file included from src/avisynth_c/avisynth.c:21:0:
include/ffms.h:333:1: warning: '__stdcall__' attribute only applies to function types [-Wattributes]
FFMS_API(FFMS_IndexErrorHandling) FFMS_GetErrorHandling(FFMS_Index *Index);
^
include/ffms.h:333:35: error: expected ',' or ';' before 'FFMS_GetErrorHandling'
FFMS_API(FFMS_IndexErrorHandling) FFMS_GetErrorHandling(FFMS_Index *Index);
^
make: *** [src/avisynth_c/avisynth.o] Error 1
Full build log on pastebin (http://pastebin.com/pwNpSWry)

[sl1pkn07]

try gcc 4.7. on my linux build fine

[Plorkyeran]

r688 should fix compilation in C stuff.

[qyot27]

r688 should fix compilation in C stuff.
Confirmed. It compiles without issues again now.

try gcc 4.7. on my linux build fine
It wasn't tied to the version of GCC. And beyond that, I'm guessing that either:
A) That's the trunk, not the C branch. The trunk doesn't exhibit the problem.
B) If it was the C branch, you didn't do a HEAD catchup. An un-caught-up C branch is still back at like, r643.

[qyot27]

Due to request,

FFMS2 C-plugin r688

FFmpeg r41540 (git-2a622c2)
Both FFmpeg and FFMS2 optimized for Pentium III
MinGW-w64 GCC 4.8.0 20120610 (experimental)

EDIT: Updated, here (http://forum.doom9.org/showthread.php?p=1578387#post1578387)

[burfadel]

Due to request,

FFMS2 C-plugin r688 (http://www.mediafire.com/?96ynnprxdlgakq3)

FFmpeg r41540 (git-2a622c2)
Both FFmpeg and FFMS2 optimized for Pentium III
MinGW-w64 GCC 4.8.0 20120610 (experimental)

Wouldn't compiling for such an old processor be detrimental for newer processors?

What about SSEx etc instruction sets?

[sl1pkn07]

qyot27:

http://pastebin.com/pjj0XfHN

c-branch r.686 with gcc 4.7

gcc 4.8 is extreme experimental

[qyot27]

qyot27:

http://pastebin.com/pjj0XfHN

c-branch r.686 with gcc 4.7

gcc 4.8 is extreme experimental
I know that gcc 4.8 is experimental, and that pastebin isn't working so I can't see the result. But it doesn't change the point that something that 4.6.2 and 4.8.0 both error out on leaves little room for 4.7 to fix. Not that it matters now, since r688 resolves the problem.

It's also not being compiled natively for Linux, if that's what was happening. It's very specifically a MinGW-w64 build, because IMO there's very little point in compiling the C plugin on Linux. It has to have the AviSynth module enabled (as it's meant as the AviSynth plugin .dll, hence MinGW), since it's avisynth_c.o where the error is tripped.

Wouldn't compiling for such an old processor be detrimental for newer processors?

What about SSEx etc instruction sets?
I don't know, and without trying to sound callous, I'm not concerned about it. I optimize for the processor I actually have and use 99% of the time. I've never run a definitive test of whether - or how much - it affects the performance of newer processors.

[sl1pkn07]

oks. thanks :)

[LigH]

Probably as mentioned before for the ffdshow decoders: Most of their optimization is already done in Assembler. The little bit of C++ compiler optimization potential left to the sources is only related to the API.

[qyot27]

Slightly updated version since there were two more commits made while I was busy compiling everything the other day, and stupidly did not save the FFmpeg dev files.

FFMS2 C-plugin r690

FFmpeg r41586 (git-ddece75)
Still PIII and MinGW-w64 GCC 4.8.0



EDIT: New build here. (http://forum.doom9.org/showthread.php?p=1582286#post1582286)

[Abs62]

r694 don't compile.
..\src\core\haalivideo.cpp(157): error C2094: label 'Error' was undefined

[JEEB]

The following interlaced H.264 sample will not work correctly in ffms2 (tested 2.17, r644, r666):
http://www.mediafire.com/?ubxfydr4owr2rmo

Multi-threaded: insanity, decoder delivers empty frame after first(?) frame
1 thread: jumping back and forth

This sample seems to have mostly been fixed with the recent multithreading-fixing commits :)

After a brief test with Aegisub the only problem I was getting was that every frame came out twice, which could be sample-related (I would like to have someone with more knowledge on the matter comment on how broken this matroska remux is, as most things seem to fail to mux or deal with the H.264 stream included to begin with). Otherwise it seems like frame order was correct, and all frames seem to be output correctly. With Avisynth I did also try with threads=1 and that for some reason brought back the jerkiness in a bit different way.

A build is available for testing here (http://x264.fushizen.eu/builds/ffms2/ffms2-r695-libav-gitd77f4af.7z).
ffms2: r695, libav: git-d77f4af

libav configuration:
--prefix=/ffms --disable-network --disable-encoders --disable-muxers --disable-hwaccels --disable-indevs --disable-outdevs --extra-cflags='-U__STRICT_ANSI__ -D_SYSCRT' --disable-debug --enable-runtime-cpudetect

[Guest]

I would like to have someone with more knowledge on the matter comment on how broken this matroska remux is. It appears fine to me. Using DGDecodeNV it decodes perfectly and the GPU deinterlacing looks very nice as well. I reported this bug years ago to the lavc guys, but nobody ever cared about it.

[JEEB]

It appears fine to me. Using DGDecodeNV it decodes perfectly and the GPU deinterlacing looks very nice as well. I reported this bug years ago to the lavc guys, but nobody ever cared about it.
Alrighty, can you link to the old bug report or something that would have more details on it, or, if that's no longer available, can you give some more technical details that I can then push towards both projects? It seems like both sides are nowadays more active with regards to getting bug reports dealt with.

[Daemon404]

This sample seems to have mostly been fixed with the recent multithreading-fixing commits :)

After a brief test with Aegisub the only problem I was getting was that every frame came out twice, which could be sample-related (I would like to have someone with more knowledge on the matter comment on how broken this matroska remux is, as most things seem to fail to mux or deal with the H.264 stream included to begin with). Otherwise it seems like frame order was correct, and all frames seem to be output correctly. With Avisynth I did also try with threads=1 and that for some reason brought back the jerkiness in a bit different way.

A build is available for testing here (http://x264.fushizen.eu/builds/ffms2/ffms2-r695-libav-gitd77f4af.7z).

My own code using the ffms2 lib works fine, but this may be related:

pts: 80
pts: 100
pts: 0
pts: 20
pts: 0
pts: 0
pts: 20
pts: 20
pts: 242
pts: 274
pts: 306
[...]

[le_canz]

I all :) First, I'd like to thank all the devs for ffmpegsource, it's the only source method I use with avisynth, and I works great (well... not always :p)

I have some trouble opening MTS files from some digital camera with ffmpegsource. I don't know which camera unfortunately, as it wasn't mine... This file plays fine with VLC.

Video is H264 interlaced 1440x1080, and what ffmpegsource shows is quite messed up : frames are sometimes repeated twice, and fields appear not to be in the good order.

I tried with several ffmpegsource builds (683 from google code, 695 compiled by JEEB), same result. FFIndex() doesn't help, nor remuxing to mkv.

I use avisynth 2.6 with linux / wine 1.4

Here is a small sample if you want to try.
http://dl.free.fr/ghi9NtIxE

[LigH]

PAFF interlaced AVC videos recorded by AVCHD cameras are known problems for the libav decoder already for longer. Did you use the parameter 'threads=1'?

[le_canz]

PAFF interlaced AVC videos recorded by AVCHD cameras are known problems for the libav decoder already for longer.

I didn't know that. Thanks for the info.

Did you use the parameter 'threads=1'?

Yes, same result.

[leoenc]

Could someone please share a current build (r700)?

Thanks

[JEEB]

Random build time: clicky (http://x264.fushizen.eu/builds/ffms2/ffms2-r700-libav-gitc29c1a1.7z).
ffms2: r700, libav: git-c29c1a1

libav configuration:
--prefix=/ffms --disable-network --disable-encoders --disable-muxers --disable-hwaccels --disable-indevs --disable-outdevs --extra-cflags='-U__STRICT_ANSI__ -D_SYSCRT' --disable-debug --enable-runtime-cpudetect

[Wilbert]

Just curious. Is FFmpegSource be able to load MXF files? I see that it was added to libavformat at some point.

[JEEB]

Just curious. Is FFmpegSource be able to load MXF files? I see that it was added to libavformat at some point.
Tried with the Cars M2V sample (http://samples.mplayerhq.hu/MXF/Cars_TL4IO6_239_DEXX_MPEG_TDC_072006.m2v.mxf) available at mplayerhq, and it seems to load fine and linear decoding seems to be fine. Seeking backwards seemed a little awkward but I'm not sure if setting threads to one might help with that.

[wonkey_monkey]

Just out of curiosity, is there a simple explanation as to why ffmpegsource is frame-accurate with, for example, MKV, but not with VOB/MPG? Is it just a limitation of a library that's no-one's ever bothered to improve?

David

[Wilbert]

Tried with the Cars M2V sample available at mplayerhq, and it seems to load fine and linear decoding seems to be fine. Seeking backwards seemed a little awkward but I'm not sure if setting threads to one might help with that.
If I try to open it with 2.17 (ffms-2.17.7z) i get the following error:

Avisynth open failure:
FFVideoSource: Can't open blabla ...

script:

FFVideoSource("F:\Cars_TL4IO6_239_DEXX_MPEG_TDC_072006.m2v.mxf")

[Plorkyeran]

I made several MXF-related fixes recently to handle its lack of timestamps. r700 works correctly on all of the files I tested it on (which was not very many).

Just out of curiosity, is there a simple explanation as to why ffmpegsource is frame-accurate with, for example, MKV, but not with VOB/MPG? Is it just a limitation of a library that's no-one's ever bothered to improve?
DGIndex mostly works fine, so things it can open are lower priority than formats which don't have any reasonable alternatives. AFAIK MPEG-2 in VOB should work fine as long as RFF handling is enabled other than that split VOBs aren't supported.

[wonkey_monkey]

AFAIK MPEG-2 in VOB should work fine as long as RFF handling is enabled other than that split VOBs aren't supported.

Just today I was unable to get within 3 frames accurate on MPEG-2 in VOB (PAL, so no RFF) :( DGIndex is great, of course, but I'd love an alternative that didn't require demuxing audio.

David

[Plorkyeran]

If you can upload a sample with issues I'll take a look at it when I get a chance.

[qyot27]

FFMS2 C-plugin r700

FFmpeg version r42437 git-9b3f9f4
Both FFmpeg and FFMS2 built with GCC 4.8.0 20120610 (experimental)
Both optimized for Pentium III

Contains some really bleeding edge support for decoding 12-bit and 14-bit 4:2:0 H.264, thanks to recent commits to FFmpeg (http://git.videolan.org/?p=ffmpeg.git&a=search&h=HEAD&st=commit&s=14+bit). It seems to be most stable with 12-bit, although some of the problems I've been having getting the samples prepared could be due either to swscale issues or the tricky nature of trying to get the config files for JM (18.3, if that matters) correctly set. I had some 14-bit tests that seemed fine, but others went wonky and I can't determine which parts threw it off. 4:2:2 and 4:4:4 in either of the new bit depths result in mostly green output, which may or may not be due to swscale (my money is on swscale, but I can't be completely sure).

EDIT: New build here (http://forum.doom9.org/showthread.php?p=1588762#post1588762)

[burfadel]

FFMS2 C-plugin r700 (http://www.mediafire.com/?dmjyn5r74tnj7zl)

FFmpeg version r42437 git-9b3f9f4
Both FFmpeg and FFMS2 built with GCC 4.8.0 20120610 (experimental)
Both optimized for Pentium III

Contains some really bleeding edge support for decoding 12-bit and 14-bit 4:2:0 H.264, thanks to recent commits to FFmpeg (http://git.videolan.org/?p=ffmpeg.git&a=search&h=HEAD&st=commit&s=14+bit). It seems to be most stable with 12-bit, although some of the problems I've been having getting the samples prepared could be due either to swscale issues or the tricky nature of trying to get the config files for JM (18.3, if that matters) correctly set. I had some 14-bit tests that seemed fine, but others went wonky and I can't determine which parts threw it off. 4:2:2 and 4:4:4 in either of the new bit depths result in mostly green output, which may or may not be due to swscale (my money is on swscale, but I can't be completely sure).

This build appears to fail, at least opening AVI files. Jeeb's r700 build works fine.

I get the same error as Wilbert in post http://forum.doom9.org/showthread.php?p=1580834#post1580834

[qyot27]

I just tested an XviD AVI and an ffvhuff AVI. Both indexed without issue and the scripts played back fine.

Without more information, it's not possible to tell whether it's a compilation problem, a libavformat/codec problem, a script problem, or something in FFMS2 itself.

[qyot27]

It seems as though something has changed which makes MP4 files no longer work. All the MP4 files I tested with it fail, including music videos purchased from iTunes and videos that have been remuxed into MP4 with MP4Box. Files muxed by L-SMASH seem to be fine.

It's probably because of a change in libavformat, since a build of FFMS2 r700 from June 28th works, but ones from July 4th and 10th don't, responding with:
Indexing error: Invalid initial pts, dts, and duration
MOV and FLV files are unaffected, and FFmpeg itself deals with these same MP4s without an issue (as did the build of r700 from June 28th), so I'm guessing that what happened is that there was an API change and that's what's messing with FFMS2.


Also, I don't know what's going on (and I doubt it's related to the MP4 issue), but FFMS2 can't link to FFmpeg on any of my cross-compile environments through MinGW-w64, as it's complaining about libraries that FFmpeg shouldn't have linked to in the first place given this is a MinGW build:
checking whether i686-w64-mingw32-gcc works... yes
checking for -std=gnu99... yes
checking whether defined(_WIN32) is true... yes
checking for CoUninitialize(); in objbase.h... yes
checking whether LIBAVCODEC_VERSION_MICRO >= 100 is true... yes
checking for avcodec_decode_video2( 0, 0, 0, 0 ); in libavformat/avformat.h... no
Failed commandline was:
--------------------------------------------------
i686-w64-mingw32-gcc conftest.c -Wall -march=pentium3 -mtune=pentium3 -std=gnu99 -lz -lbz2 -lpthreadGC2 \
-lutvideo -lole32 -I/home/qyot27/win32_build/include -I/usr/local/include -L/home/qyot27/win32_build/lib \
-lswscale -lavformat -lavcodec -lavutil -lavifil32 -pthread -L/usr/local/lib -lavformat -lavcodec -ldl -lva \
-ljack -lasound -lSDL -lxvidcore -lutvideo -lstdc++ -lbz2 -lz -lrt -lswscale -lavutil -lm
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -ldl
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -lva
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -ljack
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -lasound
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -lSDL
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -lrt
collect2: error: ld returned 1 exit status
--------------------------------------------------
DIED: unable to link against FFmpeg
It's also trying to test FFMS2 against xvidcore and I didn't even have that in the FFmpeg configure, which was this:
configuration: --prefix=/home/qyot27/win32_build --cross-prefix=i686-w64-mingw32- --enable-gpl --enable-version3 \
--disable-w32threads --enable-memalign-hack --disable-decoder=utvideo --enable-libutvideo --disable-encoders \
--disable-muxers --disable-debug --disable-network --disable-hwaccels --disable-indevs --disable-outdevs \
--cpu=pentium3 --extra-cflags='-march=pentium3 -mtune=pentium3 -DPTW32_STATIC_LIB' --target-os=mingw32 --arch=x86
The FFmpeg binary seems unaffected, because it'll display its normal output just fine under actual Windows (I can't do further testing with it due to it being reduced like it is).

That particular issue seems to have cropped up in just the last week or so, since the July 10th build was cross-compiled, but my attempts over the last day or two have resulted in the error above.

[Kovensky]

(...) -L/home/qyot27/win32_build/lib \
-lswscale -lavformat -lavcodec -lavutil -lavifil32 -pthread -L/usr/local/lib -lavformat -lavcodec -ldl -lva \
-ljack -lasound -lSDL -lxvidcore -lutvideo -lstdc++ -lbz2 -lz -lrt -lswscale -lavutil -lm
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -ldl
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -lva
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -ljack
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -lasound
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -lSDL
/usr/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld: cannot find -lrt
collect2: error: ld returned 1 exit status

It's actually trying to link with two different "ffmpegs" at the same time, including your system one. Make sure pkg-config is properly configured; use PKG_CONFIG_LIBDIR to make sure it doesn't try to look in any of the default paths.

[qyot27]

It's actually trying to link with two different "ffmpegs" at the same time, including your system one. Make sure pkg-config is properly configured; use PKG_CONFIG_LIBDIR to make sure it doesn't try to look in any of the default paths.
I figured that it was trying to do something along those lines, and it also explains why it only ever seemed to happen with the the C-plugin - I've always used PKG_CONFIG_PATH on the trunk and x264, whereas with the C-plugin I don't/didn't because of it not working back when I first started building it (http://doom10.org/index.php?topic=25.msg4244#msg4244) (although re-reading it now it probably would have worked if I'd copied/symlinked pkg-config to include the cross-prefix; I can't remember if I'd gotten into the habit of doing that at the time), meaning that I was still using FFMPEG_LIBS and FFMPEG_CFLAGS to tell it where to look and never bothered to notice when the situation changed. So I just never thought of it being a pkg-config issue. Since it does work now, I'll just switch over to that.

[hello_hello]

I'm not overly knowledgeable when it comes to video indexing/encoding, but I'm having an ffms2 indexing problem and thought I'd ask about it here. I'm using version 2.17 and I've tried r683.

I have some MKVs which contain constant frame rate DivX video and I'm fairly sure the video contains duplicate frames. If I remux the MKVs as AVIs I can open them using AVISource and the duplicate frames seem be included when encoding. If I use ffms2 to index them however, the resulting video contains fewer frames than the original. The total video duration is basically correct, but the frame rate is reduced to achieve it. Adding "fpsnum=25, fpsden=1" to the script (25fps source) fixes the frame count and I can convert without audio sync issues.

If the issue is duplicate frames, is this expected behavior or should ffms2 handle them "correctly"?
Thanks.

[kolak]

If I try to open it with 2.17 (ffms-2.17.7z) i get the following error:

Avisynth open failure:
FFVideoSource: Can't open blabla ...

script:

FFVideoSource("F:\Cars_TL4IO6_239_DEXX_MPEG_TDC_072006.m2v.mxf")


Use different build based on ffmbc for mxf files- it should work much better and it also has 10bit support (eg you can read DNxHD MXF files at 10bit):

http://forum.doom9.org/showthread.php?p=1583307#post1583307

[Selur]

calling:
LoadPlugin("G:\Hybrid\avisynthPlugins\ffms2.dll")
FFVideoSource("H:\Output\input.m2ts",cachefile="H:\Temp\input_m2ts_41.ffindex",threads=1)
with any of JEEBs builds (http://x264.fushizen.eu/builds/ffms2/) I get distorted pictures (looks like decoding is broken), works fine with ffms2-r683 from http://code.google.com/p/ffmpegsource/downloads/list
input.m2ts contains avc video

Cu Selur

[mp3dom]

Use different build based on ffmbc for mxf files- it should work much better and it also has 10bit support (eg you can read DNxHD MXF files at 10bit):

http://forum.doom9.org/showthread.php?p=1583307#post1583307

I'm getting slighty different results on a ProResHQ file using the r700 build based on ffmpeg compared to the build based on ffmbc. The 10bit data are different (at least, watching the stacked clip on VirtualDub).
The ffms2 based on ffmbc outputs the same image of ffmbc->v210->readv210
The ffms2 based on ffmpeg outputs the same image of ffmpeg->v210->readv210

Now the main question is: which is the right decode?

[kolak]

What is the difference?

I tried decoding ProRes to v210 in different ways and always had same (or 99.9%) results. Seen some tiny differences in waveform, but it's impossible to so it by eye.
I have no clue which is correct, but as far as I can tell difference is marginal.
Will try again with new Resolve 9.

[jmac698]

I'm wondering if this is the proper way to force point sized 4:1:1 export with ffms2 (original build) and Avisynth 2.6a3:

A = FFAudioSource(dir+fn)
V = FFVideoSource(dir+fn, resizer="POINT")#attempt to avoid touching chroma in 4:1:1 -> 4:2:2
AudioDub(V, A)
ConvertToYV411(chromaresample="point")#convert from YUY2->YV411

The manual states that a resizer is used if the destination doesn't support chroma subsampling, but it's not stated how the conversion is done if the subsampling resolution differs. If my theory is correct, I am recreating true 4:1:1 via 4:2:2.

[TheFluff]

The proper thing to do would be to use the C-plugin, since it has support for the Avisynth 2.6 colorspaces and thus supports outputting 4:1:1.

[jmac698]

*headslap* great! Well, I didn't know what the difference was, I did notice it in the download list. Thanks.

[mp3dom]

What is the difference?

It's at pixel level. It concern only some pixels and it resemble something similar to a 'luma' difference. Nothing correlated to visual artefacts. Watching the clip stacked, you can see better where are the difference. They're small but I've seen some bigger 'portions' of difference. Anyway I can live with it, but since the decoded image should be the same from both ffmbc and ffmpeg, I'm wondering which provide the right decode.

[kolak]

Yes- I see the same problem. Tried Resolve, ffmbc, ffmpeg and all look bit different- none of the pairs looks exactly the same. I think it's down to processing precision or whatever :)

[jmac698]

Ok,
I'm having a bunch of problems.
FFMS2 is crashing.

dir="C:\project004\home video project\"
fn="testclip.mov"
plugindir="M:\Program Files\AviSynth 2.5\plugins\temp\"
pluginfn="ffms2.dll"
Load_Stdcall_Plugin(plugindir+pluginfn)
A = FFAudioSource(dir+fn)
V = FFVideoSource(dir+fn)
AudioDub(V, A)


File "pyavs.pyo", line 328, in _GetFrame
File "avisynth.pyo", line 277, in GetFrame
WindowsError: exception: access violation reading 0x00000048

When I seek back and forth at the start, it eventually crashes.
Avisynth 2.6a3
ffms-2.17-cplugin.7z
No other plugins loaded
And the source clip is here http://www.digitalfaq.com/forum/video-workflows/4413-how-quicktime-files-2.html#post22197
NTSC DV in mov
I couldn't find any more recent versions of the C version to try.

[Reel.Deel]

Hi jmac698, here is an updated FFMS2 C plugin (http://forum.doom9.org/showthread.php?p=1582286#post1582286).

BTW, since I'm not a member of DigitalFAQ I can't download your sample.

[qyot27]

EDIT 2012-08-17: A much better solution was committed to SVN. Disregard this post.

With current revisions of both FFmpeg and libav from git, compilation of r702 (both trunk and C-plugin) fails due to some CodecID changes.

The following patch resolves the issue by moving most of the CodecID instances to AVCodecID:
[doesn't exist anymore]

I don't know if I changed it in places that may have been unnecessary, but it doesn't seem to have caused any other problems (but I also don't compile FFMS2 with Visual Studio).

[qyot27]

FFMS2 r705 trunk:
CXX src/core/matroskavideo.lo
CXX src/core/numthreads.lo
CC src/core/stdiostream.lo
CXX src/core/utils.lo
src/core/utils.cpp: In function 'void FlushBuffers(AVCodecContext*)':
src/core/utils.cpp:569:34: error: invalid conversion from 'const AVCodec*' to 'AVCodec*' [-fpermissive]
AVCodec *codec = CodecContext->codec;
^
make: *** [src/core/utils.lo] Error 1
r705 C-plugin:
CXX src/core/matroskaaudio.o
CXX src/core/matroskaindexer.o
CXX src/core/matroskavideo.o
CXX src/core/utils.o
src/core/utils.cpp: In function 'void FlushBuffers(AVCodecContext*)':
src/core/utils.cpp:569:34: error: invalid conversion from 'const AVCodec*' to 'AVCodec*' [-fpermissive]
AVCodec *codec = CodecContext->codec;
^
make: *** [src/core/utils.o] Error 1

I got around it by tacking 'const' onto the beginning of line 569 in src/core/utils.cpp like the error message says. Dunno if that's right, though.

[JEEB]

Yes, to get ffms2 to build with current libav/ffmpeg you have to do something a la this (http://pastebin.com/9uFT7ZfH).

You get somewhat less errors as you are not building it on windows/MSVC, and the weird-looking include addition comes from the fact that FFMIN and friends are being used there, yet it was not included in order to use them.

[qyot27]

Something that I've been wondering lately, partially about testing the performance of certain decoding methods:

Is it possible (or rather, how easy/difficult would it be) to add a decoder= option to FFMS2 to cover those cases where multiple decoders for the same format are present in a build of libavcodec? Something similar is there with the demuxer option, and would provide some flexibility to test if there happens to be a problem with one of the decoders.

Currently, to test this with external decoders you have to explicitly disable the native one and enable the external, and consequently make multiple builds of both FFmpeg/libav and FFMS2 to cover the difference.

[Myrsloik]

Something that I've been wondering lately, partially about testing the performance of certain decoding methods:

Is it possible (or rather, how easy/difficult would it be) to add a decoder= option to FFMS2 to cover those cases where multiple decoders for the same format are present in a build of libavcodec? Something similar is there with the demuxer option, and would provide some flexibility to test if there happens to be a problem with one of the decoders.

Currently, to test this with external decoders you have to explicitly disable the native one and enable the external, and consequently make multiple builds of both FFmpeg/libav and FFMS2 to cover the difference.

I'm against this. Just use an original ffmpeg/libav build and see if it works outside avisynth. Then file a bug report with the appropriate project.

[abyss616]

How can I avoid FFMS2 "going insane" and returning empty frames at tiny little video stream errors another VfW codec or DirectShow decoder survives?

By not using FFMS2, not multithreading it also helps sometimes.

So is it still the recommendation if you have h.264 interlaced video (VHS>.ts captured using Hauppauge HD-PVR) to use something like DSS2 instead of FFVideoSource? I have a bunch of tapes I want to digitize and would like to use the best possible source.

[Gser]

So is it still the recommendation if you have h.264 interlaced video (VHS>.ts captured using Hauppauge HD-PVR) to use something like DSS2 instead of FFVideoSource? I have a bunch of tapes I want to digitize and would like to use the best possible source.

FFVideoSource doesn't really support .ts or .m2ts, so try muxing the file into a mkv. Some broadcasts work like this and some need to use DSS2.

[qyot27]

The threading issue that was present back then with empty frames was resolved in the 690s revision range. Whether it also covers interlaced is another story, but r704 does seem to have some pertinence to interlaced H.264.

C-plugin r706 (http://www.mediafire.com/?81knav8anulht9b)

[burfadel]

The threading issue that was present back then with empty frames was resolved in the 690s revision range. Whether it also covers interlaced is another story, but r704 does seem to have some pertinence to interlaced H.264.

C-plugin r706 (http://www.mediafire.com/?81knav8anulht9b)

This build doesn't work for me, and neither does ffdshow build 4484 or 4486. I'm guessing it has something to do with LibAV... If it's instruction set related, I'm using a Core 2 Q9400 (has SSE 4.1 not 4.2), SSE4.1 was added with the E8xxx, Q8xxx, Q9xxx etc processors.

[abyss616]

FFVideoSource doesn't really support .ts or .m2ts, so try muxing the file into a mkv. Some broadcasts work like this and some need to use DSS2.
Yeah, I go the demux>mkv route but I still experience routine crashes with VirtualDub and MeGUI when the source is VHS.

I also get the insanity error when working with 720p HD .ts material also, but it doesn't seem to affect the encoding/generate errors. Should I use 'threads=1' or leave it alone?

[Plorkyeran]

The threading issue that was present back then with empty frames was resolved in the 690s revision range. Whether it also covers interlaced is another story, but r704 does seem to have some pertinence to interlaced H.264.

With r704 interlaced H264 is no longer completely broken, but I still would not particularly recommend using FFMS2 for it without spending some time verifying that it's giving sane results.

[qyot27]

With r704 interlaced H264 is no longer completely broken, but I still would not particularly recommend using FFMS2 for it without spending some time verifying that it's giving sane results.
I could gather as much, considering the wording of the commit message.


This build doesn't work for me, and neither does ffdshow build 4484 or 4486. I'm guessing it has something to do with LibAV... If it's instruction set related, I'm using a Core 2 Q9400 (has SSE 4.1 not 4.2), SSE4.1 was added with the E8xxx, Q8xxx, Q9xxx etc processors.
Without knowing the exact error, there's not much to go on.

As it's a C-plugin, it requires LoadCPlugin to make sure it loads, since it will not autoload. I've taken care of this in the .avsi, but in my own packaging I enforce an absolute path to C:\Program Files\AviSynth 2.5\plugins\ffms2.dll. If this is used on a 64-bit version of Windows, it will break since it expects 32-bit AviSynth to be installed to Program Files (x86). If that's what's going on here, just add the ' (x86)' part to the LoadCPlugin call in FFMS2.avsi.

Making it completely relative (as in, just the name of the .dll) also resolves the issue, but has the potential to break applications unexpectedly. It shouldn't, and doesn't in most applications I've tried, but I have seen it happen. Read: mencoder completely flips out when you do this and refuses to load anything through AviSynth (which is yet one more reason to avoid using mencoder if you can keep from it). But I figure if one app can freak out like that, chances are there are others that exist out there.

IMO, the most reliable solution uses GetSystemEnv to load the current directory as a variable and this abstracts the path enough for mencoder to work as well as the others. The downside to this approach is that GetSystemEnv is an external plugin and there's no guaranteeing that the end-user has it in AviSynth's plugins library.

[burfadel]

Without knowing the exact error, there's not much to go on.

As it's a C-plugin, it requires LoadCPlugin to make sure it loads, since it will not autoload. I've taken care of this in the .avsi, but in my own packaging I enforce an absolute path to C:\Program Files\AviSynth 2.5\plugins\ffms2.dll. If this is used on a 64-bit version of Windows, it will break since it expects 32-bit AviSynth to be installed to Program Files (x86). If that's what's going on here, just add the ' (x86)' part to the LoadCPlugin call in FFMS2.avsi.

Making it completely relative (as in, just the name of the .dll) also resolves the issue, but has the potential to break applications unexpectedly. It shouldn't, and doesn't in most applications I've tried, but I have seen it happen. Read: mencoder completely flips out when you do this and refuses to load anything through AviSynth (which is yet one more reason to avoid using mencoder if you can keep from it). But I figure if one app can freak out like that, chances are there are others that exist out there.

IMO, the most reliable solution uses GetSystemEnv to load the current directory as a variable and this abstracts the path enough for mencoder to work as well as the others. The downside to this approach is that GetSystemEnv is an external plugin and there's no guaranteeing that the end-user has it in AviSynth's plugins library.

I tried it either way, both seemed to work with the same error, (AVIGetStreamfail or something), but without that line, it says there isn't any filter named FFvideosource, so it is definitely loading. I believe on x64 systems, because it is a 32-bit program it automatically redirects the call to C:\Program Files (x86).

In any case, neither this, nor the latest FFDshow (4484, 4486) work for me, so I'm assuming it's LibAV related.

[TheRyuu]

ffms2-r706.7z (https://ffmpegsource.googlecode.com/files/ffms2-r706.7z)

Because of various herping and derping libav can now be built with msvc (experimental and not completely finished).

Appears to be a slight code size reduction as well as a result of using msvc (6.3MB -> 4.6MB for ffms2.dll).

Built with libav ~20120825 w/msvc stuffs.
No postproc.
No opencore.
32-bit only.

[burfadel]

ffms2-r706.7z (https://ffmpegsource.googlecode.com/files/ffms2-r706.7z)

Because of various herping and derping libav can now be built with msvc (experimental and not completely finished).

Appears to be a slight code size reduction as well as a result of using msvc (6.3MB -> 4.6MB for ffms2.dll).

Built with libav ~20120825 w/msvc stuffs.
No postproc.
No opencore.
32-bit only.

Thanks! This build works fine :)

Don't know what the differences is between it and the earlier posted r706.

What version of MSVC did you use, out of curiosity?

[TheRyuu]

Thanks! This build works fine :)

Don't know what the differences is between it and the earlier posted r706.

What version of MSVC did you use, out of curiosity?

Visual Studio 2010 (VC10). It also requires other tools such as a compile wrapper and a c99 -> c89 converter (clang based). Still very much a work in progress but it makes building ffms2 a lot easier.

Building a 64-bit version of libav in msvc is still a work in progress I believe but it should be in the works once 32-bit support is finished and working the way they want (there's still a bit of inline asm I think that needs to get ported to yasm, among other things I'm probably not aware of).

[burfadel]

Ah ok :) Once they get MSVC2010 completed, MSVC2012 will be officially available. It's finalised and available now, just not 'officially', same as Windows 8.

I'm guessing that MSVC2012 would be compatible too?

[TheRyuu]

Ah ok :) Once they get MSVC2010 completed, MSVC2012 will be officially available. It's finalised and available now, just not 'officially', same as Windows 8.

I'm guessing that MSVC2012 would be compatible too?

I don't see why not.

I'm not sure if they're specifically targeting 2010, I think at this point the idea is to just make it work and move on from there.

Apparently the CABAC inline asm isn't going to be ported since it's not feasible. Fortunately a msvc compiled binary is as fast as a gcc one (which has that inline asm) although low bitrate files may be affected. There isn't a lot of execution time spent there anyway so it's not a big deal.

[qyot27]

Previously I mentioned that some MP4 files suddenly break with builds of FFMS2 (trunk and C-plugin) using newer versions of FFmpeg/libav (specifically after the beginning of July). I've traced the issue back to this commit:

http://git.videolan.org/?p=ffmpeg.git;a=commit;h=a02b8c695c0816f4dd42ae5816463585163fb4c6
http://git.libav.org/?p=libav.git;a=commit;h=a02b8c695c0816f4dd42ae5816463585163fb4c6

Which has to do with reading iTunes cover art.

The commit immediately prior works, this one and all the ones after it cause affected files to fail indexing. The failure only occurs in FFMS2, as ffmpeg.exe/avconv.exe can deal with the files correctly. I also confirmed that that single commit is the only problem, as reversing those changes against HEAD results in FFMS2 being able to read such files again.

[TheRyuu]

Previously I mentioned that some MP4 files suddenly break with builds of FFMS2 (trunk and C-plugin) using newer versions of FFmpeg/libav (specifically after the beginning of July). I've traced the issue back to this commit:

http://git.videolan.org/?p=ffmpeg.git;a=commit;h=a02b8c695c0816f4dd42ae5816463585163fb4c6
http://git.libav.org/?p=libav.git;a=commit;h=a02b8c695c0816f4dd42ae5816463585163fb4c6

Which has to do with reading iTunes cover art.

The commit immediately prior works, this one and all the ones after it cause affected files to fail indexing. The failure only occurs in FFMS2, as ffmpeg.exe/avconv.exe can deal with the files correctly. I also confirmed that that single commit is the only problem, as reversing those changes against HEAD results in FFMS2 being able to read such files again.

Did you post a sample? I can't find anything in previous posts mentioning it but I may not have gone back far enough.

Err I found the post saying basically anything muxed with mp4box will cause it so going to go try that now, not sure how I missed that looking back the first time.

[TheRyuu]

Previously I mentioned that some MP4 files suddenly break with builds of FFMS2 (trunk and C-plugin) using newer versions of FFmpeg/libav (specifically after the beginning of July). I've traced the issue back to this commit:

http://git.videolan.org/?p=ffmpeg.git;a=commit;h=a02b8c695c0816f4dd42ae5816463585163fb4c6
http://git.libav.org/?p=libav.git;a=commit;h=a02b8c695c0816f4dd42ae5816463585163fb4c6

Which has to do with reading iTunes cover art.

The commit immediately prior works, this one and all the ones after it cause affected files to fail indexing. The failure only occurs in FFMS2, as ffmpeg.exe/avconv.exe can deal with the files correctly. I also confirmed that that single commit is the only problem, as reversing those changes against HEAD results in FFMS2 being able to read such files again.

I can't reproduce it with my latest build (https://ffmpegsource.googlecode.com/files/ffms2-r706.7z).

I downloaded a trailer from itunes, remuxed it into mp4 with mp4box (via yamb) and it worked. I'm not sure if I'm doing something wrong to attempt to reproduce it?

[Yellow_]

Hi I'm using ffmpegsource2 to decompress h264 is there anyway to tell via ffmpeg whether the source has been encoded with full range chroma, ie App0() JFIF rather than 16 - 240

Mediainfo just gives me BT709 prims and transfer with BT601 luma coeffs matrix.

[qyot27]

I can't reproduce it with my latest build (https://ffmpegsource.googlecode.com/files/ffms2-r706.7z).

I downloaded a trailer from itunes, remuxed it into mp4 with mp4box (via yamb) and it worked. I'm not sure if I'm doing something wrong to attempt to reproduce it?
I'm seeing the issue when using your build too.

The files I saw exhibiting it had cover art (although I only fully realized this after seeing which commit seemed to be the source of the problem). For instance, Music Video or TV Episode purchases, but even self-created stuff with covers can manage to set it off. It doesn't actually only affect mp4box, as I also saw it happening to other audio-only files I'd muxed with mp4creator or that had been muxed by Quicktime (I would suppose, as I'd think that would be the obvious one used for iTunes purchases), but the only detail that seems to matter is the presence of an embedded image.

Re-ran some tests,
mp4creator v1.6.1d
mp4box 0.4.6-DEV (internal rev. 7)
L-SMASH rev.669 / git-3280f261

Quicktime (I guess; the original purchase) w/ cover: fail
mp4creator w/ cover: fail
mp4box w/ cover: fail
L-SMASH w/ cover: fail

mp4creator w/o cover: success
mp4box w/o cover: success
L-SMASH w/o cover: success

In all cases of failure except Quicktime, the cover was injected with Mp3tag 2.52. I can't seem to find options to insert covers in any of the three non-Quicktime muxers (and I can't verify anything with Quicktime itself because I think only Pro can do this stuff outside of iTunes' audio encoding ability), so I had to resort to an external app to do it. Files with metadata set this way used to work just fine, though, and since the original files exhibit the issue too I think it just has to do with the covers being present, rather than a problem with the way they've been inserted.

A couple of samples (normally ffmsindex fails in the < 10% range, but these are so small that it reports 100% but still fails and therefore still doesn't write the .ffindex files)
http://www.mediafire.com/?k7ti7s4izz47a8h

[Pat357]

ffms2-r706.7z (https://ffmpegsource.googlecode.com/files/ffms2-r706.7z)

Because of various herping and derping libav can now be built with msvc
Any chance for the C build with full color-spaces support ?

[the_weirdo]

Any chance for the C build with full color-spaces support ?

You can try qyot27's build here:
http://forum.doom9.org/showthread.php?p=1588762#post1588762

[TheRyuu]

ffms2-r712.7z (https://ffmpegsource.googlecode.com/files/ffms2-r712.7z)

Contains vapoursynth support.

I reproduced that cover art in mp4 bug, it's trying to index the cover art but fails. On a side note it's nice to be able to not look at libav and see a black box when debugging in msvc.

[active1]

ffms2-r712.7z (https://ffmpegsource.googlecode.com/files/ffms2-r712.7z)

Contains vapoursynth support.

I reproduced that cover art in mp4 bug, it's trying to index the cover art but fails. On a side note it's nice to be able to not look at libav and see a black box when debugging in msvc.

isn't ffms2 already support vapoursynth?

[qyot27]

I reproduced that cover art in mp4 bug, it's trying to index the cover art but fails.
Basically. From how I understood the commit message it makes the cover art appear as some sort of video track, and somehow it's trying to taking precedence over the h264 track. Although it's not what I'd consider a typical video track since the respective projects' main apps can both see the presence of cover art in the file and still deal with the actual video tracks properly.

MPlayer2 also displays similarly weird behavior when that commit is there, as it displays the cover art as being a video track with its own vid #, and displays it when a file with it is played, but trying to override the autoselection and force playing the h264 vid # doesn't do anything and still displays the cover art image. Like with FFMS2, reverting that commit allows MPlayer2 to handle the video track again.

In the diff, it does explicitly reference that the cover art is being stored by the 'covr' atom, so my best guess to solve it would be to somehow make the parser and/or indexer aware of that atom if it's present in the file and either completely ignore it or skip it.

[burfadel]

ffms2-r712.7z (https://ffmpegsource.googlecode.com/files/ffms2-r712.7z)

Contains vapoursynth support.

I reproduced that cover art in mp4 bug, it's trying to index the cover art but fails. On a side note it's nice to be able to not look at libav and see a black box when debugging in msvc.

Works great (in general I mean), thanks!

[TheFluff]

isn't ffms2 already support vapoursynth?

It's a native vsynth plugin now, which means it can output all kinds of exotic colorspaces that Avisynth doesn't support, for example. The previous version was loaded via vsynth's Avisynth emulation layer.

[TurboPascal7]

vapoursynth support doesn't seem to be working under win7 x64, win server 2008 x64 and win8 x64. Works fine under win xp x86.

Python 3.2.3 (default, Apr 11 2012, 07:15:24) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from vapoursynth import Core
>>> c = Core()
>>> c.std.LoadPlugin(path=r'D:\ffms2.dll')

Unhandled exception at 0x7797E3FB (ntdll.dll) in python.exe: 0xC0000005: Access violation writing location 0x00000000.

Call stack:
> ntdll.dll!7797e3fb()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
ntdll.dll!7797e003()
kernel32.dll!76b114dd()
vscore.dll!53895abd()
vscore.dll!538374db()
vscore.dll!5382ff73()
vscore.dll!5382fe78()
vscore.dll!5382ba70()
vscore.dll!53895a58()
msvcr100.dll!53320269()
vapoursynth.pyd!02cdda6b()
vapoursynth.pyd!02cdeccb()
python32.dll!1e0170a7()
python32.dll!1e012656()
python32.dll!1e012d15()
python32.dll!1e011e27()
python32.dll!1e0333be()
python32.dll!1e02f5f3()
python32.dll!1e004e1b()
python32.dll!1e038fc7()
python32.dll!1e0df062()
python32.dll!1e0df804()
python32.dll!1e065352()
python32.dll!1e03b07a()
python32.dll!1e03c5cb()
python.exe!1d00103c()
msvcr90.dll!70882201()
python.exe!1d001160()
kernel32.dll!76b133ca()
ntdll.dll!77989ed2()
ntdll.dll!77989ea5()

[active1]

sorry, it was my fault

[06_taro]

Works for me.
win7 x64

[active1]

It's a native vsynth plugin now, which means it can output all kinds of exotic colorspaces that Avisynth doesn't support, for example. The previous version was loaded via vsynth's Avisynth emulation layer.

nice, but can you tell me what is the colorspaces that avisynth not support it? (and vapoursynth support it now)

[TheFluff]

nice, but can you tell me what is the colorspaces that avisynth not support it? (and vapoursynth support it now)

mostly it's the high bitdepth stuff that's interesting, but planar RGB may also be relevant to some people.

[TheRyuu]

ffms2-r712-2.7z (https://ffmpegsource.googlecode.com/files/ffms2-r712-2.7z)

ffms2 is the same as the previous build, libav a few revisions newer.

Now includes (untested) 64-bit.

[DiZzA]

Well I have the following problem. I have several recorded .ts files. Most of them have 2 audio tracks with the first being the descriptive one. So I use FFAudioSource("video.ts", track = 2, adjustdelay = -1) to select the right one and then soundout to extract the ac3. But I always get "Audio format change detected. Channels 6->2.". Is there something I am doing wrong? Thank you.

[LigH]

Recorded DVB streams may indeed contain changing audio formats (between the movie and advertizing breaks).

If you have MPEG2 video (usually in SD resolutions), you can use the Java application "ProjectX" to pre-cut the material at these format changes, to get continuous 6-channel audio in result. Unfortunately, it can't handle DVB-S2 HD streams with AVC video.

[Selur]

ProjectX can even patch these files so they only report 6 channels,....

[DiZzA]

So there is no way to do it without cutting the ts file? Or maybe an alternative to ffmpegsource?

[LigH]

Hardly any audio decoder plugin will not get confused by changing channel numbers. And DirectShowSource will always be the least to trust, except you know your filters.

[Selur]

ProjectX should be able to do this without cutting when "Presettings -> Presettings -> Audio -> replace all non-3/2 AC3 by 3/2lfe silence" is enabled, other than that I don't know of any standalone tool that can do the patching,...
For ffmpegSource it's a known issue, see: https://code.google.com/p/ffmpegsource/issues/detail?id=22 (Priority: Low, so don't hold your breath)

[DiZzA]

thank you for all your suggestions!

[pandv2]

I found also problems opening a mp4 file. It's captured and compressed from hdmi with a apple tv device.

It works ok with version r700, but not with r706, r712 or r712-2.

If I remux the file with mkvmerge, the obtained mkv file works ok with all versions.

[sneaker_ger]

vapoursynth support doesn't seem to be working under win7 x64, win server 2008 x64 and win8 x64. Works fine under win xp x86.[/CODE]

Crashes here, too, on r5. Tested the 712 and 712-2 binary from the google page.
Windows 7 x64

[sneaker_ger]

The crash on LoadPlugin seems to be gone with r6, but can someone explain to me how to actually use it?
I tried things like:
ret = core.ffms2.FFVideoSource(source='input.mkv') and
ret = core.ffms2.VSVideoSource(source='input.mkv')
but those function names are unknown.

[Myrsloik]

The crash on LoadPlugin seems to be gone with r6, but can someone explain to me how to actually use it?
I tried things like:
ret = core.ffms2.FFVideoSource(source='input.mkv') and
ret = core.ffms2.VSVideoSource(source='input.mkv')
but those function names are unknown.

The functions have been renamed to simply Index and Source. Hint: print(core.list_functions()) when you want to see all the known functions

[sneaker_ger]

Thx, it appears to be working. I did do "print(core.list_functions())", but totally missed the part above the std list.

[TheRyuu]

ffms2-r722.7z (https://ffmpegsource.googlecode.com/files/ffms2-r722.7z)

As always, includes both 32/64-bit binaries as well as the return of opencore-amr support (can be built with msvc, so it all fits in easy).

Some notable changes since the last build:

Removal of postproc (in the source, my builds haven't had it for a while now).
'Official' support for building with a libav/ffmpeg compiled with msvc.
VapourSynth support done.
Fix indexing of files with cover art.
Better YUV->RGB conversions with additional swscale flags.
Fix a year old regression in rffmode which caused it to not work.
Keep more information about the framerate around to avoid rounding problems (e.g. 60001/1001 instead of 60000/1001).

See the changelog for a semi-complete list of changes lined up for the next release (which should hopefully be soon).

[burfadel]

Thanks :) Works great!

[qyot27]

Considering the removal of postproc support from the trunk, I'd like to request a HEAD catchup on the C branch (removing postproc there too would really make it complete...patch that removes it from the C-plugin (https://gist.github.com/3773058), but it was generated against a caught-up HEAD). Not really because I can't do this myself, but because I'm going to replace my current github repo with a more standard git svn generated one and it'd be easier to integrate the necessary stuff into it - plus my own patches - if this was all committed upstream first.

I also don't know how much this matters, but the versions of config.guess and config.sub in the C-plugin are from September of 2009, compared to the ones in trunk that are from January of this year.

[Keiyakusha]

Is it somehow possible to apply better dithering when opening 10bit sources? By default it does some kind of ordered dithering but it doesn't looks very good compared to LAV's random dithering for example.
Edit: of course I can make use of hacked build and dither myself in the way I want, but I thought I'll ask, maybe I missed some handy switch...

[TheRyuu]

Is it somehow possible to apply better dithering when opening 10bit sources? By default it does some kind of ordered dithering but it doesn't looks very good compared to LAV's random dithering for example.
Edit: of course I can make use of hacked build and dither myself in the way I want, but I thought I'll ask, maybe I missed some handy switch...

I'll look into it.

In other news: ffms2-r725-icl.7z (https://ffmpegsource.googlecode.com/files/ffms2-r725-icl.7z) (x86 and binaries only)

Intel's compiler does one thing very well and that's make swscale not horribly slow. Should be >= gcc level again.

Compiled with -arch:IA32 so it should pretty much run on anything.

[kolak]

Is it somehow possible to apply better dithering when opening 10bit sources? By default it does some kind of ordered dithering but it doesn't looks very good compared to LAV's random dithering for example.
Edit: of course I can make use of hacked build and dither myself in the way I want, but I thought I'll ask, maybe I missed some handy switch...

Yes- Floyd-Steinberg dithering would be great :)

[Pat357]

I'll look into it.

While you look there fore improved 10-bit dithering and such, you might take a look at all the 8 bit, 10-> 8 bit 16bit color-space-convertions.
He didn't like swscale for the most common conversions and created new, by the book.
The one he created are high precision (up to 16bit,IIRC), written in SSE2 with both static and random dithering.
I wish you would import all this stuff in FFMS2.

In other news: ffms2-r725-icl.7z (https://ffmpegsource.googlecode.com/files/ffms2-r725-icl.7z) (x86 and binaries only)


Thanks !
Any chance for an C-plug version with support for more color-spaces ? FFMS_C v2.17 is really kind of old .....

[burfadel]

I'll look into it.

In other news: ffms2-r725-icl.7z (https://ffmpegsource.googlecode.com/files/ffms2-r725-icl.7z) (x86 and binaries only)

Compiled with -arch:IA32 so it should pretty much run on anything.

Does compiling with different arguments affect performance at all? Such as, compiling with -ia32 instead of -sse2 etc, apart from making the filesize larger due to the redundancy on recent CPU's?

[TheRyuu]

Does compiling with different arguments affect performance at all? Such as, compiling with -ia32 instead of -sse2 etc, apart from making the filesize larger due to the redundancy on recent CPU's?

No difference and could be slower.

If anything enabling the automatic ricerization (vectorization) makes things slower.

Using -arch:SSE2 with vectorization disabled (i.e. just for the fpmath) has no speed difference.

[burfadel]

Ah ok, thanks!

[TheRyuu]

Ah ok, thanks!

And as soon as I said it makes no difference we now have attempt #2:
ffms2-r725-icl-2.7z (https://ffmpegsource.googlecode.com/files/ffms2-r725-icl-2.7z)

Requires SSE2 capable CPU (isn't restricted to Intel) because as it turns out it does make a difference once you get fate to give you the green light.

[active1]

i got this error when using ffms2-r722 with vapoursynth-r10 :
vapoursynth.Error: 'Core only supports API R2 but the loaded plugin uses API R1'

script:
import vapoursynth as vs
import sys
core = vs.Core()
core.std.LoadPlugin(path='D:\\ffms2.dll')
v = core.std.FFVideoSource(source='d:\\v.mkv')
v.output(sys.stdout, y4m=True)

[Chikuzen]

i got this error when using ffms2-r722 with vapoursynth-r10 :


Myrsloik broke VS-API at VS-r9.
Therefore, you can't use old ffms2 on latest VS any more.
use ffms2-r724 or later.

[Keiyakusha]

active1
Not really sure about your exact problem but It maybe that your FFMS2 is too old
Also in recent ffms2, function FFVideoSource is no more. This is what I asked in vapoursynth thread not so long ago.

edit: i'm too slow

[active1]

ok, i used ffms2-r725-icl-2 and it works with: v = core.ffms2.Source(source='d:\\v.mkv')
thanx! :)

[kolak]

Why ffms2 is so slow when decoding ProRes in avisynth- only 30fps on my 8 core machine (and 15fps with 1 core)? Looks like very poor scaling?

[cretindesalpes]

Is it slow also when reading with FFmpeg in command line? If so, the right place to complain is the FFmpeg development mailing list, not here because FFmpegSource is "just" a wrapper around the FFmpeg libraries and the FFMS dev won't do anything regarding codec issues.

[kolak]

No- ffmpeg can read much faster, at least 2x faster.
Funny enough hacked ffms2 with 10bit read turned on is also way faster. Is it 10bit to 8bit scaling slowing it down?
It's way faster to read it at 10bit and simply crop 10bit part :)

To make it more funny DNxHD is opposite- ffms2 8bit is much faster in decoding it (than hacked ffms2 at 10bit). I'm lost now- it makes no sense :) It has to be difference in decoding between ffmpeg and ffmbc for each format.

[mastrboy]

indexing seems broken with large files in the latest revisions, last working one for me is ffms2-r712-2.
File information:

Format : AVI
Format/Info : Audio Video Interleave
Format profile : OpenDML
File size : 4.72 GiB
Duration : 19mn 34s
Overall bit rate : 34.5 Mbps
Writing library : VirtualDub build 32842/release

Video
ID : 0
Format : Huffman
Codec ID : HFYU
Duration : 19mn 34s
Bit rate : 34.5 Mbps
Width : 704 pixels
Height : 480 pixels
Display aspect ratio : 3:2
Frame rate : 23.976 fps
Standard : NTSC
Color space : RGB
Bit depth : 8 bits
Bits/(Pixel*Frame) : 4.262
Stream size : 4.72 GiB (100%)


ffms2-r722.7z and ffms2-r725-icl-2.7z jumps up to 100% and returns "Unknown error" after a while. Atleast when using ffmsindex.exe

[TheRyuu]

indexing seems broken with large files in the latest revisions, last working one for me is ffms2-r712-2.


I think I know why, I'll put up a test build later when I have a bit of time with the changes so you can test it.

[cyberbeing]

I've also noticed that x264 reports indexing fails with the ICL r725 builds, when FFMS2 is automatically loaded by x264 via Avisynth. The r722 MSVC build on GoogleCode works fine.

[mastrboy]

I think I know why, I'll put up a test build later when I have a bit of time with the changes so you can test it.

Thanks, but i found different issues with ffms2-r712-2 and ffms2-r706.

I had to go back to ffms2-r683 to get indexing to work properly.

Here are the issues i experience with the different revisions:
ffms2-r683: working, complete index file (accurate progress report)
ffms2-r706 and ffms2-r712-2: creates a index files but fails at about 4-5000 frames, even though it reports success and 100%. The indexing file when opened with avisynth FFVideoSource only returns 4-5000 frames. The progress report is also weird, it goes very fast to 99% then stays there for a while.
ffms2-r722 and ffms2-r725-icl-2: Fails with unknown error during indexing and exits.

[the_weirdo]

Just FYI, I don't have this problem with my own build (built against latest Libav git master and FFMS r725 source code using MinGW-w64 GCC for lav* and MSVC2010 for FFMS). I tried index a ~7GB MKV file with ffmsindex.exe and it works properly. Opening the indexed file in AvsPmod by FFVideoSource also doesn't show any problems.

[mastrboy]

Just FYI, I don't have this problem with my own build (built against latest Libav git master and FFMS r725 source code using MinGW-w64 GCC for lav* and MSVC2010 for FFMS). I tried index a ~7GB MKV file with ffmsindex.exe and it works properly. Opening the indexed file in AvsPmod by FFVideoSource also doesn't show any problems.

Care to share that version so i can test it on my files?

[the_weirdo]

Care to share that version so i can test it on my files?

Sure. Here (http://www.mediafire.com/?zu3dm941dhxyzfr) you go.
(32-bit only and you'll need to install MSVC++ 2010 Redist x86 (http://www.microsoft.com/en-us/download/details.aspx?id=8328) if you don't have it installed already).

[mastrboy]

Sure. Here (http://www.mediafire.com/?zu3dm941dhxyzfr) you go.
(32-bit only and you'll need to install MSVC++ 2010 Redist x86 (http://www.microsoft.com/en-us/download/details.aspx?id=8328) if you don't have it installed already).

Thanks :), your version works as it's supposed to. So i guess for the revisions i have problems with, it's not a code issue but a compiler or compiler settings issue...

[TheRyuu]

Thanks :), your version works as it's supposed to. So i guess for the revisions i have problems with, it's not a code issue but a compiler or compiler settings issue...

Yes, I haven't had time to do up a new one but like I said I'm pretty sure I know what's wrong.

[TheRyuu]

ffms2-r725-icl-3.7z (https://ffmpegsource.googlecode.com/files/ffms2-r725-icl-3.7z)

Hopefully doesn't crash. Try it and let me know if we're good now.
Also added code to override the cpu dispatcher Intel uses so it doesn't penalize AMD cpu's at all (although it should have been very minimal/not noticeable before with the settings being used).

Also now contains nearly all of the inline asm (ICL can compile a restricted version of GNU style inline assembly).

This also further improves YV12->RGB32 performance (gains about 8-10fps (from ~60fps) on a 720p file).

[TheRyuu]

ffms2-r725-icl-4.7z (https://ffmpegsource.googlecode.com/files/ffms2-r725-icl-4.7z)

Have some more experimental asm changes for even more speed (gets rid of the need for an aligned stack for certain h264/vp8 8-bit stuff).

[burfadel]

Thanks! ffms2-r725-icl-4 is noticeably faster to encode with than the standard r725 builds, at least 8 percent (roughly) on the current file.
(on i5-3570K)

[mastrboy]

ffms2-r725-icl-4.7z (https://ffmpegsource.googlecode.com/files/ffms2-r725-icl-4.7z)

Have some more experimental asm changes for even more speed (gets rid of the need for an aligned stack for certain h264/vp8 8-bit stuff).

Seems i still have problems with large files with this compiled version. It only manages to index about 7-8000 frames before exiting and reporting 100%, while the AVI file in question has about 20.000 frames.

[TheRyuu]

Seems i still have problems with large files with this compiled version. It only manages to index about 7-8000 frames before exiting and reporting 100%, while the AVI file in question has about 20.000 frames.

Oh? That's interesting. It sounds like a sample probably isn't very feasible considering the size, in which case what exactly are the specifics of the file? I'll try making one on my end to reproduce to see if I can track down the problem. Considering only ICL builds are broken it may very well be the compiler is barfing on something. I'll try and upload an updated MSVC build later as well, but I still want to try and reproduce it even if the MSVC build works.

Sample length seems to be about 20,000 frames. All I really need at that point is frame size (e.g. 1280x720) and codec used.

[mastrboy]

Media info from 2 different files which indexing fails for:

General
Format : AVI
Format/Info : Audio Video Interleave
Format profile : OpenDML
File size : 4.58 GiB
Duration : 19mn 34s
Overall bit rate : 33.5 Mbps
Writing library : VirtualDub build 32842/release

Video
ID : 0
Format : Huffman
Codec ID : HFYU
Duration : 19mn 34s
Bit rate : 33.5 Mbps
Width : 704 pixels
Height : 480 pixels
Display aspect ratio : 3:2
Frame rate : 23.976 fps
Standard : NTSC
Color space : RGB
Bit depth : 8 bits
Bits/(Pixel*Frame) : 4.135
Stream size : 4.58 GiB (100%)

General
Format : AVI
Format/Info : Audio Video Interleave
Format profile : OpenDML
File size : 5.22 GiB
Duration : 19mn 34s
Overall bit rate : 38.1 Mbps
Writing library : VirtualDub build 32842/release

Video
ID : 0
Format : Huffman
Codec ID : HFYU
Duration : 19mn 34s
Bit rate : 38.1 Mbps
Width : 768 pixels
Height : 576 pixels
Display aspect ratio : 4:3
Frame rate : 23.976 fps
Color space : RGB
Bit depth : 8 bits
Bits/(Pixel*Frame) : 3.596
Stream size : 5.22 GiB (100%)

The files where created with Virtualdub newest stable with the following settings: http://postimage.org/image/irl68g4gf/ and saved with "Fast recompress".
The source for the avi files is avs scripts which use DGindex and IVTC on vob files.

[Chikuzen]

Seems i still have problems with large files with this compiled version. It only manages to index about 7-8000 frames before exiting and reporting 100%, while the AVI file in question has about 20.000 frames.

This bug (http://git.libav.org/?p=libav.git;a=blobdiff;f=libavformat/file.c;h=c552a9eaa58c544285413d99a6f160441ea3da22;hp=fc0af92277ee7b7813c51a6ea2256b9caed233f0;hb=e04826c34e9b19cc4da60fd028334f12f84b4b2a;hpb=f79364b2c30aaaec9f0b1500a74da5a859c2ff37) that VFR_maniac fixed before half a day may be related.

[qyot27]

Testing build:
http://www.mediafire.com/?3r7xcwl4lhh8mw4

I've unfortunately been unable to load it into VapourSynth under Windows (it works on Linux; natively, I mean, not this build). I'm not sure if it's an issue with MinGW, or because both AviSynth C-plugin and VapourSynth interfaces were active (or possibly because on Windows I went with the installers for Cython and VS instead of [re-]building them myself). If I open ffms2.dll in dllexp, it shows that it contains:
VapourSynthPluginInit@12 0x6edaf13b 0x0002f13b 102 (0x66) ffms2.dll C:\Program Files\AviSynth 2.5\plugins\ffms2.dll Exported Function
But when I try to load it in VS, it complains about not finding an entry point.
Traceback (most recent call last):
File "vstestscript.vpy", line 4, in <module>
core.std.LoadPlugin(r'C:\Program Files\AviSynth 2.5\plugins\ffms2.dll')
File "vapoursynthpp.pyx", line 870, in vapoursynth.Function.__call__ (src\cython\vapoursynthpp.c:12399)
vapoursynth.Error: 'No entry point found in C:\\Program Files\\AviSynth 2.5\\plugins\\ffms2.dll'

Script:
import vapoursynth as vs
import sys
core = vs.Core()
core.std.LoadPlugin(r'C:\Program Files\AviSynth 2.5\plugins\ffms2.dll')
ret = core.ffms2.Source(r'Those Three Words Final.mp4')
ret.output(sys.stdout, y4m=True)

[Myrsloik]

How did you compile it? That's a partially decorated symbol. The exported fun tion name has to start with a _ or be without @12

[qyot27]

Cross-compiled with MinGW-w64 (gcc 4.8.0 prerelease) under Ubuntu 12.04. The integration with the C plugin's build system is here (https://github.com/qyot27/ffms2/commit/3b5da710cecc23c5a238d4a8e42b30b3af6dc555).
PKG_CONFIG_PATH=$HOME/win32_build/lib/pkgconfig ./configure --prefix=$HOME/ffms2-avs \
--cross-prefix=i686-w64-mingw32- --host=i686-pc-mingw32 --enable-avs --enable-vapoursynth \
--enable-shared --extra-cflags="-march=pentium3 -mtune=pentium3" --extra-ldflags="-lz -lbz2 -lpthreadGC2 -lutvideo"
make
make install-avs

[TheRyuu]

The files where created with Virtualdub newest stable with the following settings: http://postimage.org/image/irl68g4gf/ and saved with "Fast recompress".
The source for the avi files is avs scripts which use DGindex and IVTC on vob files.

Out of curiosity, why are you using ffms2 to open up these AVI files?

[qyot27]

I tried again, with a couple of other configurations.

It seems that having the AviSynth C-plugin active was masking a build issue with the VapourSynth code. If I tried to use only --enable-vapoursynth, I was getting errors from ffmsindex about not finding the functions in ffms.h. I'd not added vapoursynth detection to the shared library rules; once I did that, it compiled without issue, although the symbol looks exactly the same as before.

When using the trunk and using autogen.sh to get VS support enabled, it experienced similar errors about not finding things. It got resolved with:
LIBS="-lpthreadGC2 -lole32" SOFLAGS="-Wl,--export-all-symbols"
but also doesn't have a correct symbol.

[active1]

i have a problem with using ffms2 with vapoursynth under ubuntu linux
after i compiled the latest libav (with ./configure && make && sudo make install) i downloaded the latest source code for ffmpegsource and compiled it:

svn checkout http://ffmpegsource.googlecode.com/svn/trunk/ ffmpegsource-read-only
cd ffmpegsource-read-only
./configure --enable-shared=yes
make
sudo make install
then in python3:
>>> import vapoursynth as vs
>>> import sys
>>> core = vs.Core()
>>> core.std.LoadPlugin(path='/usr/local/lib/libffms2.so')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "vapoursynth.pyx", line 857, in vapoursynth.Function.__call__ (build/src/cython/vapoursynth.c:12374)
vapoursynth.Error: 'No entry point found in /usr/local/lib/libffms2.so'

(i can load libeedi3.so the same way without any problem)

[sneaker_ger]

Here's a TS file that ffms2 seems to have some serious problems with, even when remuxed to mkv. Video is interlaced H.264 from a Sony camera. If you are interested in a sample:
http://www.file-upload.net/download-6680403/sonyTS.7z.html (TS + MKV)
http://www.mjkk.de/maps/test.MTS ( TS only, direct download)

The mts starts screwed up (wrong colors, smearing etc.), the mkv jumps back and forth and does not work at the correct framerate.
The mkv can be made working by forcing fpsnum/fpsden(/threads=1), though. I know (interlaced) TS is a known issue, but maybe you are interested anyways or at least in the mkv.

[Guest]

Why is interlaced TS such a problem? Is the TS demuxer broken? Seems like a pretty simple thing to fix if so.

Works fine with DGSource() by the way, so the stream is fine.

[qyot27]

i have a problem with using ffms2 with vapoursynth under ubuntu linux
after i compiled the latest libav (with ./configure && make && sudo make install) i downloaded the latest source code for ffmpegsource and compiled it:

svn checkout http://ffmpegsource.googlecode.com/svn/trunk/ ffmpegsource-read-only
cd ffmpegsource-read-only
./configure --enable-shared=yes
make
sudo make install
The trunk hasn't had its build system regenerated yet. You have to use autogen.sh before (or instead of) configure to make it see the VapourSynth sources and use them.

./autogen.sh --enable-shared
or
./autogen.sh
./configure --enable-shared



With r730, FFMS2 has had its build system regenerated. Running autogen first is no longer necessary.

[active1]

The trunk hasn't had its build system regenerated yet. You have to use autogen.sh before (or instead of) configure to make it see the VapourSynth sources and use them.

./autogen.sh --enable-shared
or
./autogen.sh
./configure --enable-shared

ok, i will :thanks:

[sneaker_ger]

Why is interlaced TS such a problem? Is the TS demuxer broken? Seems like a pretty simple thing to fix if so.

The funny thing is that ffmpeg, LAV filters, vlc etc. seem to have no problem whatsoever. ffms2 is really messed up in this regard.

[tebasuna51]

Why is interlaced TS such a problem? Is the TS demuxer broken? Seems like a pretty simple thing to fix if so.

In this thread:

...The next time you see someone complain about interlaced h264 you can quote what I just posted here...

[Guest]

TheFluff attributes the issue to the lavf TS parser but sneaker_ger says that ffmpeg itself works fine. :confused:

[TheFluff]

TheFluff attributes the issue to the lavf TS parser but sneaker_ger says that ffmpeg itself works fine. :confused:

There are actually several different problems that contribute to the mess. lavf's TS parser is terrible, but it's not solely responsible for the problems. I don't know the details of what is currently broken though because I haven't worked on FFMS2 in a long time now. This (http://code.google.com/p/ffmpegsource/issues/detail?id=83) used to be a problem but I think plorkyeran might have fixed it, or at least tried to.

[poisondeathray]

The funny thing is that ffmpeg, LAV filters, vlc etc. seem to have no problem whatsoever. ffms2 is really messed up in this regard.


Are you sure about that?

On this sample, ffmpeg has problems (as usual with interlaced AVC transport streams) - duplicate frames, 2x fps

ffmbc has no problems , but the ffms2 build based on ffmbc has problems . Not sure why

[sneaker_ger]

Are you sure about that?

I'm not 100% sure, but I just re-converted to ffv1 and didn't see any problems. Still 25 fps, 507 frames. I went through all frames but wasn't able to spot any problems. Or do these problems only appear when seeking, not when progressively converting?

ffmpeg -i test.mts -vcodec ffv1 -acodec copy -sn ffv1.mkv
(ffmpeg (http://ffmpeg.zeranoe.com/builds/win64/static/ffmpeg-20121010-git-1a104bf-win64-static.7z))

[poisondeathray]

I'm not 100% sure, but I just re-converted to ffv1 and didn't see any problems. Still 25 fps, 507 frames. I went through all frames but wasn't able to spot any problems. Or do these problems only appear when seeking, not when progressively converting?

ffmpeg -i test.mts -vcodec ffv1 -acodec copy -sn ffv1.mkv
(ffmpeg (http://ffmpeg.zeranoe.com/builds/win64/static/ffmpeg-20121010-git-1a104bf-win64-static.7z))


Interesting, I did the same test but with huffyuv and an older binary from the same site (maybe a few months old) and it had the typical problems . If I have time I'll look into it farther, maybe they fixed it ?

[qyot27]

Well, it's probably not going to work for win64, but the VapourSynth side of the non-autotools/C plugin can actually be recognized now under win32.

New build:
ffms2-r725-2_avs+vsp (http://www.mediafire.com/?p7m8fkr8aarpacv)

Works as both C-plugin and VapourSynth plugin. 32-bit.

[kolak]

Just to inform-DNxHD 10bit decoding bug is fixed now in ffms2, but custom build based on ffmbc is still useful in some cases. It would be nice to have ffms2 based on ffmbc with vapoursynth support.

[Pat357]

Still 25 fps, 507 frames. I went through all frames but wasn't able to spot any problems.

ffmpeg -i test.mts -vcodec ffv1 -acodec copy -sn ffv1.mkv
(ffmpeg (http://ffmpeg.zeranoe.com/builds/win64/static/ffmpeg-20121010-git-1a104bf-win64-static.7z))

Strange, as this gives me a very shaky video (incl. audio drops). I can't find anything that plays the file correctly.
Neither Lav filters (softw + CUVID +DXVA) or anything else I've tried did decode the FFV1 video as it should.

This makes me wonder what software you've used to check the file ?

[sneaker_ger]

It's very high bitrate, so not suited for real time playback. Go through the frames one by one or use something sane just for the test:
ffmpeg -i test.mts -vcodec libx264 -preset medium -crf 18 -an -sn x264.mkv (progressive encoding, but should be sufficient for this test)
my output for reference (http://www.mediafire.com/?a421elp059mw19h)

Also make sure you don't have any deinterlacer trying to work with the wrong field order.

[mastrboy]

Out of curiosity, why are you using ffms2 to open up these AVI files?

When using avisynth mt i have experienced less crashes using ffvideosource(threads=1) rather than avisource, so using ffvideosource has just became a habit even if i use setmtmode or not...

Have you been able to reproduce the issue?

[kolak]

Well, it's probably not going to work for win64, but the VapourSynth side of the non-autotools/C plugin can actually be recognized now under win32.

New build:
ffms2-r725-2_avs+vsp (http://www.mediafire.com/?p7m8fkr8aarpacv)

Works as both C-plugin and VapourSynth plugin. 32-bit.

Any new builds?
ProRes decoding is more than 2x slower than DNxHD- any reason for this?

[qyot27]

Any new builds?
ProRes decoding is more than 2x slower than DNxHD- any reason for this?
There haven't been any new commits to FFMS2 (or x264, or really cool new decoders in libavcodec) to warrant it. The only thing a newer build would be doing is using a newer version of FFmpeg and a couple of the external decoders (read: libutvideo and libopus). So unless FFmpeg dramatically sped up within the last three weeks, it'd likely just stay the same performance-wise.

[kolak]

Can you make a build based on ffmbc?- some things are different there.

[qyot27]

Can you make a build based on ffmbc?- some things are different there.
Those patches aren't for the C plugin (more likely GCC in general, actually), and trying to integrate them results in compilation failure(s). So unless it gets adjusted to compile cleanly, no.

And this was after hitting ffmbc with a hammer to get it to compile cleanly. It wasn't compiling libavcodec/timecode.c and not linking it into libavformat, causing undefined references in mov and mxfdec.

[Chirico]

Is there any special configuration options needed to get this to build for and load in vapoursynth? I've compiled this on OS X and am trying to load the libffms2.dylib but I keep getting the error about no entry point found.

[Myrsloik]

Is there any special configuration options needed to get this to build for and load in vapoursynth? I've compiled this on OS X and am trying to load the libffms2.dylib but I keep getting the error about no entry point found.

The build system is a bit of a mess about these things. Wait for the next revision where I'm going to fix it if you want to keep it simple. I think you also need to pass an option to enable vs support.

[Chirico]

Ok, I read through the configuration options quickly and didn't see anything. I'll look through it again.

Edit:
Figured out the issue. Didn't notice that you needed to run the autogen.sh that was mentioned in a previous post. Now it compiled and loaded fine. Again, for anyone else on OS X that doesn't want to compile it themselves you can grab it here (http://www.sendspace.com/file/eb0dq3).

[qyot27]

I've run into an issue trying to cross-compile the trunk to test VapourSynth support with it again.

PKG_CONFIG_PATH=$HOME/win32_build/lib/pkgconfig ./configure --prefix=$HOME/win32_build \
--host=i686-w64-mingw32 --build=i686-w64-mingw32
results in
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.

Leaving out --build, configure completes, compiles fine. Previously, it wouldn't complain about the presence of both --build and --host, but that was prior to the most recent set of updates, and it might have also been prior to me updating to Ubuntu 12.10, which ships with newer versions of autotools than 12.04 did (and I cannot remember if my attempts to do any of this were after October 18th, or if they were all prior to it). Not sure if this could be contributing to the problem below.



PKG_CONFIG_PATH=$HOME/win32_build/lib/pkgconfig ./configure --prefix=$HOME/win32_build \
--host=i686-w64-mingw32 --enable-shared
configure completes, but won't link to libpthreadGC2.a or libopus.a

The warning/error itself:
*** Warning: This system can not link to static lib archive
/usr/bin/../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/lib/../lib/libopus.la.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have.



If necessary, the output from the ffmpeg it was linking against:
ffmpeg version r46401 git-3af7919 Copyright (c) 2000-2012 the FFmpeg developers
built on Nov 3 2012 19:00:58 with gcc 4.7.2 (GCC)
configuration: --prefix=/home/qyot27/win32_build --cross-prefix=i686-w64-mingw32- --enable-gpl
--enable-version3 --disable-w32threads --enable-memalign-hack --enable-avresample
--disable-decoder=utvideo --enable-libutvideo --enable-libopus --disable-encoders --disable-muxers
--disable-debug --disable-network --disable-hwaccels --disable-indevs --disable-outdevs
--cpu=pentium3 --extra-cflags='-march=pentium3 -mtune=pentium3 -DPTW32_STATIC_LIB'
--target-os=mingw32 --arch=x86
libavutil 52. 3.100 / 52. 3.100
libavcodec 54. 71.100 / 54. 71.100
libavformat 54. 35.100 / 54. 35.100
libavdevice 54. 3.100 / 54. 3.100
libavfilter 3. 21.106 / 3. 21.106
libswscale 2. 1.102 / 2. 1.102
libswresample 0. 16.100 / 0. 16.100
libpostproc 52. 1.100 / 52. 1.100

[18fps]

Thank you for all the work you put in this great plugin!
I'd like to know something. It's possible to load a sequence of numbered images (for ex. 00000000.dpx, 00000001.dpx, etc.) with FFVideoSource (like ffmpeg with the option -f image2)?

[Myrsloik]

Thank you for all the work you put in this great plugin!
I'd like to know something. It's possible to load a sequence of numbered images (for ex. 00000000.dpx, 00000001.dpx, etc.) with FFVideoSource (like ffmpeg with the option -f image2)?

No. THIS IS FILLER MATERIAL

[18fps]

No. THIS IS FILLER MATERIAL

Well, I can always create a .mov (prores 10 bit) with ffmbc and then open it with ffmpeg in avisynth. Thank you!

[LigH]

ImageSource() in AviSynth scripts can open image sequences. But probably only usual image formats. I doubt that it knows *.dpx - it may have restrictions to support only RGB32 compatible formats.

[18fps]

ImageSource() in AviSynth scripts can open image sequences. But probably only usual image formats. I doubt that it knows *.dpx - it may have restrictions to support only RGB32 compatible formats.

There's also Immaavs, which uses ImageMagick to open the dpx, but it dithers them to 8 bits. Creating the mov I keep the 10 bits and with the ffms2 hack (http://forum.doom9.org/showthread.php?p=1580141#post1580141) with "enable10bithack" I can even process it in high bit depth. I'm still trying to understand what kind of avisynth processing I can do. At the end I want to output either 10 bit dpx or x264 10 bit.

[mariner]

Problem with hard telecined video

Greetings.

I have a number of hard telecined BD which I'd like to convert to 23.976fps progressive with the following script. For the attached sample, x264 returns 960 frames, twice the frame count and duration using DirectShowSource.

Appreciate advice on correct usage.

System : W7x86, Avisynth 2.58, ffms2-r725-icl-4, latest Haali and FFdshow, Intel G45 graphics card.

FFvideoSource("zoroark.m2ts")
AssumeTFF()
TFM()
TDecimate()


Zoroark.m2ts (http://www2.zshare.ma/o9h4mnlaioed)

[sneaker_ger]

ffms can't find a suitable output format in VapourSynth for these:
http://media.xiph.org/sintel/sintel-4k-png16/
http://www11.zippyshare.com/v/74717882/file.html

ffms2 with 10 bit hack for AviSynth seems to work. (Does it downconvert/dither/clamp to 10 bit or are the 16 bits kept?)

[LigH]

@ mariner:

Never load transport streams with FFMS2 directly until their authors report that their transport stream splitter is finally correct. Instead, remux it to MKV with mkvmerge (mkvtoolnix) before indexing.

[mariner]

@ mariner:

Never load transport streams with FFMS2 directly until their authors report that their transport stream splitter is finally correct. Instead, remux it to MKV with mkvmerge (mkvtoolnix) before indexing.

Greetings LigH, thanks for the kind reply.

1. Does FFVidoeSource have problem dealing with interlaced video?

2. Is m2ts to mkv remuxing required for progressive video?

3. I've encountered a strange problem with FFVidoeSource outputting incorrect number of frames. Using the attached 136 frame progressive clip as input, a simple x264 encode with FFM2_r725_icl_4 results in 134 frames, while the version complied by Weirdo results in 136 frames. Is this a different problem?

Many thanks and best regards.

cut.m2ts
(http://www2.zshare.ma/fbbp7noio4sf)

[LigH]

1. Interlaced H.264 in (M2)TS: Most probably yes. If not anymore, FFMS2 authors will certainly announce that, but until today, instead, people kept pointing at the same explanation why it is so difficult to fix.

2. Still recommendable; FFMS2 splitters officially do not support any transport streams well; and interlaced content seems to be just another dimension of issues.

[mariner]

1. Interlaced H.264 in (M2)TS: Most probably yes. If not anymore, FFMS2 authors will certainly announce that, but until today, instead, people kept pointing at the same explanation why it is so difficult to fix.

2. Still recommendable; FFMS2 splitters officially do not support any transport streams well; and interlaced content seems to be just another dimension of issues.

Thanks for the reply, LigH.

1. Did you get a chance to look at issue #3? Weirdo's version is found here:

http://forum.doom9.org/showthread.php?p=1594210#post1594210

2. Is it necessary to remove audio when remux to mkv?

3. Does FFvideoSource work with raw h264 format?

Many thanks and best regards.

[LigH]

Sorry, I do not belong to its developers. I do not even convert videos very frequently.

Usually it is recommendable to keep audio tracks while remultiplexing to MKV, because that keeps them in sync with the video if done correctly. Just note the documentation regarding indexing files with audio and video streams, don't miss the function FFmpegSource2() { import("FFMS2.avsi") }.

Yes, FFMS2 comes with a documentation. It does contain useful information. Another answer to your questions is:

Because of LAVF's demuxer, most raw streams (such as elementary h264 and other mpeg video streams) will fail to work properly.

Thumb rule: Try to use ffmsindex.exe (a command line tool) with the desired media file before loading an AviSynth script the first time. It may already show error messages if there are problems. Or it will create a comprehensive index file for best use.

[Abs62]

FFMS2 compiled with last ffmpeg can't decode aac audio ("FFAudioSource: Bad audio format"). It seems after commit "aacdec: use float planar sample format for output" (26.11).

[qyot27]

FFMS2 compiled with last ffmpeg can't decode aac audio ("FFAudioSource: Bad audio format"). It seems after commit "aacdec: use float planar sample format for output" (26.11).
This is also the case with MP3 and now AC3 (it's really picked up in the last couple months with many of the other audio decoders as well). I've had to resort to using externally-decoded PCM files for audio input when I've tested with this.

This is being pulled upstream from libav, so it definitely affects both of them.

http://git.libav.org/?p=libav.git&a=search&h=HEAD&st=commit&s=planar
http://git.videolan.org/?p=ffmpeg.git&a=search&h=HEAD&st=commit&s=planar

I'm hoping that this isn't actually a limitation of AviSynth that prevents it from working. In such a case, I wonder if the solution would be to finally do something with SWResample and/or AVResample.

[JEEB]

There basically needs to be some work on switching the audio decoding to the current audio decoding API (avcodec_decode_audio4), as well as then possibly auto-packing it with avresample into the buffer that the calling application provides.

I did hack (https://github.com/jeeb/ffms2/commit/cfe4627a698ea987718b0a8f076df9b50dc1dde9) on the problem some time ago, and it doesn't seem to be too hard to fix, but it was a hack I wrote while very tired so it doesn't work (incorrect dumping of audio at least in the indexer as I left that out completely), as well as I never tell ffms2 that it won't be getting the type of audio it was thinking it'd get. It does seem to actually stay relatively stable memory consumption wise when decoding, though (tested by having the command line indexer go over and decode an audio track of a sample AAC file I had lying around -- which did produce a nice 7GB+ w64 file from 1min30sec of stereo, but seemed stable otherwise).

Also, looking at how I tried to use avresample there, it doesn't seem like a too shabby of a library usability wise.

[easyfab]

I have a problem with ffms2 > r722 and mpc-hc .
With r722, it works but r725 doesn't work with mpc-hc but ok with graphedit ?
As someone the same problem and is this a mpc-hc bug or FFMS2 ?

[LigH]

I don't understand your problem.

FFMS2 is a source plugin for AviSynth, not for MPC-HC.

AviSynth scripts are not meant to be viewed in MPC-HC, because AviSynth is a VfW frameserver, but MPC-HC is a media player for DirectShow (or own internal decoders). To view an AviSynth skript, use a program with VfW support (VirtualDub) or native AviSynth environment support (AvsPmod).

The DirectShow compatibility bridge for VfW may work in DirectShow media players, but doesn't have to.

[jmac698]

I'm trying to return select frame types with ffms2. I haven't been able to get it to work.


X=dir+"20121105002302.MTS"
A = FFAudioSource(X)
V = FFVideoSource(X,varprefix = "src")
ScriptClip("""
subtitle(chr(srcFFPICT_TYPE))
""")

It's showing FFPICT_TYPE as undefined, also srcFFPICT_TYPE. How can I return only select frames, when it does work?

Edit, need frame after for first frame:

varprefix = "src"
A = FFAudioSource(X)
V = FFVideoSource(X,varprefix = varprefix)
ScriptClip("""
chr(eval(varprefix + "FFPICT_TYPE"))=="I"?last:nop
""", after_frame=true)

Now, how to delete frames that aren't I frames? Does it have to be two pass? Can't I use a compile time trick somehow?

[Gavino]

Now, how to delete frames that aren't I frames? Does it have to be two pass? Can't I use a compile time trick somehow?
Deleting frames via ScriptClip is a bit tricky, but you can use the technique from here.

[Myrsloik]

I'm trying to return select frame types with ffms2. I haven't been able to get it to work.


X=dir+"20121105002302.MTS"
A = FFAudioSource(X)
V = FFVideoSource(X,varprefix = "src")
ScriptClip("""
subtitle(chr(srcFFPICT_TYPE))
""")

It's showing FFPICT_TYPE as undefined, also srcFFPICT_TYPE. How can I return only select frames, when it does work?

Edit, need frame after for first frame:

varprefix = "src"
A = FFAudioSource(X)
V = FFVideoSource(X,varprefix = varprefix)
ScriptClip("""
chr(eval(varprefix + "FFPICT_TYPE"))=="I"?last:nop
""", after_frame=true)

Now, how to delete frames that aren't I frames? Does it have to be two pass? Can't I use a compile time trick somehow?

Compile time as in c++ compile time. Using the ffms2 api directly it's very easy to build the list. It would probably only take 15 lines if you modify the ffms2 filter for your special needs.

[StainlessS]

@Jmac, If I understand correctly what you want to do, see here:
http://forum.doom9.org/showthread.php?p=1539598#post1539598

You might want to convert to using FrameSelect() rather than Prune() by removing the '0' clip index in WriteFileIf.

[StainlessS]

This extracts I/KEY frames only


X = "D:\avs\avi\1.avi"
PREFIX = "SRC_"
FFIndex(X)
V=FFVideoSource(X,varprefix = PREFIX)
NewClip=0
GSCript("""
for(i=0,V.FrameCount-1) {
V.RT_AverageLuma(n=i,w=1,h=1) # Force update of SRC_FFPICT_TYPE
if(SRC_FFPICT_TYPE==73) { # 'I'
NewClip = (IsClip(NewClip)) ? NewClip ++ V.Trim(i,-1) : V.Trim(i,-1)
}
}
""")
return NewClip

[StainlessS]

I modded the Prune select script linked 2 posts earler for this purpose, creates list for FrameSelect() instead of Prune().


X = "D:\avs\avi\1.avi"
PREFIX = "SRC_"
PROCESS = True # False will create list of I/KEYFrames, Need to play all way through to create list.
# True will auto create list and additionally select and return I/KEYFrames ONLY
FFIndex(X)
V=FFVideoSource(X,varprefix = PREFIX)
Clip = V.SelectFrames("IFrames.txt","SRC_FFPICT_TYPE==73") # Create list of I/KeyFrames

GSCript("""
if(PROCESS) {
For(i=0,Clip.framecount-1) {
Clip.RT_AverageLuma(n=i,w=1,h=1) # Force list creation by sampling single pixel from each frame, result discarded
}
Clip = 0 # Destroy Clip, Not necessary here. Can be used to call clip destructor to close/flush eg file writing
Clip = V.FrameSelect(CMD="IFrames.txt") # Select all I/KeyFrames using newly created list.
}
""")

return Clip


#SelectFrames("In_cmd.txt","YDifferenceFromPrevious>=0.1 || current_frame==0") # Always keeps first frame 0 (else delete)
#DeselectFrames("In_cmd.txt","YDifferenceFromPrevious>=0.1 || current_frame==0") # Always deletes first frame 0 (else keep)
#SelectFrames("In_cmd.txt","YDifferenceToNext>=0.1 || current_frame==framecount-1") # Always keeps last frame (else delete)
#DeselectFrames("In_cmd.txt","YDifferenceToNext>=0.1 || current_frame==framecount-1") # Always deletes last frame (else keep)

Function SelectFrames(clip c, string fileName, string condition, bool "Fast") {
# Conditional KEEP frames Command File generator for FrameSelect()
# MUST call with correct colorspace for condition eg YDifferenceFromPrevious requires a Planar colorspace.
# May require additional condition for end frames for eg YDifferenceFromPrevious and YDifferenceToNext.
# Any-DifferenceFromPrevious,
# Gives 0 for frame zero and so you may want to add to condition " || current_frame==0" to include frame 0.
# Any-DifferenceToNext,
# Gives 0 for last frame and so you may want to add to condition " || current_frame==framecount-1 " to include last frame.

c=(Default(Fast,true))?c.AssumeFPS(250.0):c # Fast as we can if Fast = true (Default true)
WriteFileIf(c, fileName, condition, "current_frame", append=false)
}

Function DeselectFrames(clip c, string fileName, string condition, bool "Fast") {
# Conditional DELETE frames Command File generator for FrameSelect()
# MUST call with correct colorspace for condition eg YDifferenceFromPrevious requires a Planar colorspace.
# Is EXACT opposite of SelectFrames() for same conditional.
# NOTE, any additional end frame condition as used in SelectFrames, will also be inverted
# eg " || current_frame==0", frame 0 would be deleted.

c=(Default(Fast,true))?c.AssumeFPS(250.0):c # Fast as we can if Fast = true (Default true)
condition = "!(" + condition + ")"
WriteFileIf(c, fileName, condition, "current_frame", append=false)
}


EDIT: After list created, can just use this:

X = "D:\avs\avi\1.avi"
Return FFVideoSource(X).FrameSelect(CMD="IFrames.txt")


FrameSelect() Here: http://forum.doom9.org/showthread.php?t=164497

EDIT: At the risk of stating the obvious, you would not want to try above on eg HuffYUV compressed AVI as they are ALL
keyframes. For AVI, try with DivX or XVid or some other lossy codec.

EDIT: You can add "Show=True" to the FrameSelect() line to show original frame numbers.

[qyot27]

Some new builds:
FFMS2 r739 (http://www.mediafire.com/?9j091vw73zu9kf4)
VapourSynth-only plugin, FFmpeg N-48238-g10a3fa8

FFMS2 r739 C-plugin (http://www.mediafire.com/?8u1c14yqymvxmnc)
AviSynth C-plugin & VapourSynth plugin, FFmpeg N-47083-g66c3bac


The reason for the disconnect is the current stuff going on in libavcodec concerning planar audio. The build with AviSynth support uses an FFmpeg from just before the shift occurred for aacdec and mpegaudiodec (that is, it's from November 25th). I didn't want to mess with doing targeted reverts, so it's just rolled back to the last good commit (although Vorbis is still affected; it got switched over on Nov 20th). The VapourSynth-only build uses a current version of FFmpeg, since audio doesn't matter for it anyway.

[Selur]

can someone compile a normal FFMS2 version for Avisynth (no C-plugin?)

[LigH]

The "planar audio" changes in libavcodec may be the reason why it doesn't compile easily anymore as usual AviSynth plugin, probably due to the calling conventions of specific function parameters supported by C.

[StainlessS]

can someone compile a normal FFMS2 version for Avisynth (no C-plugin?)

If you just want an autoload plug, then create an avsi in plugins that autoloads the C plug.

[Selur]

thanks, for the advice but I don't want an autoload plug,... :)

[StainlessS]

OK, I see, its for use by your 'Hybrid'.

[Selur]

Mainly, since I create most of my small script using it (or a slightly modified version of it). :)

[qyot27]

If you just want an autoload plug, then create an avsi in plugins that autoloads the C plug.
My builds of the C plugin (and the corresponding git repo) have the load function inside of FFMS2.avsi. Not that it matters for the reason why Selur was asking for a trunk/MSVC build.

The "planar audio" changes in libavcodec may be the reason why it doesn't compile easily anymore as usual AviSynth plugin, probably due to the calling conventions of specific function parameters supported by C.
The planar audio stuff in libavcodec only means that audio doesn't work (unless it's PCM); it doesn't stop it from compiling. At least, not yet - and it's not the planar audio that would stop it anyway.

[JEEB]

Plorky has done some more work (https://github.com/tgoyne/ffms2/commits/master) on libavresample'ing the audio part so interleaved audio can be gotten where needed.

It's not finished and currently adds a new API for setting the needed audio format as far as I can see. Should end up in the ffms2's official repository at some point.

[burfadel]

Some new builds:
FFMS2 r739 C-plugin (http://www.mediafire.com/?8u1c14yqymvxmnc)
AviSynth C-plugin & VapourSynth plugin, FFmpeg N-47083-g66c3bac

I tried this avisynth build. It worked most of the time, but when doing batch encoding occasionally it crashed, but worked the next time I ran it.

I looked around for alternative recent builds to see if they were affected too. I came across this one:
ffms2-r742+8-ffmpeg-gb454c64
https://skydrive.live.com/redir?resid=5FEFAEC438258885%21982&authkey=%21ADzTzz_MWxo3Dks

and it works beautifully! I have been continually batch encoding (on list) for a day or so with that build now. With Qyot27's build it crashed every couple of hours or so.

Qyot27, I don't know what it is about our build, but something isn't quite right? It isn't a criticism, I do appreciate the new builds! I'm just pointing it out in case something needs rectifying.

[qyot27]

Without more information, the only thing I can guess is that it might be related to the memleak-related fixes in r740 and r741. r739 certainly wouldn't have these, while r742 would. Unless it was actually something in FFmpeg that's gotten fixed between November and now - that's also a possibility.

[burfadel]

That is a possibility! I just thought I'd let you know and point it out to others if they have the same issue. If just encoding a single file you probably won't come across it.

EDIT: Progressing through a large batch of files (encoding at HD, custom very slow settings in x264), still going good with the r742 I linked earlier (unlike the r739 which crashed a couple of times a day).

[Selur]

FFVideoSource("H:\TEST\yuv422_16bitBitEndianStereo.mov",cachefile="H:\Temp\mov.ffindex",threads=1)
crashes
mov contains: progessive YUV2 and pcm audio
- plays fine with mplayer/ffplay
- ffindex doesn't report any problems on index creation
sample: https://docs.google.com/file/d/0B_WxUS1XGCPAblRwN2ozazd0Y28/edit?usp=sharing

anyone got an idea where the problem is?

[kolak]

Try disabling audio.

[Selur]

How? afaik FFVideoSource is video only.

[burfadel]

I believe that is the case too, hence the difference between FFVideoSource and FFAudioSource

[kolak]

How? afaik FFVideoSource is video only.

Delete it in MOV with QT player Pro or create ref mov file without audio.

update- still bad

It does crash for me also (with different version of ffvideo)- including avisynth. It also crashes after re-wrapping to AVI.

FFmpeg converts it fine thought.

[Selur]

FFmpeg converts it fine thought.
as does mencoder, that's why I wondered if I missed some restriction of FFMS.

[LigH]

As far as I remember, I had issues with some raw YUV AVIs in FFMS2 too (Direct Stream Copy from AviSynth to AVI in VirtualDub). Since then I always recommended to prefer AviSource over FFMS2 for AVIs with no or lossless encoding.

[Selur]

-> add a new issue to the bug tracker regarding this problem: https://code.google.com/p/ffmpegsource/issues/detail?id=108

[Farfie]

Hi there, I was directed to come here by the kind people in the "new" Avisynth thread. And mistakenly accusing them for my problem (I'm not exactly the biggest video guru,) they said I might have better luck here.
Anyway, encodes (8 or 10bit, x264) with open-gop are having a hard time opening with virtual dub, or megui's preview thing since the new avisynth, when trying to use FFVideoSource. What happens varies greatly: hanging, crashing, freezing, but in the end I cannot find a work around. One thing I've noticed is that if it's a smaller file it might work for a bit, but eventually start to exhibit problems, and hang indefinitely.
I just hope I'm talking to the right people this time, but if not, feel free to ask questions or point me somewhere else :)
My only goal is to better the software that I enjoy using, so here I am.

[Selur]

I'm no ffms developer, but here are some basic questions that you might want to answer:

0. What version of ffms are you using? (Have you tried other versions?)
1. You wrote you open x264 8/10bit with open-gop content, is it RAW content or does is reside in a container? If your streams are not raw streams in what container are they?
2. Do you use other filters than ffms.dll in your script? If you do, try to throw these out first to make sure this really is a ffms problem.
3. Are you using 32bit or 64bit Avisynth? What version of Avisynth are you using? (No clue what you call the ' "new" Avisynth thread'.)
4. What is the memory consumption of the Virtual Dub while opening and scrolling through your clip on your system?
5. Can you can reproduce the problem with a small clip ? If you can, it might help if you could share that clip with others so they too can try to reproduce the problem.
6. Is your system is overclocked in any way? (If so reset it to the default system speed, to make sure the problem is not caused due to a problem with your system.)
....
other users or a developer might have additional questions, but these should help to get a better grip on the problem.

Cu Selur

[Farfie]

I'm no ffms developer, but here are some basic questions that you might want to answer:

0. What version of ffms are you using? (Have you tried other versions?)
1. You wrote you open x264 8/10bit with open-gop content, is it RAW content or does is reside in a container? If your streams are not raw streams in what container are they?
2. Do you use other filters than ffms.dll in your script? If you do, try to throw these out first to make sure this really is a ffms problem.
3. Are you using 32bit or 64bit Avisynth? What version of Avisynth are you using? (No clue what you call the ' "new" Avisynth thread'.)
4. What is the memory consumption of the Virtual Dub while opening and scrolling through your clip on your system?
5. Can you can reproduce the problem with a small clip ? If you can, it might help if you could share that clip with others so they too can try to reproduce the problem.
6. Is your system is overclocked in any way? (If so reset it to the default system speed, to make sure the problem is not caused due to a problem with your system.)
....
other users or a developer might have additional questions, but these should help to get a better grip on the problem.

Cu Selur

0. r683 x86
1. Raw or in an MKV, the same problem is observed. I could try mp4, but I believe the same thing would happen.
2. This was the first thing I did actually :), but yes, only FFMS is used.
3. I was referring to this http://forum.doom9.org/showthread.php?t=166951&page=2, in which a new Avisynth was released on the 25th of January 2013. I'm not actually sure if it's 32 or 64 bit, but I think it's 32.
4. At first, it uses about 185K, but after it throws an error (typically that seeking is not frame accurate, or "insanity detected: decoder returned an empty frame", in which after that point the whole video is just gray, and the memory goes down to about 51k. It either does this or virtual dub hangs indefinitely until I kill the process.
5. Here we go: opengop testfile (http://www.mediafire.com/download.php?q9fx50it550axzh) SC2 anyone?:D Sorry for the size, but I can't get this working with the aforementioned software. You should be able to reproduce my problem with the newest Avisynth (http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/AVS%202.6.0%20Alpha%204%20%5B130114%5D/AviSynth_130114.exe/download). Of course, I've been there already (the avisynth thread), and they told me to come here because they think this is an ffms problem.
6. My system is overclocked, but it has been this way for a lot of time now. Only with the new avisynth does this exist. I'm fairly positive (given all this new software in this workchain at one time) that the problem is software related, but if someone truly wants me to go stock, I'll do it.

Hope this helps!

[Selur]

file, works fine with the ffms2.dll I use (https://docs.google.com/file/d/0B_WxUS1XGCPAY3NKNXFYX0VOV3c/edit?usp=sharing) (not sure which version it is).

Cu Selur

[Farfie]

file, works fine with the ffms2.dll I use (https://docs.google.com/file/d/0B_WxUS1XGCPAY3NKNXFYX0VOV3c/edit?usp=sharing) (not sure which version it is).

Cu Selur

Well, thanks for the help Selur, my problem has been solved. Those files are a newer version of the ones I was using, and I guess that's the last time I trust MeGUI to keep stuff updated (even using the development update server.)
I realize this isn't really the thread for this, but do you know of any custom servers I could throw in that do a particularly good job of keeping stuff updated?

[Selur]

Nope, sorry. + FFmpegSource filter test versions are always a challenge so I understand that the MeGui folks are probably waiting for the next stable release,..

[Zathor]

Nope, sorry. + FFmpegSource filter test versions are always a challenge so I understand that the MeGui folks are probably waiting for the next stable release,..
Correct. For every build after r683 users have reported various problems (also here in the thread or in the issues list) which is the reason that r683 is still being used.

[qyot27]

With r743+7 (+7 referring to https://github.com/tgoyne/ffms2), I'm getting segfaults when FFMS2 tries to load audio in a script being served to an FFmpeg build that uses the rewritten AviSynth demuxer (https://github.com/qyot27/FFmpeg/commits/avisynth-demuxer6). I reported it on AvxSynth's issues tracker (https://github.com/avxsynth/avxsynth/issues/90) first, and their analysis pointed back at FFMS2. I produced debug builds of both FFmpeg and FFMS2 and re-ran the test, which resulted in a segfault. The backtrace is as follows:
$ gdb -readnow ffmpeg.exe
Reading symbols from c:\dap\vid\Incoming Files\ffmpeg.exe...expanding to full symbols...done.
(gdb) r -i test.avs -vn -acodec ac3 -ab 192k test.ac3
Starting program: c:\dap\vid\Incoming Files\ffmpeg.exe -i test.avs -vn -acodec ac3 -ab 192k test.ac3
[New Thread 3616.0xe18]
ffmpeg version N-50567-g5686652 Copyright (c) 2000-2013 the FFmpeg developers
built on Mar 8 2013 10:53:44 with gcc 4.7.2 (GCC)
configuration: --prefix=/home/qyot27/win32_build --cross-prefix=i686-w64-mingw
32- --enable-gpl --enable-version3 --enable-debug --disable-stripping --enable-a
vresample --disable-w32threads --enable-libutvideo --enable-libxvid --enable-lib
twolame --enable-libmp3lame --enable-libvorbis --enable-libopus --enable-libvo-a
acenc --enable-libvpx --enable-libtheora --enable-avisynth --cpu=pentium3 --extr
a-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW32_STATIC_LIB'
--target-os=mingw32 --arch=x86
libavutil 52. 18.100 / 52. 18.100
libavcodec 54. 92.100 / 54. 92.100
libavformat 54. 63.104 / 54. 63.104
libavdevice 54. 3.103 / 54. 3.103
libavfilter 3. 42.103 / 3. 42.103
libswscale 2. 2.100 / 2. 2.100
libswresample 0. 17.102 / 0. 17.102
libpostproc 52. 2.100 / 52. 2.100
warning: FFMS2 avs plugin: Initializing...
warning: FFMS2 - avs 2.6 mode
Guessed Channel Layout for Input Stream #0.1 : stereo
Input #0, avisynth, from 'test.avs':
Duration: 00:00:15.28, start: 0.000000, bitrate: 0 kb/s
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 848x480, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc
Stream #0:1: Audio: pcm_f32le, 48000 Hz, stereo, flt, 3072 kb/s
Output #0, ac3, to 'test.ac3':
Metadata:
encoder : Lavf54.63.104
Stream #0:0: Audio: ac3, 48000 Hz, stereo, fltp, 192 kb/s
Stream mapping:
Stream #0:1 -> #0:0 (pcm_f32le -> ac3)
Press [q] to stop, [?] for help

Program received signal SIGSEGV, Segmentation fault.
std::__detail::_List_node_base::_M_hook (this=0x5d29fb8, __position=0x5f0f3b8)
at ../../../../../source/gcc-4.7.2/libstdc++-v3/src/c++98/list.cc:132
132 ../../../../../source/gcc-4.7.2/libstdc++-v3/src/c++98/list.cc: No such file or directory.
(gdb) bt
#0 std::__detail::_List_node_base::_M_hook (this=0x5d29fb8,
__position=0x5f0f3b8)
at ../../../../../source/gcc-4.7.2/libstdc++-v3/src/c++98/list.cc:132
#1 0x6f48adc7 in std::list<FFMS_AudioSource::AudioBlock, std::allocator<FFMS_AudioSource::AudioBlock> >::insert (this=0x66aa9d8, __position=..., __x=...)
at /usr/bin/../lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/include/c++/4.7.2/bits/list.tcc:103
#2 0x6ed8eb6c in FFMS_AudioSource::ResampleAndCache (this=0x66aa9c8, pos=...)
at src/core/audiosource.cpp:253
#3 0x6ed8ed8b in FFMS_AudioSource::CacheBlock (this=0x66aa9c8, pos=...)
at src/core/audiosource.cpp:276
#4 0x6ed8f20a in FFMS_AudioSource::DecodeNextBlock (this=0x66aa9c8,
pos=0x22f0c4) at src/core/audiosource.cpp:322
#5 0x6ed8fd9e in FFMS_AudioSource::GetAudio (this=0x66aa9c8, Buf=0x67dc030,
Start=10240, Count=36803) at src/core/audiosource.cpp:412
#6 0x6ed90b20 in FFMS_GetAudio@28 (A=0x66aa9c8, Buf=0x67dc030, Start=2943,
Count=44100, ErrorInfo=0x22f1f8) at src/core/ffms.cpp:215
#7 0x6eda7b50 in get_audio (fi=0x5e33e90, buf=0x67dc030, start=2943,
count=44100) at src/avisynth_c/ff_audsource.c:52
#8 0x10011092 in ?? () from C:\WINDOWS\system32\avisynth.dll
(gdb)

Under normal running conditions, this just results in FFmpeg hanging until I kill the Command Prompt.

It only occurs under particular circumstances. SSRC is what seems to be triggering the problem, as using it with certain framerates sparks the issue. Forcing a different framerate in FFMS2 or via ChangeFPS allows it to work correctly again, as does commenting out SSRC, or using KillVideo.

A sampling of framerates that I tested with. yes = working (even with SSRC), no = hang/segfault

12000/1000 = yes
12000/1001 = yes

15000/1000 = yes
15000/1001 = no

23000/1000 = no #to illustrate an arbitrary fps
23000/1001 = no

24000/1000 = yes
24000/1001 = yes

25000/1000 = yes
25000/1001 = no

30000/1000 = yes
30000/1001 = no

48000/1000 = yes
48000/1001 = no

50000/1000 = yes
50000/1001 = no

60000/1000 = yes
60000/1001 = no

[Plorkyeran]

One of the reasons I haven't committed that patchset to SVN is that it basically only handles the things Aegisub cares about (and Aegisub only asks for audio in large aligned power-of-two blocks, partially to work around various bugs FFMS2 has had). Finishing it up will be one of my top priorities once I have time to work on open-source stuff again, but that won't be for at least another week or two.

[fvisagie]

I'm having trouble seeking in supposedly PAL DVD-compliant MPEG-2 clips encoded by ffmpeg. When I remux in Avidemux, seeking works fine.

Here's a short sample of an original encode (http://www.mediafire.com/file/psrepdvupvv4peg/MPEG-2.mpg). Scrolling forward from frame 0, the display stays frozen and only starts updating from frame 12 (3 frames before the next keyframe). Thereafter scrolling forward works fine.

Scrolling back from the end of the clip, the first problem is that the first frame shown is out of sequence. The next problem is that the display only moves for the 3-4 frames immediately preceding each keyframe in time and otherwise stays frozen.

With the remuxed clip (http://www.mediafire.com/file/5zzs8mo7tpyw54h/MPEG-2_remuxed.mpg), everything works perfectly.

I load the clips with this Avisynth script:

source = "MPEG-2.mpg"
FFIndex(source=source, cachefile=source+".ffindex", indexmask=-1, dumpmask=0, errorhandling=3, overwrite=false)
Audio = FFAudioSource(source=source, track=-1, cache=true, cachefile=source+".ffindex", adjustdelay=-1)
Video = FFVideoSource(source=source, track=-1, cache=true, cachefile=source+".ffindex", seekmode=1, rffmode=0, width=-1, height=-1)
AudioDub(Video, Audio)
Info()


This behaviour is the same for every client app I use - AvsPmod, VirtualDub etc.

Versions:
Avisynth 2.58
FFMS2 r722 (version 2.18 according to the changelog)
Windows 7 Professional 32-bit SP1

Is there something I'm doing wrong? Or any way I can work around this within FFMS2, perhaps an earlier version that doesn't have this problem? Or perhaps an encode setting I can change, bearing in mind it must stay within the PAL spec?

Thanks,
Francois

[fvisagie]

Thanks.

Try using demuxer="lavf" in FFIndex

This makes no difference that I can notice.

and seekmode=-1 in FFVideoSource, though you can't do non-linear access this way.

Also this disables any kind of backward navigation :(. EDIT: for completeness I should mention that I've tried all seekmode options, and all have a problem of sorts.

And, why not use DGDecode for MPEG2 streams?

I'd love an alternative that doesn't require external preparation or work-around. Otherwise I might as well have used the remuxing work-around above.

Can you confirm that you get the same behaviour with these 2 clips?

[Selur]

LWLibavVideoSource first Time I hear of it :) btw. where to get a up-to-date version of LSMASHSource.dll ? (https://code.google.com/p/l-smash/ and https://github.com/VFR-maniac/L-SMASH-Works/tree/master/AviSynth have no downloads; aside from source code)

[fvisagie]

Yes.

Thanks for the confirmation.

One other alternative is LWLibavVideoSource(in LSMASHSource.dll of L-SMASH-Works).

Thanks, I'll try that,

LWLibavVideoSource first Time I hear of it :) btw. where to get a up-to-date version of LSMASHSource.dll ? (https://code.google.com/p/l-smash/ and https://github.com/VFR-maniac/L-SMASH-Works/tree/master/AviSynth have no downloads; aside from source code)

as soon as we get hold of it ;).

I should also mention that even with the demuxing work-around, only seekmode=0 works completely correctly.

According to MediaInfo there are some bitrate-related differences between the original and remuxed files, which I don't have much control over as this was a straight-forward remux. However, the original also has Video delay : -5ms which the remuxed does not have. Getting this to 0 in the encode caused ffmpeg to throw many warnings but didn't help FFmpegSource. I also tried all adjustdelay options without any luck.

The above were all tried with both demuxer="default" and demuxer="lavf".

So I'm looking foward to trying LWLibavVideoSource. :)

[forclip]

One other alternative is LWLibavVideoSource(in LSMASHSource.dll of L-SMASH-Works).Thanks for the info! Nice to know that we have another one source filter for AviSynth :)

P.S. I've found where to download it, but not sure that it is allowed to post link here, so everyone who interested - just ask Google for "LSMASHSource.dll" + "blog-page_17".

[Selur]

Thanks!
I created a new thread for LSMASHSource (https://forum.doom9.org/showthread.php?t=167435), so all LSMASHSource related stuff can be posted there. :)

[Plorkyeran]

With r743+7 (+7 referring to https://github.com/tgoyne/ffms2), I'm getting segfaults when FFMS2 tries to load audio in a script being served to an FFmpeg build that uses the rewritten AviSynth demuxer (https://github.com/qyot27/FFmpeg/commits/avisynth-demuxer6). I reported it on AvxSynth's issues tracker (https://github.com/avxsynth/avxsynth/issues/90) first, and their analysis pointed back at FFMS2. I produced debug builds of both FFmpeg and FFMS2 and re-ran the test, which resulted in a segfault.
Can you upload a complete set of files which reproduces this, including debug symbols? I haven't been able to trigger it, both with and without libavresample support enabled.

[qyot27]

Can you upload a complete set of files which reproduces this, including debug symbols? I haven't been able to trigger it, both with and without libavresample support enabled.
avxtest.7z
http://www.mediafire.com/?rcizx4ur7659djk

Contains a slightly newer build of FFmpeg that still exhibits the issue, the build of FFMS2, video file, and script. Both FFmpeg and FFMS2 have debug symbols. The script shows a sampling of fpsnum and fpsden values which spark the issue when used with SSRC, using the same framerates I mentioned in the previous post. It also shows working framerate/SSRC combinations that are still close to the non-working ones (as in, the difference between a denominator of 1000 vs. 1001).

My initial reason for thinking it was in the demuxer was because disabling the code that does fps/samples calculations in avisynth_read_packet_audio (here (https://github.com/qyot27/FFmpeg/commit/22c97a83d11ef684affdd4588e4dcb86b2e392e6#L1R497)) allows those non-working framerates to work with SSRC (also, the fact that wavi, the old VFW-based AviSynth demuxer, and Windows Media Player 6.4 don't have problems with it in those fps/SSRC combos). But I was told that that is part of the code that keeps video and audio in sync when used together and that it seemed to stem from FFMS2 (and the backtrace I generated did show...something that had FFMS2's audio functions in it).

My testing environment:
Windows XP SP3, 512MBs PC133 SDRAM, 1GHz Celeron Coppermine

[Selur]

I got the following script on this (http://vimeo.com/9810793) clip:
SetMemoryMax(768)
LoadPlugin("G:\Hybrid\avisynthPlugins\ffms2.dll")
Source = FFVideoSource("H:\TESTCL~1\CANONE~1.MOV",cachefile="H:\Temp\165714630mov_deb1536f480475f7d593219aa1afd74c_41.ffindex",fpsnum=29970,fpsden=1000)
SourceFiltered = Source
Source = Source.Crop(0,0,960,1088)
SourceFiltered = SourceFiltered.Crop(960,0,960,1088)
StackHorizontal(Source, SourceFiltered)
return last
when trying to open it with Virtual Dub I get:
Avisynth open failure:
Crop: you cannot use crop to enlarge or 'shift' a clip
(H:\Temp\tempPreviewAvisynthFile08_24_20_176.avs, line 5)

which first confused me until I looked at the MediaInfo output for this file, which contained:
Width : 1 920 pixels
Height : 1 080 pixels
Original height : 1 088 pixels
So from the looks of it, FFVideoSource doesn't return 1920x1088 as I assumed, but 1920x1080.
(so using ',1080)' instead of ',1088)' fixes the imminent problem, but I would prefer it if FFmpegSource would return 1088 lines,..)
-> is this behavior intended?

[LigH]

Probably yes. There are encoders which encode a height of 1088 lines (MOD 16) and store a cropping area of 1080 lines in the header. I remember that DGDecNV and DGAVCDec report something similar for FullHD AVC videos in their info windows while playing [F6].

[Selur]

but DGDecNV&Co only crops to 1080 if 'Options->Always crop 1088->1080' is enabled, since FFmpegSource doesn't have such an option, wouldn't it be more resonable to display the whole 1920x1088 pixels?

[Plorkyeran]

There are encoders which encode a height of 1088 lines (MOD 16) and store a cropping area of 1080 lines in the header.
All encoders do this; it's the only way to encode a non-mod16 resolution. The 8 extra lines are garbage data, and and there shouldn't be any reason to want to see them.

[qyot27]

FFMS2 C-plugin r753 (http://www.mediafire.com/?7le9legt1r2k8lz)

AviSynth/VapourSynth dual plugin
Optimized for Pentium III/SSE fpmath


Regarding the issue from before, I'm starting to think it's very dependent on hardware constraints. The same build of r753 exhibits the issue on my computer (running a [2001] Celeron Coppermine w/ 512MBs of RAM), but does not exhibit it on a [2006] Athlon64 Orleans w/ 2GB of RAM. My first impulse, as stated before, is that it may be some sort of memory size issue that mine gets tripped up on only because of how little I have (similar to the long-standing issue with matroskaparser.c when using any active level of optimization in GCC), the other one is that it may lie somewhere in the floating point math (or how the float stuff actually gets compiled) that the Athlon64 can compensate for but mine can't.

[Abs62]

r753 can't decode flac audio. No errors indicated, but output is empty data.

Upd.
It looks like the BytesPerSample variable don't set if codec return data not in planar format.

[zettai]

r753 and v2.17 have made a change whereby mpeg2 elementary streams are always interpreted as 25fps.

v2.16 works fine.

[qyot27]

No new build of FFMS2, but it does indeed seem that the weird framerate/SSRC issue in ffmpeg truly was in the demuxer as I first thought, because it doesn't do it now. There was recently a fix for the fact that the demuxer was off by one frame (causing the first frame to be truncated and the last frame to be duplicated; another issue was that it was inserting a null frame/sample into the video/audio before real decoding started, but that doesn't seem to be what caused the issue - it was also fixed) and this may have been what underlaid the problem, unless it was just a general libavformat problem that got fixed by some other commit.

[Soliloquy]

Is it possible to read x264's 444 lossless (not 100% on the terms there, hah) with ffms2 or should i be using something else?
Tried using the previously mentioned r753 build in vapoursynth and I get a very green output.

[TheRyuu]

ffms2-2.18-rc1.7z (https://ffmpegsource.googlecode.com/files/ffms2-2.18-rc1.7z)

Includes both 32 and 64-bit compiles.
Requires SSE2 capable CPU and XP SP3 or newer.

Changelog for 2.18:
Fix regression (r483) with rffmode that caused it to error out even if using the default output colorspace. (TheRyuu)
High(er) quality YUV->RGB conversion. (TheRyuu)
Fix indexing on files with cover art. (TheRyuu)
Add support for libav/ffmpeg built with msvc, this is the default on windows when building with msvc. (TheRyuu)
Remove postproc support. (TheRyuu)
Added VapourSynth support. (Myrsloik)
ffmsindex can now output keyframe numbers to a file while indexing. (Plorkyeran)
configure now defaults to building a shared library, except when building MinGW/Cygwin, since you usually want static for those. (Plorkyeran)
The source color space and color range used when converting with swscale can now be overridden. (Plorkyeran)
Fix issues with unicode filenames when building with mingw. (Plorkyeran)
Fix progress reporting when indexing files with non-zero initial timestamp with haali's splitter. (Plorkyeran)
Add support for formats with packet durations but no packet timestamps. (Plorkyeran)
Fix corruption when seeking in VC-1 in MKV. (Plorkyeran)
Fix bug that resulted in files opened with Haali's splitter sometimes always decoding from the beginning on every seek. (Plorkyeran)
Add support for VP8. (Plorkyeran)
Fix crash when indexing video formats with no parser. (Plorkyeran)
Fix compilation errors with recent versions of libav/ffmpeg. (Plorkyeran)
Fix NVOP handling with frame-based threading (aka zero-size frames with mp4 bug). (Plorkyeran)
Add support for vc1image. (Plorkyeran)
Use the container SAR when the codec SAR is unset when opening via lavf. (Plorkyeran)
Actually set the ColorRange and ColorSpace of frames when nothing has been overridden. (Plorkyeran)
Add support for files without timestamps to lavf audio. (Plorkyeran)
Fix handling of audio delay with invalid inital timestamps. (Plorkyeran)
Sort of partially fix interlaced H.264. (Plorkyeran)
Fix errors when the client asks for audio past the end of the file. (Plorkyeran)
Fix rounding error with MKV timestamps that resulted in things getting a FPS like 60001/1001. (TheRyuu)
Bump required version to libav 0.8/FFmpeg 0.9. (Plorkyeran)
Switch to avcodec_decode_audio4. (Plorkyeran)
Add support for planar audio from lavc. (Plorkyeran)
Add SetOutputFormatA for audio resampling/mixing using libavresample. (Plorkyeran)
There may be a few additional things not listed because the changelog wasn't updated yet.

[Abs62]

ffms2-2.18-rc1 don't decode flac audio like r753 (see my post above).
And it hangs after jump back from current frame. It seems the cache iterator "cachePos" in FFMS_AudioSource::GetAudio() becomes invalid after Cache.erase() in FFMS_AudioSource::CacheBlock().

[filler56789]

FFMS2 doesn't support MKVs with RealVideo wrapped in VFW-mode :confused:

Avisynth open failure:
FFVideoSource: video codec not found

Sample file: http://www.mediafire.com/?aab0uxsf55ef9ru

[mastrboy]

Is indexing of larger lossless avi huffyuv been fixed in 2.18-rc1?

Ref former posts:
http://forum.doom9.org/showthread.php?p=1594019#post1594019
http://forum.doom9.org/showthread.php?p=1594170#post1594170
http://forum.doom9.org/showthread.php?p=1595022#post1595022
http://forum.doom9.org/showthread.php?p=1595010#post1595010

[TheRyuu]

Is indexing of larger lossless avi huffyuv been fixed in 2.18-rc1?

Ref former posts:
http://forum.doom9.org/showthread.php?p=1594019#post1594019
http://forum.doom9.org/showthread.php?p=1594170#post1594170
http://forum.doom9.org/showthread.php?p=1595022#post1595022
http://forum.doom9.org/showthread.php?p=1595010#post1595010

Try it.

[mastrboy]

Seems fixed :)
Same amount of frames as the revision before indexing broke on my files when using ffvideosource.
Also backwards seeking seems to have gotten quite a speedup? (at least in avspmod)

[phate89]

Sort of partially fix interlaced H.264. (Plorkyeran)
Hi. Thanks for the work.
One question about the interlaced fix. Can now ffms2 be trusted to be used with interlaced h264? And if it's not are we still far from a reliable implementation?

[henryho_hk]

ffms2-2.18-rc1 don't decode flac audio like r753 (see my post above).

That's really disappointing. :(

Does ffms2 support other lossless audio compression format?

[fvisagie]

I'd also like to understand better about the sort of partially fix. :) Thanks in advance.

[Plorkyeran]

If the entire file alternates between frames with valid and invalid file positions, it skips outputting the frames with invalid positions. This happens to make all of the interlaced h264 files I had lying around appear to decode correctly when linearly decoding with no seeks, but is a pretty awful solution that'll probably break in a bunch of cases. I didn't really test it much.

[Reino]

Requires SSE2 capable CPUWhy? People without a SSE2 cpu are just out of luck now?

[sl1pkn07]

any uses p3 or amd-k7 for encode videos?

[LigH]

Development keeps progressing... ;)

I doubt there are many multi-core CPUs without SSE2 support.

[sl1pkn07]

about SSE2: http://en.wikipedia.org/wiki/SSE2#CPUs_supporting_SSE2

[Wilbert]

any uses p3 or amd-k7 for encode videos?
Yes me, i still use an old athlon ;)

[qyot27]

Since it's been a couple months since the r753 build,

FFMS2 C-plugin r755

Optimized for Pentium III and SSE. The FLAC issue and backwards seeking stuff is the same situation as r753 since neither commit has anything to do with them (r754 was for the autotools buildsystem that the C-plugin doesn't use, r755 fixed building with older point versions of FFmpeg, which is irrelevant to my builds because I always use FFmpeg-git). It does use a two months newer build of FFmpeg, though.

ffmpeg version r53371 git-ac2c521

Configuration:
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--enable-libopus
--disable-decoder=utvideo --enable-libutvideo
--disable-decoder=vp8 --enable-libvpx
--disable-encoders
--enable-avisynth
--disable-muxers
--disable-debug
--disable-network
--disable-hwaccels
--disable-indevs
--disable-outdevs
--cpu=pentium3
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW32_STATIC_LIB'
--target-os=mingw32
--arch=x86

(--enable-avisynth only got used for the novelty of accessing scripts through lavf with x264, not because of anything related to FFMS2)

[Keiyakusha]

I decided to try new ffms2 on bluray m2ts/h264 file. (normally I don't use it for bluray at all)
Uh, am I doing something wrong? Or this is some long-standing bugs still not fixed?
ffms-2.17 (https://dl.dropboxusercontent.com/u/110558786/Comparison/ffms-2.17_004170.jpg)
ffms2-2.18-rc1 (https://dl.dropboxusercontent.com/u/110558786/Comparison/ffms2-2.18-rc1_004170.jpg)

In other words with ffms2-2.18-rc1 (from googlecode) 1st frame after loading is green, after seeking first frame (and few frames after that) is whatever green, with artefacts or in-between.
Without seeking seem to be working, but framerate is wrong.

Edit:
qyot27, link seem to be broken...

[qyot27]

The link should be fixed now. I didn't pay enough attention to how the URL they provide changed to realize the ? was no longer there.

[Plorkyeran]

I decided to try new ffms2 on bluray m2ts/h264 file. (normally I don't use it for bluray at all)
Uh, am I doing something wrong? Or this is some long-standing bugs still not fixed?
ffms-2.17 (https://dl.dropboxusercontent.com/u/110558786/Comparison/ffms-2.17_004170.jpg)
ffms2-2.18-rc1 (https://dl.dropboxusercontent.com/u/110558786/Comparison/ffms2-2.18-rc1_004170.jpg)

In other words with ffms2-2.18-rc1 (from googlecode) 1st frame after loading is green, after seeking first frame (and few frames after that) is whatever green, with artefacts or in-between.
Without seeking seem to be working, but framerate is wrong.

Open GOP and PIR are still not supported. AFAICT the only way to fix them are to either write a custom h264 frame parser or add stuff to the lavc API.

[leoenc]

With 2.18 RC1 and also the above r755, I'm getting access violation errors from VirtualDub when trying to play simple scripts with FFaudioSource.

"Avisynth: access violation at 0x000067B5 in C:\Program Files (x86)\AviSynth 2.5\plugins\ffms2.dll, attempting to read from 0x038C000B"

I have so far tried MKV with DTS, an MKV with AC3, an MXF with PCM.
When it's just FFvideoSource, it works.

Version 2.17 works fine.

[pancserzso]

Hi,

I'd like to ask one question: which one is higher quality:

FFVideoSource( "mts.mts", seekmode = -1, colorspace = "RGB24", resizer = "LANCZOS" )

or

FFVideoSource( "mts.mts", seekmode = -1 )
ConvertToRGB24( matrix = "Rec709", chromaresample = "lanczos" )

[Reino]

Instead of copying the mts-files from the camera's sd-card to your harddrive and using that file for all the editing, I recommend wrapping the mts-file's streams in a Matroska container.
Pretty good chance the default seekmode=1 would be sufficient then, but above all the streams are aligned. Two weeks ago I made some recordings (multiple mts-files) at the wedding of a friend. But afterwards when I tried to splice these recordings, no matter what I tried, I always ended up with the audio out of sync. None of these problems with the footage muxed to mkv.

[raffriff42]

I think I have stumbled in a possible issue in FFMS2.avsi (including the latest version, 2.18-rc1)
FFVideoSource and FFAudioSource are called out of optimum order as per the User Manual (http://ffmpegsource.googlecode.com/svn/trunk/doc/ffms2-avisynth.html)

EDIT - No, they are not out of order, as FFIndex is explicitly called first. Please disregard. :o

[Tima]

Someone, please, share FFMS v2.19 binaries (mostly interested in VapourSynth plugin).

[Overdrive80]

Someone, please, share FFMS v2.19 binaries (mostly interested in VapourSynth plugin).

https://github.com/FFMS/ffms2/releases

[mastrboy]

https://github.com/FFMS/ffms2/releases

Latest binary on that page is still just ffms2-2.18-rc1.7z, though you can get the source code for 2.18 and 2.19, but no binary...

[qyot27]

EDIT 2013-10-04: Newer build here:
http://forum.doom9.org/showthread.php?p=1646661#post1646661

FFMS2 C-plugin r836

Optimized for Pentium III and SSE.

Explanation of the revision number: the difference between trunk and Git's internal revision counting is 67 commits, so it's just the dumb math of running 'git rev-list --count HEAD' on the cplugin_master branch (https://github.com/qyot27/ffms2/commits/cplugin_master) and then adding 67 to it. The short version: ignore the revision number right now, it's caught up to the master branch.

Since FFmpeg got the Opus-in-Matroska stuff sorted out over the last couple days, it's been patched to also be capable of handling that.

Built against ffmpeg version r56269 git-108b91c.

FFmpeg configuration:
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--enable-libopus
--disable-decoder=utvideo --enable-libutvideo
--disable-decoder=vp8 --enable-libvpx
--disable-encoders
--enable-avisynth
--disable-muxers
--disable-debug
--disable-network
--disable-hwaccels
--disable-indevs
--disable-outdevs
--cpu=pentium3
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW32_STATIC_LIB'
--target-os=mingw32
--arch=x86

[TheRyuu]

ffms2-2.19.7z (https://github.com/FFMS/ffms2/releases/download/2.19/ffms2-2.19.7z)

2.19 is the same as 2.18 except it actually compiles outside of msvc, hence the skip to 2.19. See the 2.18 release post (https://github.com/FFMS/ffms2/releases/tag/2.18) for a changelog.

2.19 20130917

Built with MSVC 2012 Update 3:
c99-to-c89 7e75aa9 https://github.com/libav/c99-to-c89
ffmpeg 78f680c http://www.ffmpeg.org/
opencore-amr 0.13 http://sourceforge.net/projects/opencore-amr/
zlib 1.28 http://www.zlib.net

../ffmpeg/configure --enable-gpl --enable-version3 --enable-runtime-cpudetect \
--disable-debug --samples=/f/build/fate-ffmpeg-samples --toolchain=msvc \
--enable-w32threads --enable-avresample --enable-zlib \
--enable-libopencore-amrnb --enable-libopencore-amrwb --disable-inline-asm \
--disable-muxers --disable-encoders --disable-filters --disable-hwaccels \
--disable-network --disable-devices

[qyot27]

EDIT: Newer build available here. (http://forum.doom9.org/showthread.php?p=1650386#post1650386).

FFMS2 C-plugin r783+33

Optimized for Pentium III and SSE. Includes a fix that allows the plugin to work with the current version of AviSynth+. (https://github.com/qyot27/ffms2/commits/cplugin_master)

I've settled on a different method of representing the revision number, which is why the number dropped.

Built against FFmpeg r56888 git-bb9e9ee, has a single patch to avoid crashing on non-SSE2 processors (https://github.com/qyot27/FFmpeg/commits/videodsp_sse_workaround)

FFmpeg configuration:
--cross-prefix=i686-w64-mingw32-
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--enable-libopus
--disable-decoder=utvideo
--enable-libutvideo
--disable-decoder=vp8
--enable-libvpx
--disable-encoders
--enable-avisynth
--disable-muxers
--disable-debug
--disable-network
--disable-hwaccels
--disable-indevs
--disable-outdevs
--cpu=pentium3
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW32_STATIC_LIB'
--target-os=mingw32
--arch=x86

[easyfab]

There is now a native Vp9 and Hevc decoder in ffmpeg, can FFMS2 use this ?

[qyot27]

There is now a native Vp9 and Hevc decoder in ffmpeg, can FFMS2 use this ?
If it's been built against a new enough build of FFmpeg it can. It's more or less automatic (for the lavf demuxer, anyway).


EDIT: Newer build available here. (http://forum.doom9.org/showthread.php?p=1658765#post1658765)

FFMS2 C-plugin r800+29

Optimized for Pentium III and SSE.

Built against FFmpeg r57511 git-8930637:
--enable-gpl
--enable-version3
--disable-w32threads
--disable-ffprobe
--disable-avdevice
--disable-swresample
--disable-postproc
--disable-avfilter
--enable-avresample
--disable-doc
--disable-debug
--disable-encoders
--disable-muxers
--disable-network
--disable-hwaccels
--enable-libilbc
--enable-libopus
--enable-libspeex
--disable-decoder=utvideo --enable-libutvideo
--enable-avisynth
--cpu=pentium3
--extra-cflags="-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW32_STATIC_LIB"
--target-os=mingw32
--arch=x86

[easyfab]

Thanks for the build.

[LigH]

Works with HEVC video in MP4. But due to the complexity of the format, random seeking is a bit unreliable (or just very slow to get decoded to the target?), linear access strongly recommended.

[AlanHK]

When using an MKV source with multiple audio tracks, is there a way to get the native specs?

Often it's obvious, different languages or number of channels, but I have some with with AC3 stereo at a high bit rate and AAC stereo at a low rate. How can I be sure which one I'm decoding?

Or what can reliably give me the same "atrack" number that ffms2 uses and the spec of that track?

[TheFluff]

When using an MKV source with multiple audio tracks, is there a way to get the native specs?

Often it's obvious, different languages or number of channels, but I have some with with AC3 stereo at a high bit rate and AAC stereo at a low rate. How can I be sure which one I'm decoding?

Or what can reliably give me the same "atrack" number that ffms2 uses and the spec of that track?

I thought that ffmsindex would tell you but apparently I was wrong. The API does expose the information as well but apparently there's no way to access it short of writing your own program. I guess we should really add an option of listing all tracks to ffmsindex.

[raffriff42]

>what can reliably give me the same "atrack" number that ffms2 uses and the spec of that track?

This little batch file will. FFprobe.exe (or ffmpeg.exe or ffplay.exe) will list the stream numbers and other information on any file it understands. In limited tests I have found the stream numbers to be compatible with FFMS. I keep this batch file in my Send To folder for quick info on any media file."path\to\ffmpeg\ffprobe.exe" -i "%~dpnx1"
pause

[LigH]

Using libav decoders, FFMS2 is apparently able to decode Lagarith YUV 4:2:0; but Lagarith YUV 4:2:2 fails, according to tests by users in the German doom9/Gleitz forum. But this format is used by some people for e.g. analog capturing or intermediately for interlaced conversions.

Therefore I'd like to put a feature request to get Lagarith YUV 4:2:2 supported too. According to JEEB, it may be possible in conjunction with 4:2:0, if it doesn't differ severely. Provided any developer has enough time and interest in it.

Are there better places to ask for it than here?
__

P.S.:

It is already implemented. Sorry for the noise. The reporter must have used an outdated version...

[Selur]

@qyot27: could you build a current version? Saw 'Fix infinite loop on garbage data at the beginning of AAC files' form 10th of december and wanted to test it.

[qyot27]

@qyot27: could you build a current version? Saw 'Fix infinite loop on garbage data at the beginning of AAC files' form 10th of december and wanted to test it.
Coincidentally, I had built it about 5 hours ago, mostly for having a newer build of FFmpeg.

FFMS2 C-plugin r809+35

Optimized for Pentium-III and SSE.

FFmpeg configuration:
ffmpeg version r59267 git-10a9f33 Copyright (c) 2000-2013 the FFmpeg developers
built on Dec 20 2013 23:42:33 with gcc 4.8.2 (GCC)

configuration:
--prefix=/home/qyot27/win32_build
--cross-prefix=i686-w64-mingw32-
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--disable-doc
--enable-libopus
--disable-decoder=utvideo
--enable-libutvideo
--disable-encoders
--disable-muxers
--disable-doc
--disable-debug
--disable-network
--disable-hwaccels
--disable-indevs
--disable-outdevs
--cpu=pentium3
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW32_STATIC_LIB'
--target-os=mingw32
--arch=x86

EDIT 2014-03-21: Updated build here (http://forum.doom9.org/showthread.php?p=1674530#post1674530)

[Selur]

Nice! Thanks!

[Taurus]

Thank you!

[pandv2]

@qyot27: Thanks for your build.

I replaced an more older oficial build with your build. And my program (a C# program) has stopped working.

After investigation is because:

In the oficial build the functions are exported as: _FFMS_Init@8
But in your build the functions are exported as: FFMS_Init@8, without the initial underscore.

I don't know who is correct, but I would appreciate if both builds can follow the same schema.

Windows like more the schema with the underscore, because I can name the function FFMS_Init and is automatically linked. With your dll i need to add a atributte (EntryPoint="FFMS_Init@8") to each function.

[qyot27]

@qyot27: Thanks for your build.

I replaced an more older oficial build with your build. And my program (a C# program) has stopped working.

After investigation is because:

In the oficial build the functions are exported as: _FFMS_Init@8
But in your build the functions are exported as: FFMS_Init@8, without the initial underscore.

I don't know who is correct, but I would appreciate if both builds can follow the same schema.

Windows like more the schema with the underscore, because I can name the function FFMS_Init and is automatically linked. With your dll i need to add a atributte (EntryPoint="FFMS_Init@8") to each function.
Not possible, because they aren't built with the same compiler. The official builds are compiled with MSVC, the C plugin is compiled with GCC/G++ - while C is coincidentally cross-compatible between the two (as I understand it), C++ is not (http://forum.doom9.org/showthread.php?t=169730). FFMS_Init is defined in the C++ portion of FFMS2's code, so it's affected by the fundamental difference in name mangling (et al.) between G++ and MSVC.

You'll probably just want to stick with the official releases:
https://github.com/FFMS/ffms2/releases

[Plorkyeran]

All of ffms2's public API, including FFMS_Init, is declared as extern "C". GCC just doesn't default to the C name mangling scheme used for Windows DLLs. Building with -fleading-underscore should fix that, but may break loading it as an avs c plugin. If that's the case, a def file is probably required.

[LoRd_MuldeR]

Not possible, because they aren't built with the same compiler.

Well, technically it is possible, I think. Different C++ compilers use different name mangling schemes, which causes this kind of problems. Since there is no official standard for name mangling, no compiler is "wrong" or "correct". But even in C++ code you can use extern "C" to have the function exported with a plain C name. Furthermore, even if you have an existing DLL, you can generate your own import library (.lib) for that DLL using the "lib" tool and a suitable DEF file. Using the DEF file method, the name of the DLL entry point and the corresponding C/C++ symbol name don't have to be the same (which is in contrast to the auto-generated import libraries). So you could do something like:

LIBRARY ffms2.dll
EXPORTS
_FFMS_Init@8=FFMS_Init@8

Plorkyeran was faster ;)

[qyot27]

extern "C" had skipped my mind, sorry.

I'm not sure if -fleading-underscore actually did anything. It still seems to show up sans leading underscore when I check in dllexp.

[Reino]

Lately I've been doing some audiomixing with AviSynth for a videogame's dynamic soundtrack. The soundtrack consists of a lot of small mp3 segments of about 5 to 10 seconds which I initially opened with BassAudioSource(). Last week I decided to have a look if it would make a lot of difference if I would use NicMPG123Source(), or FFAudioSource() instead. These are my findings, after having encoded AviSynth's output with avs2pipemod and takc.exe to TAK:
Sample_BassAudioSource.tak - 477kbps, 4045809 samples
Sample_NicMPG123Source.tak - 478kbps, 3935217 samples
Sample_FFAudioSource.tak - 495kbps, 4045809 samples
Sample_Audacity-2.0.5.tak - 475kbps, 4045809 samples (I've done the mixing before with Audacity)
NicAudio had 'resyncing' issues, but that's another story.
I was wondering if anyone knows if FFAudioSource is adding noise, doing dithering, or anything else that explains the higher bitrate?

[jdobbs]

Coincidentally, I had built it about 5 hours ago, mostly for having a newer build of FFmpeg.

FFMS2 C-plugin r809+35 (http://www.mediafire.com/?ih96amt5vik278b)

Optimized for Pentium-III and SSE.

FFmpeg configuration:
ffmpeg version r59267 git-10a9f33 Copyright (c) 2000-2013 the FFmpeg developers
built on Dec 20 2013 23:42:33 with gcc 4.8.2 (GCC)

configuration:
--prefix=/home/qyot27/win32_build
--cross-prefix=i686-w64-mingw32-
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--disable-doc
--enable-libopus
--disable-decoder=utvideo
--enable-libutvideo
--disable-encoders
--disable-muxers
--disable-doc
--disable-debug
--disable-network
--disable-hwaccels
--disable-indevs
--disable-outdevs
--cpu=pentium3
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW32_STATIC_LIB'
--target-os=mingw32
--arch=x86I tried to use this -- but when I use the LoadPlugin() line I'm getting a message saying "This is not a plugin dll for Avisynth 2.5" (or close to that). Did I miss something?

[qyot27]

I tried to use this -- but when I use the LoadPlugin() line I'm getting a message saying "This is not a plugin dll for Avisynth 2.5" (or close to that). Did I miss something?
LoadCPlugin(), or just make sure that FFMS2.avsi (which also takes care of loading it) is alongside ffms2.dll in the plugins folder.

[jdobbs]

Thanks!

[fvisagie]

I'm having trouble with output from my Canon HF G30. Frames are skipped, returned out of sequence and/or the total frame count seems wrong. I'm using AVS 2.60 Alpha 4 and FFMS2 2.19 with Haali Media Splitter 20130623 installed and configured for OGM and MPEG PS/TS as per the FFMS2 user manual. Testing was done with progressive encoding so if libav still has PAFF issues those shouldn't apply. The camera can be configured for AVCHD and MP4 output formats, but both produce similar errors. Remuxing AVCHD output to MP4 or MKV also does not help.

Following are some example output clips with problem details. The error list is probably not exhaustive, but I'm at least listing what I've found. I'm using this script to simulate and evaluate scrubbing of each clip:

source="AVCHD.MTS"

FFIndex(source=source)
FFMS2=AudioDub(FFVideoSource(source=source, fpsnum=50, fpsden=1), FFAudioSource(source=source)).Subtitle("FFMS2", size=36, align=1).Scrub()

LoadPlugin("C:\Program Files\Haali\MatroskaSplitter\avss.dll")
DSS2=DSS2(source).ConvertToYV12(matrix="PC.709", interlaced=false).Subtitle("DSS2", size=36, align=1).Scrub()

StackVertical(FFMS2, DSS2)

function Scrub(clip c) {
c.ShowFrameNumber(scroll=true, size=36)
Trim(0,11) + Trim(10,10) + Trim(9,9) + Trim(8,8) + Trim(7,7) + Trim(6,6) + Trim(5,5) + Trim(4,4) + Trim(3,3) + Trim(2,2) + Trim(1,1) + Trim(0,-1)
}


AVCHD.MTS (http://www.mediafire.com/download/7tb6q0kmyk3uj2h/AVCHD.MTS) is an untouched AVCHD format recording, and its scrubbed version is scrubbed AVCHD.MTS.avi (http://www.mediafire.com/watch/q7dmvwikfiie1mc/scrubbed%20AVCHD.MTS.avi):
* Frame 0 appears too early in time (i.e. preceding frames aren't shown)
* Rewinding from 10 to 9 the jump is too big and frame 9 is shown twice, and the jump between 6 and 5 is too big
* When the original clip is manually scrolled forward and backward, frames eventually appear closer to the correct time (+/- 4 frames later), but this results in 3 repeated frames at the beginning of the clip. This scrolling forward and backward sometimes causes further frame sequencing problems, even for normal sequential forward access.
* Reverse scrolling from the end of the original clip produces many initial repeats

MP4.MP4 (http://www.mediafire.com/watch/hsg242s1nbi4ai3/MP4.MP4) is an untouched MP4 format recording, and its scrubbed version is scrubbed MP4.MP4.avi (http://www.mediafire.com/watch/nnjxnr0nwd52xpa/scrubbed%20MP4.MP4.avi):
* The first 3 frames are repeats
* Rewinding, frame 9 is out of sequence, the jump from 6 to 5 is too big and the last 3 frames are repeats again
* Manually scrolling forward and backward a larger number of frames than in the script (or repeatedly) seems to remove rewind sequence errors, but the repeated frames at the beginning of the clip remain
* Reverse scrolling from the end of the original clip appears to work correctly, although it seems the last 2 frames aren't shown

AVCHD.MP4 (http://www.mediafire.com/watch/ym7ozxcdqdv4dc3/AVCHD.MP4) was remuxed from AVCHD.MTS with ffmpeg, and its scrubbed version is scrubbed AVCHD.MP4.avi (http://www.mediafire.com/watch/c88g8za3jdjvk2l/scrubbed%20AVCHD.MP4.avi):
* The first 3 frames are repeats
* Rewinding, frame 9 is a duplicate of 7 and the jump between 6 and 5 is too big and the last 3 frames are repeats again
* Manually scrolling forward and backward a larger number of frames than in the script (or repeatedly) seems to remove rewind sequence errors, but the repeated frames at the beginning of the clip remain
* Reverse scrolling from the end of the original clip appears to work correctly, although it seems the last 2 frames aren't shown

AVCHD.MKV (http://www.mediafire.com/download/ceo2p3m7ci4lch8/AVCHD.MKV) was remuxed from AVCHD.MTS with DSMux, and its scrubbed version is scrubbed AVCHD.MKV.avi (http://www.mediafire.com/watch/r45it3hp4zo5jje/scrubbed%20AVCHD.MKV.avi):
* The first 3 frames are repeats
* Reverse scrolling from the end of the original clip seems to correctly show the last frame, except that it is repeated 4 times before being replaced by a new frame

In summary, with this camera's output FFMS2 fared best with the MKV container, the MKV container combination still had problems with starting/ending frame numbers, and to some extent those problems seem to be shared with all combinations tried.

If I'm doing something wrong, please set me straight. Otherwise, I hope this information can assist towards improving FFMS2. I'd be happy to produce more clips and/or tests if necessary.

On the other hand, please feel free to suggest alternatives if you feel that's appropriate. Although remuxing to MKV might seem usable in theory if one is prepared to tolerate start/end inaccuracies, in practice I'm sitting with 450 clips @ 33GB and that just from 1 trip! With other formats I liked FFMS2 for its frame accuracy and video+audio support; from that point of view something like DSS2 isn't ideal either.

Thanks a lot,
Francois

[LigH]

You should not create MKV with ffmpeg, only with mkvmerge. Multiplexers of several formats in ffmpeg are notorious for probably incomplete results, due to the FIFO processing in ffmpeg (output is written only once to allow piping if required). Instead, mkvmerge may be considered as closest to the MKV specs.

I guess you may have interlaced AVC video in your M2TS. This combination used to be the least supported by different software. It may or may not help to limit "threads=1" in FFVideoSource. But using L-SMASH Source may be a more reliable alternative here.

[fvisagie]

You should not create MKV with ffmpeg


Apologies, AVCHD.MKV was in fact remuxed from AVCHD.MTS with Haali Media Splitter's DSMux.

I guess you may have interlaced AVC video in your M2TS.

Valid issue to consider, but I strongly believe that isn't the case here. Apart from the fact that MediaInfo etc. agree with the camera that its output is progressive, with SeparateFields() and VirtualDub's bob doubler (None - alternate fields) I see no field-based motion, and I don't see any interlacing artifacts either.

It may or may not help to limit "threads=1" in FFVideoSource.

Unfortunately that doesn't help here.

But using L-SMASH Source may be a more reliable alternative here.

I'll look into that, thanks.

[Selur]

You could also try FFMS2 C-plugin r809+35 which qyot27 posted; remember LoadCPlugin is needed for this.

[qyot27]

You could also try FFMS2 C-plugin r809+35 which qyot27 posted; remember LoadCPlugin is needed for this.
Technically yes, but not entirely. FFMS2.avsi contains the LoadCPlugin line, so if you keep the .dll and .avsi together in your plugins folder, it'll act as if the C plugin is autoloading. For that matter, Import("path/to/FFMS2.avsi") if they aren't in plugins/ (but still together) would probably accomplish it too.

Or use AviSynth+, since it does allow C-plugins to autoload without any special handling. This could also be read as 'just use AviSynth+ anyway'*.


*Caveat for *nix users: the builds currently don't work in Wine because they were built with VS2012 (with the MT branch, VS2012 is required because of C++11; however, it is possible to build r1576 with VS2010 and that would work in Wine).



The way I understand the state of MPEG-TS remuxing support is that even if you do remux it to MKV with any number of tools, you may still need to remux the MKV with mkvmerge because it could still have issues (or just give the TS file to mkvmerge directly). I seem to remember this being the case with eac3to remuxes needing to be treated with mkvmerge afterward to standardize them. I'm not sure how true any of this still is, though.

[LigH]

The way I understand the state of MPEG-TS remuxing support is that even if you do remux it to MKV with any number of tools, you may still need to remux the MKV with mkvmerge because it could still have issues (or just give the TS file to mkvmerge directly).

For this reason, I recommended the use of mkvmerge so explicitly too. ;)

Interlaced video in Transport Streams seems to have quirks only few tool developers understood well.

[fvisagie]

AVCHD.MKV (http://www.mediafire.com/download/ceo2p3m7ci4lch8/AVCHD.MKV) was remuxed from AVCHD.MTS with DSMux, and its scrubbed version is scrubbed AVCHD.MKV.avi (http://www.mediafire.com/watch/r45it3hp4zo5jje/scrubbed%20AVCHD.MKV.avi):
* The first 3 frames are repeats
* Reverse scrolling from the end of the original clip seems to correctly show the last frame, except that it is repeated 4 times before being replaced by a new frame

You should not create MKV with ffmpeg, only with mkvmerge.

For the sake of completeness, remuxing with mkvmerge instead yields the following:
* The first 3 frames are repeats

Another interesting thing I noticed now is that for the MTS clip FFVideoSource(source=source) would report a frame rate of 49209/1001; for the (mkvmerge) remux it reports a frame rate of 50 and the output is 2 frames longer. As far as I can tell, however, the original MTS clip shouldn't be and isn't VFR.

With DSS2() I also had a surmountable problem (http://article.gmane.org/gmane.comp.multimedia.matroska.devel/4794) with the original MTS clip, which also disappeared with the mkvmerge remux. With DSS2() the mkvmerge remux is 1 frame longer.

I'm still looking into L-SMASH and the FFMS2 C-plugin.

Thanks for the suggestions so far.

[LigH]

Regarding the strange TS framerate, I could imagine that the FFMS2 indexer incorrectly relates the number of (wrongly?) counted frames with the timecode difference between first and last GOPs. One reason may be that not the best matching demuxer was used in the indexing step. You may try to select a specific other demuxer. But as already documented in the FFMS2 AviSynth documentation, FFMS2 simply is not reliable with MPEG TS sources, even when Haali's Media Splitter is installed and used during indexing.

And if even the MKV remultiplexed by a current version of mkvmerge is wrong, then there is certainly a chance that the content of the TS is a little odd; people knowing the quirks of DVB by heart may understand better than me why.

[fvisagie]

One reason may be that not the best matching demuxer was used in the indexing step. You may try to select a specific other demuxer.

Unfortunately none of those improved matters.

But as already documented in the FFMS2 AviSynth documentation, FFMS2 simply is not reliable with MPEG TS sources, even when Haali's Media Splitter is installed and used during indexing.

Sadly my experience seems simply to prove that. I've had identical results (using these inputs) also with FFMS2 C-plugin r809+35, unfortunately.

Thanks for your inputs.

[Selur]

As a side note: LWLibavVideoSource might be also worth a try. (Personally I prefer DGs tools for transportstreams.)

[turbojet]

I've had no luck with ffms2 and ts files.

lwlibavvideosource works great for ts files, it's also very fast compared to the others especially if dr=true (but remember to crop if video padded to mod16).

If you plan on using DSS2 for ts files, best to use dss2mod (https://code.google.com/p/xvid4psp/downloads/detail?name=DSS2%20mod%20%2B%20LAVFilters.7z&can=2&q=) and set lookahead to 100+. It's a self contained dll that doesn't rely on haali.

[fvisagie]

I'm having trouble with output from my Canon HF G30. Frames are skipped, returned out of sequence and/or the total frame count seems wrong.

But using L-SMASH Source may be a more reliable alternative here.

In my testing so far LWLibavVideoSource() works perfectly. On the original M2TS files, without any remuxing or other preparation being required :).

What I find puzzling, though, from LWLibavVideoSource()'s README:
* This function uses libavcodec as video decoder and libavformat as demuxer.
- isn't libav being blamed for FFMS2's problems with MPEG PS/TS?

I've had no luck with ffms2 and ts files.

lwlibavvideosource works great for ts files, it's also very fast compared to the others especially if dr=true (but remember to crop if video padded to mod16).

If you plan on using DSS2 for ts files, best to use dss2mod (https://code.google.com/p/xvid4psp/downloads/detail?name=DSS2%20mod%20%2B%20LAVFilters.7z&can=2&q=) and set lookahead to 100+. It's a self contained dll that doesn't rely on haali.

That's useful input, thanks. I'll look into dr=true and dss2mod also.

[LigH]

The libav libraries have their forks too, and have been developed further ... probably in different ways in different projects. I am not the one with the insight in both FFMS2 and L-SMASH sources. Someone who has may explain where the difference is. But obviously in or close to the MPEG TS splitters used in either.

[lansing]

I'm trying to test ffms2 in both vapoursynth 32bit and 64bit version and ran into problem. Every time I load the same script and switch from virtualdub 32bit and 64bit, it will create a new index file overwriting the old one, and the size of the index files are different. Shouldn't the index be universal among 32bit and 64bit?

[Myrsloik]

I'm trying to test ffms2 in both vapoursynth 32bit and 64bit version and ran into problem. Every time I load the same script and switch from virtualdub 32bit and 64bit, it will create a new index file overwriting the old one, and the size of the index files are different. Shouldn't the index be universal among 32bit and 64bit?

In an ideal world it should. However the index is more or less a dump of internal memory structures so it isn't. Nobody's bothered to try to unify the mess.

[lansing]

In an ideal world it should. However the index is more or less a dump of internal memory structures so it isn't. Nobody's bothered to try to unify the mess.

or at least add a dot extension to differentiate the two, like abc.mkv.32bit.ffindex and abc.mkv.64bit.ffindex, and the filter will know which one to look for onload, so that the index file won't be replacing itself when we switch from 32bit to 64bit program.

[fvisagie]

or at least add a dot extension to differentiate the two, like abc.mkv.32bit.ffindex and abc.mkv.64bit.ffindex

You're probably aware of this, but if you're prepared to script separately for 32 and 64-bit, you can do that yourself. Default parameter value for FFIndex(), FFVideoSource() & FFAudioSource():

string cachefile = source + ".ffindex"

[lansing]

You're probably aware of this, but if you're prepared to script separately for 32 and 64-bit, you can do that yourself. Default parameter value for FFIndex(), FFVideoSource() & FFAudioSource():

string cachefile = source + ".ffindex"


that will lose the point of auto detect and one script for both version.

[icezellion]

As a side note: LWLibavVideoSource might be also worth a try. (Personally I prefer DGs tools for transportstreams.)

DGAVCDec completely fails on particular AVC transport streams. In this case, FFVideoSource works perfectly. For MPEG-2 transport streams I still use DGMPGDec though. Haven't bothered to use anything else since it still seems to do the job (I don't have a Nvidia GPU). I'm always open to trying other source filters as long as they process transport streams properly, and provide some additional benefit.

[LigH]

DGAVCDec is outdated anyway, using an obsolete version of libavcodec which did not even support PAFF interlacing yet (it was just one of the few frame-accurate versions cooperating with the DG*Dec framework).

Selur rather refers to current hardware accellerated tools like DGDecNV/IM. But yes, they require specific video decoder chips (Nvidia / intel Core i). "L-SMASH Works" does not, and is very reliable too (more than FFMS2, even with Haali support, regarding TransportStreams). And in addition, there is a DSS2Mod filter which can also use a local copy of LAV Filters natively (it doesn't need to be installed as DirectShow filters).

The alternative, to use FFMS2 rather reliably, is to multiplex TS to MKV using mkvmerge.

[qyot27]

FFMS2 C-plugin r827+36-avs+vsp

Optimized for Pentium-III and SSE.

FFmpeg r61474 git-d1bb179, built on Mar 14 2014 22:33:23 with gcc 4.8.2 (GCC):
configuration:
--prefix=/home/qyot27/win32_build
--cross-prefix=i686-w64-mingw32-
--disable-doc
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--enable-libopus
--disable-decoder=utvideo
--enable-libutvideo
--disable-encoders
--disable-muxers
--disable-doc
--disable-debug
--disable-network
--disable-hwaccels
--disable-indevs
--disable-outdevs
--cpu=pentium3
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW32_STATIC_LIB'
--target-os=mingw32
--arch=x86

EDIT 2014-05-22: Updated build here. (http://forum.doom9.org/showthread.php?p=1681399#post1681399)

[LigH]

:thanks:

Here an excerpt from the changelog since v2.18:

2.20

Add support for Opus in MKV when ffmpeg/libav are built with libopus (qyot27)
vapoursource: Provide _AbsoluteTime metadata (Daemon404)
Fix a pile of small things found by Coverity (Daemon404)
Add support for HEVC in MKV (qyot27)
Fix infinite loop on garbage data at the beginning of AAC files (Plorkyeran)
Deal with the never-ending bitrot from FFmpeg/Libav API changes (Daemon404, Plorkyeran)
Make indexes not arch-specific and trivially smaller (Plorkyeran)

[icezellion]

Thanks :) Is it possible for me to provide FFMS2 developers a 60 second H264 TS file (from Sky HD)? I haven't had any issues so far, and I think the issue is likely due to where the file was trimmed at with VideoReDo. Basically at the start of the encoded result, the video pauses for perhaps a second or two, but aside that everything else is perfect. I am doubtful it's a FFMS2 issue though, since all the other recordings from have been more or less perfect (and more of an issue where it was cut at).

[Taurus]

@qyot27
:thanks: for sharing

[Boulder]

I just get a "Unable to load C Plugin" error with that one :( ffms2.dll is in the Avisynth plugins folder along with the ffms2.avsi script.

[LigH]

Is your 7-zip outdated (older than version 9.20)? It seems to happen often for different people who use a 3rd-party unpacker which uses a 7-zip DLL from a stable but obsolete version. Since Version 9.20 beta, 7-zip prefers an improved LZMA2 algorithm for multithreading, which can't be unpacked reliably with older versions, but they are not able to detect the difference.

[Boulder]

Nope, seems to be v9.20.

Digging some older threads revealed that "As for the 0x7E error, as IanB said, you seem to be missing a CPP runtime." So which runtime is required? I have quite a few of them installed but not the correct one, it seems.

[LigH]

There is only one reference to MSCVRT.DLL in it. No version.

But I also had error 0x7e when I mistyped the directory where to load the DLL. Check it over. Don't rely on autoloading.

[Boulder]

I did that too, putting the dll file to a separate directory and edited the script accordingly.

My msvcrt.dll is dated 16.12.2011 if that's of any help.

[qyot27]

The C plugin doesn't rely on a specific msvcrt, because it was built with GCC. Or rather, it ties it to the generic msvcrt that MinGW-w64 assumes the use of.

The 7z archive was actually packed with 9.32 alpha, so that might have an impact beyond the LZMA2 situation (or maybe not).

C-plugins autoload under AviSynth+ (making the following explanation a moot point), but under 2.5 and 2.6 they do not autoload, which is the reason that LoadCPlugin("ffms2.dll") is included in FFMS2.avsi (it merely mimics autoloading, and being tied to the relative position of the .dll is why it has to be in the same folder in order to work).

[LigH]

I have it installed in a sub-directory below AviSynth 2.5\plugins, so it is not auto-loadable even if it was a generic AviSynth 2.5+ plugin (other not VapourSynth compatible FFMS2 builds were compiled in this format).

In one of my last scripts, I only imported FFMS2.avsi from this sub-directory, and the plugin was correctly loaded by its integrated LoadCPlugin command in AviSynth MT 2.60 a5.

But while I mistyped the directory where to load the import (or the plugin explicitly), I got the "could not load plugin" error 0x7e too.

[Zathor]

There seems to be a memory leak in the ffms2_r827+36-avs+vsp plugin. When opening and closing a script in VirtualDub or MeGUI the memory will be increased during every loop. This happens with AVS 2.5.8 and AVS+ r1576 - but not with FFMS 2.19.

Also I get sometimes the message that it has been tried to read unprotected memory (even at the first loop). 2.19 is rock stable in my environment.

Script is e.g.:
LoadCPlugin("C:\MeGUI\tools\ffms\ffms2.dll")
FFVideoSource("C:\test.mkv", fpsnum=24000, fpsden=1001, threads=1)

Anyone else observing this?

[Boulder]

I have it installed in a sub-directory below AviSynth 2.5\plugins, so it is not auto-loadable even if it was a generic AviSynth 2.5+ plugin (other not VapourSynth compatible FFMS2 builds were compiled in this format).

In one of my last scripts, I only imported FFMS2.avsi from this sub-directory, and the plugin was correctly loaded by its integrated LoadCPlugin command in AviSynth MT 2.60 a5.

But while I mistyped the directory where to load the import (or the plugin explicitly), I got the "could not load plugin" error 0x7e too.
I got the plugin working, I had to create a folder outside the Avisynth plugins folder and put ffms2.dll there and edit the path accordingly. I don't know why using a folder called "cplugins" under the plugins folder and loading it from there didn't work.

Zathor: I've observed some errors with VirtualDub when using F2 to reload the script, maybe they are related.

[qyot27]

Okay, I can reproduce the memory increases with the C-plugin, but not with MSVC 2010 builds of r827. Using AviSynth+ r1695. What this means is that I actually need to do more digging:
*It could be a problem in FFMS2's AviSynth C code.
Does it happen with previous builds of the C plugin?

*It could be a compilation problem in either FFmpeg, or FFMS2.
This means I'll have to experiment with the build options. If it lies in here, I have an idea of what might be the issue based on the instructions given in FFMS2's documentation.

*It could be a problem in FFmpeg that may have affected the particular revision r827+36 was built against, and it's since been corrected.
Again, requires a newer or different build to show that it only cropped up recently.

*It could be a problem inherent to AviSynth's C interface, in which case it needs to be fixed in AviSynth+.
This just means it needs to be reported upstream.


I'll admit that I never encountered a problem with this (despite being on a setup with only 512 MBs of RAM) because I don't usually close and re-open scripts repeatedly.


I'll go ahead and post the MSVC 2010 test build:
ffms2_r827-msvc2010.7z (http://www.mediafire.com/?6phncxgalxxwtd3)

ffmpeg version N-61679-g87ecefd Copyright (c) 2000-2014 the FFmpeg developers
built on Mar 22 2014 04:25:45 with Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86
libavutil 52. 67.100 / 52. 67.100
libavcodec 55. 52.102 / 55. 52.102
libavformat 55. 34.101 / 55. 34.101
libavdevice 55. 11.100 / 55. 11.100
libavfilter 4. 3.100 / 4. 3.100
libavresample 1. 2. 0 / 1. 2. 0
libswscale 2. 5.102 / 2. 5.102
libswresample 0. 18.100 / 0. 18.100
libpostproc 52. 3.100 / 52. 3.100

configuration:
--toolchain=msvc
--enable-gpl
--enable-version3
--enable-avresample
--disable-encoders
--disable-muxers
--disable-doc
--disable-debug
--disable-network
--disable-hwaccels
--disable-indevs
--disable-outdevs
--extra-cflags=-I/msinttypes
It lacks Opus decoding support because I couldn't manage to get FFmpeg to see libopus when using --toolchain=msvc, despite trying both an MSVC build of libopus and a normal GCC build of it, and fiddling with the extra-cflags/ldflags and whatnot. Something more is required here.

It is a slightly newer build of FFmpeg, though, as I'd actually built it for LSMASHSource.

[Zathor]

Thank you very much for your work.

I can confirm that the MSVC plugin does not have the problem. But I have to make more test runs over the next days. I usually encounter the problem when I convert ~30 videos with MeGUI as for every file encoding the script will be opened and closed ~10 times (fps detection, cropping, automatic deinterlacing, ...) - likely this is not needed and could be optimized in the MeGUI process but it should work the way it is and is a good detection of plugin problems ;)

I cannot test it with old C plugins. Do you have an older build available? You have modified your last post here so that the download is not available anymore. But if I remember correctly I had a similar problem with it (the cannot write protected memory error) and that was the reason why I had not added it to MeGUI.

[sqrt(9801)]

I just get a "Unable to load C Plugin" error with that one :( ffms2.dll is in the Avisynth plugins folder along with the ffms2.avsi script.

Got the same error when trying to open a script in VirtualDub v1.10.4. It looks like getting rid of FFInputDriver solves the issue, somehow.

[qyot27]

I cannot test it with old C plugins. Do you have an older build available? You have modified your last post here so that the download is not available anymore. But if I remember correctly I had a similar problem with it (the cannot write protected memory error) and that was the reason why I had not added it to MeGUI.
C-plugin builds of 2.16 and 2.17 are available from the Google Code site:
https://code.google.com/p/ffmpegsource/downloads/list?can=1&q=cplugin&colspec=Filename+Summary+Uploaded+ReleaseDate+Size+DownloadCount

I didn't build them, but if those show the issue, then it'll at least show that it's not something recent.

My own limited tests still show it with a brand new FFmpeg, so it's not that, and the -D_SYSCRT option mentioned in the FFMS2 docs didn't seem to have an effect.

This narrows it down to it being in the C plugin, it being a problem with AviSynth's C interface itself, or something that occurred to me yesterday, a side-effect of linking in a static version of libgcc (which could explain why the memory increase happens in roughly equal chunks, although I'm not sure why that would result in memory not being freed when the script closes, aside from the fact that VirtualDub keeps AviSynth.dll and DevIL.dll loaded even after the user closes the script).

The solution for that last one is pretty straightforward, but it's a lot more inconvenient (since it requires re-compiling my entire MinGW-w64 cross environment and the entire dependency chain for FFmpeg*, and then distributing libgcc_s.dll as a system lib with the FFMS2 package).

*well, I'd run the test in a VM, but if this is really the source of the problem, normal builds with a shared libgcc would have to wait until mid-April (I recompile my cross environment every six months anyway, after upgrading to the newest release of Ubuntu).

[Zathor]

C-plugin builds of 2.16 and 2.17 are available from the Google Code site:
https://code.google.com/p/ffmpegsource/downloads/list?can=1&q=cplugin&colspec=Filename+Summary+Uploaded+ReleaseDate+Size+DownloadCount

I didn't build them, but if those show the issue, then it'll at least show that it's not something recent.
Yes, based on my limited tests both builds also have the same problem. I can see a more or less constant memory increase. :(

[qyot27]

As an update, my attempt at using a shared version of GCC (by simply installing the repository version of the MinGW-w64 toolchain in 14.04 beta) crashed and burned. Even with the requisite dlls present for FFMS2/ffmsindex to rely on, it ended up failing to index immediately, even though it didn't crash. I still need to test with Clang, though.

[Zathor]

I am using ffms2_r827-msvc2010 now for nearly 2 weeks and had not a single problem and especially no memory problem. So thank you very much for this build!

[LigH]

Other users in the german doom9/Gleitz board report a wrong audio skew in certain cases, like this sample (http://www.file-upload.net/download-8750103/Comp.rar.html) (40 MB).

This file is reported to have a negative delay (http://forum.gleitz.info/showthread.php?46901&p=443748#post443748), which FFMS2 apparently tries to respect by stuffing the audio stream, but the duration seems to be incorrect, 23 ms missing.

[sneaker_ger]

To add more info, timecodes of the sample:
track_ID: 1
Media timescale: 3000
DTS = 0, CTS = 0
DTS = 100, CTS = 100
DTS = 200, CTS = 200
DTS = 300, CTS = 300
[...]
DTS = 22200, CTS = 22200
DTS = 22300, CTS = 22300

track_ID: 2
Media timescale: 44100

Edit box of the video track:
[edts: Edit Box]
position = 248
size = 36
[elst: Edit List Box]
position = 256
size = 28
version = 0
flags = 0x000000
entry_count = 1
entry[0]
segment_duration = 21750
media_time = 598
media_rate = 1.000000

Both duration and sync seem to be off, but I'm not sure I interpreted the edit box correctly (negative video delay 598s/3000?).

[Overdrive80]

Possible bug in ffvideosource??? http://forum.doom9.org/showthread.php?p=1679175#post1679175

[Myrsloik]

Possible bug in ffvideosource??? http://forum.doom9.org/showthread.php?p=1679175#post1679175

No, not at all. Because of these reasons:

1. The two scripts are not equivalent, which is evident since you need assumefps() in there at all
2. Seeking in demuxed video streams is never accurrate
3. Seeking in mpeg-ish containers usually doesn't end well either
4. Why megui is adding vfr to cfr conversion to every ffvideosource call is also a bit of a mystery

[Overdrive80]

Ok, thanks for you answer.

[hello_hello]

Possible bug in ffvideosource??? http://forum.doom9.org/showthread.php?p=1679175#post1679175

No, not at all. Because of these reasons:

I did some more testing. It does appear to be a ffmpegsource bug.

1. The two scripts are not equivalent, which is evident since you need assumefps() in there at all

assumefps() wasn't needed. It was just a test.

4. Why megui is adding vfr to cfr conversion to every ffvideosource call is also a bit of a mystery

I think it's a good idea, because the input is expected to be CFR.
I tested the sample myself and it appears to only be a problem when the video is in an AVI created by VirtualDub(Mod) and the frame rate is 23.976 (well the only other frame rate I tested was 25fps and that was fine). If you take the AVI created by VirtualDubMod and remux it with avimux, the problem goes away, as it does if you remux as an MKV and index, so (not understanding how it works myself) there appears to be some sort of frame rate miscommunication going on between VirtualDub created AVIs and ffmpegsource.

[foxyshadis]

Numerator/Denominator overflow? Does the import use 32-bit arithmetic? Avisynth used to export enormous fractions that required 64-bit arithmetic to properly handle, until it was changed in 2.5.7 or 2.5.8 to recognize certain common numbers and reduce the rest. Any old files from before then will still have the bad behavior, at least until remuxed by something that'll reduce the fractions.

[hello_hello]

Numerator/Denominator overflow? Does the import use 32-bit arithmetic?

I vaguely understand what you're saying but I don't know how to check that.

The file in question was created via Avisynth 2.6.0.4, at least in my case. I also tried AviSynth+ 2.6.0.5 portable with the same result.
I originally thought it was a VirtualDub problem but after testing a little more I think I was wrong. If I create the AVI using MeGUI (the writing application is Lavf55.33.100) the same problem occurs. The encoder used seems to make no difference. I've tried Lagaryth, huffyuv and Xvid.

For whatever reason remuxing the AVI with Avimux fixes the problem. As does remuxing as an MKV with MKVMergeGUI. Remuxing with VirtualDub doesn't fix the problem.

Adding fpsnum and fpsden to each script seems like a good idea to me. That way the frame rate is always constant and should help prevent audio sync problems. If the frame rate is constant in the first place, adding them should make no difference.
It's one of the reasons I use ffvideosource in preference to LSmash, which doesn't (as far as I know) have a similar frame rate conversion function.

[hello_hello]

While we're on the subject, here's a sample of an instance where adding fpsnum and fpsden to a script is a good idea. Aside from one missing/duplicate frame, the video is constant frame rate, 25fps. Without fpsnum and fpsden in the script, ffvideosource outputs a total of one frame less, and a frame rate of 24.971fps (it seems to output the average frame rate). Lsmash does likewise, with no way to tell it not to. AviSource/DirectShowSource "get it right" and output the correct number of frames and the correct frame rate.

I don't quite understand why ffvideosource and LSmash don't output the same as AviSource by default, so fpsnum and fpsden wouldn't be required. Without them, I think the only way to encode the video "correctly" would be to extract the timecodes from the original file and use them when remuxing the encoded version. By adding fpsnum and fpsden to each script, MeGUI eliminates the need for doing so and the encoded version has a "constant frame rate".

http://ge.tt/6fbWjpe1/v/0

[qyot27]

FFMS2 C-plugin r892+41

Optimized for Pentium-III and SSE.

FFmpeg r63367 git-f932e5f, built on May 22 2014 03:46:47 with gcc 4.9.0 (GCC):
libavutil 52. 86.100 / 52. 86.100
libavcodec 55. 63.100 / 55. 63.100
libavformat 55. 40.100 / 55. 40.100
libavdevice 55. 13.101 / 55. 13.101
libavfilter 4. 5.100 / 4. 5.100
libavresample 1. 2. 0 / 1. 2. 0
libswscale 2. 6.100 / 2. 6.100
libswresample 0. 19.100 / 0. 19.100
libpostproc 52. 3.100 / 52. 3.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-network
--disable-hwaccels
--disable-indevs
--disable-outdevs
--cpu=pentium3
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW32_STATIC_LIB'
--target-os=mingw32
--arch=x86
--optflags=-O0

There's now a native Opus decoder in libavcodec, so there's no longer a need to link to libopus just for that.


EDIT 2014-06-29: Updated build here. (http://forum.doom9.org/showthread.php?p=1685186#post1685186)

[zinga]

Hi, just wondering, are 64-bit Windows builds available from anywhere?
A number of builds used to be provided on the Google Code page, but they're now rather outdated.
Thanks.

[LigH]

The original AviSynth 2.x did not continue the development of its 64-bit core version, which was left in a quite unstable state, therefore only few plugins were made for that platform.

Now with AviSynth plus, development appears to be rather equal for both 32-bit and 64-bit architectures, therefore support for both may be more useful again.

[foxyshadis]

Thanks qyot27, so far this is the only way I can decode HEVC. (Even the command-line fails usually.) It works great.

[jackoneill]

--optflags=-O0


Say, doesn't that disable compiler optimisations?

[qyot27]

Say, doesn't that disable compiler optimisations?
Yeah, although it's mostly to avoid the flacdec issues (http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=13&t=1960) caused by using -O2 with GCC 4.9.0 (it's fixed in the 4.9.1 prerelease branch).

I've not done any performance testing to see how much impact GCC's optimizations really have (generally, -O0 gets used with debug builds, so it may just be simpler to compare debug and release builds for any performance gap).

[qyot27]

FFMS2 C-plugin r927+41

Optimized for Pentium-III and SSE.

ffmpeg version r64300 git-f02a440 Copyright (c) 2000-2014 the FFmpeg developers
built on Jun 28 2014 22:59:08 with gcc 4.9.0 (GCC)
libavutil 52. 90.101 / 52. 90.101
libavcodec 55. 68.100 / 55. 68.100
libavformat 55. 44.100 / 55. 44.100
libavdevice 55. 13.101 / 55. 13.101
libavfilter 4. 9.100 / 4. 9.100
libavresample 1. 3. 0 / 1. 3. 0
libswscale 2. 6.100 / 2. 6.100
libswresample 0. 19.100 / 0. 19.100
libpostproc 52. 3.100 / 52. 3.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-network
--disable-hwaccels
--disable-indevs
--disable-outdevs
--cpu=pentium3
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW32_STATIC_LIB'
--target-os=mingw32
--arch=x86
--optflags=-O0

EDIT 2014-07-30: Updated build here. (http://forum.doom9.org/showthread.php?p=1688398#post1688398)

[Sm3n]

@qyot27 Your plugin ain't compatible with avisynth, right? Quote: ...ffms2.dll is not an AviSynth 2.* plugin.
First time I use one of your mod. I use Avisynth MT (x86 on win 8.1 x64).

Besides, I would like to display this kind of info:

http://i.imgur.com/LdAhVDQ.png

"Quantizer" and "QPEL" things in particular. I know there is a ffms2mod (ffinfomod) existing but can't find it.
Maybe someone could help me.

Cheers.

[Selur]

Your plugin ain't compatible with avisynth, right?
It's an avisynth C-plugin -> you need to use LoadCPlugin(...) instead of LoadPlugin(...)

[Taurus]

@qyot27 Your plugin ain't compatible with avisynth, right? Quote: ...ffms2.dll is not an AviSynth 2.* plugin.
First time I use one of your mod. I use Avisynth MT (x86 on win 8.1 x64).
Did you copy FFMS2.avsi, ffmsindex.exe and finally ffms2.dll to your plugin folder?
If yes FFMS should start right out of the box.
If no follow Selur's suggestion.
Or read into the FFMS2.avsi.
It's self explaining....:D

Oh, by the way:
Thanks gyot27 for sharing:thanks:

[Reel.Deel]

Another option is to download the very recently released v2.20: https://github.com/FFMS/ffms2/releases/tag/2.20

This one is not a C-plugin so it loads like a regular plugin either by placing it in the Avisynth plugins folder (autoload) or explicitly using LoadPlugin(...).

[Sm3n]

It's an avisynth C-plugin -> you need to use LoadCPlugin(...) instead of LoadPlugin(...)
What a shame :o

Did you copy FFMS2.avsi, ffmsindex.exe and finally ffms2.dll to your plugin folder?
I didn't copy ffmsindex.exe but in fact I don't need it, just by adding "C" like Selur said, it works.


Thx everyone!

[Groucho2004]

Besides, I would like to display this kind of info:

http://i.imgur.com/LdAhVDQ.png

"Quantizer" and "QPEL" things in particular.
Avisynth doesn't know about these properties.

[phate89]

Another option is to download the very recently released v2.20: https://github.com/FFMS/ffms2/releases/tag/2.20

This one is not a C-plugin so it loads like a regular plugin either by placing it in the Avisynth plugins folder (autoload) or explicitly using LoadPlugin(...).

what's the difference between the 2 versions?

[Reel.Deel]

what's the difference between the 2 versions?
From GitHub description (versions and variants) (https://github.com/FFMS/ffms2#versions-and-variants):

avs-cplugin: Variant of the Avisynth plugin written in C. Primary purpose is to get access to the new colorspaces available in Avisynth 2.6.

[phate89]

From GitHub description (versions and variants) (https://github.com/FFMS/ffms2#versions-and-variants):

avs-cplugin: Variant of the Avisynth plugin written in C. Primary purpose is to get access to the new colorspaces available in Avisynth 2.6.


Thanks. About the "Optimized for Pentium-III and SSE" does it change anything for newer cpus?

[Sm3n]

Avisynth doesn't know about these properties.

AFAIK I see a lot of screenshots with the "B Qpel" frametype. But "Quantizer" I never seen that before today.
My first thought was it's subtitles but I don't think so.

If you say that Avisynth doesn't know that, I can just trust you on this.

[Boulder]

I'd like to compile FFMS2 to test various optimizations (just for the heck of it), but my MinGW/MSYS installation is missing some packages. This is what I get in the config.log:

No package 'libavformat' found
Package libavcodec was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavcodec.pc'
to the PKG_CONFIG_PATH environment variable

I've used the MinGW package provided by XhmikosR (http://xhmikosr.1f0.de/tools/) which I also use for compiling x264.

Can anyone point me to the right direction regarding where or how to get those missing packages (libavcodec, libswscale, libavutil, libavformat)?

[TheFluff]

Avisynth doesn't know about these properties.

FFMS2 does, though, and exports some info to Avisynth variables. Use FFInfo() (from ffms2.avsi) and it'll print the info on the video. Quantizer info is not exported though, just frame type.

[poisondeathray]

AFAIK I see a lot of screenshots with the "B Qpel" frametype. But "Quantizer" I never seen that before today.
My first thought was it's subtitles but I don't think so.

If you say that Avisynth doesn't know that, I can just trust you on this.

It's ffdshow's OSD . You can display the overlay in avisynth if you use DirectShowSource() with ffdshow configured as the directshow decoder, and the OSD enabled . (but beware of DSS issues, frame accuracy etc....) .

[Reel.Deel]

@Boulder

Have you read these compilation notes? https://github.com/FFMS/ffms2/blob/master/doc/ffms2-api.md#compilation

[Boulder]

Thanks, I'll take a look.

[qyot27]

Thanks. About the "Optimized for Pentium-III and SSE" does it change anything for newer cpus?
That only actually applies to the optimizations applied to the C and C++ code, not the assembly optimizations that exist in libavcodec. It also wouldn't affect libavcodec's runtime cpu detection of higher CPUs.

The current caveat with the C plugin is that, due to a bug in GCC 4.9.0, I have to use -O0 when building FFmpeg (which defaults to -O2 otherwise). This will get resolved once the final release of GCC 4.9.1 is released and I regenerate the toolchain I use to build everything.

I'd like to compile FFMS2 to test various optimizations (just for the heck of it), but my MinGW/MSYS installation is missing some packages. This is what I get in the config.log:

No package 'libavformat' found
Package libavcodec was not found in the pkg-config search path.
Perhaps you should add the directory containing `libavcodec.pc'
to the PKG_CONFIG_PATH environment variable

I've used the MinGW package provided by XhmikosR (http://xhmikosr.1f0.de/tools/) which I also use for compiling x264.

Can anyone point me to the right direction regarding where or how to get those missing packages (libavcodec, libswscale, libavutil, libavformat)?
The builds I provide are cross-compiled, but on Windows I would now recommend relying on msys2 (https://msys2.github.io) rather than the old msys and various MinGW-w64 packages. First and foremost because it provides properly up-to-date versions of the software involved. It also provides its own package management (a port of Arch Linux's pacman), and you can pull in everything - or nearly everything - necessary from inside of it. And since it's managed, it's easier to keep updated. The GCC that it provides actually is one of the incremental updates from the 4.9.1 prerelease branch, so it would be unaffected by the bug I mentioned above.

As mentioned by the Compilation guide on FFMS2's wiki, GCC cannot be used to compile the AviSynth (C++) plugin in the master branch, although it can build the regular library that you could then link against x264. The C++ plugin can only be built by MSVC if you want it to actually, you know, work.

[Sm3n]

It's ffdshow's OSD . You can display the overlay in avisynth if you use DirectShowSource() with ffdshow configured as the directshow decoder, and the OSD enabled . (but beware of DSS issues, frame accuracy etc....) .

I've read something about OSD I remember. But I don't know what it is.
I'll take a look. Sure I don't want any issues so I think the best option is FFvideosource, no matter if I don't have these displayed options... It's good to know anyway.

Cheers.

[Selur]

btw. FFmpegSource crashes for me when fed with mkv(vp9) content, LibAVVideo works fine.

[qyot27]

btw. FFmpegSource crashes for me when fed with mkv(vp9) content, LibAVVideo works fine.
I tested with the VP9 sample provided here:
http://www.reduser.net/forum/showthread.php?111230-Google-VP9-4K-HD-Sample

And while my old Celeron is not up to the task of seeking around in there, the script would open in VirtualDub and display actual video.

The caveat: FFMS defaults to trying to use the Haali Matroska demuxing code. And that did crash, right at the end of indexing - 99% and boom, crash. But forcing it to use lavf as the demuxer (-m lavf or demuxer=lavf) allowed the index to be written without crashing and then as I said, I was able to open it in VDub.

[Selur]

adding '-m lavf' fixes the problem, thanks :)

[kaefert]

I'm trying to get a "newer" mov file created by an Canon SX230HS camera into avisynth. It looks a lot like a h264 mp4, and it loads fine with
AudioDub(FFVideoSource(X1), FFAudioSource(X1))

But I get a lot of bad artefacts.
Sample including script + encoding + log:
http://koega.no-ip.org/misc/avisynth_load-mov/

How do I get rid of those artefacts? Opening the MOV source in any video player doesn't show any artefacts for me.

UPDATE: SOLVED: simply take the newest version of FFMS2 (ffms2-2.20-icl.7z) from https://github.com/FFMS/ffms2/releases ;)

[pandv2]

But this version doesn't works with accents and foreign chars in the path o file name.

It's dificult to find the perfect version, but thanks for all the efforts.

[qyot27]

FFMS2 C-plugin r931+50

Optimized for Pentium-III and SSE.

ffmpeg version r65087 git-65746bf Copyright (c) 2000-2014 the FFmpeg developers
built on Jul 29 2014 07:21:26 with gcc 4.9.1 (GCC)
libavutil 52. 92.101 / 52. 92.101
libavcodec 55. 71.100 / 55. 71.100
libavformat 55. 49.100 / 55. 49.100
libavdevice 55. 13.102 / 55. 13.102
libavfilter 4. 11.102 / 4. 11.102
libavresample 1. 3. 0 / 1. 3. 0
libswscale 2. 6.100 / 2. 6.100
libswresample 0. 19.100 / 0. 19.100
libpostproc 52. 3.100 / 52. 3.100

configuration:
--prefix=/home/qyot27/win32_build
--cross-prefix=i686-w64-mingw32-
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--disable-doc
--disable-encoders
--disable-muxers
--disable-doc
--disable-debug
--disable-network
--disable-hwaccels
--disable-indevs
--disable-outdevs
--cpu=pentium3
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW32_STATIC_LIB'
--target-os=mingw32
--arch=x86

No more need to set FFmpeg's optflags to -O0, so performance on some decoders should be improved compared to the GCC 4.9.0 builds.

I did slightly patch FFmpeg by commenting out the two-line change from commit 76b5e99 (http://git.videolan.org/?p=ffmpeg.git;a=commit;h=76b5e99ce9c1245e2e426203a1f535a5d83cced6) as documented in ticket #3809 (http://trac.ffmpeg.org/ticket/3809), but it's otherwise the same as git master @ 65746bf.

EDIT 2014-08-02: Updated build here. (http://forum.doom9.org/showthread.php?p=1688624#post1688624)

[LigH]

Please note that MediaFire started to un-support '+' chars in filenames during uploads; you may have to rename your file right after uploading.

[qyot27]

Please note that MediaFire started to un-support '+' chars in filenames during uploads; you may have to rename your file right after uploading.
Renaming it afterward doesn't do anything to the stored name or the download link. It still pushed it to Firefox with spaces rather than the renamed title. And at the time that file was uploaded, it didn't do anything to the + character, so this was a retroactive change applied to existing files.

Of course, it doesn't affect the links I post here because I always ever use the short-form URL. It also doesn't damage the file at all.

The only actual 'remedy' is to use a different filename, period.

[jdobbs]

I'm getting an error condition with r931+50. With rffmode=1 or rffmode=2 it says I have to use the default output colorspace -- even though I am. I noticed this note in post #1787:

- Fix regression (r483) with rffmode that caused it to error out even if using the default output colorspace. (TheRyuu)

Is this something that perhaps hasn't been included in this build?

[qyot27]

It is*, and has been since April.

*the original commit:
Fix regression in rffmode error handling.

The regression caused by r483 would cause it to error out even if we
didn't specify any change in the output color space.

Fixes issue 95.

Originally committed to SVN as r720.

diff --git a/src/avisynth/avssources.cpp b/src/avisynth/avssources.cpp
index 883ff7b..41be596 100644
--- a/src/avisynth/avssources.cpp
+++ b/src/avisynth/avssources.cpp
@@ -243,7 +243,7 @@ void AvisynthVideoSource::InitOutputFormat(
if (RFFMode > 0 && ResizeToHeight != F->EncodedHeight)
Env->ThrowError("FFVideoSource: Vertical scaling not allowed in RFF mode");

- if (RFFMode > 0 && TargetPixelFormat != PIX_FMT_NV12)
+ if (RFFMode > 0 && TargetPixelFormat != PIX_FMT_NV21)
Env->ThrowError("FFVideoSource: Only the default output colorspace can be used in RFF mode");

// set color information variables
and the corresponding commit to the C-interface:
c_plugin: Fix regression in rffmode error handling.

The regression caused by r483 would cause it to error out even if we
didn't specify any change in the output color space.

Applies change from master @ ef81fe1

diff --git a/src/avisynth_c/ff_vidsource.c b/src/avisynth_c/ff_vidsource.c
index 4ec4904..fcf8ca1 100644
--- a/src/avisynth_c/ff_vidsource.c
+++ b/src/avisynth_c/ff_vidsource.c
@@ -232,7 +232,7 @@ static AVS_Value init_output_format( ffvideosource_filter_t *filter, int dst_wid
if( filter->rff_mode > 0 && dst_height != frame->EncodedHeight )
return avs_new_value_error( "FFVideoSource: Vertical scaling not allowed in RFF mode" );

- if( filter->rff_mode > 0 && dst_pix_fmt != PIX_FMT_NV12 )
+ if( filter->rff_mode > 0 && dst_pix_fmt != PIX_FMT_NV21 )
return avs_new_value_error( "FFVideoSource: Only the default output colorspace can be used in RFF mode" );

// Set color information


EDIT: I see what happened. That change was brought over without bringing over the change in r483 to the corresponding source file. I have to fix that.

[qyot27]

FFMS2 C-plugin r931+51

Optimized for Pentium-III and SSE.

ffmpeg version r65173 git-afd62b3 Copyright (c) 2000-2014 the FFmpeg developers
built on Aug 1 2014 18:09:55 with gcc 4.9.1 (GCC)
libavutil 52. 94.100 / 52. 94.100
libavcodec 55. 71.100 / 55. 71.100
libavformat 55. 50.100 / 55. 50.100
libavdevice 55. 13.102 / 55. 13.102
libavfilter 4. 11.102 / 4. 11.102
libavresample 1. 3. 0 / 1. 3. 0
libswscale 2. 6.100 / 2. 6.100
libswresample 0. 19.100 / 0. 19.100
libpostproc 52. 3.100 / 52. 3.100

configuration:
--prefix=/home/qyot27/win32_build
--cross-prefix=i686-w64-mingw32-
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--disable-doc
--disable-encoders
--disable-muxers
--disable-doc
--disable-debug
--disable-network
--disable-hwaccels
--disable-indevs
--disable-outdevs
--cpu=pentium3
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW32_STATIC_LIB'
--target-os=mingw32
--arch=x86

This should fix the rffmode issue. The slight mod in FFmpeg mentioned last time is also no longer necessary, as it was fixed upstream.

EDIT 2014-09-15: New build available here. (http://forum.doom9.org/showthread.php?p=1693710#post1693710)

[filler56789]

^ Thanks for the fixed build :thanks:

[jdobbs]

Thanks!

[Reino]

FFMS2 C-plugin r931+51 (http://www.mediafire.com/?wm71g1ribrcbezy)

Optimized for Pentium-III and SSE.
About a week ago I updated FFMS2 2.19 to this one, but only today, when I wanted to do some video editing, I found out that the moment I opened AviSynth-scripts in MPC-BE/HC the player would crash. It took my more than an hour to find out FFMS2 to be the culprit; ffms2.dll to be precise, that now appears to be a C-plugin instead of a normal AviSynth plugin.
This is ffavisynth.dll all over again. So to fix it...

FFMS2.avsi:
# FFmpegSource 1.21 syntax compatibility
# Created by TheFluff
LoadCPlugin("C:\Program Files\Media\AviSynth 2.6.0\plugins\ffms2.dll")
...
This again only seemed to somehow affect MPC-BE/HC. I could still open the AviSynth-script with GraphStudioNext, AvsPmod, FFMpeg and avs2pipemod without having to touch FFMS2.avsi.
I guess this could probably fix your problem too, Boulder.
Do you have any idea why this would only affect MPC-BE/HC, qyot27?
I'm using Avisynth 2.6.0 Alpha 5 + SEt's avisynth.dll (28.09.2013), btw.

[TheFluff]

About a week ago I updated FFMS2 2.19 to this one, but only today, when I wanted to do some video editing, I found out that the moment I opened AviSynth-scripts in MPC-BE/HC the player would crash. It took my more than an hour to find out FFMS2 to be the culprit; ffms2.dll to be precise, that now appears to be a C-plugin instead of a normal AviSynth plugin.
It says right there in the post you quoted: "FFMS2 C-plugin r931+51"

FFMS2 has both regular Avisynth 2.5 and Avisynth-C interfaces because the Avisynth 2.6 API is a terrible hack that nobody wants to interface with, so in order to get support for the new Avisynth 2.6 colorspaces some enterprising individual hacked those into the C interface instead. Unfortunately there's no straightforward way to tell from the DLL which version you have, so you have to read the packaging when you download.

[qyot27]

The FFMS2.avsi included with the C-plugin also has the LoadCPlugin line already included. It's been there for a good 2+ years already (https://github.com/FFMS/ffms2/commit/6819c6ce046f2061579765074c0fa24afb5280ed). The only time that line isn't needed for the C-plugin is when using AviSynth+, since it autoloads C plugins.

Some [IMO, broken] programs have issues with the relative path to ffms2.dll in the C-plugin's FFMS2.avsi. mencoder, for example (like I said, broken). I even switched avisynth.dll back to 2.6 MT to test with MPC-HC. The relative path works fine.

[Reino]

It says right there in the post you quoted: "FFMS2 C-plugin r931+51"Doh! haha.
As a last resort I noticed adding AviSynth's plugin map to %PATH% (Environment Variables) would help too.

If AviSynth 6.0 is so terrible, what are you 2 using? AviSynth+, or another fork?

[LigH]

There is no AviSynth 6.0 yet. ;)

And no matter which fork, to be compatible, it would have to implement the same programming interfaces.

AviSynth+ at least supporst a list of plugin directories, similar to %PATH%.

[szabi]

Hi

I have a simple question.
FFVideoSource("D:\movie\Video.mkv", fpsnum=24, fpsden=1, threads=1)
MCTemporalDenoise(settings="medium")
crop(68, 0, -68, 0)
This script was loaded to virtualdub and compressed by ffdshow video codec with following:
Encoder: HuffYUV (FFmpeg variant), FOURCC: FFVH, colorspace: YV12, Predictor: plane, disabled adaptive huffman tables

Now i have a huge video.avi file.
I want to encode by x264.
I can not load it by FFVideoSource.
Only AviSource is working.
Why is FFVideoSource not working? Even it was created by ffdshow video codec.
Is there any quality loss by AviSource in use, not FFVideoSource?

bye
szabi

[raffriff42]

OP should perhaps be updated with link to the latest releases?
https://github.com/FFMS/ffms2/releases (if that's correct)

[Myrsloik]

OP should perhaps be updated with link to the latest releases?
https://github.com/FFMS/ffms2/releases (if that's correct)

Fixed. Guess I forgot to update it when everything moved to github.

[Groucho2004]

I can not load it by FFVideoSource.
It should work. It will however take some time to create the index file. Can you be a bit more specific than "I can not load it"?

[szabi]

Hi

When I tried by megui, the program simple crashed.
Other was simple x264 launcher, which turned unresponsive for a 1 minutes, after stopped by following message:
Warning: Input process did not respond for 60 seconds, potential deadlock...
error: FFVideoSource: Can't open 'D:\D:\movie\Video.avi' (\D:\movie\Video.avs, line 1)

Do you think any quality loss occurs by AviSource in use instead of FFVideoSource?

bye
szabi

[Groucho2004]

Do you think any quality loss occurs by AviSource in use instead of FFVideoSource?
Not that I know of.

[LigH]

D:\D:\movie\Video.avi — looks suspicious.

It might depend on the video format in the AVI. Lossless formats (like Huffyuv) should decode equally with all decoders. Lossily compressed formats may reconstruct with slight differences, depending on the decoder.

The YV12 version of Huffyuv by ffmpeg won't decode with BenRG's VfW codec, you will need ffdshow (ffvfw) installed and activated. Current builds of FFMS2 or L-SMASH Works should support it too; I remember there has been a problem with lossless AVIs though, possibly related to the huge index because every frame is a keyframe.

[szabi]

D:\D:\movie\Video.avi — looks suspicious.
Typing issue, not the reason.

Of cource ffdshow is installed, anyway not available for encoding.
Decoder setting is this one for VFW:
http://abload.de/img/ffdshowqasv2.png

HuffYUV and HuffYUV FFmpeg variant is activated.
Unfortunately add it by AviSource input there is no feedback which codec in use.

bye
szabi

[LigH]

Because the FourCC "FFVH" will only be supported by ffvfw, this codec will have been used. If there is a choice between several VfW codecs, then it depends on the preference order in the registry.

So in this case, using AviSource is a rather reliable choice for you. FFMS2 may have choked on its index.

[szabi]

Ok, thanks for it.

bye
szabi

[Boulder]

Warning: Input process did not respond for 60 seconds, potential deadlock...
error: FFVideoSource: Can't open 'D:\D:\movie\Video.avi' (\D:\movie\Video.avs, line 1)As has been mentioned earlier, it can take quite a while to index a file if it is large.

[RTW47]

for a massive source file(s) preferred way would be to perform manual indexing beforehand via ffmsindex, instead of automatic, if application waiting for FFMS2 to construct index crashes, stops responding or implements deadlock prevention such as Simple x264/x265 Launcher. Additionally user will get progress report on the indexing.

[Andouille]

Hi guys,

Because I wanted to play with the new hevc toys around (and also have a bug/artifacts free prores decoder), I updated my good old r579 to the new 2.20.

Hevc decoding and prores are just fine and I'm happy.
Compared to r579, I also found a nice 2% to 2.6% speedup for h264 decoding.(the biggest speedup is for lossless, which is really good)

However I found it is slower on other codecs like :
div3, xvid -20%
divx5 -10%
(I don't really care for this three codecs but the speed loss is quite big)

But the really annoying one :
mpeg2 -15%

I'm running Avisynth 2.5.8.5 on WinXP 32bits.

Can someone confirm this ?

Thx

[Groucho2004]

However I found it is slower on other codecs like :
...
But the really annoying one :
mpeg2 -15%

I'm running Avisynth 2.5.8.5 on WinXP 32bits.

Can someone confirm this ?
Ran a few tests with a SD PAL mpeg-2 clip on my i5 2500K (Sandy Bridge), same Avisynth version, same OS.

Script:
loadplugin("ffms2.dll")
ffvideosource("test.m2v", threads = 1)


Results:
FFMS2 r579: 1014 fps
FFMS2 2.20 (ICL): 974 fps
FFMS2 2.20 (MSVC): 545 fps

[Lenchik]

Can you please upload somewhere this r576 build for share.

[the_weirdo]

That speed loss may be a result of different compilers using to build lav* (lav* of official builds were built with ICL and MSVC, which are slower than GCC builds). You can try those FFMS2 builds (https://www.dropbox.com/sh/w1zt5qvfywj6r9z/AADtFdbpcnRole0wja_o_6TYa?dl=0) to see if that's the case.

[qyot27]

The C-plugin is another option.

[Taurus]

Can you please upload somewhere this r576 build for share.
https://code.google.com/p/ffmpegsource/downloads/list?can=1&q=&colspec=Filename+Summary+Uploaded+ReleaseDate+Size+DownloadCount
r576 is not found in this list.
But r579, the one Groucho2004 is poking on, is available.
Try your poison.

[qyot27]

FFMS2 C-plugin r936+55

Optimized for Pentium-III and SSE.

ffmpeg version r66281 git-e587a42 Copyright (c) 2000-2014 the FFmpeg developers
built on Sep 15 2014 10:35:35 with gcc 4.9.1 (GCC)
libavutil 54. 7.100 / 54. 7.100
libavcodec 56. 1.100 / 56. 1.100
libavformat 56. 4.101 / 56. 4.101
libavdevice 56. 0.100 / 56. 0.100
libavfilter 5. 1.100 / 5. 1.100
libavresample 2. 1. 0 / 2. 1. 0
libswscale 3. 0.100 / 3. 0.100
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 0.100 / 53. 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-network
--disable-hwaccels
--disable-indevs
--disable-outdevs
--cpu=pentium3
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW32_STATIC_LIB'
--target-os=mingw32
--arch=x86

EDIT 2014-11-05: Newer build available here. (http://forum.doom9.org/showthread.php?p=1698838#post1698838)

[Taurus]

@qyot27
:thanks: for the new build!
I could not resist:

Script:
ffvideosource("test.m2v", threads = 1)
Testing ffms2_r936c55-avs_vsp:
Frames processed: 4738 (0 - 4737)
FPS (min | max | average): 117.3 | 204.0 | 146.1
CPU usage (average): 98%
Thread count: 2
Physical Memory usage (peak): 18 MB
Virtual Memory usage (peak): 22 MB
Time (elapsed): 000:00:32.437


Testing ffms2-r579:
[Runtime info]
Frames processed: 4736 (0 - 4735)
FPS (min | max | average): 80.36 | 148.8 | 113.0
CPU usage (average): 89%
Thread count: 2
Physical Memory usage (peak): 24 MB
Virtual Memory usage (peak): 29 MB
Time (elapsed): 000:00:41.899

This is on an old laptop.
The speed increase of the new version is remarkable.

[Groucho2004]

Testing ffms2_r936c55-avs_vsp:
Frames processed: 4738 (0 - 4737)
Testing ffms2-r579:
[Runtime info]
Frames processed: 4736 (0 - 4735)
I wonder why the number of frames is different (assuming you did not cancel AVSMeter before all frames were processed)...

[Andouille]

Thx for all the replies.
I forgot to mention that I run an old t5500 processor and the ffms2 2.20 was the icl compiler build.
I will test the other compiler builds that you pointed out.
thx

[Lenchik]

More testing from me.
CPU: Intel Core i7-2600K CPU @ 3.40GHz (MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, EM64T, VT-x, AES, AVX)
Video Source: Previously screencaptured presentation like video 1824x992 @15fps encoded by x264 core 142 r2431kMod ac76440 with following parameters:
cabac=1 / ref=4 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=10 / psy=1 / fade_compensate=0.00 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / fgo=0 / bframes=10 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=1 / scenecut=80 / intra_refresh=0 / rc_lookahead=80 / rc=crf / mbtree=1 / crf=19.0000 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=20000 / vbv_bufsize=20000 / crf_max=0.0 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00

LoadPlugin (…)
# Load_Stdcall_plugin (…) # for C-plugins, marked as (C)
FFVideoSource(source=source, threads=1)

AVSMeter 1.8.1 set to process first 3001 frames (0 - 3000).


Log file created with: AVSMeter 1.8.1 (x86)
Avisynth version: AviSynth 2.60, build:Sep 28 2013 [15:09:12] (MT)
Active MT Mode: 0
Avg FPS Virtual Memory usage (peak, MB):
ffms2-r579 271.6 66
ffms-2.17-cplugin (C) 284.0 122
ffms2_r836-avs+vsp (C) 267.2 128
ffms2-2.19 269.2 70
ffms2-2.20-icl 261.3 77
ffms2-2.20-msvc 262.2 77
ffms2_r931+51-avs+vsp (C) 276.8 141
FFMS2-2.20-15-g08f94ee-FFmpeg-g365b9cf-32bit 277.1 77
FFMS2-2.20-15-g08f94ee-Libav-g775a0b0-32bit 276.5 76
ffms2_r936+55-avs+vsp (C) 272.9 140

[Andouille]

Here are my results with the different builds

*divx3
r579 820.76 fps
2.20gcc 691.59 fps
2.20icl 659.02 fps
2.20msvc 447.78 fps

*divx5
r579 2935.90 fps
2.20gcc 2788.51 fps
2.20icl 2674.95 fps
2.20msvc 1639.05 fps

*xvid
2.20gcc 735.20 fps
r579 722.51 fps
2.20icl 579.65 fps
2.20msvc 368.61 fps

*h264 baseline
2.20gcc 1282.36 fps
2.20icl 1246.05 fps
r579 1227.67 fps
2.20msvc 1210.35 fps


*h264 high profile
2.20gcc 165.05 fps
2.20icl 152.59 fps
r579 149.23 fps
2.20msvc 143.32 fps


*h264 lossless
2.20gcc 240.21 fps
2.20icl 237.34 fps
r579 234.14 fps
2.20msvc 224.93 fps


*mpeg2
r579 522.30 fps
2.20gcc 513.40 fps
2.20icl 453.07 fps
2.20msvc 353.64 fps


The C plugin is really fast for h264 !

Other thing I discovered :
The mpeg2 IDCT algorithm for the builds seem different :

2.20icl and 2.20gcc outputs are bit identical (crc) but not the r579 and the msvc

r579.png FF40A416 488 193
220icl.png 28C25109 488 106
220msvc.png 094891E6 488 128
220gcc.png 28C25109 488 106

[Taurus]

I wonder why the number of frames is different (assuming you did not cancel AVSMeter before all frames were processed)...
Yeah, I discovered this too.
Redid the tests, carefully deleting the index file -> same behaviour.
The old ffms2-r579 seems to be not frame accurat.
I verified with a bitrateviewer, 4738 frames is the real number.
ffms2-r579 is spitting out 4736 frames.
Two frames are missing with the older build.
Only tested on mpeg2, cant say for newer codecs.
So one should avoid the older build(s) for mpeg2!

[qyot27]

I wonder why the number of frames is different (assuming you did not cancel AVSMeter before all frames were processed)...
It could be either that FFMS2's demuxing has improved in regard to MPEG containers (as I'm not entirely sure whether this is one of the cases that FFMS2 defaults to Haali*), or it could be in libavformat itself. Since r579 is from October 2011, that's 357 commits to FFMS2 and a mountain of commits to FFmpeg (some of which I know are related to MPEG containers since I saw them in the Git log a few months ago).

*the C-plugin can't access the Haali DirectShow filter, though, so the only Haali code I think the C-plugin uses is for Matroska, as that's separate.

I'd compare the frame count against what DGIndex reports. I recall that there was a one frame difference even in recent builds. But whether the disparity is caused by FFMS2's internal stuff or simply what it gets from libavformat, I don't know.

[Taurus]

I'd compare the frame count against what DGIndex reports. I recall that there was a one frame difference even in recent builds.

DGIndex is reporting the same (correct) numbers here.
No mismatch to the newer FFMS2 builds.
Only the older builds are affected.

[qyot27]

FFMS2 C-plugin r936+55

Optimized for Pentium-III and SSE.

ffmpeg version r67362 git-db0471c Copyright (c) 2000-2014 the FFmpeg developers
built on Nov 3 2014 17:50:57 with gcc 4.9.2 (GCC)
libavutil 54. 11.100 / 54. 11.100
libavcodec 56. 10.102 / 56. 10.102
libavformat 56. 12.100 / 56. 12.100
libavdevice 56. 2.100 / 56. 2.100
libavfilter 5. 2.102 / 5. 2.102
libavresample 2. 1. 0 / 2. 1. 0
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 3.100 / 53. 3.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-network
--disable-hwaccels
--disable-indevs
--disable-outdevs
--disable-decoder=utvideo
--enable-libutvideo
--cpu=pentium3
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW32_STATIC_LIB'
--target-os=mingw32
--arch=x86

New build, no changes to the FFMS2 portions. Just a nearly-two-months newer version of FFmpeg, built with GCC 4.9.2 instead of 4.9.1.

Also, the return of libutvideo for decoding Ut Video streams, since support for UQY2 (the 10-bit 4:2:2 'Ut Video Pro' format) was added to the libutvideo wrapper.

EDIT 2014-12-23: New build available here. (http://forum.doom9.org/showthread.php?p=1703624#post1703624)

[poisondeathray]

Thanks for the update qyot27

[qyot27]

FFMS2 C-plugin r936+59

Optimized for Pentium-III and SSE.

ffmpeg version r68649 git-03b84f2 Copyright (c) 2000-2014 the FFmpeg developers
built on Dec 22 2014 08:09:17 with gcc 4.9.2 (GCC)
libavutil 54. 15.100 / 54. 15.100
libavcodec 56. 16.100 / 56. 16.100
libavformat 56. 16.101 / 56. 16.101
libavdevice 56. 3.100 / 56. 3.100
libavfilter 5. 4.100 / 5. 4.100
libavresample 2. 1. 0 / 2. 1. 0
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 3.100 / 53. 3.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-decoder=utvideo
--enable-libutvideo
--disable-debug
--disable-network
--disable-hwaccels
--disable-indevs
--disable-outdevs
--cpu=pentium3
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW32_STATIC_LIB'
--target-os=mingw32
--arch=x86

This build has the Haali DirectShow code removed. It seems as if the C-plugin actually might have been able to use it, as all the COM stuff was being thrown around. I'm not entirely certain of that, but regardless, 'haalimpeg' and 'haaliogg' no longer exist in this build. This is not in FFMS2 master (yet; I've opened a pull request).

The big test: do those troublesome M2TS files mentioned in the docs still need seekmode=0 to work right with the LAVF splitter?

EDIT 2015-02-15: Newer build available here. (http://forum.doom9.org/showthread.php?p=1709647#post1709647)

[qyot27]

FFMS2 C-plugin r940+64

Optimized for Pentium-III and SSE.

ffmpeg version r69783 git-bbb0634 Copyright (c) 2000-2015 the FFmpeg developers
built with gcc 4.9.2 (GCC)
libavutil 54. 18.100 / 54. 18.100
libavcodec 56. 22.100 / 56. 22.100
libavformat 56. 21.100 / 56. 21.100
libavdevice 56. 4.100 / 56. 4.100
libavfilter 5. 11.100 / 5. 11.100
libavresample 2. 1. 0 / 2. 1. 0
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 3.100 / 53. 3.100

configuration:
--prefix=/home/qyot27/win32_build
--cross-prefix=i686-w64-mingw32-
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--disable-encoders
--enable-libutvideo
--disable-muxers
--disable-doc
--disable-debug
--disable-network
--disable-hwaccels
--disable-indevs
--disable-outdevs
--cpu=pentium3
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW32_STATIC_LIB'
--target-os=mingw32
--arch=x86

Going even further than the last build did, this one removes the Matroska demuxer too. This means that the *only* demuxer this build of FFMS2 uses is LAVF. The test this time is whether VP8 (and maybe VP9) bearing WebM files can be used correctly with the LAVF demuxer.

Additionally, developers using FFMS2 (the standard C++ plugin .dll) as a library can now use the C-plugin .dll with their program without much/any changes, since it now exports its functions with a leading underscore like the C++ plugin does - but only in the case of the C-plugin interface being enabled (--enable-avisynth). If you build FFMS2 with GCC but don't enable the C-plugin, it will export the functions like it always has, without the underscore.

EDIT 2015-03-26: Newer build available here. (http://forum.doom9.org/showthread.php?p=1714813#post1714813)

[LigH]

:thanks: Not yet tested; but exchanging Haali dependencies with LAVF appears to me to be probably useful, the splitters used to be the main weakness of FFMS2.

[qyot27]

It's not really exchanging it since LAVF was always there, it's more that it was becoming increasingly common to have to say 'did you try with -m lavf' when responding to bug reports, and much of the time, that was all the user actually needed to do. Defaulting to Haali demuxers for MPEG, OGM, and MKV (albeit to a lesser extent than the other two) has lost whatever advantage it might have had over libavformat a few years ago, and actually was beginning to be an active disadvantage. For most containers, LAVF has always been the default.

The relevant stuff on Github:
https://github.com/FFMS/ffms2/issues/175
https://github.com/FFMS/ffms2/issues/176
https://github.com/FFMS/ffms2/pull/183 (this covers only the removal of the code from the master branch; the C-plugin migration process is handled differently)

[stax76]

Will this plugin be C only or will there be a non C version, atm. StaxRip supports only non C. I've not followed the thread in detail and I'm rather confused, I want to try the latest build because the one StaxRip currently uses fails to open a eac3to created raw h264 file.

[qyot27]

Will this plugin be C only or will there be a non C version, atm. StaxRip supports only non C. I've not followed the thread in detail and I'm rather confused, I want to try the latest build because the one StaxRip currently uses fails to open a eac3to created raw h264 file.
This depends entirely on how you're using the .dll and/or AviSynth.

The builds I provide are only of the C plugin. Builds of the traditional C++ plugin version are available officially from github.com/FFMS/ffms2/releases, but builds are usually only made available when FFMS2 reaches a point release.

If you're using the .dll directly as a library rather than an AviSynth plugin, then the latest build I provided a couple posts ago should work (as I forcibly made underscore-prefixed API calls visible).

If you're using it as an AviSynth plugin, then one of the following can be true:
Use LoadCPlugin or Load_Stdcall_Plugin to load it manually
Use the provided FFMS2.avsi to mimic autoloading (it calls LoadCPlugin) - the AviSynth plugins folder should be on the Windows %PATH% (or the calling application should treat the directory as if it is on the %PATH%) for this to work right because the .avsi uses a relative path to ffms2.dll.
If using AviSynth+, C plugins do autoload, so nothing extra should be needed for it.

[avih]

FFMS2 C-plugin r940+64 (http://www.mediafire.com/?74ls4i3woi369ic)

Optimized for Pentium-III and SSE.

ffmpeg version r69783 git-bbb0634 Copyright (c) 2000-2015 the FFmpeg developers
built with gcc 4.9.2 (GCC)

...
--disable-network
--disable-hwaccels
...



I'm completely unfamiliar with ffms2 internals and never tried to build it myself (I am building ffmpeg for other projects though, such as mpv, cross compiling in MXE, FWIW), but these 2 options could be useful and AFAIK they work rather well in ffmpeg.

hwaccel (i'm guessing that's dxva2?) actually reduces cpu load and power usage when used, and network _should_ work (can it actually be used to play network clips via avisynth?).

If that matters, I'm using ffms2 as a source plugin together with SVP.

[qyot27]

I'm not sure if FFMS2 allows using the dxva/vdpau/vda/etc. decoders, especially since there is also currently no way (in FFMS2) to select one decoder out of many for the same format that might exist in libavcodec. And I have no idea if the network support would work correctly. AviSynth did/does have the TCPSource/Deliver plugin (not that I've ever used it), but I don't know if it would have an effect in FFMS2.

The reality is that those four options (disable-network, disable-hwaccels, disable-indevs, and disable-outdevs) have been in the build options I've used for a long time. They were suggested quite a number of years ago in the API docs (https://github.com/FFMS/ffms2/blob/master/doc/ffms2-api.md#compilation) and in this thread (http://forum.doom9.org/showthread.php?p=1367924#post1367924), so part of it is just not running any tests on either one to see how necessary it actually is nowadays - unlike the encoders and muxers, which are completely useless for FFMS2 and reduce the size of the .dll by a good amount.

[avih]

Well, mpv (http://mpv.io/) uses ffmpeg's hwaccel (vpdau, dxva2, etc) and it's quite effective on windows and AFAIK on other platforms as well. As for usage for network sources via ffmpeg, imagine youtube clip url into ffms2 into svp into mpv ;) I got this exact chain working well for local files now with a system which generates an avs file on the fly, but doing the same for a network clip could be cool...

Maybe I'll try to build ffms2 myself with different ffmpeg options..

[LigH]

Not for every GPU, using the decoder chip will be a speedup compared to CPU decoding.

And if I have to be afraid that the GPU decoding applies an undesired IVTC or deinterlacing without control, I would not use FFMS2.

[qyot27]

Well, mpv (http://mpv.io/) uses ffmpeg's hwaccel (vpdau, dxva2, etc) and it's quite effective on windows and AFAIK on other platforms as well. As for usage for network sources via ffmpeg, imagine youtube clip url into ffms2 into svp into mpv ;) I got this exact chain working well for local files now with a system which generates an avs file on the fly, but doing the same for a network clip could be cool...

Maybe I'll try to build ffms2 myself with different ffmpeg options..
The YouTube example won't work, unless you do it the hard way and go through RTMP. Just giving FFmpeg the https:// url won't do anything, and thus FFMS2 won't either.

mpv supports playing streaming media through a youtube-dl bridge, only falling back on FFmpeg's network stuff if the ytdl loader fails. FFmpeg's tenuous support of it was provided through libquvi (which mpv also used to use, before dropping it in favor of ytdl), which is mostly completely broken/outdated now and should be removed from libavformat.

[Kein]

Hello, I'm having a bit of a problem and can't figure out why:

Win7x64
AviSynth_150114_260_rc1 (x86/32bit)
ffms2-2.20-msvc (x86/32bit)

This clip: http://www64.zippyshare.com/v/kTIU4syL/file.html

a=FFAudioSource("CastleInTheDarkness 2015-03-08 00-37-59-551.avi")
v=FFVideoSource("CastleInTheDarkness 2015-03-08 00-37-59-551.avi")
AudioDub(v, a)
Info()


Someone please explain what I'm doing wrong? It simply won't open it. Nothing being returned besides usual "can't open file" error by MPC/Vdub.

[LigH]

Before I download this file, could you post a MediaInfo report about it? Maybe it contains a video or audio stream format not supported by FFMS2?

[Selur]

Video is xtor (http://exkode.com/dxtory-features-en.html) and (using latest version posted by qyot27) FFVideoSource can open it fine here,..

[Kein]

Before I download this file, could you post a MediaInfo report about it? Maybe it contains a video or audio stream format not supported by FFMS2?

Format : AVI
Format/Info : Audio Video Interleave
File size : 97.2 MiB
Duration : 12s 140ms
Overall bit rate : 67.1 Mbps
Original source form/Distributed by : Video:YUV420|CompressV3 Audio:Speakers (VIA High Definition Audio)
Writing application : DxtoryCore ver2.0.0.127

Video
ID : 0
Format : xtor
Codec ID : xtor
Duration : 11s 400ms
Bit rate : 69.8 Mbps
Width : 960 pixels
Height : 640 pixels
Display aspect ratio : 3:2
Frame rate : 30.000 fps
Bits/(Pixel*Frame) : 3.789
Stream size : 94.9 MiB (98%)

Audio
ID : 1
Format : PCM
Format settings, Endianness : Little
Format settings, Sign : Signed
Codec ID : 1
Duration : 12s 140ms
Bit rate mode : Constant
Bit rate : 1 536 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Stream size : 2.22 MiB (2%)
Alignment : Aligned on interleaves
Interleave, duration : 93 ms (2.80 video frames)


http://i.imgur.com/IINL2gB.png

Video is xtor (http://exkode.com/dxtory-features-en.html) and (using latest version posted by qyot27) FFVideoSource can open it fine here,..

I know it is xtor, I recorded it. The thing is - I can't open it through ffms2 via avs script. It boggles my mind.

[qyot27]

From the MediaInfo output in the issue on Github (https://github.com/FFMS/ffms2/issues/194):
Writing application : DxtoryCore ver2.0.0.127

2.20 is from June 20th, 2014.

The FFmpeg git log, with a search for 'dxtory'. (http://git.videolan.org/?p=ffmpeg.git&a=search&h=HEAD&st=commit&s=dxtory):
2014-09-25 Michael Niedermayer avcodec/dxtory: Support dxtory-2.0.127.avi

The problem is that the official build of FFMS2 2.20 is not using a build of FFmpeg new enough to decode the file, because the build is from three months prior to that being committed to FFmpeg.

It's also why it's fixed in the C plugin builds, because those use reasonably updated versions of FFmpeg.

[Kein]

I just recorded another clip from this and another game with the same codec and same options and then opened it just fine (with your version of the plugin, ffms2_r940c64-avs_vsp). But that particular clip I cannot.

It works just fine elsewhere. It is not damaged. There is nothing special about it. You can open. Why I can't?

[kolak]

Can we have ffmpegsource based on "current" (2.6) ffmpeg, please?

[Groucho2004]

I just recorded another clip from this and another game with the same codec and same options and then opened it just fine (with your version of the plugin, ffms2_r940c64-avs_vsp). But that particular clip I cannot.

It works just fine elsewhere. It is not damaged. There is nothing special about it. You can open. Why I can't?
Did you load ffms2.dll with "LoadCPlugin" or just copy it to your auto-load directory? Your file also works for me with r940c64.

[stax76]

Possibly ffms2 misses to release a file handle, I use the avifile API, after releasing and cleaning everything the process still locks the source, I tried other source filters and it happens only with ffms2.

[stax76]

With latest C plugin build when I open 2-3 movies seeking around in StaxRip's preview memory grow up quickly causing a out of memory exception at 1,5 GB.

With the 2.20 release memory stays always below 850 MB.

Specs of test file: http://pastebin.com/MxqcTkRh

[qyot27]

This has been a mysterious leak for a while. It came up regarding MeGUI a year ago, and I could reproduce it in VirtualDub:
http://forum.doom9.org/showthread.php?p=1674911#post1674911

But I wasn't able to find where it was doing it in the C interface part of FFMS2.

[stax76]

Any ideas on the file lock?

edit: happens also with c plugin only

[Kein]

Another issue with Dxtory and FFmpeg.

For some reason ffms detects source as 1920x1080@44FPS while it was recorded in 60. What gives?

[qyot27]

FFMS2 C-plugin r944+69

Optimized for Pentium-III and SSE.

ffmpeg version r70952 git-db4234c Copyright (c) 2000-2015 the FFmpeg developers
built with gcc 4.9.2 (GCC)
libavutil 54. 20.100 / 54. 20.100
libavcodec 56. 29.100 / 56. 29.100
libavformat 56. 26.101 / 56. 26.101
libavdevice 56. 4.100 / 56. 4.100
libavfilter 5. 13.101 / 5. 13.101
libavresample 2. 1. 0 / 2. 1. 0
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 3.100 / 53. 3.100

configuration:
--prefix=/home/qyot27/win32_build
--cross-prefix=i686-w64-mingw32-
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--disable-encoders
--disable-decoder=utvideo
--enable-libutvideo
--disable-decoder=dca
--enable-libdcadec
--disable-muxers
--disable-doc
--disable-debug
--disable-devices
--cpu=pentium3
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW32_STATIC_LIB'
--target-os=mingw32
--arch=x86

Uses libdcadec, although due to the currently fairly rapid development pace of libdcadec, consider it only a snapshot. Should still be better compared to the native decoder.

EDIT 2015-05-05: Newer build available here. (http://forum.doom9.org/showthread.php?p=1720384#post1720384)

[Pat357]

FFMS2 C-plugin r944+69 (http://www.mediafire.com/?d537njuct4i95kq)

Uses libdcadec, although due to the currently fairly rapid development pace of libdcadec, consider it only a snapshot. Should still be better compared to the native decoder.

Thanks !
Finally a decent replace for the rather poor ffdca !!
Note : currently no support for 192 kHz sample rates , just up to 92 kHz !

see : https://github.com/foo86/dcadec

[Wilbert]

I have a question about the license:

The source is MIT licensed and can be obtained from https://github.com/FFMS/ffms2/. The precompiled binary is GPL3 licensed. (...)
I don't understand this construction. As I understand it you can only license the software (being the binary here). The binary can be released under different licenses, and you (if one wouldn't be the sole copyright-holder) can release it under a compatible license. It doesn't make any sense to me to say that the sourcecode is licensed under a particular license. Perhaps i'm missing something ...

[LoRd_MuldeR]

I have a question about the license:


I don't understand this construction. As I understand it you can only license the software (being the binary here). The binary can be released under different licenses, and you (if one wouldn't be the sole copyright-holder) can release it under a compatible license. It doesn't make any sense to me to say that the sourcecode is licensed under a particular license. Perhaps i'm missing something ...

Well, to my understanding, the copyright-holder can put his/her own code under whatever license he/she wants. The code can even be released under multiple different licenses at the same time - as many projects do.

Now, if you combine your own code with someone else's code, then the combined work needs to be distributed under a compatible license, of course. So, if the authors of FFMS2 decide to release their own code under the MIT license, they are of course free to do so! But as soon as a binary is created, which unavoidably contains some FFmpeg code too, then the whole thing must be distributed under the LGPL or GPL - depending on what FFmpeg feature are enabled. That's because FFmpeg is released under the LGPL - and partly under the GPL. And the GPL/LGPL is more restrictive than the MIT license. You can combine MIT'ed code with GPL'ed or LGPL'ed code, but the combined work has to be distributed under GPL/LGPL then.

Unless I'm missing anything here, this should be fine :confused:

[captainadamo]

I have a question about the license:

The source is MIT licensed and can be obtained from https://github.com/FFMS/ffms2/. The precompiled binary is GPL3 licensed. (...)

I don't understand this construction. As I understand it you can only license the software (being the binary here). The binary can be released under different licenses, and you (if one wouldn't be the sole copyright-holder) can release it under a compatible license. It doesn't make any sense to me to say that the sourcecode is licensed under a particular license. Perhaps i'm missing something ...

What exactly is the confusion? Certain source files in ffms2 are licensed under something like the MIT license, but the project also contains GPLed code. So as a whole the combined work, the binary, is licensed under the GPL per the way the GPL works. It's no different than how countless other projects such as the Linux kernel work. The Linux kernel is overarching GPLv2, but it contains MIT/BSD/etc. more permissive licensed code in it as well. There is nothing exotic or out-of-the-ordinary here.

[Wilbert]

Guess i should think a little bit before asking. I forgot that you are combining GPL en MIT code. How stupid.

[mariner]

FFMS2 C-plugin r944+69 (http://www.mediafire.com/?d537njuct4i95kq)

Optimized for Pentium-III and SSE.

ffmpeg version r70952 git-db4234c Copyright (c) 2000-2015 the FFmpeg developers
built with gcc 4.9.2 (GCC)
libavutil 54. 20.100 / 54. 20.100
libavcodec 56. 29.100 / 56. 29.100
libavformat 56. 26.101 / 56. 26.101
libavdevice 56. 4.100 / 56. 4.100
libavfilter 5. 13.101 / 5. 13.101
libavresample 2. 1. 0 / 2. 1. 0
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 3.100 / 53. 3.100

configuration:
--prefix=/home/qyot27/win32_build
--cross-prefix=i686-w64-mingw32-
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avresample
--disable-encoders
--disable-decoder=utvideo
--enable-libutvideo
--disable-decoder=dca
--enable-libdcadec
--disable-muxers
--disable-doc
--disable-debug
--disable-devices
--cpu=pentium3
--extra-cflags='-mfpmath=sse -march=pentium3 -msse -mtune=pentium3 -DPTW32_STATIC_LIB'
--target-os=mingw32
--arch=x86

Uses libdcadec, although due to the currently fairly rapid development pace of libdcadec, consider it only a snapshot. Should still be better compared to the native decoder.

Greetings qyot27. Appreciate your continuing effort to update ffms2.

Is this to be used with Avisynth 2.58?

Many thanks and best regards.

[qyot27]

Is this to be used with Avisynth 2.58?
2.5 is still supported, at the moment. But the C plugin's purpose had shifted to giving 2.6 precedence years ago.

[mariner]

2.5 is still supported, at the moment. But the C plugin's purpose had shifted to giving 2.6 precedence years ago.

Thanks for the kind reply, qyot27.
I take it yours is the preferred version to the official 2.2 built?
Many thanks and best regards.

[qyot27]

My builds of the C plugin are simply updated more often. 'Preferred' is purely subjective.

[Kein]

Another issue with Dxtory and FFmpeg.

For some reason ffms detects source as 1920x1080@44FPS while it was recorded in 60. What gives?


No ideas?

[sneaker_ger]

Make a bug report with a sample on the tracker. Best chance to get someone to look at it.
https://github.com/FFMS/ffms2/issues

[mariner]

My builds of the C plugin are simply updated more often. 'Preferred' is purely subjective.


Thanks qyot27. Two questions:

1. Can this deal with interlaced content?
2. And what about interlaced content that's been encoded as progressive (as reported by mediainfo) in a ts container? Or is there a way to flag these as interlaced without re-encoding?

Many thanks and best regards.

[qyot27]

I don't know, as I've never had to handle interlaced H.264 with FFMS2. Since the latest builds have the Haali splitters removed, its performance should map fairly equally to how it's handled in FFmpeg itself.

[Selur]

Or is there a way to flag these as interlaced without re-encoding?
iirc there's a modified ffmpeg version floating around which can remux and change the interlaced flag,..

[StainlessS]

iirc there's a modified ffmpeg version floating around which can remux and change the interlaced flag,..

Dont know about that, but there is one to hack Aspect Ratio:-
"New tool to change SAR in H264 bitstream "
http://forum.doom9.org/showthread.php?t=152419

[Selur]

damn, thought that one could also change the interlaced flags,...

[LigH]

There is quite a difference between PAFF and MBAFF interlacing. It's more than a matter of setting flags. You would confuse a decoder substantially if you patched them wrong.

[mariner]

I don't know, as I've never had to handle interlaced H.264 with FFMS2. Since the latest builds have the Haali splitters removed, its performance should map fairly equally to how it's handled in FFmpeg itself.

Thanks for the reply.

MultiAVCHD was not able to display the menu and video when the r944 files was placed in the Avisynth plugin folder. No issue with the official 2.2 build. What may have caused this?

Many thanks and best regards.

[Pat357]

Thanks for the reply.

MultiAVCHD was not able to display the menu and video when the r944 files was placed in the Avisynth plugin folder. No issue with the official 2.2 build. What may have caused this?

Many thanks and best regards.

Did you also put the file FFMS2.avsi in the plugin directory ?
You need to do so, because this is a C-plugin and it will not autoload without the FFMS2.avsi file being present in the same directory.

[LigH]

AviSynth+ (note the plus) is able to autoload AviSynth C plugins; the original AviSynth 2.x is not, therefore the import script (with additional declared convenience functions).

[mariner]

Did you also put the file FFMS2.avsi in the plugin directory ?
You need to do so, because this is a C-plugin and it will not autoload without the FFMS2.avsi file being present in the same directory.

Thanks for the reply, Pat.

All the three files are placed in the plugin directory.

Here's the situation:

1. No files in plugin directory: multiAVCHD OK.
2. Build 2.2 files in plugin directory: OK.
3. Build 944: NOT OK

Any idea?

[qyot27]

Some programs require AviSynth's plugins folder to be on the %PATH% in order to handle the .avsi. In those cases it's the program's issue, not FFMS2's.

[stax76]

Here is a problem a StaxRip user reported:


------------------------------------------------------------
Source file MediaInfo
------------------------------------------------------------

D:\Spiele\BorderlandsPreSequel 2015-02-05 20-34-18-52_merged.mkv

General
Unique ID : 242162529886412073948372795964824009988 (0xB62ECE8896C135ED9BB8CA6516F8BD04)
Complete name : D:\Spiele\BorderlandsPreSequel 2015-02-05 20-34-18-52_merged.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 6.21 GiB
Duration : 1mn 16s
Overall bit rate : 701 Mbps
Encoded date : UTC 2015-04-26 10:03:44
Writing application : mkvmerge v7.7.0 ('Six Voices') 32bit built on Feb 28 2015 23:23:00
Writing library : libebml v1.3.1 + libmatroska v1.4.2
DURATION : 00:01:16.133000000
NUMBER_OF_FRAMES : 2438
NUMBER_OF_BYTES : 14617600
_STATISTICS_WRITING_APP : mkvmerge v7.7.0 ('Six Voices') 32bit built on Feb 28 2015 23:23:00
_STATISTICS_WRITING_DATE_UTC : 2015-04-26 10:03:44
_STATISTICS_TAGS : BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES

Video
ID : 1
Format : Fraps
Codec ID : V_MS/VFW/FOURCC / FPS1
Duration : 1mn 16s
Width : 2 560 pixels
Height : 1 600 pixels
Display aspect ratio : 16:10
Frame rate mode : Constant
Frame rate : 30.000 fps
Default : Yes
Forced : No

Audio
ID : 2
Format : PCM
Codec ID : A_PCM/INT/LIT
Duration : 1mn 16s
Bit rate mode : Constant
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Default : Yes
Forced : No


------------------------------------------------------------
Index with ffmsindex
------------------------------------------------------------

"E:\Video\StaxRip_1.2.2.0\Applications\AviSynth plugins\ffms2\ffmsindex.exe" "D:\Spiele\BorderlandsPreSequel 2015-02-05 20-34-18-52_merged.mkv" "D:\Spiele\BorderlandsPreSequel 2015-02-05 20-34-18-52_merged temp files\BorderlandsPreSequel 2015-02-05 20-34-18-52_merged.ffindex"


------------------------------------------------------------
Error Index with ffmsindex
------------------------------------------------------------

Index with ffmsindex failed with exit code -1073741819

[stax76]

There is a ffmsindex memory leak with 2.20 64-Bit

General

Audio_Codec_List : DTS
Audio_Language_List : English
Codec/String : Matroska
FileSize/String4 : 9.837 GiB
Duration/String1 : 2h 8mn 15s 691ms
OverallBitRate/String : 11.0 Mbps
FrameRate/String : 23.976 fps
FrameCount : 184512
StreamSize/String : 200 MiB (2%)
Encoded_Date : UTC 2015-04-23 21:59:03
File_Created_Date_Local : 2015-04-24 21:24:08.430
File_Modified_Date_Local : 2015-04-24 08:34:08.485
Encoded_Application : mkvmerge v6.2.0 ('Promised Land') built on Apr 28 2013 12:22:01
Encoded_Library : libebml v1.3.0 + libmatroska v1.4.0

Video

ID : 1
Format_Profile : High@L4.1
Codec/String : AVC
Duration/String1 : 2h 8mn 15s 696ms
BitRate/String : 9 469 Kbps
Width/String : 1 920 pixels
Height/String : 800 pixels
PixelAspectRatio : 1.000
DisplayAspectRatio/String : 2.40:1
FrameRate/String : 23.976 fps
FrameCount : 184512
Resolution/String : 8 bits
ScanType : Progressive
StreamSize/String : 8.29 GiB (84%)
Encoded_Library : x264 - core 144 r2525 40bb568
Language/String : English
Default : Yes
Forced : No

Audio

ID : 2
Codec/String : DTS
Duration/String1 : 2h 8mn 15s 691ms
BitRate_Mode : CBR
BitRate/String : 1 509 Kbps
Channel(s)/String : 6 channels
SamplingRate/String : 48.0 KHz
Resolution/String : 24 bits
Compression_Mode : Lossy
Video_Delay : 0
StreamSize/String : 1.35 GiB (14%)
Language/String : English
Default : Yes
Forced : No

[Myrsloik]

I'm posting about it here as well since not everyone reads the VapourSynth thread...

Here's a ffms2 32bit test build (https://www.dropbox.com/s/6vxgt5npuyifjjw/ffms2-test1.7z?dl=1) from my own development branch. Compiled with latest libav.

I need help to test it to see so I didn't break anything for Avisynth users. If you don't test it now you'll be getting buggy Avisynth builds later.

[stax76]

Thanks for build although I could only test x64.

[stax76]

The ffmsindex memory leak is critical since a 8 GB movie causes ffmsindex to grow 8 GB memory, it's only happening with the x64 version.

[Myrsloik]

64 bit test build (https://www.dropbox.com/s/lc0x2qncwbaup45/ffms2-test1-x64.7z?dl=1). Basically the same code as the 32 bit one.

Report your results.

[stax76]

First thanks for your work and support. :thanks:

I confirm the ffmsindex leak is fixed but there is another problem, the filter reports 'No video track found' trying to open avc mkv.

[Myrsloik]

First thanks for your work and support. :thanks:

I confirm the ffmsindex leak is fixed but there is another problem, the filter reports 'No video track found' trying to open avc mkv.

When you do what exactly?

[stax76]

------------------------------------------------------------
Environment
------------------------------------------------------------

StaxRip version : 1.3.0.3
OS : Windows 7 Home Premium
Language : German (Germany)
CPU : Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz
GPU : NVIDIA GeForce GTX 960
LAV Filters : LAV Filters 0.65.0-2

------------------------------------------------------------
Source file MediaInfo
------------------------------------------------------------

C:\Daten\Temp\test\test.mkv

General
Unique ID : 179239962812818211157003190095008528769
Complete name : C:\Daten\Temp\test\test.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 65.4 MiB
Duration : 2mn 5s
Overall bit rate : 4 385 Kbps
Encoded date : UTC 2015-04-27 05:46:06
Writing application : mkvmerge v7.8.0 ('River Man') 32bit built on Mar 27 2015 16:18:02
Writing library : libebml v1.3.1 + libmatroska v1.4.2
DURATION : 00:02:05.185000000
NUMBER_OF_FRAMES : 6260
NUMBER_OF_BYTES : 1272797
_STATISTICS_WRITING_APP : mkvmerge v7.8.0 ('River Man') 32bit built on Mar 27 2015 16:18:02
_STATISTICS_WRITING_DATE_UTC : 2015-04-27 05:46:06
_STATISTICS_TAGS : BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 2mn 5s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Writing library : x264 core 146 r2538 121396c
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex /
subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 /
8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 /
lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 /
bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 /
direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 /
intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=22.0 / qcomp=0.60 / qpmin=0 /
qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Default : Yes
Forced : No

Audio
ID : 2
Format : Opus
Codec ID : A_OPUS
Duration : 2mn 5s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Default : Yes
Forced : No

------------------------------------------------------------
Index with ffmsindex
------------------------------------------------------------

"C:\Daten\Projekte\GitHub\staxrip\bin\Tools\Plugins\ffms2\ffmsindex.exe" "C:\Daten\Temp\test\test.mkv"
"C:\Daten\Temp\test\test temp files\test.ffindex"

Writing index... done.

Start: 11:44:34
End: 11:44:34
Duration: 00:00:00


------------------------------------------------------------
Error opening source
------------------------------------------------------------

FFVideoSource: No video track found
(C:\Daten\Temp\test\test temp files\test_new_Source.avs, line 2)

FFVideoSource("C:\Daten\Temp\test\test.mkv", cachefile = "C:\Daten\Temp\test\test temp files\test.ffindex")
AssumeFPS(25.000000)