FFmpegSource

[LoRd_MuldeR]

What is your current work-flow? In case it's tsmuxer > mkvmerge > ffms2

Exactly.

you can try DGDecNV instead if you capture much and have a Nvidia card.

I do have a Nvidia card (GTX260), but I don't have a DGDecNV license. And I'm currently not planning to buy one (as I don't have a PayPal account or Credit Card and don't plan to get one).

BTW: DGAVCDecode fails on my streams. It crashed reproducible. I guess that is because of the hopelessly outdated libavcodec that it uses...

[Guest]

All developers get free licenses. Send me a PM with your email addie for registration if you want it.

[TheFluff]

http://www.mod16.org/ffms2/ffms2-r338.7z

Go test this. Fixes a heap corruption/crash and possibly a memleak when using Haali's splitter on a h264 ts.

This will become 2.14 unless someone complains.

[LoRd_MuldeR]

Sorry, but I still get constantly increasing "private bytes" until it crashes:

http://img194.imageshack.us/img194/5852/ffms2memleak3.th.jpg (http://img194.imageshack.us/img194/5852/ffms2memleak3.jpg)

[kemuri-_9]

It still doesn't look like that the bitstream filtering is being done correctly...

try and see if ffms2-maybe-fix.rar works fine
(been a loooong time since i built ffms2 through visual studio, so it may be a bit bumpy)
It'll probably either explode magnificentally or work as intended.
patch is included...

[LoRd_MuldeR]

Thanks kemuri-_9, but no luck either:

It takes some time to index and then crashes reproducible:

http://img843.imageshack.us/img843/6964/ffms2memleak4.th.jpg (http://img843.imageshack.us/img843/6964/ffms2memleak4.jpg)

[asarian]

So, where's the 2.14 release then? All I see on google code page is 2.13 still.

[Myrsloik]

http://www.mod16.org/ffms2/ffms2-r338.7z
This will become 2.14 unless someone complains.

Then kemuri objected... he'll probably make the release cycle longer than for CCCP by objecting.

[asarian]

Then kemuri objected... he'll probably make the release cycle longer than for CCCP by objecting.

Thanks for the clarification. I merely looked at the changelog on the first page. My bad.

[kemuri-_9]

Then kemuri objected... he'll probably make the release cycle longer than for CCCP by objecting.

huh? Are you implying that I'm at fault here?
I was just trying to fix the issue that LoRd_MuldeR is still reporting that was supposedly already fixed.
but my change just broke more stuff, so it should be ignored....

2.14 can go out as long as its noted to not use it with h.264 in TS which causes a severe memory-leak and will likely lead to a crash.

[Myrsloik]

Yes, I'm shifting blame like a pro and there's nothing you can do about it. I'll poke TheFluff about preparing 2.14 for release immediately.

[kemuri-_9]

I'm willing to spend some time to try and figure out the issue in the mean time,
but i particularly need an AVC in TS sample to do so as i don't have any atm.

[LoRd_MuldeR]

I'm willing to spend some time to try and figure out the issue in the mean time,
but i particularly need an AVC in TS sample to do so as i don't have any atm.

Well, I can provide one easily. But uploading will take some time. Did I mention my upstream is SLOW ???

[kemuri-_9]

Well, I can provide one easily. But uploading will take some time. Did I mention my upstream is SLOW ???

well it's whenever you can,
In the meantime i have a new theory as to the leak's cause and have made a new build around that and am awaiting the sample for confirmation.

[asarian]

This is the full todo list for FFMS2. Vote on the features you want or suggest your own. I'm personally guessing 2-5 are what people want mostly but I could be wrong...


Request: add 'fps=' parameter to FFVideoSource (especially needed for mkv at times).

[TheFluff]

It would be nice to have that bug fixed in 2.14. I'll wait and see if kemuri's patch is successful.

Request: add 'fps=' parameter to FFVideoSource (especially needed for mkv at times).
RTFM, it's already there (at least its functional equivalent). Unless you want something like assumefps(), but if you want that just use assumefps().

[Underground78]

I'm willing to spend some time to try and figure out the issue in the mean time,
but i particularly need an AVC in TS sample to do so as i don't have any atm.

If it can help, here an AVC in TS sample I uploaded previously for other use : http://www.mediafire.com/?g2xjd4rwa2n.

[TheFluff]

http://www.mod16.org/ffms2/ffms2-r339.7z probably fixes the issue, thanks to kemuri-_9.

[LoRd_MuldeR]

http://www.mod16.org/ffms2/ffms2-r339.7z probably fixes the issue, thanks to kemuri-_9.

Great, testing now...

[LoRd_MuldeR]

Great job! Loos like the issue is fixed indeed:

http://img840.imageshack.us/img840/7416/ffms2memleak5.th.jpg (http://img840.imageshack.us/img840/7416/ffms2memleak5.jpg)

:thanks:

[stax76]

Fantastic, thanks everybody! :thanks:

It's also fixed in my test, similar source then mulder and the user who originally brought it to my attention, I'll report to him. :thanks:

[asarian]

Fantastic, thanks everybody! :thanks:

Yes, appreciate the fast fixes. :) Looking forward to the 2.14 release.

[Sharktooth]

any chance for MT and a 64bit build (including mt as well)?

[TheRyuu]

any chance for MT and a 64bit build (including mt as well)?

After it's official I'll make 'em.

[Sharktooth]

thanks

[stax76]

I don't know if this is a known problem, MakeMKV generated AVC MKV, result in macro blocks for a while when seeking, this makes such files unusable since seeking is needed for preview, cropping, cutting etc. If I use eac3to instead to create a AVC MKV from any Blu-ray source it works. Sorry I my upstream speed of my internet connection is very slow, I hope somebody can upload a sample. I'll point the MakeMKV author here.

[TheFluff]

The problem with AVC in MKV remuxed from a ts or m2ts is known.

[stax76]

Only post I found is a changelog entry posted by Myrsloik:

Fixed h264 in mkv which was remuxed from bd sources, there are no longer decoding artifacts after seeking

[TheRyuu]

Only post I found is a changelog entry posted by Myrsloik:
Fixed h264 in mkv which was remuxed from bd sources, there are no longer decoding artifacts after seeking

Certain streams still exhibit artifacts. Before almost all of them did, now only some of them do.

[tebasuna51]

The problem with AVC in MKV remuxed from a ts or m2ts is known.
Can you explain the problem, or put a link to explanation, please?

[TheFluff]

grab h264 m2ts from bluray -> remux to mkv -> decode with ffmpegsource -> lol artifacts

sometimes remuxing it again with mkvmerge (not gdsmux or eac3to or anything else) fixes it for some reason

[stax76]

mkvmerge nor Haali's muxer which eac3to uses cause this problem, only MakeMKV's muxer so I hope the MakeMKV author will help, I've already pointed him to this thread.

[TheFluff]

2.14 is finally out, grab it from the Google Code (http://code.google.com/p/ffmpegsource/) page. ffmpeg-mt and avs64 versions aren't posted yet as of this writing, but I'm pretty sure TheRyuu and kemuri-_9 will post them soon.

This is mostly a bugfix release, and it fixes a bunch of rather critical issues. Full changelog since 2.13:

Reworked filename handling a bit. Index files should no longer get a garbled name when using the Avisynth plugin and an input filename in the local codepage (issue 9), and FFMS_USE_UTF8_PATHS does no longer require patching ffmpeg. (TheFluff, nielsm)
Fixed a bunch of compiler warnings and added versioning for the shared library when building under Unix. (Kovensky)
Fixed an invalid memory access bug that could cause random crashes or other errors when opening files. (TheFluff)
The timebase for video tracks is now corrected if it's invalid. (kemuri_-9)
Fixed a number of multithreaded decoding issues. (kemuri_-9)
Use aligned memory for audio decoding buffers; fixes some crashes during audio decoding. (greg)
Fixed a bug that caused ffmsindex -c to fail. (chdheu)
Added support for MKV files using header stripping compression. (TheFluff)
It is now possible to compile FFMS2 using a ffmpeg without libpostproc compiled in (this will obviously cause postprocessing-related functions to fail). Hence it is now possible to build a GPL-free FFMS2, since the rest of ffmpeg can be compiled as LGPL. (TheFluff)
Audio streams that change channel layout, sample rate or bitdepth mid-stream will no longer cause crashes; an error will be raised during indexing instead. (TheFluff)
Fix a potential crash when ffmpeg thought it couldn't decode a certain format, but was wrong. Fixes issues with some FLV's. (Plorkyeran)
Fix heap corruption that could cause crashes and odd issues when opening H.264 in MPEG-TS with Haali's splitter. (Plorkyeran)
Fix a memleak when decoding H.264 in MPEG-TS using Haali's splitter. (kemuri-_9)
Updated FFmpeg to rev 25329.

[elguaxo]

:thanks:

[TheRyuu]

ffmpegsource-2.14-mt.7z (http://ffmpegsource.googlecode.com/files/ffmpegsource-2.14-mt.7z)
ffmpegsource-2.14-mt-avs64.7z (http://ffmpegsource.googlecode.com/files/ffmpegsource-2.14-mt-avs64.7z)

ffmpeg-mt flavor with some avs64 topping.

[michaelusa]

Pardon my ignorace, What is the difference between the ffmpegsource vanilla and mt flavors? Which one should I use? I'd like to use it as a plugin for AviSynth. Thanks.

[Myrsloik]

FFmpeg-mt is a branch of FFmpeg with multithreaded video decoding for most formats. The only difference is which library FFMS2 is linked against. In theory the mt compiles should be faster with no drawbacks at all.

[asarian]

Thanks for the 2.14 version! Much appreciated.

[asarian]

Kemuri, is there a reason why the index now seems to get rebuilt every time I call the same script with FFVideoSource in it? That takes an awful lot of time each time.

EDIT: Okay, something is not entirely right. When I delete the index, prior to FFVideoSource rebuilding it (for as yet unknown reasons), the encoding goes well. If I don't, I get errors like these:


avs : 1920x796p 1:1 @ 24000/1001 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 4.1
x264 [warning]: non-strictly-monotonic pts at frame 1 (2 <= 2)
x264 [warning]: non-strictly-monotonic pts at frame 2 (2 <= 3)
x264 [warning]: non-strictly-monotonic pts at frame 3 (2 <= 4)
x264 [warning]: too many nonmonotonic pts warnings, suppressing further ones
x264 [warning]: 69 suppressed nonmonotonic pts warnings
^CTerminate batch job (Y/N)? y


Clearly, there's something off with the rebuilding of the indices (for one, it should not have to rebuild/update/whatever) at all when the 'parent' movie hasn't changed. And secondly, whatever it changes, it messes things up.

Mind you, this [I]only occurs on the 64-bit version of FFmpegSource.

[kemuri-_9]

and whose 64bit avisynth build are you using?

I have not changed anything in the core avisynth C code that would cause the code to regenerate the indexes every time, so indexes always regenerating should not be occurring unless you specified cache=false to FFVideoSource.

So it's something else that's causing the issue, as to what, dunno...

you're still probably using JoshyD's avisynth build which has been known to have issues,
so you'll have to compare the effect against squid_80's avisynth x64 build based on avisynth 2.55 or so and see if the issue occurs there as well.
If you're using the MT avs64 build, then try the generic avs64 build...

and so on and so forth until you can tell me what's causing it.

[asarian]

and whose 64bit avisynth build are you using?

...
you're still probably using JoshyD's avisynth build which has been known to have issues,


Yep, still using that one, at: http://forum.doom9.org/showthread.php?t=152800

Didn't even know there was an alternative, to be honest.


I have not changed anything in the core avisynth C code that would cause the code to regenerate the indexes every time, so indexes always regenerating should not be occurring unless you specified cache=false to FFVideoSource.


I just call it with these two lines:

LoadCPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins64\ffms2.dll")
FFVideoSource("f:\jobs\stargate.mkv").ConvertToYV12()

Yet index is rebuilding constantly (whenever I call the script).


So it's something else that's causing the issue, as to what, dunno...


Not a whole lot to be found on the "non-strictly-monotonic pts" errors, except it seems to be related to some sort of internal avisynth resizing bug (but one which should have been fixed a long time ago, if I read things right; so I'm still unclear what's causing it).


so you'll have to compare the effect against squid_80's avisynth x64 build based on avisynth 2.55 or so and see if the issue occurs there as well.
If you're using the MT avs64 build, then try the generic avs64 build...

and so on and so forth until you can tell me what's causing it.


That's gonna take a bit of looking into. Anyway, thanks for your time.

[kypec]

Results of your testing are eagerly awaited asarian, please post them later, thanks!
I'm planning to start using 64-bit Avisynth myself...

[kypec]

Is there any particular reason why 32-bit & 64-bit plugins cannot share the same *.ffindex file?
I'm using both 32-bit & 64-bit Avisynth on the same machine and the necessity to re-index same file every time I switch to another Avisynth environment is tedious.
If each FFMS2 build definitely needs specific version of ffindex file then please at least differentiate them by file extension (like ffindex & ffindex64 or anything else that suits developers better)
:thanks: A LOT!!!

[Myrsloik]

Yes, they do need to be different because you never know exactly how having FFmpeg compiled with different number of bits affects the timestamps. Just create a wrapper function if it's such a big problem. Or modify the avsi file.

[Blue_MiSfit]

What IS the suggested x64 build to use these days? JoshyD's build from April is the most current one I'm aware of...

Derek

[TheFluff]

my suggestion is to not use avs64 at all unless you really enjoy broken stuff

[Hagbard23]

[OFFTOPIC]

my suggestion is to not use avs64 at all unless you really enjoy broken stuff

Why? I never noticed broken stuff until now...tell me more...

[TheFluff]

read a few posts above?

[SledgeHammer_999]

Is anyone monitoring the bug tracker on the project's page?

[kemuri-_9]

Is anyone monitoring the bug tracker on the project's page?

If you were the one who posted about
Application crashes if FFMS2-avs64 is used and index file is from 32-bit flavour

It's not reproducable with the 32bit and 64bit versions i have made, the indexes are remade each time.
rather than being MT specific, I would say it's more likely because the 32bit version you're using is made by visual studio and the 64bit one is made by MinGW.