FFmpegSource

[MatMaul]

At least with libfaad2 because don't exist a good dedicated aac decoder for AviSynth, actually we need use DirectShowSource.

For ac3 (and mpa, mp2, mp3) we can use NicAudio.dll also based in liba52.
For WAVE_FORMAT_EXTENSIBLE, ogg, flac, wma, ... we can use BassAudio.dll and Bass libraries + Add-Ons. BassAudioSource can decode stereo aac/mp4 but don't work for multichannel aac.
yes but with ffmpegsource we can do that without demux the avi or mkv and it is great :)

[Lele-brz]

Hi,
I switched to this amazing FFMpegSource for some of the video like mp4 container, I found it more reliable than DirecShowSource especially for x264 encoding.
Now I'd like to use it for a video with this specs:
container: flv, video: vp6f, audio: mp3
But it doesen't work, is it only a problem of libraries, since the latest ffplay can read it.

thanks in advance for any help

Bye

[ajp]

I suggest liba52 and libfaad2 then we can decode ac3 and aac streams which are very common.

I agree, that would be sweeeet.... :devil:

[Susana]

What's the problem with directshow-based ones? :confused:

[ajp]

Is there a size limit for the input file? When I tried earlier today it wouldn't accept a 8.5GB file but a smaller segment of the same file was ok.... ?

[Myrsloik]

It's probably limited to 4GB or so because of the fseek usage. It could probably be fixed for matroska but I have no idea what to do about libavformat.

[ajp]

It's probably limited to 4GB or so because of the fseek usage. It could probably be fixed for matroska but I have no idea what to do about libavformat.

What a shame, too bad it isn't an easy fix. At least now I know it won't work, thanks. :)

[Lele-brz]

I'm not sure the limit is 4Gb, I was able to encode a 5.15 Gb video using FFMpegSource

container: mov
video: dvvideo
audio: pcm_s16be
duration: 24:18
bitrate: 30.341 kbps

[ajp]

I'm not sure the limit is 4Gb, I was able to encode a 5.15 Gb video using FFMpegSource

container: mov
video: dvvideo
audio: pcm_s16be
duration: 24:18
bitrate: 30.341 kbps

Hmmm, that's odd. I'll have to try it on some more large files then. My input was a .mkv-file. I'll try the new AutoMKV as well... (and yes, the partition is NTFS :) )

[ajp]

Nope, tried a second 8GB file and I get the same error message...

FFMpegSource: Can't parse Matroska file: I/O Error: Invalid argument

I'm on Vista (32bit), maybe that's why... :-O

[Myrsloik]

New test compile that should fix the issues with huge mkv files and mpeg2 in mkv:
deleted

Note that it requires the dlls from the normal package and that it now uses the AVISYNTH_C interface. ONLY FOR TESTING.

[video_magic]

Hurrah for Myrsloik!!!! :thanks: Very useful and time-saving :)

[ajp]

New test compile that should fix the issues with huge mkv files and mpeg2 in mkv:
http://ivtc.org/new/beta/FFmpegSource.dll

Note that it requires the dlls from the normal package and that it now uses the AVISYNTH_C interface. ONLY FOR TESTING.

Nice! However, I get a message saying "ffmpegsource.dll is not an Avisynth 2.5 plugin"?

[Myrsloik]

That could be because it isn't one. As I wrote in the post, quoted by you for additional effect, it uses the the c interface. Load it with load_stdcall_plugin or loadcplugin.

[buzzqw]

would be possible to build with standard interface ? with loadplugin ? is more handy

thanks

BHH

[ajp]

Sorry 'bout that, I had no idea there was such a thing... :eek:

Now I get 'access violation' though, maybe I'm doing something wrong...

[Myrsloik]

Another updated version has been released that fixes lots of trivial typos in the code that have shown up through the versions and adds aac and ac3 decoding support to the included libavcodec.

The website is also hosted at a real webspace provider now so the download speeds should be much better.

[ajp]

The ffmpegsource.dll is still dated 07/18/2007 and says 'audio codec not found' when fed a source with ac3? Still v1.4? Other than that, can't wait to try the new one... :)

[Myrsloik]

No, it's the right one and it works here. Check the version number listed in the documentation if you think you've somehow gotten an older version.

[ajp]

Hmmm, that's weird.. now it's the correct version. Maybe I had it cached or something... thanks!

[ajp]

Can't get audio (ac3) to work in .mkv files, I just get silence. I also get a lot of messages when encoding that it's ignoring certain matroska headers. VOB seems to work and .avi with ac3 as well. Also, the audio cache gets pretty huge, is that normal?

[Myrsloik]

New version uploaded that should fix ac3 and some other audio formats in matroska.

It's normal that the audio cache is huge since the whole file is stored as raw pcm in it. It's also why audio isn't opened by default.

[ajp]

Wow, that was quick! I'm beginning to feel like a pain in the rear... ;) Makes sense about the audio, better than demuxing it myself anyway... cheers! :D

[ajp]

Now I get "System exception - Stack overflow" with .mkv... :eek:

[Myrsloik]

Exactly what does the mkv contain? Could you cut a piece of it and upload to ftp://upload:upload@mellbin.org ?

[ajp]

It contains just an AVC/H264 video stream and the AC3 stream...

Uploading a sample shortly...

[Myrsloik]

It works here. Did you try deleting all old cache files?

[ajp]

Yes, deleted all old cache files. I'll reboot my machine shortly too just in case...

What commandline did you use in your .avs?

[ajp]

Doh! It was only when playing the .avs in WMP11, MPC works fine...

Another problem (surprise).. now my wmcmd.vbs won't recognize the audio format, I guess that's because it's 6ch PCM and not 6ch WAV?

Edit: Ah, enabling ffdshow raw audio took care of the wmcmd.vbs problem... :)

[foxyshadis]

I don't have a problem with the audio cache, if random access methods are going to cause problems. But would it be possible to either pass each block through zlib first, or designate the file as compressed? (ie, by passing FILE_ATTRIBUTE_COMPRESSED to CreateFile.) Doesn't help much, but since disk i/o will be the big blocker there, it'll help some.

[Leak]

I don't have a problem with the audio cache, if random access methods are going to cause problems. But would it be possible to either pass each block through zlib first, or designate the file as compressed? (ie, by passing FILE_ATTRIBUTE_COMPRESSED to CreateFile.) Doesn't help much, but since disk i/o will be the big blocker there, it'll help some.
How about storing (rolling) checksums of, say, 4KB blocks of audio instead (like rsync does) so that you can start decoding at some approximate position in the compressed audio and figure out where you actually are after decoding at most 8kB minus one byte followed by adjusting accordingly? (i.e. seek back some more or decode a bit more until you hit the right sample)

That way you get sample-accurate seeks to each 4kB position while only having to store only a fraction of the current amount of data, with only a small performance hit after a seek.

np: Thomas Fehlmann - Atlas 2 (Honigpumpe)

[Myrsloik]

The following information could be very wrong since most of my observations come from comp.exe and not even a real hex editor...

The things I've tried so far is to index the audio in a way similar to the video, demuxing the raw audio stream to its own file to eliminate inaccurate seeking and the current method. Demuxing the audio to a separate file didn't make any real difference in decoding behavior in most cases.

Some kind of state does however seem to be kept by some decoders (mp3 which I mainly tested with) that means you won't get the same output even if you start at a much earlier point. Interestingly enough offset isn't what made me give up but the fact that the decoded samples seemed to be off by +-1 in a systematic way.

I could resurrect the most working version of the code as a separate filter if anyone wants to try their luck. Don't think anyone really commented on how it worked before it was removed.

I think I'll go read the flac documentation now...

[smok3]

all i ever get is: cant load ffmpegsource.dll..., what is there to do?

[Leak]

all i ever get is: cant load ffmpegsource.dll..., what is there to do?
Are you using LoadCPlugin to load it? (Note the extra "C" in there...)

[smok3]

yes, i have tried all possible things.

[buzzqw]

unzip ffmpegsource.zip in your \windows\system32, and overwrite all file

then take the ffmpegsource.dll and put where you want

load it with standard LoadPlugin

BHH

[CruNcher]

could it be that ffmpegsource is damaged ? i get this here after some encodes (1920x1080p 23.976 Film) of the same clip in the cmd

Compiler did not align stack variables. Libavcodec has been miscompiled
and may be very slow or crash. This is not a bug in libavcodec,
but in the compiler. Do not report crashes to FFmpeg developers.

System is AMD Athlon 64 Venice @ 2.4 Ghz Windows XP SP2
playbacking the .avs with mpc works fine tough but encoding results in output errors (strange blocks, luma changes)

[Gusar]

The bug is, as the message says, in the compiler. Only the recently released gcc-4.2 for MinGW compiles correct code, older MinGW compilers do not.

[Myrsloik]

Version 1.7 already is compiled with gcc 4.2.1 which I got from http://forum.doom9.org/showthread.php?p=1028402#post1028402 since
3.4.5 couldn't even link faad2 and a52dec properly. So there has to be more to it than just the compiler version.

[Gusar]

Version 1.7 already is compiled with gcc 4.2.1 which I got from http://forum.doom9.org/showthread.php?p=1028402#post1028402 since
3.4.5 couldn't even link faad2 and a52dec properly. So there has to be more to it than just the compiler version.Some MinGW fixes have been added to ffmpeg revision 10106 (Aug 13). If your build is older, that's the problem.

[TheRyuu]

Version 1.7 already is compiled with gcc 4.2.1 which I got from http://forum.doom9.org/showthread.php?p=1028402#post1028402 since
3.4.5 couldn't even link faad2 and a52dec properly. So there has to be more to it than just the compiler version.

Your right it is more then just the compiler.
The 3.4.x versions are the ones that break libavcodec, not to mention can't link those items properly.

The newer 4.2.x versions shouldn't break it.
This is based off of experience with libav with xbmc's mplayer.dll.

I suppose ffmpeg shouldn't be that much different.

could it be that ffmpegsource is damaged ? i get this here after some encodes (1920x1080p 23.976 Film) of the same clip in the cmd

System is AMD Athlon 64 Venice @ 2.4 Ghz Windows XP SP2
playbacking the .avs with mpc works fine tough but encoding results in output errors (strange blocks, luma changes)

It's normally a compiler error.
And it can break some decoding options in libavcodec.

[Myrsloik]

Try the new version and see what happens.

[smok3]

unzip ffmpegsource.zip in your \windows\system32, and overwrite all file

then take the ffmpegsource.dll and put where you want

load it with standard LoadPlugin

BHH

great, that did it, can i expect to get some aac audio throught this?

[winnydows]

Myrsloik
:thanks: for your plugin. I dream about it a lot of years. I add your plugin to my program:
XviD4PSP 5.000 beta 15 lite (http://winnydows.com/download/xvid4psp/XviD4PSP_5000_beta_15_lite.exe)
Framework 3.0 required.

One question:
How i can change audio track in your plugin ?

Best regards in your developing. You my Saviour.

[Myrsloik]

From The Book of Encoding chapter 5 verse 9:
atrack & vtrack: Track number as seen by the relevant demuxer, starts from 0, -1 means it will pick the first suitable track and -2 means it's disabled.

I've had some more time to figure out how to use flac for the audio cache and it seems possible with very little work since the library actually supports sample accurate seeking natively. There ara however a few implementation details I don't know what to do about...

Should it be possible to select between raw pcm and flac compression? There will be at least one added argument for flac's compression level anyway since there's a big difference in speed between them.

If yes, should the uncompressed cache be extended to write real wav files instead of just raw pcm? Would that improve anything for people who just want the audio decoded for processing with other programs?

Note that it should be easy to autodetect the cache type so it wouldn't cause any issues to implements all 3 (pcm/raw/flac) options.

[CruNcher]

@ Myrsloik
yep no more message no problems anymore thx :)

[MatMaul]

hey !
first thanks for this great plugin.

do you think the support for mov files can be added please ?

I would like to open the video of my camera (mov file, mjpeg codec) with this plugin. My videos play fine with ffmpeg.exe

[Myrsloik]

Upload the file or a part of it to ftp://upload:upload@mellbin.org/ and I'll take a look at it when I've got the time.

[MatMaul]

done !

[Myrsloik]

The bugs have been found and the file will work in the next version. The stack overflow was caused by av_find_stream_info() needing a really big stack. It is now executed in a separate thread with 4MB of stack all to itself. No idea why it needs so much but it works.