FFmpegSource

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