[FFmpeg-devel] [PATCH 2/3] Provide local copies of avisynth_c.h, avxsynth_c.h, and avxsynth_c.h's requisite headers in compat/avisynth/. The versions of the headers are the same as those provided with x264 for consistency.
qyot27 at gmail.com
Sun Mar 3 06:26:14 CET 2013
On Sat, Mar 2, 2013 at 8:05 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> Normally libraries on posix systems install their headers somewhere
> in /usr/include or /usr/local/include or other similar places
> when they are installed
> Why do applications that want to use avisynth/avxsynth on "linux"
> need to duplicate these headers?
> also i see avisynth_c.h in libx264 but not the others
x264 committed AvxSynth support (which includes the extra headers) on
Feb 26th in the latest big push:
In AviSynth's case it's probably a historical situation since AviSynth
is built with Visual Studio, not GCC*, and so Windows users would have
to track down a copy of the header themselves and manually copy it
into /usr/include or wherever they have their includes in their
MSys/MinGW or Cygwin environment (or MinGW environment on a
non-Windows OS). There's also probably the element of convenience of
not wanting to force users to have to compile the AviSynth DLL first,
and simply rely on the official builds.
*avisynth_c.h provides the C interface that GCC can use, but only
covers plugins and external programs that want to load the AviSynth
Providing the headers for AvxSynth locally is meant to match this
behavior to an extent, but it also sidesteps a circular dependency
(FFmpeg is a dependency of AvxSynth to start with), and a lesser issue
with how the avxsynth_c.h from a standard AvxSynth install includes
the windowsPorts subdirectory. The last one is something that should
get fixed on AvxSynth's side, and in the event of that happening it
would mean it'd only be for convenience and to match AviSynth.
Regarding the demuxer patch itself, there's been a couple new issues
that have cropped up during additional testing that need to be fixed
(one is the Unicode filenames issue on Windows reappearing, and the
other has to do with something causing ffmpeg to hang before encoding
starts when trying to use audio from scripts with certain framerates).
d s/avxsynth-testing did say they were willing to be a maintainer for
the code if it's accepted, though.
More information about the ffmpeg-devel