search

FFMS / ffms2

An FFmpeg based source library and Avisynth/VapourSynth plugin for easy frame accurate access
Other
576 stars 104 forks source link

c_plugin branch is now up to date with master and compiles again on non windows plataforms #321

Closed rsd closed 4 years ago

rsd commented 6 years ago

c_plugin was modified to only compile on windows. Now it works again (tested on ubuntu 18.04). AvxSynth had some updates and a few deprecated API was restored to make it compile again.

qyot27 commented 6 years ago

This is not the process by which the c_plugin gets updated. The -municode issue is not something that requires a full revert, as it's just an issue in the configure script's cc_check and cxx_check tests that need to be extended to cover/gloss over the OS differences in GCC (I have half a mind to move the build system on c_plugin back to CMake just so I can use Ninja and/or test the c_plugin with MSVC and Clang too).

The AvxSynth plugin stuff looks dead wrong, though. Putting aside the fact that AvxSynth as a project has been dead for over 3 years and any effort therein is better served by trying to finish up the Linux porting work on AviSynth+, the FFMS2 wrapper in AvxSynth's source tree needs to be disabled when building AvxSynth (--disable-ffms2), or else it throws all kinds of issues - like complaining about missing ffmscompat.h and use of PixelFormat - when trying to use a newer FFMS2; this is a known problem on AvxSynth's side. Regardless, the correct solution to this if it has been broken again by the stuff in January is to update the AvxSynth plugin to use the current FFMS API, not keep hobbling deprecated API functions around. If irreconcilable breakage has actually happened, then the AvxSynth plugin needs to be dropped.

I would have gotten around to this in just a couple of days anyway. Between FFmpeg finally breaking XP for good and Ubuntu 18.04 being released next week, all of it would have happened during the refresh of my build environments.

myrsloik commented 6 years ago

You're all just reminding me about how much I want to throw out the c_plugin branch so it's a separate project. None of the actual FFMS2 developers like it or care about its existence. Actually now that clang-cl works well enough I doubt it has any real reason to exist...

qyot27 commented 6 years ago

@myrsloik By pruning c_plugin out with the other old branches, or by just leaving it to rot? If the former, then no further HEAD catchups would be necessary and this thread can die out now, and if the latter, I can submit one more that has this PR's quibbles sorted and then that's it.

@rsd The fact that master was able to merge into c_plugin cleanly was mostly a side effect of the last HEAD catchup being only a few months ago. If anything in the build system in master had been touched or new files added/old ones deleted, it would've been a lot messier.

The configure checks have been fixed on my patches branch. The only AvxSynth-related fix required was moving back to AV_PIXFMT* in ffswscale.cpp - the rest of it was completely invalid because AvxSynth did not have some updates, it's the c_plugin's AvxSynth plugin source that's more up-to-date (read: virtually identical to the regular AviSynth plugin in the master branch, sans 2.6/avsplus pixfmts and internal resizers AvxSynth doesn't support). Use --disable-ffms2 when building AvxSynth, use --enable-shared --enable-avxsynth when building FFMS2 from c_plugin.

myrsloik commented 6 years ago

I'd rather prune all old branches. That way there's no confusion.