- 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>
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.
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>
libgsm never installed more than a single header, the headers installed into
the gsm/ subdirectory by some distros are private. Who started this nonsense
is a mystery, but it got cargo-culted around ever since.
Build h2645_parse.o with it, as every hevc_ps dependency also needs it.
This is more in line with h264's h264parse module.
Signed-off-by: James Almer <jamrial@gmail.com>
This helper is split off check_pkg_config(), setting only the pkg CFLAGS
and extralibs. This is useful for checks that do not require or do not
benefit from setting global CFLAGS.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Diego Biurrun <diego@biurrun.de>
The filter supports two inputs and (implicitly) scaling the second input
during composition, unlike the software overlay.
The code has been separated into common interface and qsv overlay
implementation. The common part mainly creates the qsv session and
manages the surface which is nearly the same for all qsv filters.
So the qsvvpp.c/qsvvpp.h API can be used by other QSV vpp filters
to reduce code redundancy.
Usage:
-hwaccel qsv -c:v mpeg2_qsv -r 25 -i in.m2v -hwaccel qsv -c:v h264_qsv
-i in.h264 -filter_complex
"overlay_qsv=eof_action=repeat:x=(W-w)/2:y=(H-h)/2" -b 2M -maxrate 3M
-c:v h264_qsv -y out.h264
Two inputs should have different sizes otherwise one will be completely
covered or you need to scale the second input as follows:
-hwaccel qsv -c:v mpeg2_qsv -r 25 -i in.m2v -hwaccel qsv -c:v h264_qsv
-i in.h264 -filter_complex
"overlay_qsv=w=720:h=576:x=(W-w)/2:y=(H-h)/2" -b 2M -maxrate 3M -c:v
h264_qsv -y out.h264
Signed-off-by: ChaoX A Liu <chaox.a.liu@gmail.com>
Signed-off-by: Zhengxu Huang <zhengxu.maxwell@gmail.com>
Signed-off-by: Andrew Zhang <huazh407@gmail.com>
Change-Id: I5c381febb0af6e2f9622c54ba00490ab99d48297
Signed-off-by: Maxym Dmytrychenko <maxim.d33@gmail.com>
Add common filters of the qsv vpp features including scale,denosie,
deinterlace,frc,crop and procAmp.
Performance will be significantly reduced in the test if using cascade
mode just like qsv framerate + qsv scale + qsv deinterlace + qsv denoise in
separated way no matter in system or video memmory cases.
And the code is so redundant because so much the same just as session and
surface's creation and management.
So we add a common qsv filter.
Usage:
-hwaccel qsv -c:v h264_qsv -r 25 -i in -vf
vpp_qsv=w=iw/2:h=400:deinterlace=1:framerate=60:detail=50:denoise=50
-b 2M -maxrate 3M -c:v h264_qsv -y out.h264
Signed-off-by: ChaoX A Liu <chaox.a.liu@gmail.com>
Signed-off-by: Zhengxu Huang <zhengxu.maxwell@gmail.com>
Signed-off-by: Andrew Zhang <huazh407@gmail.com>
Change-Id: I130392ce722138c209ab658c5f03f0009b6e8024
Signed-off-by: Maxym Dmytrychenko <maxim.d33@gmail.com>
This avoids having to use pseudo relocations.
The version script used for exporting functions is skipped as soon
as the set of object files contains symbols marked with dllexport,
therefore we need to use makedef to produce the full list of symbols
to be exported.
Signed-off-by: Martin Storsjö <martin@martin.st>
The toolchain for this target is unmaintained since many years.
While it has been continuously build tested on fate, it hasn't
actually been tested at runtime since many, many years (and back
then, only a few codecs in libavcodec were tested).
So far, keeping support for it has been mostly effortless, but
the compiler does seem to have issues with dllimported data symbols,
ending up as internal compiler errors in some cases. Instead of
jumping through further hoops to work around that, just remove the
target.
Signed-off-by: Martin Storsjö <martin@martin.st>
