F4V is Adobe's mp4/iso media variant, with the most significant
addition/change being supporting other flash codecs than just
aac/h264.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is in preparation for removing a .rodata kludge
which was only required for older YASM versions.
The movbe instruction was introduced in 0.8.0, which already
had AVX, which was introduced in 0.7.0, and NASM introduced
movbe in 2.0.3, which is the same version which introduced
AVX support.
Also, make the failure message more accurate.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
The implementation of 25cb0c1a involves lots of spurious labels.
The effect of keeping those labels around is making debugging harder.
Those labels are meaningless, and complicate the disassembly. Also,
gdb can't tell the difference between them and function entry points.
This new strip command is irrelevant to any usage of Libav that would
have used the old fully stripped version, because the old one was for
non-debug use.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Qansi-alias worked on 12.x, then caused miscompilation on 13.x, but now
works again passing all FATE tests for icl version 14.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Prior to this on msvc/icl there was no handling of deprecated functions
and the deprecated warning was disabled.
After enabling there are a number of warnings relating to the CRT and
the use of the non-secure versions of several functions. Defining
_CRT_SECURE_NO_WARNINGS silences these warnings.
Signed-off-by: Martin Storsjö <martin@martin.st>
The i686 feature really is a CPU feature and should be handled as such.
The cpunop dependency on i686 should be expressed with a standard _deps
declaration instead of a manual test.
The hls muxer itself doesn't have any direct (object file level)
dependencies on mpegtsenc.o, and including that object file
directly doesn't ensure that it is registered so that the muxer
actually is accessible.
Signed-off-by: Martin Storsjö <martin@martin.st>
There is no record of this ever being used at all, anywhere,
since the feature was added in 2effd27446.
This gets rid of extra linker tricks just to support a feature
that isn't used, simplifying portability to other platforms.
Signed-off-by: Martin Storsjö <martin@martin.st>
Use this for enabling the ppc timer.h implementation only on
assemblers that support labels in the inline assembly.
Signed-off-by: Martin Storsjö <martin@martin.st>
Because O1 or O2 are required to build libav with msvc/icl, this must be
explicitly set instead of just omitting Oy.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
It is implied by O1 or O2, both of which are required to build libav
with msvc/icl. Silences warnings when targeting x64 with icl.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This avoids warnings about this option not having any effect on
this platform.
We still want to enable the pic configure item for these platforms
(if detected via the compiler builtin define __PIC__) to get proper
inline assembly workarounds.
Signed-off-by: Martin Storsjö <martin@martin.st>
This reverts e08c946c6 and 05165c2f7a. The actual intention of
e08c946c6 was to fix shared library builds for arm/win32, which
can also be accomplished in other ways.
Disabling pic on those platforms broke inline assembly on cygwin/64
(since some inline assembly requires knowing whether we are building
as PIC or not), and might also break inline assembly on other
compilers on windows.
As a side-effect, this unfortunately brings back all the warnings
about PIC not having any effect on that platform.
Signed-off-by: Martin Storsjö <martin@martin.st>
The object file format doesn't support PIC loads in ARM assembly,
there are no relocation types in PE/COFF that correspond to
BFD_RELOC_32_PCREL (R_ARM_REL32 in ELF).
Signed-off-by: Martin Storsjö <martin@martin.st>
Allows for easier handling of flags that may be specific to icl or msvc.
Furthermore, simplify the handling of warnings and remarks thanks to
icl's support of -Wall on Windows.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
