Made appropriate changes to be able to successfully
build C++ files using a Visual C++ build on Windows.
Based on an earlier patch by Kyle Schwarz.
Comments:
-- compat/w32pthreads.h: Made appropriate changes to w32pthreads.h to
get it to build when it is being included in a C++ file and built
with Visual C++. This is mostly a copy of Kyle Schwarz's patch as
described above.
-- configure:
a) Now calling set_ccvars CXX to cause the various CXX_ variables to
be setup properly. For example, with MSVC (Microsoft Visual C++),
this causes CXX_O to be set to -Fo$@ instead of using the default
value. The default value does not work with Visual C++. This
change will also have the impact of correcting CXX_O (and possibly
CXX_C) for other compilers, although this is really only relevant
for the Intel compiler, in addition to MSVC.
b) Now using cl for the C++ compiler for the MSVC toolchain. This is
currently only relevant for building the
Blackmagic/Decklink-related files under avdevice.
Signed-off-by: Hendrik Leppkes <h.leppkes@gmail.com>
The typeof keyword is apparently not available when using the -std=c99 option.
Fixes the use of C11 atomic functions with old GCC.
Reviewed-by: Muhammad Faiz <mfcc64@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
The Solaris and Windows emulations of atomic_compare_exchange_strong()
need typecasts to avoid compiler warnings, because the functions they
call expect a void* pointer but an intptr_t integer is passed.
Note that the emulations of atomic_compare_exchange_strong() (except
the gcc version) only work for atomic_intptr_t because of the type of
the second argument (|expected|). See
http://en.cppreference.com/w/c/atomic:
_Bool atomic_compare_exchange_strong( volatile A* obj,
C* expected, C desired );
The types of the first argument and second argument are different
(|A| and |C|, respectively). |C| is the non-atomic type corresponding
to |A|. In the emulations of atomic_compare_exchange_strong(), |C| is
intptr_t. This implies |A| can only be sig_intptr_t.
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Supporting the system was a nice joke for the 9 release, but it has
run its course. Nowadays Plan 9 receives no testing and has no
practical usefulness.
Adapted from the code by Rémi Denis-Courmont from VLC
This merges libav commit eb34d40354.
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Adapted from the code by Rémi Denis-Courmont from VLC
This merges libav commit f9a6a80e06.
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Adapted from the code by Rémi Denis-Courmont from VLC
This merges libav commit bb81ed4765.
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Adapted from the code by Rémi Denis-Courmont from VLC
This merges libav commit c2755864af.
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Adapted from the code by Rémi Denis-Courmont from VLC
This merges libav commit 4e928ef340.
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
The nvidia 375.xx driver introduces support for P016 output surfaces,
for 10bit and 12bit HEVC content (it's also the first driver to support
hardware decoding of 12bit content).
The cuvid api, as far as I can tell, only declares one output format
that they appear to refer to as P016 in the driver strings. Of course,
10bit content in P016 is identical to P010, and it is useful for
compatibility purposes to declare the format to be P010 to work with
other components that only know how to consume P010 (and to avoid
triggering swscale conversions that are lossy when they shouldn't be).
For simplicity, this change does not maintain the previous ability
to output dithered NV12 for 10/12 bit input video - the user will need
to update their driver to decode such videos.
We need to remove the dynlink fanciness and replace it with normal
function prototypes and update the include paths and configure logic.
We don't need to explicitly check for PICPARMS now - they're going
to be there.
For unknown reasons, the only accurately descriptive version of
cuviddec.h is in the Video SDK - the one in CUDA 7.5 lacks vp8
PICPARAMS and the vp9 struct definition is inaccurate. The CUDA 8 RC
includes an ancient version of this file from many many years go.
However, the one in the Video SDK is modified to work through a
dynamic link mechanism which we don't really want to use, so the
next change will modify the files to just declare functions in
the normal way.
I've split the changes so it's clear to see what changed between
the original files and ones that work for us.
As Nvidia has put the most recent Video Codec SDK behind a double
registration wall, of which one needs manual approval of a lenghty
application, bundling this header saves everyone trying to use NVENC
from that headache.
The header is still MIT licensed and thus fine to bundle with ffmpeg.
Not bundling this header would get ffmpeg stuck at SDK v6, which is
still freely available, holding back future development of the NVENC
encoder.
Previously, with JACK installed, the configure script would enable the
JACK indev; this broke on OS X due to an incomplete pthreads
implementation. Add some simple macros to map libdispatch to pthreads
on OS X.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
1. Manipulate waiting count in pthread_cond_wait()
2. Use builtin atomic functions to manipulate waiting count
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '407ac22322e5ce67996ec54ef619cafa4c9ceb78':
w32pthreads: Map MemoryBarrier to __sync_synchronize on mingw
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
This is how the other perl scripts in git call perl
Reviewed-by: Ganesh Ajjanagadde <gajjanag@mit.edu>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When SSE2 or higher compiler optimizations are used, mingw uses
the _mm_mfence intrinsic for MemoryBarrier, however it doesn't include
the appropriate headers automatically.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
When SSE2 or higher compiler optimizations are used, mingw uses
the _mm_mfence intrinsic for MemoryBarrier, however it doesn't include
the appropriate headers automatically.
The versioning facility in the Solaris linker differs from Linux in 3 ways:
1. It does not support globs in linker scripts for
symbol versioning -- this is a GNU extension.
2. The linker argument is '-M', instead of '--version-script'.
3. It is picky about line endings.
Each symbol or directive must be on a line of it's own.
Let's use make_sunver.pl from GCC to generate a version script that works
correctly with the Solaris linker. It's function is to correctly expand the
globs in the original generated version script.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This removes the requirement of calling w32thread_init before being
able to use the threading primitives.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The emulation uses native InitOnce* APIs on Windows Vista+, and a
lock-free/allocation-free approach using atomics and spinning for
Windows XP.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
favor link over link.exe in case some wrapper script already exists
fallback to "link" in the path if the one next to cl is not found
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If the user attempts to use AviSynth 2.5, an error message will
now tell them they need to upgrade.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The demuxer doesn't use these functions, so it shouldn't affect
anything. Investigate whether this can be fixed by how headers
are checked in configure.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Wrap the function calls in a similar fashion to how it's being done
with the critical section API.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
This silences warnings about passing arguments from incompatible pointer type
when targeting Windows Vista or newer.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
Wrap the function calls in a similar fashion to how it's being done
with the critical section API.
Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: James Almer <jamrial@gmail.com>
This silences warnings about passing arguments from incompatible pointer type
when targeting Windows Vista or newer.
Tested-by: Matt Oliver <protogonoi@gmail.com>
Reviewed-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: James Almer <jamrial@gmail.com>
* commit '6baeadd11083774ebd823dd5e1a744c2150a3bfc':
w32pthreads: Mark functions in compatibility wrapper as av_unused
Conflicts:
compat/w32pthreads.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This avoids annoying warnings about unused functions. The compatibility
wrapper is designed to provide a complete (stub) API, so some functions
being unused by some files is natural and no reason for a warning.
* commit '428b0578c64241fc677fed7083cc8fe65e10f32e':
w32threads: Use newer thread synchronization functions when targeting Vista
Merged-by: Michael Niedermayer <michaelni@gmx.at>
When explicitly targeting Vista or newer (which only happens if the
caller explicitly sets _WIN32_WINNT to a high enough value via the
extra cflags option - otherwise configure script sets
-D_WIN32_WINNT=0x0502), we already unconditionally link to the
ConditionVariable functions, since 4622f11f9.
Similarly use the newer -Ex versions of CreateEvent, CreateSemaphore,
InitializeCriticalSection and WaitForSingleObject, that all appeared
in Vista. When building Windows Store applications, the older versions
of these functions aren't available, only the -Ex functions. When
doing such a build, the user can set -D_WIN32_WINNT=0x0600 to
forcibly use the newer functions instead.
Signed-off-by: Martin Storsjö <martin@martin.st>
The values of {FLT,DBL}_{MAX,MIN} macros on some systems (older musl
libc, some BSD flavours) are not exactly representable, i.e.
(double)DBL_MAX == DBL_MAX is false
This violates (at least some interpretations of) the C99 standard and
breaks code (e.g. in vf_fps) like
double f = DBL_MAX;
[...]
if (f == DBL_MAX) { // f has not been changed yet
[....]
}
Since we have this compat/va_copy.h header already we might just as well make
use of it for more than one compiler.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
* commit 'ef51692a49d58963966adca55c62da9c34c3c7e1':
Revert "w32pthread: help compiler figure out undeeded code"
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '4332bf98dc051fd1ffbd9d4ddc1c5e55790c96f1':
w32threads: Don't use function pointers when linking directly to newer APIs
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This reverts commit 4622f11f9c.
The compiler should be able to do the dead code elimination now
without this when the cond_* names point directly to the real
functions instead of to local function pointers.
Signed-off-by: Martin Storsjö <martin@martin.st>
This reduces the call overhead slightly. More noticeably, it
restores the earlier (unintended?) feature that condition variable
functions work just fine even if w32thread_init() hasn't been called.
This was broken as a side effect of 4622f11f9, if explicitly targeting
Vista+.
This makes w32threading work in VP8 again, if targeting Vista+.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit '4622f11f9c83db8a2e08408c71ff901826ca652c':
w32pthread: help compiler figure out undeeded code
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The emulation code is not needed when targetting Vista+
This helps getting rid of CreateSemaphore symbol, which is
forbidden in Windows Store apps.
Signed-off-by: Martin Storsjö <martin@martin.st>
Uses the 2.5 compatibility header included with the variant of
FFMS2 that uses AviSynth's C-interface. A copy of this header is
now provided in compat/avisynth.
avs_get_row_size_p and avs_get_height_p changed between versions
2.5 and 2.6. Since the avisynth_c.h header that avformat uses
assumes AviSynth 2.6, it would cause 2.5 to crash if given any
kind of real video (the Version() function was known to work,
though).
AvxSynth was unaffected by this issue because, despite being based
on AviSynth 2.5.8 and using 2.5.8's interface version number of 3,
it actually uses 2.6's versions of these functions.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
As far as I can tell the code should not change behaviour
depending on locale in any of these places.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
