• 台湾“裤子大王”:百姓三餐不济谈啥“台湾价值” 2019-05-23
  • 韩国釜山海滩变“垃圾场” 清洁工叫苦不堪 2019-05-23
  • 浙江宣讲十九大:之江大地“好声音”“红船”精神入人心 2019-05-19
  • “回天地区”下月开放千套人才公寓 ——凤凰网房产北京 2019-05-13
  • 中国智能手机在东南亚受追捧 2019-04-25
  • 阜阳网络达人“点赞”颍泉绿化提升专项工作 2019-04-23
  • 《国家人文历史》往期杂志汇总 2019-04-22
  • 一师一团土地确权登记颁证工作全面展开 2019-04-14
  • 德州扑克赌场披“俱乐部”外衣 打竞技旗号难掩赌博实质 2019-04-12
  • 自治区党委召开常委(扩大)会议 陈全国主持 2019-04-12
  • 17年来首次!塔利班组织宣布停火3天 与阿富汗民众自拍 2019-04-04
  • 2022年冬奥会筹备进行时 2019-04-03
  • 人家80年前就造航母,我们现在才造航母,基础不一样。 2019-04-03
  • 葡萄牙首都上演城市节狂欢 2019-04-01
  • RED EARTH红地球展现自我丝绒唇膏全新发布 2019-03-24
  • Welcome to

    Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

     

    Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

    Reply
     
    Thread Tools Search this Thread Display Modes
    Old 12th March 2019, 11:11   #21  |  Link
    Registered Developer
     
    Join Date: Mar 2010
    Location: Hamburg/Germany
    Posts: 9,688
    I would even go as far as saying that win32threads is what I would even recommend if you're building for windows/mingw, since pthreads for windows is also just a wrapper around windows-threads, so using windows-threads directly should be beneficial.
    __________________
    LAV Filters - open source ffmpeg based media splitter and decoders
    nevcairiel is offline   Reply With Quote
    Old 12th March 2019, 11:20   #22  |  Link
     
    Groucho2004's Avatar
     
    Join Date: Mar 2006
    Posts: 4,149
    Quote:
    Originally Posted by nevcairiel View Post
    I would even go as far as saying that win32threads is what I would even recommend if you're building for windows/mingw, since pthreads for windows is also just a wrapper around windows-threads, so using windows-threads directly should be beneficial.
    Exactly. I've been using win32threads in my own x264 builds for years. It's even slightly faster than pthreads.
    __________________
    Groucho's Avisynth Stuff
    Groucho2004 is offline   Reply With Quote
    Old 13th March 2019, 01:04   #23  |  Link
    Registered User
     
    Join Date: Dec 2008
    Location: Brazil
    Posts: 17
    Quote:
    Originally Posted by Groucho2004 View Post
    Exactly. I've been using win32threads in my own x264 builds for years. It's even slightly faster than pthreads.
    Hey Groucho2004, do you have plans to provide your x264 builds for "mere mortals" (like me ) in the future? Would be interesting compare to other providers like LigH, jpsdr and the vanilla ones.
    masterkivat is offline   Reply With Quote
    Old 13th March 2019, 09:42   #24  |  Link
     
    Groucho2004's Avatar
     
    Join Date: Mar 2006
    Posts: 4,149
    Quote:
    Originally Posted by masterkivat View Post
    Hey Groucho2004, do you have plans to provide your x264 builds for "mere mortals" (like me ) in the future? Would be interesting compare to other providers like LigH, jpsdr and the vanilla ones.
    My builds are very barebone, no swscale, gpac, ffms, lsmash, etc. I only enable avs support. Apart from that, I think there are enough options around from which to pick.
    __________________
    Groucho's Avisynth Stuff
    Groucho2004 is offline   Reply With Quote
    Old 16th March 2019, 01:51   #25  |  Link
    Registered User
     
    Join Date: Feb 2019
    Posts: 20
    Quote:
    Originally Posted by qyot27 View Post
    No, you were cross-compiling if you were using mingw. Cygwin doesn't support the win32threads threading mode, and so trying to enable that when doing a native Cygwin build will fail and disable threading. If you're building for MinGW-w64, win32threads is supported.
    Hey there, me again. I managed to compile the rest of the packages pretty smoothly, surprisingly enough, but I'm now stuck at the final stage of compiling FFmpeg itself. I'm sorry to bother you with this again, but the officially-recommended avenue by the failed output of the compiler is the FFmpeg mailing list, and it was abrasive and unpleasant, so it looks like I'm stuck coming back to this forum.

    After having successfully compiled the binaries and libraries for x264, x265, fdk_aac, libopus and AV1 (aom), and then running the following command to compile the all-important FFmpeg:

    Code:
    cd /ffmpeg_sources &&
    wget -O ffmpeg-snapshot.tar.bz2 https://ffmpeg.org/releases/ffmpeg-snapshot.tar.bz2 &&
    tar xjvf ffmpeg-snapshot.tar.bz2 &&
    cd ffmpeg && PKG_CONFIG_PATH="/usr/local/lib/pkgconfig" &&
     ./configure --arch=x86_64 --cross-prefix=x86_64-w64-mingw32- --target-os=mingw32 \
    --enable-cross-compile \
    --extra-cflags="-I/usr/local/include" \
    --extra-ldflags="-L/usr/local/lib" \
    --prefix="/usr/local" \
    --pkg-config-flags="--static" \
    --extra-libs="-lpthread -lm" \
    --enable-libaom \
    --enable-libass \
    --enable-libfdk-aac \
    --enable-libfreetype \
    --enable-libmp3lame \
    --enable-libopus \
    --enable-libvorbis \
    --enable-libvpx \
    --enable-libx264 \
    --enable-libx265 \
    --enable-gpl \
    --enable-nonfree 2>&1 | tee "/ffmpeg_compile.txt" &&
    make -j$(nproc) 2>&1 | tee -a "/ffmpeg_compile.txt" &&
    make install 2>&1 | tee -a "/ffmpeg_compile.txt"
    ...I get the following output:

    Code:
        ERROR: aom >= 1.0.0 not found using pkg-config
    
        If you think configure made a mistake, make sure you are using the latest
        version from Git.  If the latest version fails, report the problem to the
        [email protected] mailing list or IRC #ffmpeg on irc.freenode.net.
        Include the log file "ffbuild/config.log" produced by configure as this will help
        solve the problem.
        Makefile:160: /tests/Makefile: No such file or directory
        make: *** No rule to make target '/tests/Makefile'.  Stop.
        Makefile:160: /tests/Makefile: No such file or directory
        make: *** No rule to make target '/tests/Makefile'.  Stop.
    libaom has definitely been compiled, and its binaries, libraries and pkg-config files are in the relevant folders. When I skip the libaom package, I get the same error for libass, which was installed via Cygwin's package manager. Could this error possibly be caused by how each package was compiled? Not all of the packages that I compiled from source were compiled with the mingw64 compiler - if they didn't cause any problems, I tended to compile with Cygwin's own GCC. In retrospect, it occurred to me that this may have been what you meant earlier when you said:

    Quote:
    So you could sidestep the issue by building your own MinGW-w64/GCC cross-compile environment under Cygwin, and use that instead of the package(s) for them that Cygwin provides. But if you do that, you can't link to any of the MinGW-based dependencies provided by Cygwin (zlib, freetype, libass, or so on), because doing so will cause any program they're linked into to require the same .dlls they do. The only way to prevent that is to build all of it yourself all the way up the chain to avoid contaminating the end-product binaries of x264, FFmpeg, or whatever with needing libgcc-1.dll or libwinpthread-1.dll.
    It makes sense after the fact, but it didn't occur to me that when cross-compiling all dependencies must themselves be compiled with the same toolchain. Although libaom itself was one of the packages compiled with MinGW-w64, which is confusing. Then again, I suppose that rule applies to *all* dependencies used by the compiler process, such as those I installed from Cygwin's package repository.

    Am I correct in thinking, then, that in order to get a successful MinGW-w64 cross-compilation under Cygwin I will need to either build every dependency it relies on from source specifically with the MinGW-w64 toolchain, or have it rely only on MinGW-w64 variants in Cygwin's package repository? These are the dependencies in question:

    Code:
    apt-cyg install \
    autoconf \
    automake \
    binutils \
    bc \ (?)
    cmake \
    cygport \
    doxygen \
    mingw64-x86_64-gcc-g++ \
    gcc-core \
    gcc_g++ \
    git \
    hg \
    libass-devel \
    libfreetype-devel \
    libmp3lame-devel \
    libogg-devel \
    libopus-devel \
    libSDL2-devel  \
    libtheora-devel \
    libtool \
    libvorbis-devel \
    libvpx-devel \
    make \
    mingw64-x86_64-binutils \
    mingw64-x86_64-gcc-core \
    mingw64-x86_64-headers \
    mingw64-x86_64-runtime \
    mingw64-x86_64-winpthreads \
    mingw64-x86_64-windows-default-manifest \
    nasm \
    pkg-config \
    texinfo \
    wget \
    yasm
    Or is it perhaps just the libraries that I need to find MinGW-64 variants for?

    Or am I entirely jumping the gun here and could this error be entirely unrelated? I also have the config.log if that would help you.

    Thank you once again.

    Last edited by Kaos-Industries; 16th March 2019 at 19:21.
    Kaos-Industries is offline   Reply With Quote
    Old 16th March 2019, 02:58   #26  |  Link
    ...?
     
    qyot27's Avatar
     
    Join Date: Nov 2005
    Location: Florida
    Posts: 1,022
    Well,

    The --target-os should be just a plain 'mingw32'.

    --enable-cross-compile probably shouldn't be used here; I'm not really sure what the use case for it actually is, but I've never had to use it while doing cross-compiles with MinGW-w64.

    PKG_CONFIG_PATH in the command above is separated from configure with && rather than being passed to ./configure as a local environment variable; while this may be innocuous (having it as a separate command should have the effect of simply forcing it for the entire environment, until you exit the Cygwin shell), it's generally better practice to make sure that stuff like that is attached to the command it's meant to be paired with.
    qyot27 is offline   Reply With Quote
    Old 16th March 2019, 19:16   #27  |  Link
    Registered User
     
    Join Date: Feb 2019
    Posts: 20
    Quote:
    Originally Posted by qyot27 View Post
    Well,

    The --target-os should be just a plain 'mingw32'.

    --enable-cross-compile probably shouldn't be used here; I'm not really sure what the use case for it actually is, but I've never had to use it while doing cross-compiles with MinGW-w64.

    PKG_CONFIG_PATH in the command above is separated from configure with && rather than being passed to ./configure as a local environment variable; while this may be innocuous (having it as a separate command should have the effect of simply forcing it for the entire environment, until you exit the Cygwin shell), it's generally better practice to make sure that stuff like that is attached to the command it's meant to be paired with.
    My bad, the inclusion of the longer target OS value was a mistake that I was experimenting with, I can confirm that the output above was from using mingw32 as a target OS, I'll edit that now.

    I'll try removing the --enable--cross-compile flag and putting PKG CONFIG in the right place and then report back. Do you not think the error is a result of using non-minGW-64 depednencies then?
    Kaos-Industries is offline   Reply With Quote
    Old 16th March 2019, 21:25   #28  |  Link
    ...?
     
    qyot27's Avatar
     
    Join Date: Nov 2005
    Location: Florida
    Posts: 1,022
    Without knowing the exact errors, I'd just be guessing. Considering that the libraries were built with at least three different build systems (handwritten for x264, autotools for several, CMake for x265), it could also have been in how some of those were configured as well. First-hand, cross-compiling with CMake is weird because of the need for a toolchain file - and if you used one of the build scripts that the x265 project provides, then you're up to the whims of said script. I was mostly going on how most chained dependencies act under normal circumstances; but it wouldn't surprise me if it actually is impossible to mix native-Cygwin and MinGW-w64 libraries, rather than simply causing the build to require extra .dlls. In which case, yeah, you'd have to choose to build the entire dependency chain?with either MinGW-w64 or Cygwin, not some with one and some with the other.

    箂aid dependency chain is the libraries themselves, not the build system components; in the list you gave, it would mean just the -devel packages that would need to be built with MinGW-w64. In that list, the only significantly problematic one is libass, because freetype2 and fontconfig both have a potential litany of their own dependencies to handle too (and I would recommend using fontconfig rather than libass' native ability to use Windows' DirectWrite functionality, especially if you either have lots of system fonts, and/or plan to use the FFmpeg libs to build a media player like mpv).

    Due to how FFmpeg's configuration script works, the part of ffbuild/config.log that would be relevant to help troubleshoot is the very last portion, it should be clear where it executed the command that made configure fail.

    Last edited by qyot27; 16th March 2019 at 21:28.
    qyot27 is offline   Reply With Quote
    Old 18th March 2019, 00:52   #29  |  Link
    Registered User
     
    Join Date: Feb 2019
    Posts: 20
    Quote:
    Originally Posted by qyot27 View Post
    Without knowing the exact errors, I'd just be guessing. Considering that the libraries were built with at least three different build systems (handwritten for x264, autotools for several, CMake for x265), it could also have been in how some of those were configured as well. First-hand, cross-compiling with CMake is weird because of the need for a toolchain file - and if you used one of the build scripts that the x265 project provides, then you're up to the whims of said script. I was mostly going on how most chained dependencies act under normal circumstances; but it wouldn't surprise me if it actually is impossible to mix native-Cygwin and MinGW-w64 libraries, rather than simply causing the build to require extra .dlls. In which case, yeah, you'd have to choose to build the entire dependency chain?with either MinGW-w64 or Cygwin, not some with one and some with the other.

    箂aid dependency chain is the libraries themselves, not the build system components; in the list you gave, it would mean just the -devel packages that would need to be built with MinGW-w64. In that list, the only significantly problematic one is libass, because freetype2 and fontconfig both have a potential litany of their own dependencies to handle too (and I would recommend using fontconfig rather than libass' native ability to use Windows' DirectWrite functionality, especially if you either have lots of system fonts, and/or plan to use the FFmpeg libs to build a media player like mpv).

    Due to how FFmpeg's configuration script works, the part of ffbuild/config.log that would be relevant to help troubleshoot is the very last portion, it should be clear where it executed the command that made configure fail.
    Here are the last six "blocks" of the config.log. They don't mean anything to me, but maybe you can decode them. Let me know if you need more.

    Code:
                            ^
    x86_64-w64-mingw32-gcc -L/usr/local/lib -Wl,--nxcompat,--dynamicbase -Wl,--high-entropy-va -Wl,--as-needed -Wl,--image-base,0x140000000 -o /tmp/ffconf.s2SqLWqy/test.exe /tmp/ffconf.s2SqLWqy/test.o -lm -lpthread -lm
    check_mathfunc sinf 1 -lm
    test_ld cc -lm
    test_cc
    BEGIN /tmp/ffconf.s2SqLWqy/test.c
        1	#include <math.h>
        2	float foo(float f, float g) { return sinf(f); }
        3	int main(void){ return (int) foo; }
    END /tmp/ffconf.s2SqLWqy/test.c
    x86_64-w64-mingw32-gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1 -D__printf__=__gnu_printf__ -D_WIN32_WINNT=0x0600 -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -I/usr/local/include -std=c11 -fomit-frame-pointer -c -o /tmp/ffconf.s2SqLWqy/test.o /tmp/ffconf.s2SqLWqy/test.c
    /tmp/ffconf.s2SqLWqy/test.c: In function 'main':
    /tmp/ffconf.s2SqLWqy/test.c:3:24: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
     int main(void){ return (int) foo; }
                            ^
    x86_64-w64-mingw32-gcc -L/usr/local/lib -Wl,--nxcompat,--dynamicbase -Wl,--high-entropy-va -Wl,--as-needed -Wl,--image-base,0x140000000 -o /tmp/ffconf.s2SqLWqy/test.exe /tmp/ffconf.s2SqLWqy/test.o -lm -lpthread -lm
    check_mathfunc trunc 1 -lm
    test_ld cc -lm
    test_cc
    BEGIN /tmp/ffconf.s2SqLWqy/test.c
        1	#include <math.h>
        2	float foo(float f, float g) { return trunc(f); }
        3	int main(void){ return (int) foo; }
    END /tmp/ffconf.s2SqLWqy/test.c
    x86_64-w64-mingw32-gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1 -D__printf__=__gnu_printf__ -D_WIN32_WINNT=0x0600 -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -I/usr/local/include -std=c11 -fomit-frame-pointer -c -o /tmp/ffconf.s2SqLWqy/test.o /tmp/ffconf.s2SqLWqy/test.c
    /tmp/ffconf.s2SqLWqy/test.c: In function 'main':
    /tmp/ffconf.s2SqLWqy/test.c:3:24: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
     int main(void){ return (int) foo; }
                            ^
    x86_64-w64-mingw32-gcc -L/usr/local/lib -Wl,--nxcompat,--dynamicbase -Wl,--high-entropy-va -Wl,--as-needed -Wl,--image-base,0x140000000 -o /tmp/ffconf.s2SqLWqy/test.exe /tmp/ffconf.s2SqLWqy/test.o -lm -lpthread -lm
    check_mathfunc truncf 1 -lm
    test_ld cc -lm
    test_cc
    BEGIN /tmp/ffconf.s2SqLWqy/test.c
        1	#include <math.h>
        2	float foo(float f, float g) { return truncf(f); }
        3	int main(void){ return (int) foo; }
    END /tmp/ffconf.s2SqLWqy/test.c
    x86_64-w64-mingw32-gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1 -D__printf__=__gnu_printf__ -D_WIN32_WINNT=0x0600 -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -I/usr/local/include -std=c11 -fomit-frame-pointer -c -o /tmp/ffconf.s2SqLWqy/test.o /tmp/ffconf.s2SqLWqy/test.c
    /tmp/ffconf.s2SqLWqy/test.c: In function 'main':
    /tmp/ffconf.s2SqLWqy/test.c:3:24: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
     int main(void){ return (int) foo; }
                            ^
    x86_64-w64-mingw32-gcc -L/usr/local/lib -Wl,--nxcompat,--dynamicbase -Wl,--high-entropy-va -Wl,--as-needed -Wl,--image-base,0x140000000 -o /tmp/ffconf.s2SqLWqy/test.exe /tmp/ffconf.s2SqLWqy/test.o -lm -lpthread -lm
    check_complexfunc cabs 1
    test_ld cc
    test_cc
    BEGIN /tmp/ffconf.s2SqLWqy/test.c
        1	#include <complex.h>
        2	#include <math.h>
        3	float foo(complex float f, complex float g) { return cabs(f * I); }
        4	int main(void){ return (int) foo; }
    END /tmp/ffconf.s2SqLWqy/test.c
    x86_64-w64-mingw32-gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1 -D__printf__=__gnu_printf__ -D_WIN32_WINNT=0x0600 -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -I/usr/local/include -std=c11 -fomit-frame-pointer -c -o /tmp/ffconf.s2SqLWqy/test.o /tmp/ffconf.s2SqLWqy/test.c
    /tmp/ffconf.s2SqLWqy/test.c: In function 'main':
    /tmp/ffconf.s2SqLWqy/test.c:4:24: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
     int main(void){ return (int) foo; }
                            ^
    x86_64-w64-mingw32-gcc -L/usr/local/lib -Wl,--nxcompat,--dynamicbase -Wl,--high-entropy-va -Wl,--as-needed -Wl,--image-base,0x140000000 -o /tmp/ffconf.s2SqLWqy/test.exe /tmp/ffconf.s2SqLWqy/test.o -lpthread -lm
    check_complexfunc cexp 1
    test_ld cc
    test_cc
    BEGIN /tmp/ffconf.s2SqLWqy/test.c
        1	#include <complex.h>
        2	#include <math.h>
        3	float foo(complex float f, complex float g) { return cexp(f * I); }
        4	int main(void){ return (int) foo; }
    END /tmp/ffconf.s2SqLWqy/test.c
    x86_64-w64-mingw32-gcc -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -U__STRICT_ANSI__ -D__USE_MINGW_ANSI_STDIO=1 -D__printf__=__gnu_printf__ -D_WIN32_WINNT=0x0600 -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -I/usr/local/include -std=c11 -fomit-frame-pointer -c -o /tmp/ffconf.s2SqLWqy/test.o /tmp/ffconf.s2SqLWqy/test.c
    /tmp/ffconf.s2SqLWqy/test.c: In function 'main':
    /tmp/ffconf.s2SqLWqy/test.c:4:24: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
     int main(void){ return (int) foo; }
                            ^
    x86_64-w64-mingw32-gcc -L/usr/local/lib -Wl,--nxcompat,--dynamicbase -Wl,--high-entropy-va -Wl,--as-needed -Wl,--image-base,0x140000000 -o /tmp/ffconf.s2SqLWqy/test.exe /tmp/ffconf.s2SqLWqy/test.o -lpthread -lm
    require_pkg_config libaom aom >= 1.0.0 aom/aom_codec.h aom_codec_version
    check_pkg_config libaom aom >= 1.0.0 aom/aom_codec.h aom_codec_version
    test_pkg_config libaom aom >= 1.0.0 aom/aom_codec.h aom_codec_version
    false --exists --print-errors aom >= 1.0.0
    ERROR: aom >= 1.0.0 not found using pkg-config
    In the meantime, I'll see how far I get trying to re-build the libraries with MinGW-W64 and looking up the MinGW-w64 variants for the rest.

    Last edited by Kaos-Industries; 18th March 2019 at 00:58.
    Kaos-Industries is offline   Reply With Quote
    Old 18th March 2019, 05:52   #30  |  Link
    Registered User
     
    Join Date: Feb 2019
    Posts: 20
    Quote:
    Originally Posted by nevcairiel View Post
    I would even go as far as saying that win32threads is what I would even recommend if you're building for windows/mingw, since pthreads for windows is also just a wrapper around windows-threads, so using windows-threads directly should be beneficial.
    Quote:
    Originally Posted by Groucho2005
    Exactly. I've been using win32threads in my own x264 builds for years. It's even slightly faster than pthreads.
    Thanks for your responses.

    How would I build FFmpeg with win32threads? Is it as simple as making sure the compiled FFmpeg is enabled with it, or do all of the dependencies also somehow need the option enabled (although so far I haven't seen anything to indicate they're disabled by default)?
    Kaos-Industries is offline   Reply With Quote
    Old 18th March 2019, 09:07   #31  |  Link
    Registered Developer
     
    Join Date: Mar 2010
    Location: Hamburg/Germany
    Posts: 9,688
    If you are building FFmpeg with a cross-prefix, you need to ensure that either a prefixed pkg-config also exists (which is not typically the case for mingw), or you need to also pass --pkg-config=pkg-config to tell it which pkg-config to use.
    It appears the error you are seeing comes from pkg-config not being found, which would be remedied passing the above option.

    For win32threads, I would personally recommend to build as many dependencies with it as possible - however, for AOM thats really hard, so I wold skip that, and just do x264/x265 and ffmpeg itself. Its not really required to have dependencies use the same threading model, and they could use pthreads.
    __________________
    LAV Filters - open source ffmpeg based media splitter and decoders
    nevcairiel is offline   Reply With Quote
    Old 18th March 2019, 16:49   #32  |  Link
    Registered User
     
    Join Date: Feb 2019
    Posts: 20
    Quote:
    Originally Posted by nevcairiel View Post
    If you are building FFmpeg with a cross-prefix, you need to ensure that either a prefixed pkg-config also exists (which is not typically the case for mingw), or you need to also pass --pkg-config=pkg-config to tell it which pkg-config to use.
    It appears the error you are seeing comes from pkg-config not being found, which would be remedied passing the above option.
    Thank you, I'll try this.

    Quote:

    For win32threads, I would personally recommend to build as many dependencies with it as possible - however, for AOM thats really hard, so I wold skip that, and just do x264/x265 and ffmpeg itself. Its not really required to have dependencies use the same threading model, and they could use pthreads.
    How would I do this? The only relevant options in x264's configure script are --disable-win32thread and --disable-thread, the latter of which's description is: disable multithreaded encoding, which to me sounds like it disables both pthreads and win32threads.

    x265 has to be configured with CMake, so I'm not even sure how to go about finding what option I need to pass to it in order to enable win32thread. cmake --help returns nothing relevant.
    Kaos-Industries is offline   Reply With Quote
    Old 18th March 2019, 17:40   #33  |  Link
    Registered Developer
     
    Join Date: Mar 2010
    Location: Hamburg/Germany
    Posts: 9,688
    Quote:
    Originally Posted by Kaos-Industries View Post
    How would I do this? The only relevant options in x264's configure script are --disable-win32thread and --disable-thread, the latter of which's description is: disable multithreaded encoding, which to me sounds like it disables both pthreads and win32threads.
    As far as I can tell, building without --disable-win32thread should be enough to use it.

    For x265, I'm not sure, I haven't build that for a while.
    __________________
    LAV Filters - open source ffmpeg based media splitter and decoders
    nevcairiel is offline   Reply With Quote
    Old 22nd March 2019, 23:00   #34  |  Link
    Registered User
     
    Join Date: Feb 2019
    Posts: 20
    To update where I am with this, I'm still getting the same error while building FFmpeg, even after compiling or sourcing only MinGW-w64 dependencies, although I have made some progress on the cause:

    https://stackoverflow.com/questions/...n-by-configure

    Hopefully someone here can figure out what's going wrong here that I can't see and put me out of my misery.

    Last edited by Kaos-Industries; 22nd March 2019 at 23:05.
    Kaos-Industries is offline   Reply With Quote
    Old 25th March 2019, 19:17   #35  |  Link
    Registered User
     
    Join Date: Feb 2019
    Posts: 20
    Quote:
    Originally Posted by qyot27 View Post
    Without knowing the exact errors, I'd just be guessing. Considering that the libraries were built with at least three different build systems (handwritten for x264, autotools for several, CMake for x265), it could also have been in how some of those were configured as well. First-hand, cross-compiling with CMake is weird because of the need for a toolchain file - and if you used one of the build scripts that the x265 project provides, then you're up to the whims of said script. I was mostly going on how most chained dependencies act under normal circumstances; but it wouldn't surprise me if it actually is impossible to mix native-Cygwin and MinGW-w64 libraries, rather than simply causing the build to require extra .dlls. In which case, yeah, you'd have to choose to build the entire dependency chain?with either MinGW-w64 or Cygwin, not some with one and some with the other.

    箂aid dependency chain is the libraries themselves, not the build system components; in the list you gave, it would mean just the -devel packages that would need to be built with MinGW-w64. In that list, the only significantly problematic one is libass, because freetype2 and fontconfig both have a potential litany of their own dependencies to handle too (and I would recommend using fontconfig rather than libass' native ability to use Windows' DirectWrite functionality, especially if you either have lots of system fonts, and/or plan to use the FFmpeg libs to build a media player like mpv).

    Due to how FFmpeg's configuration script works, the part of ffbuild/config.log that would be relevant to help troubleshoot is the very last portion, it should be clear where it executed the command that made configure fail.
    Okay, so after a lot of testing and digging into directories, I've managed to figure out that the cause is that while pkg-config/configure is able to see all the packages that I compiled from source (located in /usr/bin/local/lib/pkgconfig), it isn't able to see the rest that I installed via Cygwin's package manager - which are located in /usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig.

    So naturally it seemed that all I needed to do was add the latter path to PKG_CONFIG_LIBDIR (which I'm using in place of PKG_CONFIG_PATH because it doesn't include /usr/bin by default and therefore avoids potential conflicts between Cygwin and MinGW-w64 packages).

    However, this still doesn't work to compile any of the packages in the mingw prefix folder,

    This is the most working version of the command I currently have:

    Code:
    cd /ffmpeg_sources && rm -fr ffmpeg &&
    wget -O ffmpeg-snapshot.tar.bz2 https://ffmpeg.org/releases/ffmpeg-snapshot.tar.bz2 &&
    tar xjvf ffmpeg-snapshot.tar.bz2 1> /dev/null && rm -f ffmpeg-snapshot.tar.bz2 && cd ffmpeg &&
    export PKG_CONFIG_LIBDIR="/usr/local/lib/pkgconfig:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig" &&
    ./configure --arch=x86_64 --cross-prefix=x86_64-w64-mingw32- --target-os=mingw32 \
    --extra-cflags="-static -I/usr/local/include -I/usr/x86_64-w64-mingw32/sys-root/mingw/include" \
    --extra-ldflags="-static -L/usr/local/lib -L/usr/x86_64-w64-mingw32/sys-root/mingw/lib" \
    --extra-libs="-pthread -lm" \
    --prefix="/usr/local" \
    --pkg-config="pkg-config" \
    --pkg-config-flags="--static" \
    --enable-libaom \
    --enable-libass \
    --enable-libfdk-aac \
    --enable-libfreetype \
    --enable-libmp3lame \
    --enable-libopus \
    --enable-libvorbis \
    --enable-libvpx \
    --enable-libx264 \
    --enable-libx265 \
    --enable-gpl \
    --enable-nonfree \
    --enable-static  \
    --disable-shared &&
    make -j$(nproc) &&
    make install
    Adding --sysinclude="/usr/x86_64-w64-mingw32/sys-root/mingw/lib" on its own makes no difference ot it, and adding --sysroot="/usr/x86_64-w64-mingw32/sys-root/mingw" seems to take everything into a completely different direction - instead of the usual pkg-config errors, I get an error that says:

    Quote:
    x86_64-w64-mingw32-gcc is unable to create an executable file.

    C compiler test failed.
    I've made so much progress with this that I feel like I'm way too close to call it quits at this point, so any suggestions as to why pkg-config still refuses to see the packages in the sys-root folder would be appreciated.
    Kaos-Industries is offline   Reply With Quote
    Old 2nd April 2019, 18:14   #36  |  Link
    Registered User
     
    Join Date: Feb 2019
    Posts: 20
    An update on this: I finally managed to determine that the problem I was running into wasn't what I thought it was at all - that the packages installed through Cygwin's setup/package manager were unable to be seen by pkg-config or PKG_CONFIG_PATH while those I'd built from source could be seen fine. It turns out the only packages that were actually failing to build were three in particular - libvorbis, libass, and libfreetype. I realised this when I started removing --enable-package options and noticed that many of those installed from the Cygwin setup were working fine. I can only assume that the Cygwin version of these particular packages are broken in some way. The plan is now to build these three packages from source, and see whether that solves my issues.
    Kaos-Industries is offline   Reply With Quote
    Old 2nd April 2019, 22:11   #37  |  Link
    ...?
     
    qyot27's Avatar
     
    Join Date: Nov 2005
    Location: Florida
    Posts: 1,022
    Running into that was largely why I hadn't responded. The errors being emitted for libass indicated that it wasn't finding the other libraries* libass links against, even though several of them (in their mingw64- variants, of course) were installed. libvorbis only depends on libogg, IIRC. Freetype2 is part of the libass dependency chain, so all the things it needs would be covered by getting all the things libass needs.

    *libass missing dependencies:
    harfbuzz
    glib-2.0
    pcre
    fontconfig
    expat
    freetype
    png16

    Some of those have questionable levels of necessity (harfbuzz, for example, is really only needed if you need to have the ability to render RTL-formatted subtitles, but the downside is that harfbuzz is also what calls in glib2, which I can tell you right now is a nightmare and something I avoided in my build guide because it's so easy to get stuck on; pcre is only needed by either harfbuzz or glib2). The proper order for the libass dependencies are libpng?(which might require zlib? so be prepared for that), then from the "Subtitle rendering" section of the guide? iconv->enca->freetype2->c2man->fribidi->expat->json-c->fontconfig->uchardet->lua (likewise, json-c and uchardet might not actually be necessary for libass, its dependencies, or FFmpeg, but they're there for mpv's sake; lua is definitely just for mpv). c2man is something fribidi needs, and I think that's why I didn't bother with harfbuzz, since it and fribidi have some overlap (IIRC).

    Also, libass doesn't have to use fontconfig; it can use Windows' own DirectWrite API, which could mean not having to compile a lot of those dependencies (although at this point I'm not sure which ones). The reason I don't recommend building libass to use DirectWrite is that if you have large (talking several hundred to over a thousand) numbers of fonts installed, you'll have a constant performance hit whenever invoking libass; with fontconfig, so long as you aren't constantly installing fonts, the only hiccup will be the first time it's called, since it has to cache the font list, but fontconfig's cache list is persistent, DirectWrite's is not.

    ?a target="_blank">https://github.com/qyot27/mpv/blob/e...dious.txt#L391
    ?a target="_blank">https://github.com/qyot27/mpv/blob/e...dious.txt#L772
    ?a target="_blank">https://github.com/qyot27/mpv/blob/e...ious.txt#L1058
    qyot27 is offline   Reply With Quote
    Old 3rd April 2019, 04:21   #38  |  Link
    Registered User
     
    Join Date: Feb 2019
    Posts: 20
    Quote:
    Originally Posted by qyot27 View Post
    Running into that was largely why I hadn't responded. The errors being emitted for libass indicated that it wasn't finding the other libraries* libass links against, even though several of them (in their mingw64- variants, of course) were installed. libvorbis only depends on libogg, IIRC. Freetype2 is part of the libass dependency chain, so all the things it needs would be covered by getting all the things libass needs.

    *libass missing dependencies:
    harfbuzz
    glib-2.0
    pcre
    fontconfig
    expat
    freetype
    png16

    Some of those have questionable levels of necessity (harfbuzz, for example, is really only needed if you need to have the ability to render RTL-formatted subtitles, but the downside is that harfbuzz is also what calls in glib2, which I can tell you right now is a nightmare and something I avoided in my build guide because it's so easy to get stuck on; pcre is only needed by either harfbuzz or glib2). The proper order for the libass dependencies are libpng?(which might require zlib? so be prepared for that), then from the "Subtitle rendering" section of the guide? iconv->enca->freetype2->c2man->fribidi->expat->json-c->fontconfig->uchardet->lua (likewise, json-c and uchardet might not actually be necessary for libass, its dependencies, or FFmpeg, but they're there for mpv's sake; lua is definitely just for mpv). c2man is something fribidi needs, and I think that's why I didn't bother with harfbuzz, since it and fribidi have some overlap (IIRC).

    Also, libass doesn't have to use fontconfig; it can use Windows' own DirectWrite API, which could mean not having to compile a lot of those dependencies (although at this point I'm not sure which ones). The reason I don't recommend building libass to use DirectWrite is that if you have large (talking several hundred to over a thousand) numbers of fonts installed, you'll have a constant performance hit whenever invoking libass; with fontconfig, so long as you aren't constantly installing fonts, the only hiccup will be the first time it's called, since it has to cache the font list, but fontconfig's cache list is persistent, DirectWrite's is not.

    ?a target="_blank">https://github.com/qyot27/mpv/blob/e...dious.txt#L391
    ?a target="_blank">https://github.com/qyot27/mpv/blob/e...dious.txt#L772
    ?a target="_blank">https://github.com/qyot27/mpv/blob/e...ious.txt#L1058
    Yeah, I came across the glib2 problem a lot while researching this stuff, that and harfbuzz and libass being in some weird dependency loop, so I'd definitely like to avoid the ones I don't need where I can.

    So if I'm understanding you correctly, are you saying that I would need to cross-compile each package in those dependency chains from source?

    And that those chains would be, in left-to-right order of compilation/install:

    libogg > libvorbis

    zlib (possibly) > libpng > iconv > enca > freetype2 > c2man > fribidi > expat > fontconfig > json-c (possibly) > uchardet (possibly) > libass

    Correct me if I've misunderstood any of the above.

    As for fontconfig, I don't have much use for it myself as I've never really seen a need to use FFmpeg's subtitle-generation feature, but part of my being so invested in this project at this point is that I've decided I'll be writing up a guide on how to accomplish this with Cygwin for anyone that comes after (seems a waste not to with the time I've spent on it), and I'm currently weighing up whether the extra packages are worth including that feature for others. Including libass without fontconfig might be a good compromise between making a more complete guide for others and making life easier on myself, but I suppose it ultimately depends on just how much more packages I'll need to compile from source for fontconfig vs libass. How would I find out exactly which dependencies fontconfig needs?
    Kaos-Industries is offline   Reply With Quote
    Reply


    Posting Rules
    You may not post new threads
    You may not post replies
    You may not post attachments
    You may not edit your posts

    BB code is On
    Smilies are On
    [IMG] code is On
    HTML code is Off

    Forum Jump


    All times are GMT +1. The time now is 10:33.


    Powered by vBulletin® Version 3.8.11
    Copyright ©2000 - 2019, vBulletin Solutions Inc.
  • 台湾“裤子大王”:百姓三餐不济谈啥“台湾价值” 2019-05-23
  • 韩国釜山海滩变“垃圾场” 清洁工叫苦不堪 2019-05-23
  • 浙江宣讲十九大:之江大地“好声音”“红船”精神入人心 2019-05-19
  • “回天地区”下月开放千套人才公寓 ——凤凰网房产北京 2019-05-13
  • 中国智能手机在东南亚受追捧 2019-04-25
  • 阜阳网络达人“点赞”颍泉绿化提升专项工作 2019-04-23
  • 《国家人文历史》往期杂志汇总 2019-04-22
  • 一师一团土地确权登记颁证工作全面展开 2019-04-14
  • 德州扑克赌场披“俱乐部”外衣 打竞技旗号难掩赌博实质 2019-04-12
  • 自治区党委召开常委(扩大)会议 陈全国主持 2019-04-12
  • 17年来首次!塔利班组织宣布停火3天 与阿富汗民众自拍 2019-04-04
  • 2022年冬奥会筹备进行时 2019-04-03
  • 人家80年前就造航母,我们现在才造航母,基础不一样。 2019-04-03
  • 葡萄牙首都上演城市节狂欢 2019-04-01
  • RED EARTH红地球展现自我丝绒唇膏全新发布 2019-03-24
  • 北京赛车pk跟投注软件 新时时彩三星组六玩法 北京时时彩10开奖直播现场 大乐透杀号定胆 桥头竞彩北单店 北京pk10彩票合法的吗 半全场胜平负单场固定 牛牛撸牛牛热视频 体彩p5开奖283结果 华东15选5开奖结果 排列3计算器 广东彩票36选7开奖好彩1 新疆时时彩走势图开奖及时更新 湖南彩票刮刮乐 时时彩自由的百科天堂 河南泳坛夺金直播