This avoids issues linking to a DLL version of libspeex, since the
libspeex headers lack proper dllimport declarations for the data
symbols.
This isn't an issue when building with mingw with GNU binutils, since
GNU ld can fix up that kind of data import automatically.
libspeexdec.c already uses speex_lib_get_mode as well.
Signed-off-by: Martin Storsjö <martin@martin.st>
- Move generating config.fate to a more sensible place.
- Move printing warnings to a more appropriate place.
- Improve "generated by" comment in libavutil/avconfig.h.
- Drop pointless informative output about generating config files.
- Write a standard comment header to config.asm as well.
- Reuse sanitize_var_name() where appropriate
- Add some quotes to enabled()/disabled() to ease readability
- Fix logged names of some helper functions
- Filter LDFLAGS also in test_ldflags()
There shouldn't be any functional difference between the import
library created by dlltool and the one produced by the linker itself.
Keep installing it with both names though, for compatibility with users
that expect both to exist.
The dlltool step was added in ec10a9ab4; prior to that, a MSVC
compatible import library was generated using lib.exe. After that
commit, there was no functional difference between the two import
libraries (and since MSVC 2012, link.exe works just fine with the
GNU binutils generated one).
Signed-off-by: Martin Storsjö <martin@martin.st>
Leads to setting of DefaultDuration in Matroska muxer based on frame rate instead of timebase.
Fixes playback in Chrome.
Signed-off-by: Peter Große <pegro@friiks.de>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This is an ABI change in libva2: previously the Intel driver had this
behaviour and it was implemented as a driver quirk, but now it is part
of the specification so all drivers must do it.
This has been deprecated in libva2 because hardware does not and will not
support it. Therefore never consider it for decode, and for encode assume
the user meant constrained baseline profile instead.
Commit b46a77f19d accidentally broke this (requested change that was
added to the patch later and which was not fully tested).
Signed-off-by: Mark Thompson <sw@jkqxz.net>
This adds a new API, which allows the API user to query the required
AVHWFramesContext parameters. This also reduces code duplication across
the hwaccels by introducing ff_decode_get_hw_frames_ctx(), which uses
the new API function. It takes care of initializing the hw_frames_ctx
if needed, and does additional error handling and API usage checking.
Support for VDA and Cuvid missing.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
According to the MediaSDK documentation the idr_interval value has
a different meaning depending on the codec:
0 in H264 means make every I-frame IDR, in HEVC it means to have
it only at the beginning.
1 in H264 means every other I-frame is not-IDR, in HEVC it means
that every I-frame is IDR.
Keep the behaviour consistent between the two encoders by increasing
by 1 internally the idr_interval value for HEVC.
The extra space got included as part of the expansion of ELF, which
later interfered with gas-preprocessor which earlier only stripped out
leftover lines starting with '#' if the line started with that char.
Signed-off-by: Martin Storsjö <martin@martin.st>
Support for this device has been removed in the Linux kernel since v2.6.37.
dv1394 has been superseded by libiec61883 which is functionally equivalent.
Signed-off-by: Josh de Kock <josh@itanimul.li>
Signed-off-by: Diego Biurrun <diego@biurrun.de>
The libavformat API is not suitable for exporting output devices as muxers.
Some practical problems are e.g. lack of timing/synchronization mechanisms
or interaction with output-specific features.
Since this machine type is 5 chars while the existing ones only
were 3 (which the regexp assumed), the regexp has to be extended
a little.
Signed-off-by: Martin Storsjö <martin@martin.st>
On X86 windows, asflags weren't actually ever used for anything,
since assembling used x86asflags instead, and that flags list
had -DPIC already.
This fixes building shared libraries with clang for arm/aarch64
windows. (This wasn't an issue when in msvc mode before, since
we don't try to enable pic at all there, since the msvc armasm
assembler fails on our pic constructs there.)
Signed-off-by: Martin Storsjö <martin@martin.st>
We skipped adding it to cflags for mingw/cygwin configurations
where the compiler either complains loudly or even errors out;
do the same for target_os=win32, for the case when building with
clang in msvc mode.
This wasn't needed for the actual msvc before, since msvc uses
msvc_common_flags to filter out this flag from cflags.
When building with clang in msvc mode, no such filter is used.
This fixes building shared libraries with clang in msvc mode.
Signed-off-by: Martin Storsjö <martin@martin.st>
