FFMS2 (The Fabulous FM Source 2)

[komisar]

TheRyuu, this (452) version dont "play" pcm-files created with `ffindex -f -c -t -1 -d -1 -v -s3 movie_file.mp4`...

[qyot27]

I don't know if this was caused by the fix in r451, but I was attempting to force the fps of an FLV file to 24000/1001 and the resultant MPEG-2 file had its audio sync skewed (as did the script itself when played in a media player) - since I didn't know if maybe it was a problem with HCenc 0.26's pulldown flagging, I removed the flags with DGPulldown and remuxed, but the desync was still there.  When I've used the same build on FLVs I'm forcing to 30000/1001, there's no desync (however, the 29.97 stuff is H.264/AAC, the skewed 23.976 is VP6F/MP3).

The FLV file in question was reported as 23.976 Constant fps by mediainfo, but using FLVExtract to dump the video, audio, and timecodes output the video fps as 23.444.  So I used avi2tc and inserted null frames into the video to make sure it equaled 23.976, and then loaded it and the decoded PCM audio track using AVISource.  No sync issue.  Loading that same corrected AVI file with FFVideoSource results in the desync also seen in the FLV.




On a related note, I've been getting crashes at the end of encoding using HCenc (both 0.25 and now 0.26).  It reports that it's ffms2.dll that crashed, but this doesn't happen with other programs, which makes me think it's HCenc.  On the other hand, rolling back to the vanilla 2.14 official build results in no crash.  But my own C-interface compiles (also vanilla, not -mt - at least not before that got merged) all exhibit the behavior, even with revisions close to when 2.14 was tagged.  I seem to recall the official 2.15 vanilla build crashing too, but can't say that definitively.

[sneaker]

No problem here using r452. Maybe you should upload a sample.

[qyot27]

No problem here using r452. Maybe you should upload a sample.

Are you referring to the desync or the crashing?

[qyot27]

In any case, here's the first 20 MBs of the problematic FLV I was talking about:
http://www.mediafire.com/?vski3makecnwf57

As a test, I also used FFmpeg (git-849f80f, the same one linked into the FFMS2 build I was using) and attempted to transcode the file.  Everything was synced properly.

[sneaker]

I was referring to your desync.

And I didn't notice any kind of desync using r452 and the following script:
audio=ffaudiosource("example.flv")
video=ffvideosource("example.flv",fpsnum=24000,fpsden=1001)
AudioDub(video, audio)

Or is the sample too short to see it?

[qyot27]

I was referring to your desync.

And I didn't notice any kind of desync using r452 and the following script:
audio=ffaudiosource("example.flv")
video=ffvideosource("example.flv",fpsnum=24000,fpsden=1001)
AudioDub(video, audio)

Or is the sample too short to see it?

It can be seen with that sample (the desync starts occurring before the title sequence even starts), but you're not specifying anything about what r452 you're using.  I explicitly said I was using the C-interface, not the trunk Visual Studio ones - if that ends up being the problem.

Moreover, the method I used was:
ffmsindex -t -1 example.flv

FFmpegSource2("example.flv",atrack=-1,fpsnum=24000,fpsden=1001)

Audio written first through wavi, video either passed to HCenc or to mencoder for intermediate processing to ffvhuff.  mencoder ends prematurely at around 97%.  The difference is worse at the end of the episode; taking the last 1000 frames, the audio is written completely, and mencoder ends at 36%.


This is the link to the FFMS2 build itself:
http://www.mediafire.com/?au46yfd3178ji8f

[sneaker]

I was using the following build:
http://code.google.com/p/ffmpegsource/downloads/detail?name=ffms2-mt-r452.7z&can=2&q=

/edit:
ok, I can reproduce the problem.
Using FFVideoSource() the sync is fine, using FFmpegSource2() it is not.
Don't know if this is a bug or a feature though.

/edit2:
don't have that problem when I use "my" build though

[qyot27]

The spam protection is getting on my nerves.  Seriously.

The post that's been rejected twice is here, just in case neither of the flagged ones end up being approved:
http://pastebin.com/n0ur81Zh

[sneaker]

And I experienced the desync while using FFVideoSource with mine*.

Just tested it again: me too. Maybe I mixed things up yesterday. Guess it's time for a dev to look into it.

[qyot27]

Just tested it again: me too. Maybe I mixed things up yesterday. Guess it's time for a dev to look into it.

As mentioned, it seems to appear under the following circumstances:

• C-interface branch, therefore compiled by GCC
• Using fpsnum and fpsden to force CFR.

Using said C-interface builds and not specifying the fps params results in no crash and no desync.  The problem is that with the posted sample, the framerate FFMS2 outputs is 23.395, which then causes issues with HCenc unless I use ChangeFPS to make it 23.976.  While that is something to keep in mind in the meanwhile, I'd prefer to use the internal framerate conversion instead.

[kemuri-_9]

the avs C interface branch was missing the latest 2 commits from the HEAD branch,
one of which had a commit comment of "Fix crash when the last frame is requested in forced cfr mode. Closes issue #41."

I'll try looking into this desync issue...

[qyot27]

the avs C interface branch was missing the latest 2 commits from the HEAD branch,
one of which had a commit comment of "Fix crash when the last frame is requested in forced cfr mode. Closes issue #41."

I'll try looking into this desync issue...

Yeah, I had been doing an 'svn merge' operation on it so that r451 and r452 would be included, or so I thought.  The stuff from r451 didn't report any conflicts, but r452 did - even though it was just the internal version numbers.

[kemuri-_9]

Yeah, I was doing an 'svn merge' operation on it so that r451 and r452 would be included.  Unless that's not actually sufficient?

that should suffice...

anyways, it looks like the C branch's fps conversion is broken as the frames it's generating is different from HEAD's
(C's is faster and this is causing the desync)
I'll have to look over the code differences between the two and see what's incorrect.

[Edit]
And..... that was easy (looks like a careless miss on my part on the original port to C), try r454
[/Edit]

[qyot27]

Thanks, r454 fixes it.  The HCenc end-of-encode crashes seem to be fixed now too - I was getting them with the 'svn merge'd r452, but since I'd already figured it was somehow related to the fps conversion, it killed two birds with one stone.

[qyot27]

I don't know how necessary/relevant this might be, but I've prepared a script for automatically packaging a build into a 7z archive with all of the files typically expected for distro.  I'm sure it could take some adjustment (I'm not really sure if those command -v lines are the smartest way to verify the right stuff is installed) and expansion to cover more than just the C interface.

Code: [Select]

#!/bin/bash
set -e
command -v todos &>/dev/null || { echo "Package 'tofrodos' required. Install it and try again." >&2; error 1; }
command -v 7za &>/dev/null || { echo "Package '7za' required. Install it and try again." >&2; error 1; }
PACKDIR=$((grep -w 'prefix=' config.mak) | cut -d = -f2- -)
REVNUM=$(svnversion .)
cd etc
cp * $PACKDIR/bin
cd ..
cp -R doc $PACKDIR/bin
cd $PACKDIR/bin
mkdir $PACKDIR/ffms2-avs_r$REVNUM
sed '3 c\
LoadCPlugin("C:\\Program Files\\AviSynth 2.5\\plugins\\ffms2.dll")' $PACKDIR/bin/FFMS2.avsi > $PACKDIR/bin/FFMS2a.avsi
mv $PACKDIR/bin/FFMS2a.avsi $PACKDIR/bin/FFMS2.avsi
todos $PACKDIR/bin/FFMS2.avsi
mv * ../ffms2-avs_r$REVNUM
7za a -mx9 $HOME/ffms2-avs_r$REVNUM.7z $PACKDIR/ffms2-avs_r$REVNUM -xr!?svn\*

[geminigod]

What type of AVI?  It sounds like the same issue I am having.  I indexed and encoded one lagarith AVI file just fine using ffms2 and meGui.  But now with a different one it has made the same error twice where the first ~10 seconds of video is skipped.  It may appear to be a desynching issue as described by others, but look more closely at it.  It isn't desynched.  Just an error at the beginning. 

Thoughts?  I'm assuming this is a job for the programmer.  (sigh) I guess its back to using DSS2.  Bummer.

[TheRyuu]

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)

Remember for the 64bit binary is an avisynth_c plugin so load with:

Code: [Select]

LoadCPlugin("X:\path\to\ffms2.dll")
Now with 100% more Opeth influence while building.

Changes from last build:
-Updated libav

What type of AVI?  It sounds like the same issue I am having.  I indexed and encoded one lagarith AVI file just fine using ffms2 and meGui.  But now with a different one it has made the same error twice where the first ~10 seconds of video is skipped.  It may appear to be a desynching issue as described by others, but look more closely at it.  It isn't desynched.  Just an error at the beginning.  

Thoughts?  I'm assuming this is a job for the programmer.  (sigh) I guess its back to using DSS2.  Bummer.

You should be using avisource for lags files.

[Chumbo]

Hello,
It's been awhile since the last time I encoded anything but was doing so successfully with megui.  I updated to the latest updates and now am having issues that I've narrowed down to opening the AVS which is using ffms2 and was wondering if anyone can please help.  I've Googled the issue but have not found anything that has fixed it yet.

I have an interlaced file I'd like to convert and crop (see mediainfo info below for the file) but I can't even play it with the following basic script.

Code: [Select]

LoadCPlugin("E:\MultiMediaTools\megui64\tools\ffms\ffms2.dll")
Load_Stdcall_Plugin("E:\MultiMediaTools\megui64\tools\yadif\yadif.dll")
FFVideoSource("D:\Media\work\video.1080.ts").AssumeFPS(30000,1001)

When I load the script into VirtualDub 1.9.11 (64bit) the file loads but the displayed frame is corrupted and when I play the file I get the error dialog with:
Avisynth read error:
Avisynth: unknown exception

File info:

Code: [Select]

General
ID                               : 1 (0x1)
Complete name                    : D:\media\work\video.1080.ts
Format                           : MPEG-TS
File size                        : 4.74 GiB
Duration                         : 1h 2mn
Overall bit rate                 : 10.9 Mbps
Maximum Overall bit rate         : 35.5 Mbps

Video
ID                               : 4113 (0x1011)
Menu ID                          : 1 (0x1)
Format                           : AVC
Format/Info                      : Advanced Video Codec
Format profile                   : Main@L4.0
Format settings, CABAC           : Yes
Format settings, ReFrames        : 4 frames
Codec ID                         : 27
Duration                         : 1h 2mn
Bit rate mode                    : Variable
Bit rate                         : 9 937 Kbps
Maximum bit rate                 : 20.0 Mbps
Width                            : 1 920 pixels
Height                           : 1 080 pixels
Display aspect ratio             : 16:9
Frame rate                       : 29.970 fps
Color space                      : YUV
Chroma subsampling               : 4:2:0
Bit depth                        : 8 bits
Scan type                        : Interlaced
Scan order                       : Top Field First
Bits/(Pixel*Frame)               : 0.160
Stream size                      : 4.33 GiB (91%)
Color primaries                  : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics         : BT.709-5, BT.1361
Matrix coefficients              : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177

Audio
ID                               : 4352 (0x1100)
Menu ID                          : 1 (0x1)
Format                           : AC-3
Format/Info                      : Audio Coding 3
Mode extension                   : CM (complete main)
Codec ID                         : 129
Duration                         : 1h 2mn
Bit rate mode                    : Constant
Bit rate                         : 384 Kbps
Channel(s)                       : 2 channels
Channel positions                : Front: L R
Sampling rate                    : 48.0 KHz
Bit depth                        : 16 bits
Compression mode                 : Lossy
Stream size                      : 171 MiB (4%)
Language                         : English

Any ideas to help resolve this are greatly appreciated.

[EDIT] I forgot to add that I'm running Win7U64 and the last successful encode was around August or September of 2010 on the same OS and computer.

[EDIT 2] I found an older ffms2.dll back from last August and I've confirmed that this one works fine.  The DLL has no version details in the properties so I have no idea.  I put it on mediafire here if you want it: http://www.mediafire.com/file/w7jpwx4qs6as3ke/ffms2.7z

[EDIT 3] I have one more issue now, going back to the older DLL has broken ffmsindex.exe as the latest isn't compatible with that version.

[TheFluff]

Lagarith support in ffmpeg is still experimental and it doesn't work very well at all, really. Don't use ffms2 for Lagarith, at least not yet.
(ps: don't use Lagarith at all)

[Chumbo]

For my issue above, TheRyuu made some suggestions of which one worked.  That being to use threads=1 with FFVideoSource.  It works but is extremely slow.  On a first pass with x264 (via megui) I get around ~18fps where the 32bit version using dss2 I get ~65fps.  Hopefully a fix soon?

[TheFluff]

For my issue above, TheRyuu made some suggestions of which one worked.  That being to use threads=1 with FFVideoSource.  It works but is extremely slow.  On a first pass with x264 (via megui) I get around ~18fps where the 32bit version using dss2 I get ~65fps.  Hopefully a fix soon?

hahaha you want to load an interlaced h264 ts with ffms2
you might as well go throw your cpu cycles at playing conway's game of life or something, that'd be more productive

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.
- progressive h264: only safe way to get this to work is demuxer="lavf" and seekmode=0 or -1 (-1 prevents wasting cpu cycles on pointless shit).
- 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.
- any type of vc1: it is a mystery

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.

[TheRyuu]

ffms2-r473.7z
ffms2-r473-avs64.7z

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

[Snowknight26]

The following file makes FFMS2 exhibit a large memory leak:
http://stfcc.org/misc/ffms2.memleak.sample.ts

[Myrsloik]

The following file makes FFMS2 exhibit a large memory leak:
http://stfcc.org/misc/ffms2.memleak.sample.ts

With libav or haalits as the demuxer? or both?

[Snowknight26]

Whatever the default is. I'll investigate further if necessary.

[TheRyuu]

ffms2-r484.7z
ffms2-r484-avs64.7z

Changes since last build:
-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

[TheRyuu]

ffms2-r507.7z
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.

Code: [Select]

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.

[kemuri-_9]

I need some victi-*cough*-volunteers to test an experimental build of the ffms2 c-style plugin.

Q: why? what is there to test now?
A: Simultaneous 2.5 and 2.6 support.

that's right, i'm trying to get it to work for 2.6 - adding support for the new csps (Y8, YV411, YV16 and YV24 - yes ffmpeg supports them all), while not breaking backwards support for 2.5

Q: How should i test it?
A1: if you're a 2.5 user, continue using it like normal - if it doesn't work, say something.
A2: if you're a 2.6 user, try using the new csps - if they don't work, say something.

Q: why only 32bit?
A: because that's what most people are still using.

Q: why the c plugin, isn't it inferior to the C++ plugin?
A1: I don't like MSVC that much.
A2: the C plugin is my playground.

Q: LoadPlugin doesn't work, what am I doing wrong?
A: it's LoadCPlugin

ffms2_25_26_dual_experimental.zip

[qyot27]

How to determine that the output is properly being handled?

With a 4:4:4 H.264 file:
Playback in DirectShow-based players through AviSynth+experimental FFMS2 is grayscale, presumably because of lack of a video renderer that supports it or something (is there one for XP?  The original 4:4:4 file has correct colors through DirectShow when played normally, but not when loaded in a script).

VirtualDub 1.9.11 shows correct colors from the script.  Under 'Color Depth', Decompression format is set to Autoselect, Output format is set to Same as decompression format.  File Information reports Internal DIB decoder (YV24) as the Decompression format.

avsmeter reports the colorspace as YV12.

avs2avi 1.40a reports "YV24 (not tested)", output to uncompressed (-c null), and the mediainfo readout of the resulting file is YV24.

Playback of resulting file in mplayer2 has correct colors and reports colorspace as yuv444p.


AviSynth 2.6 (110525), [any other relevant statistics needed here?], script was:

Code: [Select]

LoadCPlugin("ffms2.dll")
FFVideoSource("test.mp4",colorspace="YV24")

I'd guess it wouldn't really matter what compression format the loaded files use, so long as it's in one of the desired colorspaces?  Uncompressed is as good as any other format is, or would different formats need specific testing?