FFmpegSource

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