Giter Club home page Giter Club logo

aom's Introduction

AV1 Codec Library

Building the library and applications

Prerequisites

  1. CMake version 3.5 or higher.
  2. Git.
  3. Perl.
  4. For x86 targets, yasm, which is preferred, or a recent version of nasm.
  5. Building the documentation requires doxygen.
  6. Building the unit tests requires Python.

Basic build

CMake replaces the configure step typical of many projects. Running CMake will produce configuration and build files for the currently selected CMake generator. For most systems the default generator is Unix Makefiles. The basic form of a makefile build is the following:

$ cmake path/to/aom
$ make

The above will generate a makefile build that produces the AV1 library and applications for the current host system after the make step completes successfully. The compiler chosen varies by host platform, but a general rule applies: On systems where cc and c++ are present in $PATH at the time CMake is run the generated build will use cc and c++ by default.

Configuration options

The AV1 codec library has a great many configuration options. These come in two varieties:

  1. Build system configuration options. These have the form ENABLE_FEATURE.
  2. AV1 codec configuration options. These have the form CONFIG_FEATURE.

Both types of options are set at the time CMake is run. The following example enables ccache and disables high bit depth:

$ cmake path/to/aom -DENABLE_CCACHE=1 -DCONFIG_HIGHBITDEPTH=0
$ make

The available configuration options are too numerous to list here. Build system configuration options can be found at the top of the CMakeLists.txt file found in the root of the AV1 repository, and AV1 codec configuration options can currently be found in the file build/cmake/aom_config_defaults.cmake.

Dylib builds

A dylib (shared object) build of the AV1 codec library can be enabled via the CMake built in variable BUILD_SHARED_LIBS:

$ cmake path/to/aom -D BUILD_SHARED_LIBS=1
$ make

This is currently only supported on non-Windows targets.

Cross compiling

For the purposes of building the AV1 codec and applications and relative to the scope of this guide, all builds for architectures differing from the native host architecture will be considered cross compiles. The AV1 CMake build handles cross compiling via the use of toolchain files included in the AV1 repository. The toolchain files available at the time of this writing are:

  • arm64-ios.cmake
  • arm64-linux-gcc.cmake
  • armv7-ios.cmake
  • armv7-linux-gcc.cmake
  • armv7s-ios.cmake
  • mips32-linux-gcc.cmake
  • mips64-linux-gcc.cmake
  • x86-ios-simulator.cmake
  • x86-linux.cmake
  • x86-macos.cmake
  • x86_64-ios-simulator.cmake

The following example demonstrates use of the x86-macos.cmake toolchain file on a x86_64 MacOS host:

$ cmake path/to/aom \
  -DCMAKE_TOOLCHAIN_FILE=path/to/aom/build/cmake/toolchains/x86-macos.cmake
$ make

To build for an unlisted target creation of a new toolchain file is the best solution. The existing toolchain files can be used a starting point for a new toolchain file since each one exposes the basic requirements for toolchain files as used in the AV1 codec build.

As a temporary work around an unoptimized AV1 configuration that builds only C and C++ sources can be produced using the following commands:

$ cmake path/to/aom -DAOM_TARGET_CPU=generic
$ make

In addition to the above it's important to note that the toolchain files suffixed with gcc behave differently than the others. These toolchain files attempt to obey the $CROSS environment variable.

Microsoft Visual Studio builds

Building the AV1 codec library in Microsoft Visual Studio is supported. The following example demonstrates generating projects and a solution for the Microsoft IDE:

# This does not require a bash shell; command.exe is fine.
$ cmake path/to/aom -G "Visual Studio 15 2017"

Xcode builds

Building the AV1 codec library in Xcode is supported. The following example demonstrates generating an Xcode project:

$ cmake path/to/aom -G Xcode

Testing the AV1 codec

Testing basics

Currently there are two types of tests in the AV1 codec repository:

  1. Unit tests.
  2. Example tests.

The unit tests can be run at build time:

# Before running the make command the LIBAOM_TEST_DATA_PATH environment
# variable should be set to avoid downloading the test files to the
# cmake build configuration directory.
$ cmake path/to/aom
# Note: The AV1 CMake build creates many test targets. Running make
# with multiple jobs will speed up the test run significantly.
$ make runtests

The example tests require a bash shell and can be run in the following manner:

# See the note above about LIBAOM_TEST_DATA_PATH above.
$ cmake path/to/aom
$ make
# It's best to build the testdata target using many make jobs.
# Running it like this will verify and download (if necessary)
# one at a time, which takes a while.
$ make testdata
$ path/to/aom/test/examples.sh --bin-path examples

IDE hosted tests

By default the generated projects files created by CMake will not include the runtests and testdata rules when generating for IDEs like Microsoft Visual Studio and Xcode. This is done to avoid intolerably long build cycles in the IDEs-- IDE behavior is to build all targets when selecting the build project options in MSVS and Xcode. To enable the test rules in IDEs the ENABLE_IDE_TEST_HOSTING variable must be enabled at CMake generation time:

# This example uses Xcode. To get a list of the generators
# available, run cmake with the -G argument missing its
# value.
$ cmake path/to/aom -DENABLE_IDE_TEST_HOSTING=1 -G Xcode

Downloading the test data

The fastest and easiest way to obtain the test data is to use CMake to generate a build using the Unix Makefiles generator, and then to build only the testdata rule:

$ cmake path/to/aom -G "Unix Makefiles"
# 28 is used because there are 28 test files as of this writing.
$ make -j28 testdata

The above make command will only download and verify the test data.

Coding style

The coding style used by this project is enforced with clang-format using the configuration contained in the .clang-format file in the root of the repository.

Before pushing changes for review you can format your code with:

# Apply clang-format to modified .c, .h and .cc files
$ clang-format -i --style=file \
  $(git diff --name-only --diff-filter=ACMR '*.[hc]' '*.cc')

Check the .clang-format file for the version used to generate it if there is any difference between your local formatting and the review system.

See also: http://clang.llvm.org/docs/ClangFormat.html

Support

This library is an open source project supported by its community. Please please email [email protected] for help.

Bug reports

Bug reports can be filed in the Alliance for Open Media issue tracker.

aom's People

Contributors

aconverse avatar agrange avatar debargha avatar dmitriykovalev avatar fritzk avatar gezalore avatar imgmips1 avatar jamesaberry avatar jimbankoski avatar jingninghan avatar jkoleszar avatar jmvalin avatar jzern avatar luctrudeau avatar marco99zz avatar mbebenita avatar mstorsjo avatar paulwilkins avatar pengchongjin avatar peterderivaz avatar punksu avatar rbultje avatar stemidts avatar tdaede avatar tomfinegan avatar urvangjoshi avatar vigneshvg avatar yaowuxu avatar ycho avatar zoeviper avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

aom's Issues

CODE_OF_CONDUCT.md file missing

As of January 1 2019, Mozilla requires that all GitHub projects include this CODE_OF_CONDUCT.md file in the project root. The file has two parts:

  1. Required Text - All text under the headings Community Participation Guidelines and How to Report, are required, and should not be altered.
  2. Optional Text - The Project Specific Etiquette heading provides a space to speak more specifically about ways people can work effectively and inclusively together. Some examples of those can be found on the Firefox Debugger project, and Common Voice. (The optional part is commented out in the raw template file, and will not be visible until you modify and uncomment that part.)

If you have any questions about this file, or Code of Conduct policies and procedures, please see Mozilla-GitHub-Standards or email [email protected].

(Message COC001)

break twice

\av1\encoder\mcomp.c line 2608 duplicate break

Incorrect cmake configuration for different x86_64 processors

Many old processors don't support all of those instructions: sse, sse2, sse3, sse4.1, avx, avx2.
Cmake script enables all instructions but it's completely wrong.

If disable all instructions then compilation fail with undefined reference to... in av1_rtcd.h and aom_dsp_rtcd.h

profile bitdepth color sampling confusion

According to https://en.wikipedia.org/wiki/AV1#Profiles
High profile (--profile 1) supports 4:2:0, but when I use 8bit with profile 1 I get:

Profile 1 requires 4:4:4 color format

High profile (--profile 1) supports 4:2:0, but when I use 8bit with profile 1 I get:

Profile 1 requires 4:4:4 color format

Professional profile (--profile 2) supports 4:2:0, but when I use 8bit with profile 2 I get:

Profile 2 bit-depth < 10 requires 4:2:2 color format

-> would be nice if someone could clear up which profile bit depth combinations support which color samplings (in AV1 and aomenc in case they differ)

Wiki changes

FYI: The following changes were made to this repository's wiki:

These were made as the result of a recent automated defacement of publically writeable wikis.

compiline VLC for Android fails

compiling VLC traget arm64 ABI ...
somehow fals into compiling for an x86

In file included from
vlc-android/vlc/contrib/contrib-android-aarch64-linux-android/aom/aom_build/config/aom_dsp_rtcd.h:1721:

vlc-android/vlc/contrib/contrib-android-aarch64-linux-android/aom/aom_ports/x86.h:50:26: note:
expanded from macro 'cpuid'
: "=a"(ax), "=b"(bx), "=c"(cx), "=d"(dx)
^

vlc-android/vlc/contrib/contrib-android-aarch64-linux-android/aom/aom_ports/x86.h:192:3: error:
invalid output constraint '=a' in asm
cpuid(1, 0, reg_eax, reg_ebx, reg_ecx, reg_edx);
^

vlc-android/vlc/contrib/contrib-android-aarch64-linux-android/aom/aom_ports/x86.h:215:9: error:
invalid output constraint '=a' in asm
cpuid(7, 0, reg_eax, reg_ebx, reg_ecx, reg_edx);
^

vlc-android/vlc/contrib/contrib-android-aarch64-linux-android/aom/aom_ports/x86.h:233:38: error:
invalid output constraint '=a' in asm
asm volatile("rdtsc\n\t" : "=a"(tsc) :);
^

vlc-android/vlc/contrib/contrib-android-aarch64-linux-android/aom/aom_ports/x86.h:251:34: error:
invalid output constraint '=a' in asm
asm volatile("rdtsc" : "=a"(lo), "=d"(hi));
^
5 errors generated.

Patent troll warning

Sorry if this is the wrong place to post this, but ive recently seen this link

https://www.streamingmedia.com/Articles/News/Online-Video-News/Sisvel-Launches-Patent-Pools-for-VP9-and-AV1-130840.aspx

where company Sisvel is purported to be charging for license to AV1 product

this is concerning because it appears to be in direct contradiction of this statement:

AOMedia Video 1 (AV1) is an open, royalty-free video coding format

https://wikipedia.org/wiki/AV1

can someone please clarify - or point me to where a clarification could be found?

ppc_cpudetect.c:15:10: fatal error: asm/cputable.h: No such file or directory

PPC check is broken on macOS:

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_aom/aom/work/aom-3.5.0/aom_ports/ppc_cpudetect.c:15:10: fatal error: asm/cputable.h: No such file or directory
   15 | #include <asm/cputable.h>
      |          ^~~~~~~~~~~~~~~~
compilation terminated.

Segmentation fault in aomenc, can't find common factor

I appreciate that this is not as much information as you would like, but this is what I have, so I hope it helps.

$ time ~/build2/aomenc Input.y4m --width=720 --height=552 --fps=25000/1000 --passes=2 --lag-in-frames=25 --end-usage=vbr --target-bitrate=950 --threads=16 --cpu-used=3 --kf-min-dist=60 --buf-sz=2000 --maxsection-pct=200 --kf-max-dist=60 -o Output.webm
Pass 1/2 frame 147925/147926 30768608B 1664b/f 41600b/s 7659861 ms (19.31 fps)
Pass 2/2 frame 633/608 1792796B 8962660 ms 4.24 fpm [ETA 610:08:33] Segmentation fault

real 170m47.089s
user 118m19.541s
sys 18m1.843s
$

This crash appears to be tied to the input file or the settings, and not the particular build or version of aomenc, since it happened in exactly the same place with 2.01, and also after I recompiled the encoder with with 2.1.0rc1 from GIT, but only for these file/settings as I completed several 2+ hour streams at different resolutions prior to this crash.

I reviewed the original, and tightened up the crop just a little to alter the input slightly, and re-ran the encoder, and it still crashed in exactly the same place.

IE:-
$ffmpeg -i Input.mkv -vf "yadif, crop=716:550:2:12" Input.y4m
$ time ~/build2/aomenc Input.y4m --width=716 --height=550 --fps=25000/1000 --passes=2 --lag-in-frames=25 --end-usage=vbr --target-bitrate=950 --threads=16 --cpu-used=3 --kf-min-dist=60 --buf-sz=2000 --maxsection-pct=200 --kf-max-dist=60 -o Output.webm
Pass 1/2 frame 147925/147926 30768608B 1664b/f 41600b/s 5494870 ms (26.92 fps)
Pass 2/2 frame 633/608 1790326B 6218393 ms 6.11 fpm [ETA 423:20:37] Segmentation fault

real 115m19.786s
user 116m58.766s
sys 18m21.942s
$

I also changed the bitrate and saw the same result, yet I have another video which is almost identical, but has no issue... and I'm starting to wonder if it's some kind of system resource, as I've not tried to encode 4 streams concurrently before... unfortunately it will be several days before I can reduce the number running to test this. There's plenty of RAM and other obvious resources available.

Will continue to test different configuration.

The package was compiled with the following options:-
cmake path/to/aom -DENABLE_CCACHE=1 -DCONFIG_AV1_ENCODER=1 -DBUILD_SHARED_LIBS=1

$ gcc --version
gcc (Ubuntu 10.2.1-20ubuntu1) 10.2.1 20210220
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Unable to compile it on Ubuntu 18.04

I have tried to compile it on Ubuntu 18.04 LTS stable and this is the output:

$ make
[  1%] Built target aom_rtcd
[  2%] Built target aom_av1_common_ssse3_intrinsics
[  3%] Built target aom_av1_encoder_sse2_intrinsics
[  4%] Built target webm
[ 12%] Built target aom_av1_common
[ 17%] Built target yuv
[ 19%] Built target aom_dsp_encoder_avx2_intrinsics
[ 20%] Built target aom_dsp_encoder_sse4_1_intrinsics
[ 30%] Built target aom_av1_encoder
[ 31%] Built target aom_dsp_common_sse4_1_intrinsics
[ 33%] Built target aom_av1_common_sse4_intrinsics
[ 34%] Built target aom_common_app_util
[ 34%] Built target aom_decoder_app_util
[ 35%] Built target aom_dsp_common_sse2_intrinsics
[ 37%] Built target aom_av1_decoder
[ 38%] Built target aom_dsp_decoder
[ 39%] Built target aom_dsp_common_avx2_intrinsics
[ 42%] Built target aom_dsp_encoder
[ 43%] Built target aom_scale
[ 43%] Built target aom_av1_encoder_ssse3_intrinsics
[ 45%] Built target aom_dsp_encoder_sse2_intrinsics
[ 47%] Built target aom_dsp_common
[ 48%] Built target aom_dsp_common_ssse3_intrinsics
[ 49%] Built target aom_av1_common_sse2_intrinsics
[ 50%] Built target aom_util
[ 51%] Built target aom_av1_encoder_sse4_intrinsics
[ 52%] Built target aom_av1_encoder_avx2_intrinsics
[ 52%] Built target aom_av1_common_avx2_intrinsics
[ 52%] Built target aom_mem
[ 53%] Built target aom_dsp_encoder_ssse3_intrinsics
[ 54%] Built target aom_dsp
[ 63%] Built target aom
[ 64%] Linking CXX executable examples/decode_with_drops
/usr/bin/x86_64-linux-gnu-ld: libaom.a(fwd_txfm_ssse3_x86_64.asm.o): relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/x86_64-linux-gnu-ld: libaom.a(quantize_ssse3_x86_64.asm.o): relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/x86_64-linux-gnu-ld: libaom.a(subpel_variance_sse2.asm.o): relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/x86_64-linux-gnu-ld: libaom.a(highbd_subpel_variance_impl_sse2.asm.o): relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIC
/usr/bin/x86_64-linux-gnu-ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
CMakeFiles/decode_with_drops.dir/build.make:155: recipe for target 'examples/decode_with_drops' failed
make[2]: *** [examples/decode_with_drops] Error 1
CMakeFiles/Makefile2:936: recipe for target 'CMakeFiles/decode_with_drops.dir/all' failed
make[1]: *** [CMakeFiles/decode_with_drops.dir/all] Error 2
Makefile:129: recipe for target 'all' failed
make: *** [all] Error 2

documentation, missing defaults/ranges

Would be nice if the help would also include defaults and ranges for:

--resize-mode=<arg>        	Frame resize mode
--resize-denominator=<arg> 	Frame resize denominator
--resize-kf-denominator=<ar	Frame resize keyframe denominator
--superres-mode=<arg>      	Frame super-resolution mode
--superres-denominator=<arg	Frame super-resolution denominator
--superres-kf-denominator=<	Frame super-resolution keyframe denominator
--superres-qthresh=<arg>   	Frame super-resolution qindex threshold
--superres-kf-qthresh=<arg>	Frame super-resolution keyframe qindex threshold
--min-q=<arg>              	Minimum (best) quantizer
--max-q=<arg>              	Maximum (worst) quantizer
--undershoot-pct=<arg>     	Datarate undershoot (min) target (%)
--overshoot-pct=<arg>      	Datarate overshoot (max) target (%)
--buf-sz=<arg>             	Client buffer size (ms)
--buf-initial-sz=<arg>     	Client initial buffer size (ms)
--buf-optimal-sz=<arg>     	Client optimal buffer size (ms)
--minsection-pct=<arg>     	GOP min bitrate (% of target)
--maxsection-pct=<arg>     	GOP max bitrate (% of target)
--enable-fwd-kf=<arg>      	Enable forward reference keyframes
--kf-min-dist=<arg>        	Minimum keyframe interval (frames)
--kf-max-dist=<arg>        	Maximum keyframe interval (frames)
--auto-alt-ref=<arg>       	Enable automatic alt reference frames
--static-thresh=<arg>      	Motion detection threshold
-tile-columns=<arg>       	Number of tile columns to use, log2
--tile-rows=<arg>          	Number of tile rows to use, log2
--arnr-maxframes=<arg>     	AltRef max frames (0..15)
--arnr-strength=<arg>      	AltRef filter strength (0..6)
--max-intra-rate=<arg>     	Max I-frame bitrate (pct)
--max-inter-rate=<arg>     	Max P-frame bitrate (pct)
--gf-cbr-boost=<arg>       	Boost for Golden Frame in CBR mode (pct)
--max-partition-size=<arg> 	Set max partition size (4:4x4, 8:8x8, 16:16x16, 32:32x32, 64:64x64, 128:128x128)
--reduced-tx-type-set=<arg>	Use reduced set of transform types
--use-intra-dct-only=<arg> 	Use DCT only for INTRA modes
--use-inter-dct-only=<arg> 	Use DCT only for INTER modes
--use-intra-default-tx-only	Use Default-transform only for INTRA modes
--quant-b-adapt=<arg>      	Use adaptive quantize_b
-coeff-cost-upd-freq=<arg>	Update freq for coeff costs0: SB, 1: SB Row per Tile, 2: Tile
--mode-cost-upd-freq=<arg> 	Update freq for mode costs0: SB, 1: SB Row per Tile, 2: Tile
--mv-cost-upd-freq=<arg>   	Update freq for mv costs0: SB, 1: SB Row per Tile, 2: Tile, 3: Off
--noise-sensitivity=<arg>  	Noise sensitivity (frames to blur)
--color-primaries=<arg>    	Color primaries (CICP) of input content: bt709, unspecified, bt601, bt470m, bt470bg, smpte240, film, bt2020, xyz, smpte431, smpte432, ebu3213
--transfer-characteristics=	Transfer characteristics (CICP) of input content: unspecified, bt709, bt470m, bt470bg, bt601, smpte240, lin, log100, log100sq10, iec61966, bt1361, srgb, bt2020-10bit, bt2020-12bit, smpte2084, hlg, smpte428
--matrix-coefficients=<arg>	Matrix coefficients (CICP) of input content:identity, bt709, unspecified, fcc73, bt470bg, bt601, smpte240, ycgco, bt2020ncl, bt2020cl, smpte2085, chromncl, chromcl, ictcp
--chroma-sample-position=<a	The chroma sample position when chroma 4:2:0 is signaled: unknown, vertical, colocated
--sb-size=<arg>            	Superblock size to use  dynamic, 64, 128
--timing-info=<arg>        	Signal timing info in the bitstream (model unly works for no hidden frames, no super-res yet): unspecified, constant, model
--denoise-noise-level=<arg>	Amount of noise (from 0 = don't denoise, to 50)
--sframe-dist=<arg>        	S-Frame interval (frames)
--sframe-mode=<arg>        	S-Frame insertion mode (1..2)
--annexb=<arg>             	Save as Annex-B

[i386] Build system does not check whether AVX are actually supported by assembler

Tried to build aom on i386 (Core Duo) with GCC. Build misdetects AVX as supported and that breaks it:

[  7%] Building CXX object CMakeFiles/yuv.dir/third_party/libyuv/source/row_gcc.cc.o
/opt/local/bin/g++-mp-13  -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_aom/aom/work/aom-3.8.1 -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_aom/aom/work/build -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_aom/aom/work/aom-3.8.1/apps -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_aom/aom/work/aom-3.8.1/common -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_aom/aom/work/aom-3.8.1/examples -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_aom/aom/work/aom-3.8.1/stats -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_aom/aom/work/aom-3.8.1/third_party/libyuv/include -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_aom/aom/work/aom-3.8.1/third_party/libwebm -pipe -Os -DNDEBUG -isystem/opt/local/include/LegacySupport -I/opt/local/include -D_GLIBCXX_USE_CXX11_ABI=0  -std=c++11 -Wall -Wdisabled-optimization -Wextra -Wextra-semi -Wfloat-conversion -Wformat=2 -Wlogical-op -Wpointer-arith -Wshadow -Wsign-compare -Wtype-limits -Wuninitialized -Wunused -Wvla -Wc++14-extensions -Wc++17-extensions -Wc++20-extensions -Wstack-usage=240000 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -arch i386 -mmacosx-version-min=10.6 -fPIC -Wno-shadow -MD -MT CMakeFiles/yuv.dir/third_party/libyuv/source/row_gcc.cc.o -MF CMakeFiles/yuv.dir/third_party/libyuv/source/row_gcc.cc.o.d -o CMakeFiles/yuv.dir/third_party/libyuv/source/row_gcc.cc.o -c /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_aom/aom/work/aom-3.8.1/third_party/libyuv/source/row_gcc.cc
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_aom/aom/work/aom-3.8.1/third_party/libyuv/source/row_gcc.cc:557:no such instruction: `vbroadcastf128 __ZN6libyuvL23kShuffleMaskARGBToRGB24E-L7$pb(%eax),%ymm6'
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_aom/aom/work/aom-3.8.1/third_party/libyuv/source/row_gcc.cc:558:no such instruction: `vmovdqa __ZN6libyuvL15kPermdRGB24_AVXE-L7$pb(%eax),%ymm7'
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_aom/aom/work/aom-3.8.1/third_party/libyuv/source/row_gcc.cc:560:no such instruction: `vmovdqu (%edx),%ymm0'
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_aom/aom/work/aom-3.8.1/third_party/libyuv/source/row_gcc.cc:561:no such instruction: `vmovdqu 0x20(%edx),%ymm1'
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_aom/aom/work/aom-3.8.1/third_party/libyuv/source/row_gcc.cc:562:no such instruction: `vmovdqu 0x40(%edx),%ymm2'
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_aom/aom/work/aom-3.8.1/third_party/libyuv/source/row_gcc.cc:563:no such instruction: `vmovdqu 0x60(%edx),%ymm3'
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_multimedia_aom/aom/work/aom-3.8.1/third_party/libyuv/source/row_gcc.cc:565:no such instruction: `vpshufb %ymm6,%ymm0,%ymm0'

Configure checks for flags support, but that is not sufficient; compiler may support flags, but assembler may not support instruction set.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.