Fixes the following security issues (https://ffmpeg.org/security.html):
3.2.4:
CVE-2017-5024 - FFmpeg in Google Chrome prior to 56.0.2924.76 for Linux,
Windows and Mac, failed to perform proper bounds checking, which allowed a
remote attacker to potentially exploit heap corruption via a crafted video
file.
CVE-2017-5025 - FFmpeg in Google Chrome prior to 56.0.2924.76 for Linux,
Windows and Mac, failed to perform proper bounds checking, which allowed a
remote attacker to potentially exploit heap corruption via a crafted video
file.
3.2.5:
CVE-2017-9991 - Heap-based buffer overflow in the xwd_decode_frame function
in libavcodec/xwddec.c in FFmpeg before 2.8.12, 3.0.x before 3.0.8, 3.1.x
before 3.1.8, 3.2.x before 3.2.5, and 3.3.x before 3.3.1 allows remote
attackers to cause a denial of service (application crash) or possibly have
unspecified other impact via a crafted file.
CVE-2017-9992 - Heap-based buffer overflow in the decode_dds1 function in
libavcodec/dfa.c in FFmpeg before 2.8.12, 3.0.x before 3.0.8, 3.1.x before
3.1.8, 3.2.x before 3.2.5, and 3.3.x before 3.3.1 allows remote attackers to
cause a denial of service (application crash) or possibly have unspecified
other impact via a crafted file.
CVE-2017-9994 - libavcodec/webp.c in FFmpeg before 2.8.12, 3.0.x before
3.0.8, 3.1.x before 3.1.8, 3.2.x before 3.2.5, and 3.3.x before 3.3.1 does
not ensure that pix_fmt is set, which allows remote attackers to cause a
denial of service (heap-based buffer overflow and application crash) or
possibly have unspecified other impact via a crafted file, related to the
vp8_decode_mb_row_no_filter and pred8x8_128_dc_8_c functions.
CVE-2017-9996 - The cdxl_decode_frame function in libavcodec/cdxl.c in
FFmpeg 2.8.x before 2.8.12, 3.0.x before 3.0.8, 3.1.x before 3.1.8, 3.2.x
before 3.2.5, and 3.3.x before 3.3.1 does not exclude the CHUNKY format,
which allows remote attackers to cause a denial of service (heap-based
buffer overflow and application crash) or possibly have unspecified other
impact via a crafted file.
3.2.6:
CVE-2017-9608 - NULL pointer exception.
CVE-2017-9993 - FFmpeg before 2.8.12, 3.0.x and 3.1.x before 3.1.9, 3.2.x
before 3.2.6, and 3.3.x before 3.3.2 does not properly restrict HTTP Live
Streaming filename extensions and demuxer names, which allows attackers to
read arbitrary files via crafted playlist data.
3.2.7:
CVE-2017-11399 - Integer overflow in the ape_decode_frame function in
libavcodec/apedec.c in FFmpeg through 3.3.2 allows remote attackers to cause
a denial of service (out-of-array access and application crash) or possibly
have unspecified other impact via a crafted APE file.
CVE-2017-11665 - The ff_amf_get_field_value function in
libavformat/rtmppkt.c in FFmpeg 3.3.2 allows remote RTMP servers to cause a
denial of service (Segmentation Violation and application crash) via a
crafted stream.
CVE-2017-11719 - The dnxhd_decode_header function in libavcodec/dnxhddec.c
in FFmpeg through 3.3.2 allows remote attackers to cause a denial of service
(out-of-array access) or possibly have unspecified other impact via a
crafted DNxHD file.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
ffmpeg always enables support for nvenc/cuda even if their support
libraries are not present:
External libraries providing hardware acceleration:
cuda cuvid nvenc
[...]
Enabled hwaccels:
h264_cuvid mjpeg_cuvid mpeg2_cuvid vc1_cuvid vp9_cuvid
hevc_cuvid mpeg1_cuvid mpeg4_cuvid vp8_cuvid
This leads to a crash in freeswitch git master when transcoding video
streams on a system without nvidia hardware:
2017-07-22 15:06:27.306760 [INFO] avcodec.c:1077 initializing encoder 352x288
2017-07-22 15:06:27.306760 [NOTICE] avcodec.c:828 NVENC HW CODEC ENABLED
This patch disables the support of nvidia hardware acceleration support
for now until the needed packages are added to buildroot. For details
about this please refer to https://developer.nvidia.com/ffmpeg
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
(cherry picked from commit 3b6fa452f6)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Upstream has dropped SDL support for ffplay in favor of SDL2.
This results in silently not building ffplay even if it is selected
in Buildroot config.
[Peter: propagate !static dependency from sdl2]
Signed-off-by: Phil Eichinger <phil@zankapfel.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This option is needed to prevent this message from configure:
WARNING: unknown CPU. Disabling all MIPS optimizations.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
[Thomas:
- group with the other --cpu conditions so that only one is passed.
- improve the comment.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The current logic to pass the --{enable,disable}-mipsfpu option is:
ifeq ($(BR2_MIPS_SOFT_FLOAT),y)
FFMPEG_CONF_OPTS += --disable-mipsfpu
else
FFMPEG_CONF_OPTS += --enable-mipsfpu
endif
In practice, this means that on MIPS soft-float, --disable-mipsfpu is
passed, and that in *all* other cases, --enable-mipsfpu is passed,
including if we are *not* targetting the MIPS architecture.
Even though this doesn't seem to cause any problem, it is a bit weird to
see --enable-mipsfpu when you're building ffmpeg for a non-MIPS
architecture, so we better fix this by enclosing the MIPS-related
options in a MIPS condition.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When BR2_ARM_CPU_HAS_NEON=y, we pass --enable-neon. However, when
BR2_ARM_CPU_HAS_NEON is disabled, we don't pass anything. This generally
works fine, but turned out to integrate NEON code in ARMv7-M
builds (since it's ARMv7, ffmpeg assumed it should enable NEON code).
Even though ffmpeg is now disabled for ARMv7-M, it still makes sense to
be explicit, and disable NEON support when the CPU doesn't have it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In the ffmpeg code, libavutil/arm/asm.S makes some assumption about the
ARM architecture for which the code is built. Only ARMv4, ARMv5, ARMv6
and ARMv7-A is supported. Due to this, object files built out of
ARM-optimized assembly code have the wrong architecture information,
causing a failure at link time.
Adding ARMv7-M support would be possible, but it doesn't exist yet in
ffmpeg, and it's pretty unlikely that ffmpeg will ever be needed on an
ARMv7-M platform, so this commit takes the simple approach of disabling
ffmpeg for ARMv7-M.
Fixes:
http://autobuild.buildroot.net/results/ca4c67b093afd6f14349fcdc87b02e0480172e8c/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
MIPS architecture detection is not accurate and is always detected as
mips64 even if we are using mips64r2 or mips64r6. Due to that, ffmpeg's
build system will pass the -mips64 flag which will conflict with the
-march option that our toolchain wrapper uses, and it will fail to build
showing errors like this one:
error: '-mips64' conflicts with the other architecture options, which
specify a mips64r2 processor
This problem has been already fixed upstream, but we would need to
backport 17 patches plus some changes in the ffmpeg.mk file. This is too
much, so better to just disable ffmpeg for mips64r2 and mips64r6 for the
upcoming Buildroot release.
This commit can be reverted in the next ffmpeg's version bump.
Fixes:
http://autobuild.buildroot.net/results/7fd/7fd8187c0110cdcac622e667f4a81d2db84f11ef/
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
ffmpeg was already marked as not available for the NIOS2 Sourcery
toolchains, but it could still be built with the internal toolchain
backend or a custom external toolchain.
However, an inspection of the latest glibc source code indicates that
FE_INVALID, FE_OVERFLOW and FE_UNDERFLOW and indeed not available in
the nios2 variant of <fenv.h>.
Consequently, this patch makes ffmpeg not available on nios2, which
allows to simplify a bit the dependencies.
It propagates this dependency to:
- minidlna (and at the same time makes sure the minidlna comment is
not displayed on nios2, which wasn't properly taken into account
until now)
- mpd
- opencv
- opencv3
- squeezelite
- tovid
Even if it selects ffmpeg, Kodi does not need an update since Kodi is
only available on a limited number of architectures (which don't
include nios2, obviously). Other packages only make use of ffmpeg when
available.
Fixes:
http://autobuild.buildroot.org/results/921/9212f5a6432c5e695ac0630695405cea05e28610/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
DSP support depends on the core implementation, not on the ISA, so
enabling it for mips64r2 is not correct since you can build a mips64r2
core without DSP support.
Disable mipsdspr1 and mipsdspr2 options by default and let the user
enable them via the BR2_PACKAGE_FFMPEG_EXTRACONF kconfig option, which
will take preference and override the default values.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
0016-ranlib.patch is not needed anymore since the problem that it fixes
is already handled upstream:
2c77ca459e
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
