FFmpegSource

[Leak]

Originally Posted by 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.

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]

Originally Posted by smok3

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.ph...02#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]

Originally Posted by Myrsloik

Version 1.7 already is compiled with gcc 4.2.1 which I got from http://forum.doom9.org/showthread.ph...02#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]

Originally Posted by Myrsloik

Version 1.7 already is compiled with gcc 4.2.1 which I got from http://forum.doom9.org/showthread.ph...02#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.

Originally Posted by 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

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]

Originally Posted by 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

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

[winnydows]

Myrsloik
for your plugin. I dream about it a lot of years. I add your plugin to my program:
XviD4PSP 5.000 beta 15 lite
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.