Author Topic: FFMS2 (The Fabulous FM Source 2) (Read 84036 times)

TheFluff · « **Reply #180 on:** January 27, 2011, 02:21:19 AM »

I'm here but I don't debug -mt builds. If you can reproduce it with a build using a vanilla ffmpeg I'm all ears but -mt is Somebody Else's Problem.

forclip · « **Reply #181 on:** January 27, 2011, 04:10:48 AM »

Sure, that`s why I asked about

Quote

complie non-MT 32-bit version too

Procrustean · « **Reply #182 on:** January 27, 2011, 09:10:06 AM »

Quote from: forclip on January 27, 2011, 04:10:48 AM

complie non-MT 32-bit version too

http://ge.tt/2gBFf0x/ - no-MT
works fine for me

forclip · « **Reply #183 on:** January 27, 2011, 09:19:20 AM »

Procrustean
Thanks! Works fine for me too. Not crashes on my sample and no problems with seeking.

TheFluff · « **Reply #184 on:** January 27, 2011, 04:36:35 PM »

I'm planning to release 2.15 quite soon. Have a test build (vanilla ffmpeg as usual): http://mod16.org/ffms2/ffms2-r426.7z

Changes since 2.14:

FFMS2 can now be used to decode Lagarith, but note that libavcodec's decoder is very experimental at the moment. (Plorkyeran)
SWScale can now use SSE2 optimizations for certain operations if your CPU supports it. (kemuri_-9)
Fixed a bug that could cause SWScale initialization to fail. (kemuri_-9)
Fixed a bug that could cause index files to never be considered valid, forcing a reindexing every time a script was loaded. (TheRyuu)
Trying to use postprocessing on a fullrange YUV clip will no longer cause errors. (TheFluff)
Fixed a few random decoding bugs related to unaligned memory or buffers that were not initialized properly. (TheFluff)
It is now possible to force FFMS2 to use a specific demuxer instead of letting it pick one automatically. (TheFluff)
When converting YUV to RGB, FFMS2 will now try to actually use the correct color coefficients rather than assuming everything is bt470bg. (Plorkyeran)
Moved support for container-level audio delay from the Avisynth plugin to the core and exposed it in the API (Plorkyeran)
Audio decoding has been substantially reworked. Linearly decoding audio now almost always works correctly and seeking is now actually sample-accurate for many formats. (Plorkyeran)
It is now possible to build 64bit versions of the plugin for use with Avisynth (and whatever else) from MSVC by means of black magic (this probably only works when the planets are aligned, also 64bit builds might require msvcr90.dll). (TheRyuu)
The Avisynth plugin now supports UTF8 filenames; ffmsindex.exe also supports Unicode filenames. FFMS_USE_UTF8_PATHS is now a runtime option instead of a compile-time one. (TheFluff)
The FFInfo() function (supplied by ffms2.avsi) will now round timestamps to nearest millisecond instead of truncating them. It's also been cleaned up in general and no longer relies on global variables. (Gavino)
Containers opened with libavformat will now report a framerate based on the average frame duration instead of the duration of the first frame, just like Matroska files and files opened with Haali's splitter does. Should fix CFR framerates being reported incorrectly in dumb containers like FLV. (TheFluff)
PC/TV luma range (16-235 versus 0-255) detection should now be a bit more reliable. (TheFluff)
Fixed a crash when opening files with Unicode filename support enabled. (Plorkyeran)

Quite a few regressions in earlier test builds have also been fixed.

To force a demuxer, use demuxer="lavf" as an argument to ffindex(). Possible choices are lavf, matroska, haalimpeg and haaliogg.

forclip · « **Reply #185 on:** January 28, 2011, 12:23:10 AM »

I have another problem\question. It seems like FFAudioSource have some troubles with decoding audio from the *.wmv files.
With "adjustdelay=-3" I can open the file, but after seeking I get this error message "FFAudioSource: Seeking is severely broken", so only linear access is working.
With default "adjustdelay=-1" or "adjustdelay=-2" I get crash immediately.

Sample, but I think that this can be reproduced with any *.wmv files.

Code: [Select]

FFAudioSource("F:\Sample2.wmv")

= crash.

Can be something done about this? Or is it a known limitation? Thanks.

-----

ffms2-mt-r411 and ffms2-r426 - as described above
ffms2-mt-r375 - audio screwed

2.14 and ffms2-r363 - seems works fine

Plorkyeran · « **Reply #186 on:** January 28, 2011, 12:13:22 PM »

WMA seeking was broken in a ffmpeg change about a month ago; I haven't gotten around to investigating if it's a lavc bug or a ffms2 bug that was simply exposed by a change.

It turns out that I never actually pushed the commit which made audio delay handling work correctly. That crash should be fixed in r428.

forclip · « **Reply #187 on:** January 29, 2011, 01:17:52 AM »

OK, thanks.

kypec · « **Reply #188 on:** January 30, 2011, 02:41:29 AM »

Quote from: Plorkyeran on January 28, 2011, 12:13:22 PM

That crash should be fixed in r428.

I can't see that revision released on Google project page downloads yet...when will be or where else is the build available?
Thanks!

forclip · « **Reply #189 on:** January 30, 2011, 04:37:38 AM »

kypec
See the link above from Procrustean.

r430 - yes, works fine for me now. Thanks for the fix!

------

However, I have another question, or maybe it`s more likely a feature request. When I use FFAudioSource like this

Code: [Select]

FFAudioSource("some_file_1.m4a", cachefile="c:\my_temp\audio_cache.ffindex")

I get index file created* in "my_temp" folder - OK. But now, if I change the audio file w/o changing the index file name (I need it for some reasons) I will get error message "FFAudioSource: The index does not match the source file" - yes

But is it possible some how to force re-indexing of my file in this case? "cache=false" - this is not what I want, because in this case re-indexing will be started every time when I load the script. But I need it only in one case: when "The index does not match the source file". Is it possible to add an option for this?

*only if this folder exist, otherwise i get error message: "Failed to open "c:\my_temp\audio_cache.ffindex" for writing", same thing with function FFindex.

Plorkyeran · « **Reply #190 on:** January 30, 2011, 07:41:56 PM »

I don't really see any reason for an out of date index to be an error in the first place. There's already plenty of cases where it'll automatically replace the already-present index file.

TheFluff · « **Reply #191 on:** January 31, 2011, 04:16:14 AM »

I think it does that (complain that the source does not match the index instead of automatically replace it) if you explicitly specify an index filename, because by doing so you're telling FFMS that you have a very specific file that you would like to use, so instead of silently overwriting it, it errors out.

TheRyuu · « **Reply #192 on:** January 31, 2011, 09:20:55 PM »

ffms2-mt-r430.7z
ffms2-mt-r430-avs64.7z

Uses a slightly older ffmpeg-mt to avoid the issues with the new one for now.
I tested the crashing sample earlier in this thread and it appeared to work fine. It also worked on another sample I had which had issues with the newer ffmpeg-mt.

If anyone has issues with these (although I suspect it should be fine) let me know.

Edit:
Some vanilla ffmpeg builds if you want them (dunno why):
ffms2-r430.7z
ffms2-r430-avs64.7z

sneaker · « **Reply #193 on:** January 31, 2011, 10:09:36 PM »

Already posted it on doom9, but since it's still offline:

The following sample will get jerky if you specify fpsnum=24000 and fpsden=1001:
http://www.mediafire.com/?jfr22uqg3c122rl

Tested on r426 and r430 single thread version.

TheRyuu · « **Reply #194 on:** January 31, 2011, 11:45:13 PM »

Quote from: sneaker on January 31, 2011, 10:09:36 PM

Already posted it on doom9, but since it's still offline:

The following sample will get jerky if you specify fpsnum=24000 and fpsden=1001:
http://www.mediafire.com/?jfr22uqg3c122rl

Tested on r426 and r430 single thread version.

Does it work correctly if you don't specify fpsnum/fpsden?

sneaker · « **Reply #195 on:** January 31, 2011, 11:51:36 PM »

forclip · « **Reply #196 on:** February 02, 2011, 04:35:14 AM »

Quote from: TheFluff on January 31, 2011, 04:16:14 AM

I think it does that (complain that the source does not match the index instead of automatically replace it) if you explicitly specify an index filename, because by doing so you're telling FFMS that you have a very specific file that you would like to use, so instead of silently overwriting it, it errors out.

It will complain about that even if the index file wasn`t explicitly specified. How about changin this behavior or making an option for this?

TheFluff · « **Reply #197 on:** February 02, 2011, 05:11:54 AM »

I guess I can add an overwrite parameter to ffvideosource/ffaudiosource so they behave just like ffindex does.

forclip · « **Reply #198 on:** February 02, 2011, 08:09:42 AM »

So index file will be re-created every time I reload the script? Hm.. not exactly what I want..

forclip · « **Reply #199 on:** February 11, 2011, 10:23:07 AM »

Hi there. Thanks for r431

I have another problem. When I`m trying to open an mkv file with compressed header, I get Access Violation on closing AviSynth environment.

Sample file, AviSynth script:

Code: [Select]

FFAudioSource("f:\zlib-001.mkv")

or

Code: [Select]

video=BlankClip()
audio=FFAudioSource("f:\zlib-001.mkv")
audiodub(video, audio)

Open this script in AvsP and load preview. Now, if you don`t get error message immediately, press F5 button or close the tab. Same thing happens with MPC-HC (File->Close).

With version ffms2-mt-r375 - all works fine, with version ffms2-r408 and more recent - as described above.

--------

r431:

Message "FFVideoSource: Cache will overwrite the source" in CreateFFAudioSource() - copy-paste typo?

TheFluff · « **Reply #200 on:** February 11, 2011, 04:45:47 PM »

All of those are fixed in 2.15, which is out now. You can grab it from the Google Code page.

Changes since 2.14:

FFVideoSource and FFAudioSource will now automatically reindex and overwrite the index file if it doesn't match the file being opened and the cachefile argument is left as the default. (Plorkyeran)
FFMS2 can now be used to decode Lagarith, but note that libavcodec's decoder is very experimental at the moment. (Plorkyeran)
SWScale can now use SSE2 optimizations for certain operations if your CPU supports it. (kemuri_-9)
Fixed a bug that could cause SWScale initialization to fail. (kemuri_-9)
Fixed a bug that could cause index files to never be considered valid, forcing a reindexing every time a script was loaded. (TheRyuu)
Trying to use postprocessing on a fullrange YUV clip will no longer cause errors. (TheFluff)
Fixed a few random decoding bugs related to unaligned memory or buffers that were not initialized properly. (TheFluff)
It is now possible to force FFMS2 to use a specific demuxer instead of letting it pick one automatically. (TheFluff)
When converting YUV to RGB, FFMS2 will now try to actually use the correct color coefficients rather than assuming everything is bt470bg. (Plorkyeran)
Moved support for container-level audio delay from the Avisynth plugin to the core and exposed it in the API (Plorkyeran)
Audio decoding has been substantially reworked. Linearly decoding audio now almost always works correctly and seeking is now actually sample-accurate for many formats. (Plorkyeran)
It is now possible to build 64bit versions of the plugin for use with Avisynth (and whatever else) from MSVC by means of black magic (this probably only works when the planets are aligned, also 64bit builds might require msvcr90.dll). (TheRyuu)
The Avisynth plugin now supports UTF8 filenames; ffmsindex.exe also supports Unicode filenames. FFMS_USE_UTF8_PATHS is now a runtime option instead of a compile-time one. (TheFluff)
The FFInfo() function (supplied by ffms2.avsi) will now round timestamps to nearest millisecond instead of truncating them. It's also been cleaned up in general and no longer relies on global variables. (Gavino)
Containers opened with libavformat will now report a framerate based on the average frame duration instead of the duration of the first frame, just like Matroska files and files opened with Haali's splitter does. Should fix CFR framerates being reported incorrectly in dumb containers like FLV. (TheFluff)
PC/TV luma range (16-235 versus 0-255) detection should now be a bit more reliable. (TheFluff)
Fixed a crash when opening files with Unicode filename support enabled. (Plorkyeran)

I've updated the Avisynth plugin documentation a bit; it should be easier to read and understand now. I've also updated the known issues part of it, so all actual known issues are listed there now. If you find a problem that isn't listed there, please report it, regardless of what I or other people have said or claimed about it in the past.

forclip · « **Reply #201 on:** February 11, 2011, 05:36:01 PM »

Thanks!

Well, another problem with the same sample. After seeking i get error message: "FFAudioSource: Error decompressing data: ZLib error." - is it fixable?

TheFluff · « **Reply #202 on:** February 12, 2011, 04:55:35 AM »

Doubtful. That error comes from within Haali's matroska parser itself, so chances are you are actually looking at a damaged stream there. Does it happen in the small sample you uploaded for me too? If so, where in the sample?

forclip · « **Reply #203 on:** February 12, 2011, 10:39:21 AM »

Quote from: TheFluff on February 12, 2011, 04:55:35 AM

Does it happen in the small sample you uploaded for me too? If so, where in the sample?

Yes, just try to seek or play it till the end and then press Play button again w/o closing the file, so player will seek to the beginning (tested with MPC-HC).
Hm.. it seems like only backward seeking is broken.

-------

One more thing.

Quote

Seeking should be sample-accurate with most codecs in AVI, MKV, MP4 and FLV with two notable exceptions, namely MP3 and AC3 where FFmpeg's decoders seem to be completely broken

I have another sample (here it is), "FFAudioSource: No audio track found" - that`s what I get. But FFplay can play it and FFmpeg can see the audio stream. It`s another problem, or the same ("FFmpeg's decoders seem to be completely broken")?

Plorkyeran · « **Reply #204 on:** February 12, 2011, 05:37:51 PM »

Quote from: forclip on February 12, 2011, 10:39:21 AM

One more thing.I have another sample (here it is), "FFAudioSource: No audio track found" - that`s what I get. But FFplay can play it and FFmpeg can see the audio stream. It`s another problem, or the same ("FFmpeg's decoders seem to be completely broken")?

The last packet of that file fails to decode (which is pretty common), and for some bizarre reason FFAudioSource uses error handling mode 1 (pretend the track doesn't exist) for indexing. Explicitly calling FFIndex lets you override this (or just leave it at the default as FFIndex defaults to ignoring errors).

forclip · « **Reply #205 on:** February 12, 2011, 06:55:04 PM »

Thanks. It requires one extra-step, but it works.

Gweilo · « **Reply #206 on:** March 04, 2011, 09:35:23 PM »

In the docs it says :

Quote

Seeking should be sample-accurate with most codecs in AVI, MKV, MP4 and FLV with two notable exceptions, namely MP3 and AC3 where FFmpeg's decoders seem to be completely broken (with MP3 in particular you can feed the decoder the same encoded data three times in a row and get a different decoded result every time). Still, results should usually be "good enough" for most purposes.

What does "good enough" mean here? Within a few hundredths of a second?
It does seem to be "close enough" when I play a script anyway.

I've used FFMS2 on AVIs with VBR MP3 as it makes it much easer to edit (setting Trims, replaying, adjusting, adding fade, etc) as it doesn't have to rewind the whole file to start playing in sync as it does using Avisource (with EnsureVBRMP3sync()).

Would it be advisable to swap the source back to Avisource() for my encode after all the editing is done?

TheFluff · « **Reply #207 on:** March 06, 2011, 11:02:12 PM »

Quote from: Gweilo on March 04, 2011, 09:35:23 PM

In the docs it says :
What does "good enough" mean here? Within a few hundredths of a second?

Something like that. It's probably safe to use FFMS2 unless you actually do need exact sample-accuracy.

Plorkyeran · « **Reply #208 on:** March 07, 2011, 11:51:24 AM »

In the case of MP3 and AC3, there shouldn't be any sort of accumulated error or desync, so if you can't hear anything wrong at the trim points there's nothing to worry about. Tossing in EnsureVBRMP3sync for the final encode after you're done editing will probably eliminate the errors entirely, but unless bit-exact decoding is a hard requirement it probably won't make a noticeable difference.

TheRyuu · « **Reply #209 on:** March 15, 2011, 03:46:34 AM »

ffms2-mt-r452.7z
ffms2-mt-r452-avs64.7z

There was a rather large merge a few days ago that brings ffmpeg-mt up to date (first one since 12/2010 I believe). And I guess ffmpegsource got a fix or two since 2.15.

News:

Author Topic: FFMS2 (The Fabulous FM Source 2) (Read 84036 times)