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>
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>
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.