Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
18th July 2011, 22:50 | #1201 | Link | |
Compiling Encoder
Join Date: Jan 2007
Posts: 1,348
|
Quote:
this will, as a by-product, be likely to break backwards compatibility, preventing use in 2.5. |
|
19th July 2011, 04:46 | #1202 | Link |
Avisynth Developer
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
|
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. |
19th July 2011, 11:56 | #1203 | Link |
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
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?
|
23rd July 2011, 11:08 | #1204 | Link |
warpsharpened
Join Date: Feb 2007
Posts: 787
|
ffms2-r507.7z
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. Code:
LoadPlugin(X:\path\to\ffms2.dll") 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). Last edited by TheRyuu; 24th July 2011 at 03:50. |
24th July 2011, 10:14 | #1206 | Link |
warpsharpened
Join Date: Feb 2007
Posts: 787
|
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... Last edited by TheRyuu; 24th July 2011 at 10:17. |
1st August 2011, 11:37 | #1208 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,419
|
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.
|
1st August 2011, 15:32 | #1209 | Link | |
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
Quote:
|
|
2nd August 2011, 10:49 | #1210 | Link |
Compiling Encoder
Join Date: Jan 2007
Posts: 1,348
|
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) |
2nd August 2011, 11:27 | #1211 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,419
|
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. Last edited by qyot27; 2nd August 2011 at 11:32. |
2nd August 2011, 13:29 | #1212 | Link |
Compiling Encoder
Join Date: Jan 2007
Posts: 1,348
|
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... |
2nd August 2011, 20:30 | #1213 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,419
|
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.
|
2nd August 2011, 23:05 | #1214 | Link |
Compiling Encoder
Join Date: Jan 2007
Posts: 1,348
|
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 could also trying to see if this version causes a crash or not. |
3rd August 2011, 05:15 | #1215 | Link | |
warpsharpened
Join Date: Feb 2007
Posts: 787
|
Quote:
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 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. Last edited by TheRyuu; 3rd August 2011 at 06:00. |
|
6th August 2011, 23:10 | #1216 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,419
|
I wasn't able to get to testing with the different pthreads builds until today, but the results are below.
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. |
7th August 2011, 00:34 | #1217 | Link |
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
http://code.google.com/p/ffmpegsourc...s/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? |
7th August 2011, 05:02 | #1219 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,419
|
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: Code:
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 |
7th August 2011, 11:57 | #1220 | Link | |
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
Okay, then I guess we get to do this the hard way.
Quote:
So, let me sum up what you're saying to see if I got it right:
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. Last edited by TheFluff; 7th August 2011 at 11:59. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|