FFmpegSource

[kemuri-_9]

FFMS2 can't output YV24 because Avisynth (2.5) doesn't support it. Avisynth 2.6 does, but so far I haven't looked into what needs to be done on FFMS2's side to make it a working 2.6 plugin. If you want the support like RIGHT NOW you need to write a patch yourself (any contributions are welcome), but if you're okay with waiting we'll get around to it eventually.

due to how broken/incomplete the avisynth 2.6 interface is right now, you'd have to not only take the avisynth.h but also the implementation code behind it (i think it was interface.cpp) to get any 2.6 plugins to compile atm.

this will, as a by-product, be likely to break backwards compatibility, preventing use in 2.5.

[IanB]

Yes it was never the intention for 2.6 plugins to work in 2.5.

Cunning plugin authors may crib and allow this to work for their plugin, but in general it should not be expected.


Note: 2.5 plugins are intended to be fully supported in 2.6 within the constraints of the 2.5 framework.

[TheFluff]

Yes it was never the intention for 2.6 plugins to work in 2.5.

Cunning plugin authors may crib and allow this to work for their plugin, but in general it should not be expected.

That's really annoying. I really don't want to maintain two separate interfaces (three, if you count the avs64 C interface that kemuri-_9 maintains). How much clever ifdeffing is required, really?

[TheRyuu]

ffms2-r507.7z (https://ffmpegsource.googlecode.com/files/ffms2-r507.7z)
ffms2-r507-x64.7z (https://ffmpegsource.googlecode.com/files/ffms2-r507-x64.7z)

64-bit binary no longer requires LoadCPlugin. It's just a regular avisynth plugin now.
I changed the name slightly to try and reflect this. My compiles will no longer require LoadCPlugin (obviously all old avs64 compiles will) but archives labeled as "x64" will be regular plugins.

LoadPlugin(X:\path\to\ffms2.dll")
For both 32 and 64-bit binaries.

Changes since last build:
-Updated libav to rev. b4cfb82.
-Update project files in svn to msvc2010.
-x64 target in msvc.
-Auto-detect number of threads if threads < 1. (The avisynth plugin already did this, this functionality is now extended to those using the api as well).

Now, msvc x64 and mingw-w64 don't exactly play nice now, but they play together well enough to make the builds possible now. :)

Also now included with the builds is some stuff for devs (.lib for linking, ffms.h header file, and pdb's for debugging).

[TheFluff]

64-bit binary no longer requires LoadCPlugin. It's just a regular avisynth plugin now.

Wrong. It depends on who compiled it and with what compiler.

[TheRyuu]

Wrong. It depends on who compiled it and with what compiler.

Edited post to better announce this fact. Although you have to be pretty retarded to not realize it.

Also for future releases I'm going to do a separate 'SDK' package or something which contains release/debug builds and associated libs/headers etc...

[kemuri-_9]

shenanigans mentioned here (http://doom10.org/index.php?topic=25.240) are now committed, enjoy (and report found bugs).

I've also renamed the avs64 branch to c_plugin in a preemptive to avoid arguments like the above.

[qyot27]

Is there some difference between the way the MSVC and C-plugin builds handle pthreads? Because any time I try to use the C-plugin with more than one thread (of which I mean 'leave it at the defaults', but as I'm using it on a Core 2 Duo...), HCenc crashes almost immediately. If I use the distributed MSVC builds, make the C-plugin use threads=1, or if I compile with win32threads, the crash doesn't happen. If there isn't really a difference, then I'll know it's an HCenc-side issue.

[TheFluff]

Is there some difference between the way the MSVC and C-plugin builds handle pthreads? Because any time I try to use the C-plugin with more than one thread (of which I mean 'leave it at the defaults', but as I'm using it on a Core 2 Duo...), HCenc crashes almost immediately. If I use the distributed MSVC builds, make the C-plugin use threads=1, or if I compile with win32threads, the crash doesn't happen. If there isn't really a difference, then I'll know it's an HCenc-side issue.

The handling on FFMS2's side isn't different but the two variants are compiled by different people with different compiler versions in different ways, so it's not at all impossible that kemuri-_9's pthreads compile has some funny issue while TheRyuu's does not. I leave further investigation to kemuri-_9 since the c-plugin is his playground.

[kemuri-_9]

I actually never build ffmpegsource against an ffmpeg that was built with pthreads on windows.

so I can't say the c plugin is very much tested in that regards, though like TheFluff has stated, it shouldn't really have a weird issue like that.

Though, this is reminding me of an issue i've seen previously with pthreads crashing x264 when built with msvc (though this was x86_64 specific).

file a bug in googlecode for it to track this, and i'll try and find time to investigate (and temporarily put aside my distaste in requiring to build ffmpeg against pthreads for the full mt support)

[qyot27]

Would it possibly be entirely up to the version of pthreads, though? Mainly because x264 doesn't exhibit the issue, even with the C-plugin using pthreads and calling more than 1 thread. Then again, x264 is built against the same version of pthreads that ffmpeg was. That was partially why I thought it might actually be something about HCenc interacting with it in some way, except it still seems isolated to when I'm using the C-plugin.

I suppose if I rolled back to a much older revision of pthreads and the crash doesn't occur, that would show it's somewhere in there, right? It was happening with stuff built against a pthreads from April 30th, 2011, and also with the current CVS version as of this past week. I used to use a build from October 2009, and I think I might do a test with it built against that one to see if the crash still happens. My memory's not good enough to recall if the builds I used to do against that one also crashed in this manner.

[kemuri-_9]

It could be the version of pthreads.

I base this on the fact that the pthread issue i previously mentioned was only for a newer version, whereas an older verison did not exhibit the issue (i think the major difference for my issue was whether that autostatic stuff was there or not).
ffmpegsource nor ffmpeg handle static-but-not-non-autostatic pthread-win32 correctly, however, so you probably can't go back before that if you want to link pthread-win32 statically.
you could try using the shared lib version of pthread-win32 if you need to go back before that addition though.
in fact, trying the share lib version may be a helpful test overall...

[qyot27]

Well, the build from October 2009 caused an error during the compile process, even though it is an autostatic build (autostatic with the old patch that added it, rather than as part of the trunk CVS code); it just must be too old now to compile a current ffmpeg against. I'll have to see about building it against a shared version.

[kemuri-_9]

i would also like to point out that TheRyuu does not typically use the standard pthread-win32 when he builds.
he generally uses a version that's based off the win32 thread support i wrote for x264, which is available here (https://github.com/TheRyuu/pw32threads)

could also trying to see if this version causes a crash or not.

[TheRyuu]

i would also like to point out that TheRyuu does not typically use the standard pthread-win32 when he builds.
he generally uses a version that's based off the win32 thread support i wrote for x264, which is available here (https://github.com/TheRyuu/pw32threads)

could also trying to see if this version causes a crash or not.

Incorrect, of all the builds I've done: 32bit builds all have standard pthreads-w32. 64bit c-plugin builds all have standard pthreads-w32.
Only 64bit msvc builds (which I've posted one build ever, as of this post) have the version based off of win32 threads to avoid some weird linker issues with standard pthreads.

All of the above have and use autostatic for libav.

ffms2-r517.7z (https://ffmpegsource.googlecode.com/files/ffms2-r517.7z)

Changes:
Built with libav rev. 62ee0e6
Implement a working version of avcodec_find_best_pix_fmt. This should fix all automatic selection of output colorspace in avisynth.
Make FFMS_Index reference counted and shared between sources instead of partially copied.
Fix deprecation in libavformat usage. Replace av_find_stream_info with avformat_find_stream_info.

[qyot27]

I wasn't able to get to testing with the different pthreads builds until today, but the results are below.

Static pthreads-win32 (July 2011) crashes HCenc (at 3%) on sampling pass
Shared pthreads-win32 crashes HCenc (at 3%) on sampling pass with both:
The pthreadGC2.dll that matched with the version of the library (July 2011) FFMS2 was built against.
A pthreadGC2.dll from 2008 that was laying around in C:\Windows\system32
pw32threads crashes HCenc (at 3%) on sampling pass
The initial stuff as well:
w32threads = no crash
pthreads-win32 (July 2011) with threading disabled (threads=1) = no crash




As a different test, I decided to use a different file. With the static pthreads-win32 build of r512 (C-plugin).

It crashed at 7% in the sampling pass, because I think the issue has to do with the length of the file and where the threading would actually divvy up the frames.

However, I then remuxed the file from FLV to MKV using ffmpeg and reran the test. No crash with the MKV remux.

I'd overlooked the fact that the MSVC test I'd run earlier was with an MKV remux, so I reran it with the FLV instead. MSVC (r517, as distributed on googlecode) crashed on the FLV at 7%, just like the C-plugin did. As already stated, no crash with the MKV.

It would seem that it's an issue with the FLV demuxer (I'd guess FLV just uses libavformat, since using -m lavf when indexing still resulted in HCenc crashing at 7%) choking with pthreads-win32 when using more than one thread, but it still only happens with HCenc; x264 seems completely unaffected by it, which I wouldn't think would happen if it was something intrinsic to libavformat.

In all cases the video and audio were H.264 and AAC.

[TheFluff]

http://code.google.com/p/ffmpegsource/issues/detail?id=50

Possibly the same issue. Can you redo the test with r518 and see if you get a nice error message instead of a crash?

[kemuri-_9]

huh, i guess it's not surprising that w32threads does not exhibit the issue, as w32threads with ffmpeg still do not allow full mt support like building with pthreads.

[qyot27]

r518 still crashes HCenc at 7%, no inkling of an error message during playback of the script with MPC when it passes the 7% mark.



As an aside, I normally do an svn merge in those times between the C-plugin's HEAD updates, but doing a plain merge currently fails due to the recent revisions concerning MSVC x64. Readout below:
svn merge http://ffmpegsource.googlecode.com/svn/trunk
--- Merging r506 into '.':
C build-msvc/ffms2_include_dirs.props
C build-msvc/ffmsindex.vcxproj.filters
C build-msvc/ffms2.vcxproj
C build-msvc/ffms2.sln
C build-msvc/ffmsindex.vcxproj
C build-msvc/ffms2.vcxproj.filters
D build-msvc/ffms2_include_dirs.vsprops
C build-msvc/ffms2.vcproj
C build-msvc/ffmsindex.vcproj
svn: Attempt to add tree conflict that already exists at 'build-msvc/ffmsindex.vcxproj'
svn: Error reading spooled REPORT request response

I can work around that by specifying the revisions with -r, but if left alone it wants to merge from back at r506 instead of starting at the last C-plugin revision.

[TheFluff]

Okay, then I guess we get to do this the hard way.

It would seem that it's an issue with the FLV demuxer (I'd guess FLV just uses libavformat, since using -m lavf when indexing still resulted in HCenc crashing at 7%)

FLV uses libavformat, yes. We don't have a special demuxer for it.

So, let me sum up what you're saying to see if I got it right:

The crash only affects HCenc; not x264 or MPC
The crash only appears if you use a FFMS2 compiled with pthreads, and only if you're actually using threads >1
It only affects FLV; remuxing to MKV makes the problem disappear
The crash happens with both the native and the C-style plugins


When you tested with r518, are you sure you actually merged in the changes from r518 in trunk to the C-plugin branch?

Also, do you have Visual Studio installed? If you do, compile FFMS2 in debug mode (or at least get ahold of a .pdb file somewhere and stick it with the .dll) and try attaching Visual Studio to the HCenc process and see if you can get a stack trace when it crashes.

[qyot27]

So, let me sum up what you're saying to see if I got it right:

The crash only affects HCenc; not x264 or MPC
The crash only appears if you use a FFMS2 compiled with pthreads, and only if you're actually using threads >1
It only affects FLV; remuxing to MKV makes the problem disappear
The crash happens with both the native and the C-style plugins

Correct.

When you tested with r518, are you sure you actually merged in the changes from r518 in trunk to the C-plugin branch?
The method used for the merge was:
svn checkout http://ffmpegsource.googlecode.com/svn/branches/c_plugin ffms2-cinterface
cd ffms2-cinterface
svn merge -r 512:518 http://ffmpegsource.googlecode.com/svn/trunk
I also compared videosource.cpp in r519 with the one from the merge operation and from trunk. The relevant section of code was the same (and so were the files' checksums).

Also, do you have Visual Studio installed? If you do, compile FFMS2 in debug mode (or at least get ahold of a .pdb file somewhere and stick it with the .dll) and try attaching Visual Studio to the HCenc process and see if you can get a stack trace when it crashes.
VS Express 2008, yes.




However, I just tried something else (with a smaller file I'd meant to use as a sample if it came to that), and I'm now pretty convinced that the issue is squarely on HCenc's side, specifically in the 1-pass mode's sampling pass routine, and if anything, the method used for the sampling pass must be exposing something in the way libavformat handles FLV demuxing that it doesn't like. Using 2-pass mode averts the issue entirely, with the same file and same FFMS2 build, even where that combination would make it crash during 1-pass mode's sampling pass at ~24%. I can still attempt building a debug version through VSE2008, even if only for completeness' sake.

[qyot27]

VSE2008 seems to have miscompiled the plugin, because ffmsindex crashes immediately. I used the following steps:

Build FFmpeg as usual with MinGW

Open build-msvc/ffms2_2008.sln

Select ffms2 Project from Solution Explorer

Options->Projects and Solutions->VC++ Directories

Library files directories. Add the following to the end of the list:
C:\MinGW\cross-mingw.gcc446.generic.20101013\lib\gcc\i686-pc-mingw32\4.4.6
C:\MinGW\cross-mingw.gcc446.generic.20101013\i686-pc-mingw32\lib
[FFmpeg install directory /lib folder]

Include files directories. Add the following to the end of the list:
C:\MinGW\msinttypes
C:\MinGW\cross-mingw.gcc446.generic.20101013\lib\gcc\i686-pc-mingw32\4.4.6\include
C:\MinGW\cross-mingw.gcc446.generic.20101013\i686-pc-mingw32\include
[FFmpeg install directory /include folder]

Leave configuration as Debug

Configuration Properties->C/C++->Preprocessor
Under 'Preprocessor Definitions', remove HAALISOURCE

Configuration Properties->Linker
Under 'Additional Dependencies' add:
vfw32.lib
libgcc.a
libmingwex.a
libcoldname.a
libz.a
libbz2.a
libpthreadGC2.a


Right-click on ffms2 Project in Solution Explorer. Select Build.

After it finishes, right-click on ffmsindex Project. Select Build.

[TheFluff]

That looks mostly correct to me, but you shouldn't need to add the extra libs to the additional dependencies like that; they should be autoadded via libs.cpp (except libbz2.a, which is not in there). What do you need vfw32.lib for anyway? Also, I think you should use libmoldname.a and not libcoldname.a.

[TheRyuu]

However, I just tried something else (with a smaller file I'd meant to use as a sample

Can you upload the sample anyway?

Edit:
If you can't compile ffms2, here's a debug build for you: http://warpsharp.info/ffms2/ffms2-r519-debug.7z

[qyot27]

The sample and the HCenc profile used: http://www.mediafire.com/?95ngx1h5nl2znat

It can be seen with HCenc 0.25 or 0.26 beta.

ffmsindex test.flv
echo FFVideoSource("test.flv",fpsnum=30000,fpsden=1001).BilinearResize(720,480)>test.avs
hcenc_026 -i test.avs -o test.m2v -ini "testprof.ini"

[zerowalker]

Can you use this, to decode Fraps files correctly?
I have tried, it becomes YV12 (but it should be Yuy2 as far as i know), and it takes alot of time, as with avisource it takes a sec, but it decodes to RGB32 thanks to Fraps Decoder,

[Myrsloik]

Can you use this, to decode Fraps files correctly?
I have tried, it becomes YV12 (but it should be Yuy2 as far as i know), and it takes alot of time, as with avisource it takes a sec, but it decodes to RGB32 thanks to Fraps Decoder,

Which version of ffms2 did you use? Can you make a short sample and upload somewhere that shows the same behavior?

[zerowalker]

i downloaded from the google project site, so probably latest, was made the 3rd i think.
Well don´t think i need to send a sample, just fraps anyting;P
But isn´t it supposed to be in Yuy2, cause everyone i asked told me it should be, and i read that FFVideoSource was suppose to decode it right, without the upsampling that the fraps decoder do.
But when i use FFvideosource("fraps") it becomes YV12, atleast Avspmod tells me so, and RGB32 with AviSource.

[Myrsloik]

Fraps is only YV12 or RGB24, do your homework next time.

...and don't ask whoever you asked ever again about video related things.

[zerowalker]

Okay, hmm, can i ask how you are sure about it?
Cause i can´t find and definite answer except for believing what people are saying.
You say YV12 or RGB24, and the ones in CCCP forum and another place att sourceforge said Yuy2.
I also read it´s YV12 Full Range, which i why i convert from RGB32 (with avisource) to .ConvertToYV12(matrix="Rec709").

Sorry didn´t want to Hijack this thread or anything, but as you seems to know about it, it would be nice to be done with it.

[Myrsloik]

Okay, hmm, can i ask how you are sure about it?
Cause i can´t find and definite answer except for believing what people are saying.
You say YV12 or RGB24, and the ones in CCCP forum and another place att sourceforge said Yuy2.
I also read it´s YV12 Full Range, which i why i convert from RGB32 (with avisource) to .ConvertToYV12(matrix="Rec709").

Sorry didn´t want to Hijack this thread or anything, but as you seems to know about it, it would be nice to be done with it.

All I did was read the source for the libav decoder, which only support full range yv12 and rgb24 output... and that must be right since it decodes properly

(note: you can't really trust what vfw decoders output, they have a tendency to pick a different output format than what the actual contents are in)

[zerowalker]

Sorry but what is VFW decoder, i heard of it, but which one is it?
The fraps or the FFVideo?
Thanks for helping out:)

EDIT: and why does it take a year for FFVideoSource to load the fraps movie when AviSource take a sec?

[Plorkyeran]

FFVideoSource indexes the file, which requires reading the entire video from disk, while AviSource trusts the index in the file.

[zerowalker]

Ah i see, thanks.
Is there a way to prevent the indexing?

And found out that FFVS makes the Fraps movies alot darker (all decoders except fraps does that i think), so i guess i have to do with the upsampling and downsampling anyhow.

[Rumbah]

It's because Fraps uses full range but your players/encoders expect tv range. You can change it with e.g. Colormatrix.

[Myrsloik]

Ah i see, thanks.
Is there a way to prevent the indexing?


No. That is the whole point of ffms2.

If indexing bothers you so much just go use the official fraps vfw decoder or ffdshow's vfw decoder.

[zerowalker]

No. That is the whole point of ffms2.

If indexing bothers you so much just go use the official fraps vfw decoder or ffdshow's vfw decoder.

Oh didn´t know that, soz:)

And i see, will try with colormatrix:)

But is there anyway to speed indexing upp, cause if i take many videos, let´s say 15. It takes a Really long time, so if there is a way to reduce the time, please tell.

Thanks for the help guys:)!

[Myrsloik]

Oh didn´t know that, soz:)

And i see, will try with colormatrix:)

But is there anyway to speed indexing upp, cause if i take many videos, let´s say 15. It takes a Really long time, so if there is a way to reduce the time, please tell.

Thanks for the help guys:)!

May I suggest buying an SSD or maybe a bit of RAID?

[zerowalker]

Ah, if it´s can´t be reduced by software or how to put it, i will just go with it as it is:)
Didn´t mean to be rude against the plugin or what to say or anything, i am just not to good with this things.
But thank you all for helping out, appreciate it:)

[Dogway]

Is it normal the green color cast when resizing with ffvideosource?

[LigH]

Details, please: Color format, scaling function, source and target rectangles ... ?

[TheRyuu]

Is it normal the green color cast when resizing with ffvideosource?

I think without any context (unless I missed something) all I see in this post is a fail attempt at a question in fairly mangled english that I really don't understand.

[Dogway]

for the record:
I think without any context (unless I missed something) all I see in this post is a fail attempt at a question in fairly mangled english that I really don't understand.
@TheRyuu: You can also read it as "I observed a green color cast when resizing with ffvideosource, is this normal?" c'mon it's not that hard ; )

LigH, I didn't post any details because it happens with different sources, so its more likely to be a ffms2 issue. None the less I can show some examples for skepticals.

You can use a video of your own, or use my example.
http://www.mediafire.com/?h12ccly94edg249
Frame 6:

setmtmode(5,2)
ffvideosource("VTS_02_0.demuxed.m2v",width=360,height=240,resizer="SPLINE")
#~ setmtmode(2,2)
#~ Spline36Resize(width/2,height/2)

and yes I'm aware SPLINE is not Spline36 :)

http://i212.photobucket.com/albums/cc35/Dogway/Misc/th_source.png (http://i212.photobucket.com/albums/cc35/Dogway/Misc/source.png)http://i212.photobucket.com/albums/cc35/Dogway/Misc/th_Spline36.png (http://i212.photobucket.com/albums/cc35/Dogway/Misc/Spline36.png)http://i212.photobucket.com/albums/cc35/Dogway/Misc/th_FFSPLINE.png (http://i212.photobucket.com/albums/cc35/Dogway/Misc/FFSPLINE.png)

[kemuri-_9]

does it still occur if you split the resizing out of FFVideoSource directly and use SWScale to resize with instead?

[Dogway]

I don't use that resizer, so I don't know, but if it helps it also occurs using lanczos in ffvideosource.
Now this is sounding like I am the only one with this problem? Tell me so I can search what is causing it...

[TheFluff]

I can reproduce the problem, and it's a bug in libswscale's spline and lanczos resizers. The more you downsize an image with either of them, the greener it gets. Try something like bicubicresize(width*4,height*4).swscale(320,240,"SPLINE") for hilarious results.

As a workaround, either use Avisynth's resizers, or use swscale's bicubic resizer (which doesn't have the problem).

[Dogway]

I also wouldn't expect an unconstructive reply as I had above. Im resizing from 1080p to 480p and it takes time so I expected to gain some speed resizing inside ffms2, I will have a look at swscale (never used) but these days I'm busy and I thought the developers would be more thankful than annoyed when someone reports a bug of their tools. I will check whether spline36/16 is fast enough for my task.

[henryho_hk]

Unless it is a 24fps or 23.976fps "film" footage, I would say 99% of the chance you need deinterlacing (or, rarely for bluray, ITVC) before resize. And since you are downsizing from 1080p to 480p, ffmpeg's builtin 5-tap-low-pass or ffmpeg-deint should work pretty well.

And would ppls please mind your net manner.

[kemuri-_9]

I also wouldn't expect an unconstructive reply as I had above. Im resizing from 1080p to 480p and it takes time so I expected to gain some speed resizing inside ffms2, I will have a look at swscale (never used) but these days I'm busy and I thought the developers would be more thankful than annoyed when someone reports a bug of their tools. I will check whether spline36/16 is fast enough for my task.


We can't magically fix serious problems in ffmpeg.
If you want these types of problems fixed you need to file bug reports against ffmpeg.
And as TheFluff indicates, the problem is a serious bug in ffmpeg - specifically libswscale, its not in an area we have to fix.

With the bug being in libswscale's resizers itself, SWScale is equally bugged - as it's just libswscale exposed as an avisynth filter, so don't use it either.

[Dogway]

nono, I'm ok by just being aware, I don't want you to fix them, that's ffmpeg business (right?), but by allowing ffms2 to use bugged features I understand it also supports them, you know...