Re: [FFmpeg-devel] [FFmpeg-cvslog] Merge commit '7cb1d9e2dbbe5bf4652be5d78cdd68e956fa3d63'
Hello On 10/14/2017 01:32 AM, James Almer wrote: On 10/13/2017 6:30 PM, Reino Wijnsma wrote: On 13-10-2017 18:48, James Almer wrote: Are "-lshlwapi -lpthread -lcrypt32" extralibs you added manually, or were they derived from dependencies like libmpg123, vorbis, etc by pkg-config? My configure line up until now with the manually added extra-libs: # ./configure --arch=x86 --target-os=mingw32 --cross-prefix=/cygdrive/m/ffmpeg-windows-build-helpers-master/native_build/windows/ffmpeg_local_builds/sandbox/cross_compilers/mingw-w64-i686/bin/i686-w64-mingw32- --pkg-config=pkg-config --pkg-config-flags=--static --extra-version=Reino --enable-gray --enable-version3 --disable-debug --disable-doc --disable-htmlpages --disable-manpages --disable-podpages --disable-schannel --disable-txtpages --disable-w32threads --enable-avisynth --enable-avresample --enable-fontconfig --enable-frei0r --enable-filter=frei0r --enable-gmp --enable-gnutls *--extra-libs=-lcrypt32* --enable-gpl --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --extra-cflags=-DCACA_STATIC --enable-libfdk-aac --enable-libflite --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libilbc *--extra-libs=-lpthread* --enable-libmp3lame --enable-libmysofa --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenmpt *--extra-libs=-lshlwapi* --enable-libopus --enable-librubberband --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --extra-cflags=-DLIBTWOLAME_STATIC --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxml2 --enable-libxvid --enable-libzimg --enable-libzvbi --extra-cflags='-march=pentium3' --extra-cflags=-O2 --extra-cflags='-mfpmath=sse' --extra-cflags=-msse --enable-static --disable-shared --prefix=/cygdrive/m/ffmpeg-windows-build-helpers-master/native_build/windows/ffmpeg_local_builds/sandbox/cross_compilers/mingw-w64-i686/i686-w64-mingw32 See if adding -lstdc++ fixes it. It does. Ok, fixing this way then. Consider reporting this bug to libopenmpt, while at it. They should add -lstdc++ to their pkg-config file for static builds, instead of projects using the library having to workaround it. I'm the libopenmpt maintainer. The problem is not solved by adding a hard-coded -lstdc++ to pkg-config Libs.private. This would only be correct if the C++ standard library is actually called "libstdc++" on the given platform. In particular, it is not called libstdc++ on FreeBSD and macOS (where LLVM libc++ is used by default) and libstdc++ might be available additionally. Android is even worse with its many available C++ standard libraries. Sadly, I am not aware of an easy and fail-proof way to detect the name of the C++ standard library from within the build system. As far as I know (please correct me if I am wrong), there is no gcc or clang option to actually return it (which could be used in an Autoconf check). For clang, it can even be chosen by the user when building by specifying appropriate CXXFLAGS (-stdlib=[libstdc++|libc++]). The problem is fundamentally inherent to statically linking libraries implemented in C++ with pkg-config. "Libs.private: -lstdc++" would fix the default Linux setup with GCC (and cross-compiling with MinGW), but would break FreeBSD and macOS. I'd rather prefer to not handle that and leave it up to the user who builds (the user knows which build system/target/platform system is used and can thus add the required C++ standard library when using static linking (or use the C++ compiler instead of the linker for linking everything, however this implies using a C++ compiler for libraries that themselves do not actually use C++ in the first place)). I am fully aware that this is not a perfect solution, but frankly, I do not think there is one available with the current infrastructure situation. There was also a discussion on the pkg-config mailing list not too long ago which further goes into details about the issue (talking about a different library, but it applies equally well to the ffmpeg / libopenmpt situation): https://lists.freedesktop.org/archives/pkg-config/2016-August/001055.html Regard, Jörn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Configure: commit 6dfcbd80ad446ff163b47f2bf432bbf706436ea8 broke my builds
I build FFmpeg and all the libraries I need every night. Since 08:00
BST on 12-Oct-2017 that build has not worked, the previous build on
11-Oct-2017 worked.
My configure command for building 64bit Linux that is run on an Ubuntu
16.04 system, which worked on Wednesday but not on Thursday, is:
./configure --extra-version=static_x86_64-pc-linux-gnu
--extra-cflags="--static -static" --extra-libs="-static"
--pkg-config-flags="--static" --cross-prefix= --arch=x86_64
--target-os=linux --prefix="/opt/bbc/ff_lib" --enable-gpl
--enable-nonfree --disable-ffplay --disable-dxva2 --enable-libmp3lame
--enable-libfdk-aac --enable-libspeex --enable-libtheora
--enable-libvorbis --enable-libopus --enable-libopenjpeg
--enable-libvpx --enable-libxvid --enable-libx264 --enable-libx265
(yes, the configure contains options, like cross-prefix and arch and
target that are not necessarily normally needed, but I build for
Linux, Windows 32 and 64 bit static binaries and macOS static binary
with the same configure command but with different variable
substitutions)
The configure.log extract is:
...
require libmp3lame >= 3.98.3 lame/lame.h lame_set_VBR_quality -lmp3lame
check_lib libmp3lame lame/lame.h lame_set_VBR_quality -lmp3lame
check_func_headers lame/lame.h lame_set_VBR_quality -lmp3lame
check_ld cc -lmp3lame
check_cc
BEGIN /tmp/ffconf.Daqbd9DA/test.c
1 #include
2 #include
3 long check_lame_set_VBR_quality(void) { return (long)
lame_set_VBR_quality; }
4 int main(void) { int ret = 0;
5ret |= ((intptr_t)check_lame_set_VBR_quality) & 0x;
6 return ret; }
END /tmp/ffconf.Daqbd9DA/test.c
gcc --static -static -I/opt/bbc/ff_lib/include -D_ISOC99_SOURCE
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112
-D_XOPEN_SOURCE=600 --static -static -I/opt/bbc/ff_lib/include
--static -static -std=c11 -fomit-frame
-pointer -pthread -I/opt/bbc/ff_lib/include -c -o
/tmp/ffconf.Daqbd9DA/test.o /tmp/ffconf.Daqbd9DA/test.c
gcc -L/opt/bbc/ff_lib/lib -static -Wl,--as-needed -Wl,-z,noexecstack
-o /tmp/ffconf.Daqbd9DA/test /tmp/ffconf.Daqbd9DA/test.o -lmp3lame
-static
/opt/bbc/ff_lib/lib/libmp3lame.a(gain_analysis.o): In function `AnalyzeSamples':
gain_analysis.c:(.text+0xedd): undefined reference to `log10'
/opt/bbc/ff_lib/lib/libmp3lame.a(gain_analysis.o): In function `analyzeResult':
gain_analysis.c:(.text+0x12aa): undefined reference to `ceil'
/opt/bbc/ff_lib/lib/libmp3lame.a(lame.o): In function `filter_coef':
lame.c:(.text+0xb1): undefined reference to `cos'
/opt/bbc/ff_lib/lib/libmp3lame.a(lame.o): In function `lame_init_params':
lame.c:(.text+0x320c): undefined reference to `pow'
lame.c:(.text+0x3463): undefined reference to `powf'
/opt/bbc/ff_lib/lib/libmp3lame.a(lame.o): In function `lame_print_internals':
lame.c:(.text+0x4613): undefined reference to `log10'
...
Etc. Which suggests to me that -lm is missing.
When I checkout 58143b15adda6391ec07f3eb19e80ed91d801edd, the parent
of 6dfcbd80ad446ff163b47f2bf432bbf706436ea8, my configure works.
When I checkout 6dfcbd80ad446ff163b47f2bf432bbf706436ea8 my configure fails.
If I edit configure to add -lm to the mp3lame tests, which works for
that library, the next library test fails in a similar way. I think
6dfcbd80ad446ff163b47f2bf432bbf706436ea8 has done sevear damage to the
configuration of FFmpeg. I wonder if building static was considered,
or whether my configure command line is not passing the right
parameters to make a static builds.
--
Mark Himsley
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Configure: commit 6dfcbd80ad446ff163b47f2bf432bbf706436ea8 broke my builds
Update: for me with my specific set of libraries, I have had to apply
this patch to configure in order to make configure accept my
configuration parameters: specifically changes to mp3lame, openjpeg
1.5, x265 and xvid.
diff --git a/configure b/configure
index dfbc251..67c012d 100755
--- a/configure
+++ b/configure
@@ -6008,7 +6008,7 @@ enabled libkvazaar&& require_pkg_config
libkvazaar "kvazaar >= 0.8.1" kv
enabled libmfx&& { use_pkg_config libmfx libmfx
"mfx/mfxvideo.h" MFXInit ||
{ require libmfx "mfx/mfxvideo.h"
MFXInit -llibmfx && warn "using libmfx without pkg-config"; } }
enabled libmodplug&& require_pkg_config libmodplug libmodplug
libmodplug/modplug.h ModPlug_Load
-enabled libmp3lame&& require "libmp3lame >= 3.98.3"
lame/lame.h lame_set_VBR_quality -lmp3lame
+enabled libmp3lame&& require "libmp3lame >= 3.98.3"
lame/lame.h lame_set_VBR_quality -lmp3lame -lm
enabled libmysofa && require libmysofa "mysofa.h" mysofa_load -lmysofa
enabled libnpp&& { check_lib libnpp npp.h
nppGetLibVersion -lnppig -lnppicc -lnppc ||
check_lib libnpp npp.h
nppGetLibVersion -lnppi -lnppc ||
@@ -6027,7 +6027,7 @@ enabled libopenjpeg && { { check_lib
libopenjpeg openjpeg-2.3/openjpeg.h o
{ check_lib libopenjpeg
openjpeg-2.1/openjpeg.h opj_version -lopenjp2 -DOPJ_STATIC &&
add_cppflags -DOPJ_STATIC; } ||
check_lib libopenjpeg
openjpeg-2.1/openjpeg.h opj_version -lopenjp2 ||
{ check_lib libopenjpeg
openjpeg-2.0/openjpeg.h opj_version -lopenjp2 -DOPJ_STATIC &&
add_cppflags -DOPJ_STATIC; } ||
- { check_lib libopenjpeg
openjpeg-1.5/openjpeg.h opj_version -lopenjpeg -DOPJ_STATIC &&
add_cppflags -DOPJ_STATIC; } ||
+ { check_lib libopenjpeg
openjpeg-1.5/openjpeg.h opj_version -lopenjpeg -lm -DOPJ_STATIC &&
add_cppflags -DOPJ_STATIC; } ||
{ check_lib libopenjpeg openjpeg.h
opj_version -lopenjpeg -DOPJ_STATIC && add_cppflags -DOPJ_STATIC; } ||
die "ERROR: libopenjpeg not found"; }
enabled libopenmpt&& require_pkg_config libopenmpt
"libopenmpt >= 0.2.6557" libopenmpt/libopenmpt.h openmpt_module_create
@@ -6096,10 +6096,10 @@ enabled libx264 && { use_pkg_config
libx264 x264 "stdint.h x264.h" x26
require_cpp_condition x264.h "X264_BUILD
>= 118" &&
{ check_cpp_condition x264.h "X264_MPEG2" &&
enable libx262; }
-enabled libx265 && require_pkg_config libx265 x265 x265.h
x265_api_get &&
+enabled libx265 && require_pkg_config libx265 x265 x265.h
x265_api_get -lpthread &&
require_cpp_condition x265.h "X265_BUILD >= 68"
enabled libxavs && require libxavs "stdint.h xavs.h"
xavs_encoder_encode -lxavs
-enabled libxvid && require libxvid xvid.h xvid_global -lxvidcore
+enabled libxvid && require libxvid xvid.h xvid_global
-lxvidcore -lpthread -lm
enabled libzimg && require_pkg_config libzimg "zimg >=
2.3.0" zimg.h zimg_get_api_version
enabled libzmq&& require_pkg_config libzmq libzmq zmq.h zmq_ctx_new
enabled libzvbi && require libzvbi libzvbi.h
vbi_decoder_new -lzvbi &&
On 14 October 2017 at 11:00, Mark Himsley wrote:
> I build FFmpeg and all the libraries I need every night. Since 08:00
> BST on 12-Oct-2017 that build has not worked, the previous build on
> 11-Oct-2017 worked.
>
> My configure command for building 64bit Linux that is run on an Ubuntu
> 16.04 system, which worked on Wednesday but not on Thursday, is:
>
> ./configure --extra-version=static_x86_64-pc-linux-gnu
> --extra-cflags="--static -static" --extra-libs="-static"
> --pkg-config-flags="--static" --cross-prefix= --arch=x86_64
> --target-os=linux --prefix="/opt/bbc/ff_lib" --enable-gpl
> --enable-nonfree --disable-ffplay --disable-dxva2 --enable-libmp3lame
> --enable-libfdk-aac --enable-libspeex --enable-libtheora
> --enable-libvorbis --enable-libopus --enable-libopenjpeg
> --enable-libvpx --enable-libxvid --enable-libx264 --enable-libx265
>
> (yes, the configure contains options, like cross-prefix and arch and
> target that are not necessarily normally needed, but I build for
> Linux, Windows 32 and 64 bit static binaries and macOS static binary
> with the same configure command but with different variable
> substitutions)
>
> The configure.log extract is:
>
> ...
> require libmp3lame >= 3.98.3 lame/lame.h lame_set_VBR_quality -lmp3lame
> check_lib libmp3lame lame/lame.h lame_set_VBR_quality -lmp3lame
> check_func_headers lame/lame.h lame_set_VBR_quality -lmp3lame
> check_ld cc -lmp3lame
> check_cc
> BEGIN /tmp/ffconf.Daqbd9DA/test.c
> 1 #include
> 2 #include
> 3 long check_lame_set
[FFmpeg-devel] latest ffmpeg (git) and libvpx_vp9
Hello, I freshly recompiled libvpx (for both VP8 and VP9) then FFMPEG and strangely the result only allows me libvpx_vp8 as encoder despite a configure with enable-encoder=libvpx_vp8 and enable-encoder=libvpx_vp9 vpxenc's help lists VP9 as a possible encoder Configuration for libvpx: ./configure --disable-unit-tests --disable-docs --enable-vp8 --enable-vp9 --enable-postproc --enable-vp9-postproc --enable-vp9-temporal-denoising --enable-runtime-cpu-detect Configuration for ffmpeg: ./configure --enable-nonfree --disable-doc --enable-libvpx --prefix=/usr/local --disable-encoders --enable-encoder=libvpx_vp8 --enable-encoder=libvpx_vp9 --disable-ffserver --enable-gpl --enable-encoder=png --enable-encoder=libopus --enable-encoder=webvtt --enable-libopus --enable-ffplay --enable-ffprobe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] latest ffmpeg (git) and libvpx_vp9
Hi, On Sat, Oct 14, 2017 at 8:28 AM, ZikZak wrote: > I freshly recompiled libvpx (for both VP8 and VP9) then FFMPEG and > strangely the result only allows me libvpx_vp8 as encoder despite a > configure with enable-encoder=libvpx_vp8 and enable-encoder=libvpx_vp9 > Please send these types of questions to the user mailinglist: https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-user/ This list is intended for discussions regarding the development of FFmpeg. Thanks, Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/als: remove check for predictor order of a block
Hi, On Sat, Sep 23, 2017 at 8:45 PM, Michael Niedermayer wrote: > > On Fri, Sep 22, 2017 at 01:54:27PM +0530, Umair Khan wrote: > > On Thu, Sep 21, 2017 at 6:30 PM, Paul B Mahol wrote: > > > On 9/21/17, Umair Khan wrote: > > >> Hi Ronald, > > >> > > >> On Mon, Sep 11, 2017 at 10:27 PM, Ronald S. Bultje > > >> wrote: > > >>> Hi Umair, > > >>> > > >>> On Mon, Sep 11, 2017 at 4:06 AM, Umair Khan wrote: > > >>> > > On Sun, Sep 10, 2017 at 10:30 PM, Paul B Mahol > > wrote: > > > On 9/10/17, Umair Khan wrote: > > >> On Sun, Sep 10, 2017 at 9:52 PM, Thilo Borgmann > > >> > > > > >> wrote: > > >>> > > >>> Hi, > > >>> > > >>> > This patch fixes this bug - https://trac.ffmpeg.org/ticket/5297 > > >>> > > >>> this is yet another iteration of > > >>> > > >>> http://ffmpeg.org/pipermail/ffmpeg-devel/2017-June/213005.html > > >> > > >> I see. I was keepnig reference codec as the source of truth. > > >> > > >> How do I reproduce this segfault? - > > >> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/202530.html > > >> Is it one of the fate tests failing? > > > > > > No. > > > > In that case there's not much which can be done with this bug. > > That being said, I'm pretty sure we will anyways end up removing this > > check. > > >>> > > >>> > > >>> I think your question is "how do I get access to this sample", right? > > >>> You > > >>> could ask Michael. > > >> > > >> Paul also tried to fix this bug, hence I'm assuming that he already > > >> asked Michael about the sample file. Anyways, it'd not be difficult to > > >> fix this bug if we can reproduce it. > > > > > > Thilo do not want to apply Michael fix because he do not understand his > > > patch. > > > > Which fix are you talking about? > > > > I see that Michael added this check in the first place - > > http://git.videolan.org/?p=ffmpeg.git;a=commit;h=18f94df8af > > If someone can provide me with the file which is causing the segfault, > > maybe I can look into it. > > file sent privatly to umair I tested the file which Michael sent. The thing is that I'm getting error in decoding that file in both the cases, with or without the patch. I will begin debugging this issue, however I think the file which Michael sent has got nothing to do with the patch in this thread. -Umair ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] latest ffmpeg (git) and libvpx_vp9
Ah sorry, as I used the git version I thought it would be better here. My bad. On 14 October 2017 at 14:50, Ronald S. Bultje wrote: > Hi, > > On Sat, Oct 14, 2017 at 8:28 AM, ZikZak wrote: > > > I freshly recompiled libvpx (for both VP8 and VP9) then FFMPEG and > > strangely the result only allows me libvpx_vp8 as encoder despite a > > configure with enable-encoder=libvpx_vp8 and enable-encoder=libvpx_vp9 > > > > Please send these types of questions to the user mailinglist: > https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-user/ > > This list is intended for discussions regarding the development of FFmpeg. > > Thanks, > Ronald > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/als: remove check for predictor order of a block
On Sat, Oct 14, 2017 at 7:29 PM, Umair Khan wrote: > Hi, > > On Sat, Sep 23, 2017 at 8:45 PM, Michael Niedermayer > wrote: >> >> On Fri, Sep 22, 2017 at 01:54:27PM +0530, Umair Khan wrote: >> > On Thu, Sep 21, 2017 at 6:30 PM, Paul B Mahol wrote: >> > > On 9/21/17, Umair Khan wrote: >> > >> Hi Ronald, >> > >> >> > >> On Mon, Sep 11, 2017 at 10:27 PM, Ronald S. Bultje >> > >> wrote: >> > >>> Hi Umair, >> > >>> >> > >>> On Mon, Sep 11, 2017 at 4:06 AM, Umair Khan wrote: >> > >>> >> > On Sun, Sep 10, 2017 at 10:30 PM, Paul B Mahol >> > wrote: >> > > On 9/10/17, Umair Khan wrote: >> > >> On Sun, Sep 10, 2017 at 9:52 PM, Thilo Borgmann >> > >> > > > >> > >> wrote: >> > >>> >> > >>> Hi, >> > >>> >> > >>> > This patch fixes this bug - https://trac.ffmpeg.org/ticket/5297 >> > >>> >> > >>> this is yet another iteration of >> > >>> >> > >>> http://ffmpeg.org/pipermail/ffmpeg-devel/2017-June/213005.html >> > >> >> > >> I see. I was keepnig reference codec as the source of truth. >> > >> >> > >> How do I reproduce this segfault? - >> > >> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/202530.html >> > >> Is it one of the fate tests failing? >> > > >> > > No. >> > >> > In that case there's not much which can be done with this bug. >> > That being said, I'm pretty sure we will anyways end up removing this >> > check. >> > >>> >> > >>> >> > >>> I think your question is "how do I get access to this sample", right? >> > >>> You >> > >>> could ask Michael. >> > >> >> > >> Paul also tried to fix this bug, hence I'm assuming that he already >> > >> asked Michael about the sample file. Anyways, it'd not be difficult to >> > >> fix this bug if we can reproduce it. >> > > >> > > Thilo do not want to apply Michael fix because he do not understand his >> > > patch. >> > >> > Which fix are you talking about? >> > >> > I see that Michael added this check in the first place - >> > http://git.videolan.org/?p=ffmpeg.git;a=commit;h=18f94df8af >> > If someone can provide me with the file which is causing the segfault, >> > maybe I can look into it. >> >> file sent privatly to umair > > I tested the file which Michael sent. The thing is that I'm getting > error in decoding that file in both the cases, with or without the > patch. I will begin debugging this issue, however I think the file > which Michael sent has got nothing to do with the patch in this > thread. I tried decoding the file with the reference codec, and it also gives an error with it. I think the issue is with the file itself. ➜ mp4alsRM23 ./bin/mac/mp4alsRM23 -x als_05_2ch48k16b.mp4 ERROR: Unable to convert MP4 to ALS: A2MERR_INIT_MP4READER IMO, we are good to go with the current patch. -Umair ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/als: remove check for predictor order of a block
Hi Umair, On Sat, Oct 14, 2017 at 9:59 AM, Umair Khan wrote: > I tested the file which Michael sent. The thing is that I'm getting > error in decoding that file in both the cases, with or without the > patch. I will begin debugging this issue, however I think the file > which Michael sent has got nothing to do with the patch in this > thread. > I don't think the file is meant to be decoded correctly, it's a specially crafted file to demonstrate that certain codepaths (triggered by files such as this) can be used to trigger unwanted behaviour (overreads, overwrites, etc.). Eventually, combinations of such files can be used to break into your system with specially crafted media files (yes, really). Your patch introduces such a security issue (since it's triggered by the file after, but not before the patch). This must be fixed before the patch can be committed. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Configure: commit 6dfcbd80ad446ff163b47f2bf432bbf706436ea8 broke my builds
On 10/14/2017 7:48 AM, Mark Himsley wrote:
> Update: for me with my specific set of libraries, I have had to apply
> this patch to configure in order to make configure accept my
> configuration parameters: specifically changes to mp3lame, openjpeg
> 1.5, x265 and xvid.
>
> diff --git a/configure b/configure
> index dfbc251..67c012d 100755
> --- a/configure
> +++ b/configure
> @@ -6008,7 +6008,7 @@ enabled libkvazaar&& require_pkg_config
> libkvazaar "kvazaar >= 0.8.1" kv
> enabled libmfx&& { use_pkg_config libmfx libmfx
> "mfx/mfxvideo.h" MFXInit ||
> { require libmfx "mfx/mfxvideo.h"
> MFXInit -llibmfx && warn "using libmfx without pkg-config"; } }
> enabled libmodplug&& require_pkg_config libmodplug libmodplug
> libmodplug/modplug.h ModPlug_Load
> -enabled libmp3lame&& require "libmp3lame >= 3.98.3"
> lame/lame.h lame_set_VBR_quality -lmp3lame
> +enabled libmp3lame&& require "libmp3lame >= 3.98.3"
> lame/lame.h lame_set_VBR_quality -lmp3lame -lm
Will fix this. Thanks.
> enabled libmysofa && require libmysofa "mysofa.h" mysofa_load
> -lmysofa
> enabled libnpp&& { check_lib libnpp npp.h
> nppGetLibVersion -lnppig -lnppicc -lnppc ||
> check_lib libnpp npp.h
> nppGetLibVersion -lnppi -lnppc ||
> @@ -6027,7 +6027,7 @@ enabled libopenjpeg && { { check_lib
> libopenjpeg openjpeg-2.3/openjpeg.h o
> { check_lib libopenjpeg
> openjpeg-2.1/openjpeg.h opj_version -lopenjp2 -DOPJ_STATIC &&
> add_cppflags -DOPJ_STATIC; } ||
> check_lib libopenjpeg
> openjpeg-2.1/openjpeg.h opj_version -lopenjp2 ||
> { check_lib libopenjpeg
> openjpeg-2.0/openjpeg.h opj_version -lopenjp2 -DOPJ_STATIC &&
> add_cppflags -DOPJ_STATIC; } ||
> - { check_lib libopenjpeg
> openjpeg-1.5/openjpeg.h opj_version -lopenjpeg -DOPJ_STATIC &&
> add_cppflags -DOPJ_STATIC; } ||
> + { check_lib libopenjpeg
> openjpeg-1.5/openjpeg.h opj_version -lopenjpeg -lm -DOPJ_STATIC &&
> add_cppflags -DOPJ_STATIC; } ||
> { check_lib libopenjpeg openjpeg.h
> opj_version -lopenjpeg -DOPJ_STATIC && add_cppflags -DOPJ_STATIC; } ||
> die "ERROR: libopenjpeg not found"; }
OpenJPEG will be solved soon by switching to pkg-config (which adds the
math library ldflag).
> enabled libopenmpt&& require_pkg_config libopenmpt
> "libopenmpt >= 0.2.6557" libopenmpt/libopenmpt.h openmpt_module_create
> @@ -6096,10 +6096,10 @@ enabled libx264 && { use_pkg_config
> libx264 x264 "stdint.h x264.h" x26
> require_cpp_condition x264.h "X264_BUILD
>> = 118" &&
> { check_cpp_condition x264.h "X264_MPEG2" &&
> enable libx262; }
> -enabled libx265 && require_pkg_config libx265 x265 x265.h
> x265_api_get &&
> +enabled libx265 && require_pkg_config libx265 x265 x265.h
> x265_api_get -lpthread &&
This one should be fixed by x265. It's them who should add a pthreads
dependency on their pkg-config file for static builds if it's required.
> require_cpp_condition x265.h "X265_BUILD >= 68"
> enabled libxavs && require libxavs "stdint.h xavs.h"
> xavs_encoder_encode -lxavs
> -enabled libxvid && require libxvid xvid.h xvid_global -lxvidcore
> +enabled libxvid && require libxvid xvid.h xvid_global
> -lxvidcore -lpthread -lm
Will fix it.
> enabled libzimg && require_pkg_config libzimg "zimg >=
> 2.3.0" zimg.h zimg_get_api_version
> enabled libzmq&& require_pkg_config libzmq libzmq zmq.h
> zmq_ctx_new
> enabled libzvbi && require libzvbi libzvbi.h
> vbi_decoder_new -lzvbi &&
>
>
>
> On 14 October 2017 at 11:00, Mark Himsley wrote:
>> I build FFmpeg and all the libraries I need every night. Since 08:00
>> BST on 12-Oct-2017 that build has not worked, the previous build on
>> 11-Oct-2017 worked.
>>
>> My configure command for building 64bit Linux that is run on an Ubuntu
>> 16.04 system, which worked on Wednesday but not on Thursday, is:
>>
>> ./configure --extra-version=static_x86_64-pc-linux-gnu
>> --extra-cflags="--static -static" --extra-libs="-static"
>> --pkg-config-flags="--static" --cross-prefix= --arch=x86_64
>> --target-os=linux --prefix="/opt/bbc/ff_lib" --enable-gpl
>> --enable-nonfree --disable-ffplay --disable-dxva2 --enable-libmp3lame
>> --enable-libfdk-aac --enable-libspeex --enable-libtheora
>> --enable-libvorbis --enable-libopus --enable-libopenjpeg
>> --enable-libvpx --enable-libxvid --enable-libx264 --enable-libx265
>>
>> (yes, the configure contains options, like cross-prefix and arch and
>> target that are not necessarily normally needed, but I build for
>> Linux, Windows 32 and 64 bit static binari
Re: [FFmpeg-devel] [PATCH 1/3] libavformat/avio: retry_transfer_wrapper: don't treat 0 as EOF
On Sat, Oct 14, 2017 at 07:10:37AM +0200, Daniel Kučera wrote: > breaks fate-indeo3-2 > > [...] > -- > > > You need to apply the whole set. It passed all fate tests on my machine. I applied the whole set and bisected to find which patch caused the failure also the i-th patch of a set must pass fate with it and the 0th to ith patches applied, otherwise there would be checkouts that fail some tests [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] configure: add libm ldflags globally
It's used by every library, and by making it global we simplify a lot
of checks.
Signed-off-by: James Almer
---
configure | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/configure b/configure
index 22026ef832..a0bfb269e8 100755
--- a/configure
+++ b/configure
@@ -3332,23 +3332,17 @@ cws2fws_extralibs="zlib_extralibs"
# libraries, in linking order
avcodec_deps="avutil"
-avcodec_suggest="libm"
avcodec_select="null_bsf"
avdevice_deps="avformat avcodec avutil"
-avdevice_suggest="libm"
avfilter_deps="avutil"
-avfilter_suggest="libm"
avformat_deps="avcodec avutil"
-avformat_suggest="libm network"
+avformat_suggest="network"
avresample_deps="avutil"
-avresample_suggest="libm"
-avutil_suggest="clock_gettime libm libdrm libmfx opencl user32 vaapi
videotoolbox corefoundation corevideo coremedia wincrypt"
+avutil_suggest="clock_gettime libdrm libmfx opencl user32 vaapi videotoolbox
corefoundation corevideo coremedia wincrypt"
postproc_deps="avutil gpl"
-postproc_suggest="libm"
swresample_deps="avutil"
-swresample_suggest="libm libsoxr"
+swresample_suggest="libsoxr"
swscale_deps="avutil"
-swscale_suggest="libm"
avcodec_extralibs="pthreads_extralibs iconv_extralibs"
avfilter_extralibs="pthreads_extralibs"
@@ -5944,7 +5938,9 @@ enabled lzma && check_lib lzma lzma.h
lzma_version_number -llzma
# On some systems dynamic loading requires no extra linker flags
check_lib libdl dlfcn.h "dlopen dlsym" || check_lib libdl dlfcn.h "dlopen
dlsym" -ldl
-check_lib libm math.h sin -lm
+# Add -lm to global extralibs if required. Every library uses it, and it
simplifies
+# several of the external library checks below.
+check_lib libm math.h sin -lm && add_extralibs $libm_extralibs
atan2f_args=2
copysign_args=2
@@ -6098,7 +6094,7 @@ enabled libx264 && { use_pkg_config libx264
x264 "stdint.h x264.h" x26
enable libx262; }
enabled libx265 && require_pkg_config libx265 x265 x265.h
x265_api_get &&
require_cpp_condition x265.h "X265_BUILD >= 68"
-enabled libxavs && require libxavs "stdint.h xavs.h"
xavs_encoder_encode "-lxavs $pthreads_extralibs $libm_extralibs"
+enabled libxavs && require libxavs "stdint.h xavs.h"
xavs_encoder_encode "-lxavs $pthreads_extralibs"
enabled libxvid && require libxvid xvid.h xvid_global -lxvidcore
enabled libzimg && require_pkg_config libzimg "zimg >= 2.3.0" zimg.h
zimg_get_api_version
enabled libzmq&& require_pkg_config libzmq libzmq zmq.h zmq_ctx_new
--
2.14.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/pafvideo: Check for bitstream end in decode_0()
On Fri, Oct 13, 2017 at 03:06:53AM +0200, Michael Niedermayer wrote: > Fixes: Timeout > Fixes: 3529/clusterfuzz-testcase-5057068371279872 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/pafvideo.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) patchset applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/dvbsubdec: Factor a few expressions out of compute_default_clut()
On Sun, Oct 01, 2017 at 06:25:14PM +0200, Clément Bœsch wrote:
> On Sun, Oct 01, 2017 at 06:10:35PM +0200, Michael Niedermayer wrote:
> > 32% faster loop
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/dvbsubdec.c | 16 +---
> > 1 file changed, 9 insertions(+), 7 deletions(-)
> >
> > diff --git a/libavcodec/dvbsubdec.c b/libavcodec/dvbsubdec.c
> > index b683109643..6a40f2376f 100644
> > --- a/libavcodec/dvbsubdec.c
> > +++ b/libavcodec/dvbsubdec.c
> > @@ -653,8 +653,9 @@ static void compute_default_clut(AVSubtitleRect *rect,
> > int w, int h)
> > uint8_t list_inv[256];
> > int counttab[256] = {0};
> > int count, i, x, y;
> > +ptrdiff_t ls = rect->linesize[0];
>
> You use this variable in 3 places where the length doesn't matter; please
> use a longer name (maybe "lsize", "stride", or even "linesize").
>
> >
> > -#define V(x,y) rect->data[0][(x) + (y)*rect->linesize[0]]
> > +#define V(x,y) rect->data[0][(x) + (y)*ls]
> > for (y = 0; y > for (x = 0; x > int v = V(x,y) + 1;
> > @@ -665,7 +666,7 @@ static void compute_default_clut(AVSubtitleRect *rect,
> > int w, int h)
> > counttab[v-1] += !!((v!=vl) + (v!=vr) + (v!=vt) + (v!=vb));
> > }
> > }
> > -#define L(x,y) list[ rect->data[0][(x) + (y)*rect->linesize[0]] ]
>
> > +#define L(x,y) list[ d[(x) + (y)*ls] ]
>
> since you modify this line, feel free to drop the extra spacing
> after and before the [].
>
> >
> > for (i = 0; i<256; i++) {
> > int scoretab[256] = {0};
> > @@ -673,12 +674,13 @@ static void compute_default_clut(AVSubtitleRect
> > *rect, int w, int h)
> > int bestv = 0;
> > for (y = 0; y > for (x = 0; x > -int v = rect->data[0][x + y*rect->linesize[0]];
> > +uint8_t *d = &rect->data[0][x + y*ls];
> > +int v = *d;
> > int l_m = list[v];
> > -int l_l = x ? L(x-1, y) : 1;
> > -int l_r = x+1 > -int l_t = y ? L(x, y-1) : 1;
> > -int l_b = y+1
> > +int l_l = x ? L(-1, 0) : 1;
> > +int l_r = x+1 > +int l_t = y ? L(0, -1) : 1;
> > +int l_b = y+1
> I'd be more comfortable with:
>
>int l_l = x ? L(-1, 0) : 1;
>int l_r = x+1int l_t = y ? L( 0,-1) : 1;
>int l_b = y+1
> I feel like at some point in the future compilers will complain about
> these "(+3)*x"
>
> Should be fine otherwise
will apply with the suggested changes
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/dvbsubdec: Split best score computation out of loop in compute_default_clut()
On Sun, Oct 01, 2017 at 06:26:53PM +0200, Clément Bœsch wrote:
> On Sun, Oct 01, 2017 at 06:10:36PM +0200, Michael Niedermayer wrote:
> > 3% faster
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/dvbsubdec.c | 9 ++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavcodec/dvbsubdec.c b/libavcodec/dvbsubdec.c
> > index 6a40f2376f..e60bf41936 100644
> > --- a/libavcodec/dvbsubdec.c
> > +++ b/libavcodec/dvbsubdec.c
> > @@ -681,14 +681,17 @@ static void compute_default_clut(AVSubtitleRect
> > *rect, int w, int h)
> > int l_r = x+1 > int l_t = y ? L(0, -1) : 1;
> > int l_b = y+1 > -int score;
> > if (l_m)
> > continue;
> > scoretab[v] += l_l + l_r + l_t + l_b;
> > -score = 1024LL*scoretab[v] / counttab[v];
> > +}
> > +}
> > +for (x = 0; x < 256; x++) {
> > +if (scoretab[x]) {
> > +int score = 1024LL*scoretab[x] / counttab[x];
> > if (score > bestscore) {
> > bestscore = score;
> > -bestv = v;
> > +bestv = x;
> > }
> > }
> > }
>
> OK
applied
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] configure: add pthreads ldflags globally
It's used by libavutil and by extension every other library, and by
making it global we simplify a lot of checks.
Signed-off-by: James Almer
---
configure | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/configure b/configure
index a0bfb269e8..09f8ed305b 100755
--- a/configure
+++ b/configure
@@ -3327,7 +3327,6 @@ transcode_aac_example_deps="avcodec avformat swresample"
transcoding_example_deps="avfilter avcodec avformat avutil"
# EXTRALIBS_LIST
-cpu_init_extralibs="pthreads_extralibs"
cws2fws_extralibs="zlib_extralibs"
# libraries, in linking order
@@ -3344,9 +3343,8 @@ swresample_deps="avutil"
swresample_suggest="libsoxr"
swscale_deps="avutil"
-avcodec_extralibs="pthreads_extralibs iconv_extralibs"
-avfilter_extralibs="pthreads_extralibs"
-avutil_extralibs="nanosleep_extralibs pthreads_extralibs vaapi_drm_extralibs
vaapi_x11_extralibs vdpau_x11_extralibs"
+avcodec_extralibs="iconv_extralibs"
+avutil_extralibs="nanosleep_extralibs vaapi_drm_extralibs vaapi_x11_extralibs
vdpau_x11_extralibs"
# programs
ffmpeg_deps="avcodec avfilter avformat swresample"
@@ -5925,6 +5923,7 @@ fi
if enabled pthreads; then
+ add_extralibs $pthreads_extralibs
check_func pthread_cancel $pthreads_extralibs
fi
@@ -5993,7 +5992,7 @@ enabled libgme&& { use_pkg_config libgme
libgme gme/gme.h gme_new_em
enabled libgsm&& { for gsm_hdr in "gsm.h" "gsm/gsm.h"; do
check_lib libgsm "${gsm_hdr}" gsm_create
-lgsm && break;
done || die "ERROR: libgsm not found"; }
-enabled libilbc && require libilbc ilbc.h WebRtcIlbcfix_InitDecode
-lilbc $pthreads_extralibs
+enabled libilbc && require libilbc ilbc.h WebRtcIlbcfix_InitDecode
-lilbc
enabled libkvazaar&& require_pkg_config libkvazaar "kvazaar >= 0.8.1"
kvazaar.h kvz_api_get
# While it may appear that require is being used as a pkg-config
# fallback for libmfx, it is actually being used to detect a different
@@ -6094,7 +6093,7 @@ enabled libx264 && { use_pkg_config libx264
x264 "stdint.h x264.h" x26
enable libx262; }
enabled libx265 && require_pkg_config libx265 x265 x265.h
x265_api_get &&
require_cpp_condition x265.h "X265_BUILD >= 68"
-enabled libxavs && require libxavs "stdint.h xavs.h"
xavs_encoder_encode "-lxavs $pthreads_extralibs"
+enabled libxavs && require libxavs "stdint.h xavs.h"
xavs_encoder_encode -lxavs
enabled libxvid && require libxvid xvid.h xvid_global -lxvidcore
enabled libzimg && require_pkg_config libzimg "zimg >= 2.3.0" zimg.h
zimg_get_api_version
enabled libzmq&& require_pkg_config libzmq libzmq zmq.h zmq_ctx_new
--
2.14.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] build: add global extralibs to pkg-config file generation
Dependencies like libm and pthreads are now global again, so handle
that while generating our pkg-config files.
Signed-off-by: James Almer
---
The pkg-config file generation nonetheless needs some more thought.
Much like how we're dealing with external libs not properly listing
all their dependencies for static builds, it's likely we're also
doing something wrong in that regard.
configure | 1 +
ffbuild/pkgconfig_generate.sh | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index 09f8ed305b..56e9b906f8 100755
--- a/configure
+++ b/configure
@@ -7158,6 +7158,7 @@ rpath=$(enabled rpath && echo "-Wl,-rpath,\${libdir}")
source_path=${source_path}
LIBPREF=${LIBPREF}
LIBSUF=${LIBSUF}
+extralibs="$extralibs"
extralibs_avutil="$avutil_extralibs"
extralibs_avcodec="$avcodec_extralibs"
extralibs_avformat="$avformat_extralibs"
diff --git a/ffbuild/pkgconfig_generate.sh b/ffbuild/pkgconfig_generate.sh
index e5de6716d2..ed1cbb3635 100755
--- a/ffbuild/pkgconfig_generate.sh
+++ b/ffbuild/pkgconfig_generate.sh
@@ -12,7 +12,7 @@ shortname=$1
name=lib${shortname}
fullname=${name}${build_suffix}
comment=$2
-libs=$(eval echo \$extralibs_${shortname})
+libs=$(eval echo \$extralibs_${shortname} \$extralibs)
deps=$(eval echo \$${shortname}_deps)
for dep in $deps; do
--
2.14.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] libavformat/avio: retry_transfer_wrapper: don't treat 0 as EOF
2017-10-14 17:46 GMT+02:00 Michael Niedermayer : > On Sat, Oct 14, 2017 at 07:10:37AM +0200, Daniel Kučera wrote: >> breaks fate-indeo3-2 >> >> [...] >> -- >> >> >> You need to apply the whole set. It passed all fate tests on my machine. > > I applied the whole set and bisected to find which patch caused the > failure > > also the i-th patch of a set must pass fate with it and the 0th to ith > patches applied, otherwise there would be checkouts that fail some tests > So should I reorder them and post again? -- S pozdravom / Best regards Daniel Kucera. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] libavformat/avio: retry_transfer_wrapper: don't treat 0 as EOF
2017-10-14 19:16 GMT+02:00 Daniel Kučera : > 2017-10-14 17:46 GMT+02:00 Michael Niedermayer : >> On Sat, Oct 14, 2017 at 07:10:37AM +0200, Daniel Kučera wrote: >>> breaks fate-indeo3-2 >>> >>> [...] >>> -- >>> >>> >>> You need to apply the whole set. It passed all fate tests on my machine. >> >> I applied the whole set and bisected to find which patch caused the >> failure >> >> also the i-th patch of a set must pass fate with it and the 0th to ith >> patches applied, otherwise there would be checkouts that fail some tests >> > > So should I reorder them and post again? > > What if they don't pass fate in any order? should I post them as one patch? -- S pozdravom / Best regards Daniel Kucera. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavformat/cache: don't treat 0 as EOF libavformat/aviobuf: don't treat 0 as EOF libavformat/avio: retry_transfer_wrapper: don't treat 0 as EOF
transfer_func variable passed to retry_transfer_wrapper
are h->prot->url_read and h->prot->url_write functions.
These need to return EOF or other error properly.
In case of returning >= 0, url_read/url_write is retried
until error is returned.
Signed-off-by: Daniel Kucera
---
libavformat/avio.c| 6 --
libavformat/aviobuf.c | 20
libavformat/cache.c | 4 ++--
3 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/libavformat/avio.c b/libavformat/avio.c
index 64248e098b..d3004c007f 100644
--- a/libavformat/avio.c
+++ b/libavformat/avio.c
@@ -391,8 +391,10 @@ static inline int retry_transfer_wrapper(URLContext *h,
uint8_t *buf,
}
av_usleep(1000);
}
-} else if (ret < 1)
-return (ret < 0 && ret != AVERROR_EOF) ? ret : len;
+} else if (ret == AVERROR_EOF)
+ return (len > 0) ? len : AVERROR_EOF;
+else if (ret < 0)
+return ret;
if (ret) {
fast_retries = FFMAX(fast_retries, 2);
wait_since = 0;
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 636cb46161..0d4eb051e1 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -572,13 +572,14 @@ static void fill_buffer(AVIOContext *s)
if (s->read_packet)
len = s->read_packet(s->opaque, dst, len);
else
-len = 0;
-if (len <= 0) {
+len = AVERROR_EOF;
+if (len == AVERROR_EOF) {
/* do not modify buffer if EOF reached so that a seek back can
be done without rereading data */
s->eof_reached = 1;
-if (len < 0)
-s->error = len;
+} else if (len < 0) {
+s->eof_reached = 1;
+s->error= len;
} else {
s->pos += len;
s->buf_ptr = dst;
@@ -646,13 +647,16 @@ int avio_read(AVIOContext *s, unsigned char *buf, int
size)
// bypass the buffer and read data directly into buf
if(s->read_packet)
len = s->read_packet(s->opaque, buf, size);
-
-if (len <= 0) {
+else
+len = AVERROR_EOF;
+if (len == AVERROR_EOF) {
/* do not modify buffer if EOF reached so that a seek back
can
be done without rereading data */
s->eof_reached = 1;
-if(len<0)
-s->error= len;
+break;
+} else if (len < 0) {
+s->eof_reached = 1;
+s->error= len;
break;
} else {
s->pos += len;
diff --git a/libavformat/cache.c b/libavformat/cache.c
index 6aabca2e78..66bbbf54c9 100644
--- a/libavformat/cache.c
+++ b/libavformat/cache.c
@@ -201,7 +201,7 @@ static int cache_read(URLContext *h, unsigned char *buf,
int size)
}
r = ffurl_read(c->inner, buf, size);
-if (r == 0 && size>0) {
+if (r == AVERROR_EOF && size>0) {
c->is_true_eof = 1;
av_assert0(c->end >= c->logical_pos);
}
@@ -263,7 +263,7 @@ resolve_eof:
if (whence == SEEK_SET)
size = FFMIN(sizeof(tmp), pos - c->logical_pos);
ret = cache_read(h, tmp, size);
-if (ret == 0 && whence == SEEK_END) {
+if (ret == AVERROR_EOF && whence == SEEK_END) {
av_assert0(c->is_true_eof);
goto resolve_eof;
}
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] libavformat/avio: retry_transfer_wrapper: don't treat 0 as EOF
On 10/14/2017 2:22 PM, Daniel Kučera wrote: > 2017-10-14 19:16 GMT+02:00 Daniel Kučera : >> 2017-10-14 17:46 GMT+02:00 Michael Niedermayer : >>> On Sat, Oct 14, 2017 at 07:10:37AM +0200, Daniel Kučera wrote: breaks fate-indeo3-2 [...] -- You need to apply the whole set. It passed all fate tests on my machine. >>> >>> I applied the whole set and bisected to find which patch caused the >>> failure >>> >>> also the i-th patch of a set must pass fate with it and the 0th to ith >>> patches applied, otherwise there would be checkouts that fail some tests >>> >> >> So should I reorder them and post again? >> >> > > What if they don't pass fate in any order? should I post them as one patch? If one patch introduces a problem that gets fixed by a subsequent patch then yes, both should be squashed into one to make sure the problem is never introduced. The idea is that no patch/commit on its own should generate a fate failure of any kind, as it would make bisecting unrelated future issues harder. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] libavformat/avio: retry_transfer_wrapper: don't treat 0 as EOF
> > If one patch introduces a problem that gets fixed by a subsequent patch > then yes, both should be squashed into one to make sure the problem is > never introduced. > > The idea is that no patch/commit on its own should generate a fate > failure of any kind, as it would make bisecting unrelated future issues > harder. Thank you for explaining. I've sent squashed patch. -- S pozdravom / Best regards Daniel Kucera. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/als: remove check for predictor order of a block
On Sat, Oct 14, 2017 at 8:02 PM, Ronald S. Bultje wrote: > Hi Umair, > > On Sat, Oct 14, 2017 at 9:59 AM, Umair Khan wrote: > >> I tested the file which Michael sent. The thing is that I'm getting >> error in decoding that file in both the cases, with or without the >> patch. I will begin debugging this issue, however I think the file >> which Michael sent has got nothing to do with the patch in this >> thread. >> > > I don't think the file is meant to be decoded correctly, it's a specially > crafted file to demonstrate that certain codepaths (triggered by files such > as this) can be used to trigger unwanted behaviour (overreads, overwrites, > etc.). Eventually, combinations of such files can be used to break into > your system with specially crafted media files (yes, really). > > Your patch introduces such a security issue (since it's triggered by the > file after, but not before the patch). This must be fixed before the patch > can be committed. Okay. You mean the file isn't supposed to be decoded and that the als decoder should output the proper error message instead of breaking at a random point. Am I getting it correct? -Umair ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/als: remove check for predictor order of a block
Hi Umair, On Sat, Oct 14, 2017 at 1:43 PM, Umair Khan wrote: > On Sat, Oct 14, 2017 at 8:02 PM, Ronald S. Bultje > wrote: > > Hi Umair, > > > > On Sat, Oct 14, 2017 at 9:59 AM, Umair Khan wrote: > > > >> I tested the file which Michael sent. The thing is that I'm getting > >> error in decoding that file in both the cases, with or without the > >> patch. I will begin debugging this issue, however I think the file > >> which Michael sent has got nothing to do with the patch in this > >> thread. > >> > > > > I don't think the file is meant to be decoded correctly, it's a specially > > crafted file to demonstrate that certain codepaths (triggered by files > such > > as this) can be used to trigger unwanted behaviour (overreads, > overwrites, > > etc.). Eventually, combinations of such files can be used to break into > > your system with specially crafted media files (yes, really). > > > > Your patch introduces such a security issue (since it's triggered by the > > file after, but not before the patch). This must be fixed before the > patch > > can be committed. > > Okay. You mean the file isn't supposed to be decoded and that the als > decoder should output the proper error message instead of breaking at > a random point. Am I getting it correct? > More specifically: after your patch, you'll notice that address sanitizer (clang -fsanitize=address) or valgrind output warnings when decoding this file. These warnings should be tracked down and fixed. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] web/download: add Zeranoe macOS builds
--- src/download | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/download b/src/download index d2db75a..2dbc338 100644 --- a/src/download +++ b/src/download @@ -100,6 +100,9 @@ http://ffmpegmac.net/";> Builds 32-bit and 64-bit for OS X 10.5 and above + https://ffmpeg.zeranoe.com/builds/";> +Static and shared builds for macOS 64-bit + -- 2.14.2.windows.3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/7] decode: add a method for attaching lavc-internal data to frames
On Fri, Oct 13, 2017 at 09:19:04PM +0200, wm4 wrote:
> On Fri, 13 Oct 2017 19:41:28 +0200
> Michael Niedermayer wrote:
>
> > On Fri, Oct 06, 2017 at 01:48:14AM +0200, wm4 wrote:
> > > On Fri, 6 Oct 2017 00:01:30 +0200
> > > Michael Niedermayer wrote:
> > >
> > > > The opaque_ref wraping is a really bad design. Iam not sure why
> > > > people defend it.
> > >
> > > FFmpeg is full of this design. There are plenty of structs with
> > > opaque/priv fields that change meaning depending on the context
> > > (basically how the struct is used or what uses it). It affects all
> > > decoders, encoders, filters, demuxers, muxers, the av_log() call,
> > > functions that work with AVClass, AVOption, and probably more.
> >
> > what you write is not true
> >
> > each decoder, demuxer, ... CLASS has its own type of private context
> > nothing outside code specific to that class messes with it.
> > A snow decoder has a snow context.
> > If the outside structure is moved around its still a snow decoder with
> > a snow private context. No amount of moving the structure around makes
> > it invalid.
> >
> > OTOH, opaque_ref is defined by the user application.
> > There is a single user application in the address space.
>
> You misunderstand how AVFrame works. AVFrame has an owner, and this
> owner decides how certain fields are handled. This includes for example
> the pts fields, whose meaning entirely depend on an undefined timebase.
> opaque_ref is merely a more advanced case of this.
The API docs say about opaque_ref
"FFmpeg will never check the contents of the buffer ref."
the unwraping code does exactly that and any code using it internally
does as well.
Let me quote the code from one of these patches:
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 437b848248..04f7156154 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
[...]
+if (frame->opaque_ref) {
+FrameDecodeData *fdd;
+AVBufferRef *user_opaque_ref;
+
+fdd = (FrameDecodeData*)frame->opaque_ref->data;
This violates the API and it is semantically wrong.
about pts, that is off topic, but no amount of moving an AVFrame
around makes a valid AVFrame pts into an invalid AVFrame pts.
AVFrame pts refers to a unspecified timebase either way.
If the code knows that timebase and knows the origin it can interpret
the timestamp.
It may make sense to add more information about the pts into AVFrame
so its more self contained, but this is off topic
>
> > Before the patch
> > all AVFrame opaque_ref have the same type, no amount of moving/passing
> > AVFrames around results in an invalid AVFrame.
>
> Wrong. Even a user application could have multiple uses of opaque_ref,
> all with their own meaning. You can't interpret this field without
> context about where its value came from.
No matter if the user app uses 1, 2 or n types in opaque_ref.
Its still at all points the user apps type and thus the same type for
this discussions point of view.
interpreting the user apps opaque_ref is entirely in the user
applications domain. We can never interpret it. The user application
should know how to interpret its own data.
[...]
> > more so if that field is not void* it could provide type checking
> > which most people consider a good thing.
> >
> > A system simiar to side data for opaque data could be used too, i
> > would say thats overkill but some people like side data
>
> Side data has literally nothing to do with this. Side data types can't
> be defined by the user anyway.
> Why do codec/filter/demuxer private
> fields have no type checking? Or av_log? Or the whole AVOption API?
> Please answer this.
This thread is the wrong place to discuss this, this is off topic
Of course it would be good if we can check types in more cases ...
[...]
> > And this way you need no wraping or unwraping, a AVFrame either
>
> YOU FUCKING NEED UNWRAPPING FOR POSTPROCESSING
>
> Both intended uses, cuvid and videotoolbox, require this. Unwrapping
> can't be skipped. Skipping unwrapping is a bug.
IIUC these need a postprocessing function to be called.
There is no relation between calling a postprocessing function and
wraping and unwraping the users opaque_ref. You can do either without
the other.
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The educated differ from the uneducated as much as the living from the
dead. -- Aristotle
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] Merge commit '7cb1d9e2dbbe5bf4652be5d78cdd68e956fa3d63'
On 14-10-2017 1:32, James Almer wrote: > On 10/13/2017 6:30 PM, Reino Wijnsma wrote: >> _Libilbc_ >> On 13-10-2017 20:09, James Almer wrote: >>> With this, the check will include the needed pthreads ldflags when >>> pkg-config is invoked with the --static flag. >> My 'libilbc.pc' doesn't include -lpthread at all. Adding it here >> manually works for me. > It doesn't? That's weird, seeing "Libs.private: @PTHREAD_LIBS@" is > listed in the source package. I've seen it too in 'libilbc.pc.in', but still the final 'libilbc.pc' doesn't have it. On 14-10-2017 1:32, James Almer wrote: > On 10/13/2017 6:30 PM, Reino Wijnsma wrote: >> And this works. No more errors during ./configure, but then... >> [...] >> CC fftools/ffmpeg_cuvid.o >> LD ffmpeg_g.exe >> /cygdrive/[...]/lib/libgnutls.a(sha256-ssse3-x86.o): warning: common of >> `_gnutls_x86_cpuid_s' overridden by definition >> /cygdrive/[...]/lib/libgnutls.a(x86-common.o): warning: defined here >> /cygdrive/[...]/lib/libmpg123.a(compat.o):compat.c:(.text+0xcb): >> undefined reference to `_imp__PathIsRelativeW@4' >> /cygdrive/[...]/lib/libmpg123.a(compat.o):compat.c:(.text+0x224): >> undefined reference to `_imp__PathIsUNCW@4' >> /cygdrive/[...]/lib/libmpg123.a(compat.o):compat.c:(.text+0x4e9): >> undefined reference to `_imp__PathIsRelativeW@4' >> /cygdrive/[...]/lib/libmpg123.a(compat.o):compat.c:(.text+0x670): >> undefined reference to `_imp__PathIsUNCW@4' >> /cygdrive/[...]/lib/libmpg123.a(compat.o):compat.c:(.text+0xd4b): >> undefined reference to `_imp__PathCombineW@12' >> /cygdrive/[...]/lib/libmpg123.a(compat.o):compat.c:(.text+0xf1b): >> undefined reference to `_imp__PathIsRelativeW@4' >> /cygdrive/[...]/lib/libmpg123.a(compat.o):compat.c:(.text+0x10c4): >> undefined reference to `_imp__PathIsUNCW@4' > These are from -lshlwapi. >> /cygdrive/[...]/lib/libgnutls.a(keys-win.o):keys-win.c:(.text+0xe66): >> undefined reference to `_imp__CertGetCertificateContextProperty@16' >> /cygdrive/[...]/lib/libgnutls.a(keys-win.o):keys-win.c:(.text+0x1652): >> undefined reference to `_imp__CertOpenSystemStoreA@8' >> /cygdrive/[...]/lib/libgnutls.a(keys-win.o):keys-win.c:(.text+0x168e): >> undefined reference to `_imp__CertFindCertificateInStore@24' >> /cygdrive/[...]/lib/libgnutls.a(keys-win.o):keys-win.c:(.text+0x16b1): >> undefined reference to `_imp__CertGetCertificateContextProperty@16' >> /cygdrive/[...]/lib/libgnutls.a(keys-win.o):keys-win.c:(.text+0x192d): >> undefined reference to `_imp__CertFreeCertificateContext@4' >> /cygdrive/[...]/lib/libgnutls.a(keys-win.o):keys-win.c:(.text+0x193f): >> undefined reference to `_imp__CertCloseStore@8' >> /cygdrive/[...]/lib/libgnutls.a(keys-win.o):keys-win.c:(.text+0x2167): >> undefined reference to `_imp__CertOpenSystemStoreA@8' >> /cygdrive/[...]/lib/libgnutls.a(keys-win.o):keys-win.c:(.text+0x21a3): >> undefined reference to `_imp__CertFindCertificateInStore@24' >> /cygdrive/[...]/lib/libgnutls.a(keys-win.o):keys-win.c:(.text+0x21f0): >> undefined reference to `_imp__CertFreeCertificateContext@4' >> /cygdrive/[...]/lib/libgnutls.a(keys-win.o):keys-win.c:(.text+0x221d): >> undefined reference to `_imp__CertCloseStore@8' >> /cygdrive/[...]/lib/libgnutls.a(keys-win.o):keys-win.c:(.text+0x23ad): >> undefined reference to `_imp__CertCloseStore@8' >> /cygdrive/[...]/lib/libgnutls.a(keys-win.o):keys-win.c:(.text+0x249f): >> undefined reference to `_imp__CertOpenSystemStoreA@8' >> /cygdrive/[...]/lib/libgnutls.a(keys-win.o):keys-win.c:(.text+0x255b): >> undefined reference to `_imp__CertEnumCertificatesInStore@8' >> /cygdrive/[...]/lib/libgnutls.a(keys-win.o):keys-win.c:(.text+0x26db): >> undefined reference to `_imp__CertOpenSystemStoreA@8' >> /cygdrive/[...]/lib/libgnutls.a(keys-win.o):keys-win.c:(.text+0x2735): >> undefined reference to `_imp__CertFindCertificateInStore@24' >> /cygdrive/[...]/lib/libgnutls.a(keys-win.o):keys-win.c:(.text+0x277b): >> undefined reference to `_imp__CertGetCertificateContextProperty@16' >> /cygdrive/[...]/lib/libgnutls.a(keys-win.o):keys-win.c:(.text+0x27cd): >> undefined reference to `_imp__CertCloseStore@8' >> /cygdrive/[...]/lib/libgnutls.a(keys-win.o):keys-win.c:(.text+0x286f): >> undefined reference to `_imp__CertDeleteCertificateFromStore@4' >> /cygdrive/[...]/lib/libgnutls.a(keys-win.o):keys-win.c:(.text+0x2ab5): >> undefined reference to `_imp__CertCloseStore@8' >> /cygdrive/[...]/lib/libgnutls.a(keys-win.o):keys-win.c:(.text+0x2d70): >> undefined reference to `_imp__PFXImportCertStore@12' >> /cygdrive/[...]/lib/libgnutls.a(keys-win.o):keys-win.c:(.text+0x2e7f): >> undefined reference to `_imp__CertFindCertificateInStore@24' >> /cygdrive/[...]/lib/libgnutls.a(certs.o):certs.c:(.text+0xe0): undefined >> reference to `_imp__CertOpenSystemStoreA@8' >> /cygdrive/[...]/lib/libgnutls.a(certs.o):certs.c:(.text+0xf5): undefined >> reference to `_imp__CertEnumCertificatesInStore@8' >> /cygdrive/[...]/lib/libgnutls.a(certs.o):certs.c:(.text+0x1fb): >> undefined reference to `_imp__CertClo
Re: [FFmpeg-devel] Configure: commit 6dfcbd80ad446ff163b47f2bf432bbf706436ea8 broke my builds
Hello. Per ticket https://trac.ffmpeg.org/ticket/6731 I too am having trouble cross-compiling ffmpeg. This is the configure being used ./configure --arch=x86 --target-os=mingw32 --cross-prefix=/home/u/Desktop/ffmpeg-windows-build-helpers-withOpenCL-master/sandbox/cross_compilers/mingw-w64-i686/bin/i686-w64-mingw32- --pkg-config=pkg-config --pkg-config-flags=--static --enable-gray --enable-version3 --disable-debug --disable-doc --disable-htmlpages --disable-manpages --disable-podpages --disable-txtpages --disable-w32threads --enable-nvenc --enable-cuda --enable-cuvid --enable-d3d11va --enable-libsoxr --enable-fontconfig --enable-libass --enable-libbluray --enable-iconv --enable-libtwolame --enable-libzvbi --enable-libcaca --enable-libmodplug --extra-libs=-lstdc++ --extra-libs=-lpng --extra-libs=-loleaut32 --enable-libmp3lame --enable-version3 --enable-zlib --enable-librtmp --enable-libvorbis --enable-libtheora --enable-libspeex --enable-libopenjpeg --enable-gnutls --enable-libgsm --enable-libfreetype --enable-libopus --enable-bzlib --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libvo-amrwbenc --enable-libvpx --enable-libilbc --enable-libwavpack --enable-libwebp --enable-libgme --enable-dxva2 --enable-gray --enable-libopenh264 --enable-libmysofa --enable-libflite --enable-lzma --enable-libsnappy --enable-libzimg --enable-libbs2b --enable-gmp --enable-libfribidi --enable-cross-compile --enable-pic --extra-libs=-lpsapi --extra-libs=-lspeexdsp --disable-schannel --extra-cflags=-DLIBTWOLAME_STATIC --extra-cflags=-DMODPLUG_STATIC --extra-cflags=-DCACA_STATIC --enable-gpl --enable-avisynth --enable-frei0r --enable-filter=frei0r --enable-librubberband --enable-libvidstab --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-libmfx --enable-avresample --enable-libcdio --extra-cflags=-mtune=generic --extra-cflags=-O3 --enable-static --disable-shared --prefix=/home/u/Desktop/ffmpeg-windows-build-helpers-withOpenCL-master/sandbox/cross_compilers/mingw-w64-i686/i686-w64-mingw32 --enable-nonfree --enable-decklink --enable-libfdk-aac --enable-opencl --enable-runtime-cpudetect --disable-libx264 --extra-libs=-lpthread --extra-libs=-lcrypt32 --extra-libs=-lstdc++ --extra-libs=-lass --extra-libs=-lfontconfig --extra-libs=-lexpat --extra-libs=-lfribidi --extra-libs=-lfreetype --extra-libs=-lharfbuzz --extra-libs=-lbz2 --extra-libs=-llzma --extra-libs=-liconv --extra-libs=-lcdio --extra-libs=-lcdio_paranoia --extra-libs=-lz --extra-libs=-lm --extra-libs=-lpsapi --extra-libs=-lspeexdsp And this is a part of my script in which I am adding libraries one by one once I see what error message appears in each subsequent attempt to build (I started with a set I saw in another post somewhere). # 2017.10.14 - START add this for various errors per https://patchwork.ffmpeg.org/patch/5540/ - removed from being extralibs being global any more ? config_options+=" --extra-libs=-lpthread" config_options+=" --extra-libs=-lcrypt32" config_options+=" --extra-libs=-lstdc++" config_options+=" --extra-libs=-lass" config_options+=" --extra-libs=-lfontconfig" config_options+=" --extra-libs=-lexpat" config_options+=" --extra-libs=-lfribidi" config_options+=" --extra-libs=-lfreetype" config_options+=" --extra-libs=-lharfbuzz" config_options+=" --extra-libs=-lpsapi" # dlfcn [frei0r?] requires this, has no .pc file should put in frei0r.pc? ... config_options+=" --extra-libs=-lspeexdsp" # libebur :| config_options+=" --extra-libs=-lbz2" config_options+=" --extra-libs=-llzma" config_options+=" --extra-libs=-liconv" config_options+=" --extra-libs=-lcdio" config_options+=" --extra-libs=-lcdio_paranoia" config_options+=" --extra-libs=-lz" config_options+=" --extra-libs=-lm" config_options+=" --extra-libs=-lgdi32" However I'm not quite sure what to do when I see the following errors in config.log, so advice would be appreciated. /home/u/Desktop/ffmpeg-windows-build-helpers-withOpenCL-master/sandbox/cross_compilers/mingw-w64-i686/bin/i686-w64-mingw32-gcc -Wl,--large-address-aware -Wl,--nxcompat,--dynamicbase -Wl,--as-needed -Wl,--pic-executable,-e,_mainCRTStartup -o /tmp/ffconf.a5swywFH/test.exe /tmp/ffconf.a5swywFH/test.o -lcdio_paranoia -lcdio_cdda -lcdio -lspeexdsp -lpsapi -lm -lz -lcdio_paranoia -lcdio -liconv -llzma -lbz2 -lharfbuzz -lfreetype -lfribidi -lexpat -lfontconfig -lass -lstdc++ -lcrypt32 -lpthread -lspeexdsp -lpsapi -loleaut32 -lpng -lstdc++ /home/u/Desktop/ffmpeg-windows-build-helpers-withOpenCL-master/sandbox/cross_compilers/mingw-w64-i686/lib/gcc/i686-w64-mingw32/7.2.0/../../../../i686-w64-mingw32/lib/../lib/libcdio.a(win32.o):win32.c:(.text+0x80): undefined reference to `_imp__mciSendCommandA@16' /home/u/Desktop/ffmpeg-windows-build-helpers-withOpenCL-master/sandbox/cross_compilers/mingw-w64-i686/lib/gcc/i686-w64-mingw32/7.2.0/../../../../i686-w64-mingw32/lib/../lib/libcdio.a(
Re: [FFmpeg-devel] Configure: commit 6dfcbd80ad446ff163b47f2bf432bbf706436ea8 broke my builds
On 10/14/2017 8:46 PM, hydra3...@gmail.com wrote: > Hello. Per ticket https://trac.ffmpeg.org/ticket/6731 I too am having > trouble cross-compiling ffmpeg. > > This is the configure being used > ./configure --arch=x86 --target-os=mingw32 > --cross-prefix=/home/u/Desktop/ffmpeg-windows-build-helpers-withOpenCL-master/sandbox/cross_compilers/mingw-w64-i686/bin/i686-w64-mingw32- > --pkg-config=pkg-config --pkg-config-flags=--static --enable-gray > --enable-version3 --disable-debug --disable-doc --disable-htmlpages > --disable-manpages --disable-podpages --disable-txtpages > --disable-w32threads --enable-nvenc --enable-cuda --enable-cuvid > --enable-d3d11va --enable-libsoxr --enable-fontconfig --enable-libass > --enable-libbluray --enable-iconv --enable-libtwolame --enable-libzvbi > --enable-libcaca --enable-libmodplug --extra-libs=-lstdc++ > --extra-libs=-lpng --extra-libs=-loleaut32 --enable-libmp3lame > --enable-version3 --enable-zlib --enable-librtmp --enable-libvorbis > --enable-libtheora --enable-libspeex --enable-libopenjpeg > --enable-gnutls --enable-libgsm --enable-libfreetype --enable-libopus > --enable-bzlib --enable-libopencore-amrnb --enable-libopencore-amrwb > --enable-libvo-amrwbenc --enable-libvpx --enable-libilbc > --enable-libwavpack --enable-libwebp --enable-libgme --enable-dxva2 > --enable-gray --enable-libopenh264 --enable-libmysofa --enable-libflite > --enable-lzma --enable-libsnappy --enable-libzimg --enable-libbs2b > --enable-gmp --enable-libfribidi --enable-cross-compile --enable-pic > --extra-libs=-lpsapi --extra-libs=-lspeexdsp --disable-schannel > --extra-cflags=-DLIBTWOLAME_STATIC --extra-cflags=-DMODPLUG_STATIC > --extra-cflags=-DCACA_STATIC --enable-gpl --enable-avisynth > --enable-frei0r --enable-filter=frei0r --enable-librubberband > --enable-libvidstab --enable-libx264 --enable-libx265 --enable-libxavs > --enable-libxvid --enable-libmfx --enable-avresample --enable-libcdio > --extra-cflags=-mtune=generic --extra-cflags=-O3 --enable-static > --disable-shared > --prefix=/home/u/Desktop/ffmpeg-windows-build-helpers-withOpenCL-master/sandbox/cross_compilers/mingw-w64-i686/i686-w64-mingw32 > --enable-nonfree --enable-decklink --enable-libfdk-aac --enable-opencl > --enable-runtime-cpudetect --disable-libx264 --extra-libs=-lpthread > --extra-libs=-lcrypt32 --extra-libs=-lstdc++ --extra-libs=-lass > --extra-libs=-lfontconfig --extra-libs=-lexpat --extra-libs=-lfribidi > --extra-libs=-lfreetype --extra-libs=-lharfbuzz --extra-libs=-lbz2 > --extra-libs=-llzma --extra-libs=-liconv --extra-libs=-lcdio > --extra-libs=-lcdio_paranoia --extra-libs=-lz --extra-libs=-lm > --extra-libs=-lpsapi --extra-libs=-lspeexdsp > > And this is a part of my script in which I am adding libraries one by > one once I see what error message appears in each subsequent attempt to > build (I started with a set I saw in another post somewhere). > # 2017.10.14 - START add this for various errors per > https://patchwork.ffmpeg.org/patch/5540/ - removed from being extralibs > being global any more ? > config_options+=" --extra-libs=-lpthread" > config_options+=" --extra-libs=-lcrypt32" > config_options+=" --extra-libs=-lstdc++" > config_options+=" --extra-libs=-lass" > config_options+=" --extra-libs=-lfontconfig" > config_options+=" --extra-libs=-lexpat" > config_options+=" --extra-libs=-lfribidi" > config_options+=" --extra-libs=-lfreetype" > config_options+=" --extra-libs=-lharfbuzz" > config_options+=" --extra-libs=-lpsapi" # dlfcn [frei0r?] requires > this, has no .pc file should put in frei0r.pc? ... > config_options+=" --extra-libs=-lspeexdsp" # libebur :| > config_options+=" --extra-libs=-lbz2" > config_options+=" --extra-libs=-llzma" > config_options+=" --extra-libs=-liconv" > config_options+=" --extra-libs=-lcdio" > config_options+=" --extra-libs=-lcdio_paranoia" > config_options+=" --extra-libs=-lz" > config_options+=" --extra-libs=-lm" > config_options+=" --extra-libs=-lgdi32" > > However I'm not quite sure what to do when I see the following errors in > config.log, so advice would be appreciated. > > /home/u/Desktop/ffmpeg-windows-build-helpers-withOpenCL-master/sandbox/cross_compilers/mingw-w64-i686/bin/i686-w64-mingw32-gcc > -Wl,--large-address-aware -Wl,--nxcompat,--dynamicbase -Wl,--as-needed > -Wl,--pic-executable,-e,_mainCRTStartup -o /tmp/ffconf.a5swywFH/test.exe > /tmp/ffconf.a5swywFH/test.o -lcdio_paranoia -lcdio_cdda -lcdio > -lspeexdsp -lpsapi -lm -lz -lcdio_paranoia -lcdio -liconv -llzma -lbz2 > -lharfbuzz -lfreetype -lfribidi -lexpat -lfontconfig -lass -lstdc++ > -lcrypt32 -lpthread -lspeexdsp -lpsapi -loleaut32 -lpng -lstdc++ > /home/u/Desktop/ffmpeg-windows-build-helpers-withOpenCL-master/sandbox/cross_compilers/mingw-w64-i686/lib/gcc/i686-w64-mingw32/7.2.0/../../../../i686-w64-mingw32/lib/../lib/libcdio.a(win32.o):win32.c:(.text+0x80): > undefined reference to `_imp__mciSendCommandA@16' > /home/u/Desktop
[FFmpeg-devel] Build Errors
1. I need to comment out the following lines in configure while building in
mingw using msvc 2013. Else configure gets stuck, anything I need to take
care. Started happening recently.
#for linkunit in $LIBRARY_LIST $PROGRAM_LIST $EXTRALIBS_LIST; do
#flatten_extralibs ${linkunit}_extralibs
#unique ${linkunit}_extralibs
#resolve ${linkunit}_extralibs
#eval ${linkunit}_extralibs=\$\(\$ldflags_filter \$${linkunit}_extralibs\)
#done
2. Also getting linking errors now.
./compat/windows/mslink: line 5: /c/Program Files (x86)/Microsoft Visual Studio
12.0/VC/BIN/amd64/link: Argument list too long
./compat/windows/mslink: line 5: /c/Program Files (x86)/Microsoft Visual Studio
12.0/VC/BIN/amd64/link: Argument list too long
Thanks,
Yogender
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
---
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Build Errors
On Sun, Oct 15, 2017 at 8:17 AM, Yogender Gupta wrote:
> 1. I need to comment out the following lines in configure while building in
> mingw using msvc 2013. Else configure gets stuck, anything I need to take
> care. Started happening recently.
>
> #for linkunit in $LIBRARY_LIST $PROGRAM_LIST $EXTRALIBS_LIST; do
> #flatten_extralibs ${linkunit}_extralibs
> #unique ${linkunit}_extralibs
> #resolve ${linkunit}_extralibs
> #eval ${linkunit}_extralibs=\$\(\$ldflags_filter \$${linkunit}_extralibs\)
> #done
>
> 2. Also getting linking errors now.
>
> ./compat/windows/mslink: line 5: /c/Program Files (x86)/Microsoft Visual
> Studio 12.0/VC/BIN/amd64/link: Argument list too long
> ./compat/windows/mslink: line 5: /c/Program Files (x86)/Microsoft Visual
> Studio 12.0/VC/BIN/amd64/link: Argument list too long
>
You get the second error because you disabled the code to cleanup the
library list, which makes it far far far longer.
I build on windows regularly and I have not noticed any problems with
configure getting stuck, though.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
