1README.md {#LREADME} 2========= 3# AV1 Codec Library 4 5## Contents 61. [Building the lib and applications](#building-the-library-and-applications) 7 - [Prerequisites](#prerequisites) 8 - [Get the code](#get-the-code) 9 - [Basics](#basic-build) 10 - [Configuration options](#configuration-options) 11 - [Dylib builds](#dylib-builds) 12 - [Debugging](#debugging) 13 - [Cross compiling](#cross-compiling) 14 - [Sanitizer support](#sanitizers) 15 - [MSVC builds](#microsoft-visual-studio-builds) 16 - [Xcode builds](#xcode-builds) 17 - [Emscripten builds](#emscripten-builds) 18 - [Extra Build Flags](#extra-build-flags) 19 - [Build with VMAF support](#build-with-vmaf) 202. [Testing the library](#testing-the-av1-codec) 21 - [Basics](#testing-basics) 22 - [Unit tests](#1_unit-tests) 23 - [Example tests](#2_example-tests) 24 - [Encoder tests](#3_encoder-tests) 25 - [IDE hosted tests](#ide-hosted-tests) 26 - [Downloading test data](#downloading-the-test-data) 27 - [Adding a new test data file](#adding-a-new-test-data-file) 28 - [Additional test data](#additional-test-data) 29 - [Sharded testing](#sharded-testing) 30 - [Running tests directly](#1_running-test_libaom-directly) 31 - [Running tests via CMake](#2_running-the-tests-via-the-cmake-build) 323. [Coding style](#coding-style) 334. [Submitting patches](#submitting-patches) 34 - [Login cookie](#login-cookie) 35 - [Contributor agreement](#contributor-agreement) 36 - [Testing your code](#testing-your-code) 37 - [Commit message hook](#commit-message-hook) 38 - [Upload your change](#upload-your-change) 39 - [Incorporating Reviewer Comments](#incorporating-reviewer-comments) 40 - [Submitting your change](#submitting-your-change) 41 - [Viewing change status](#viewing-the-status-of-uploaded-changes) 425. [Support](#support) 436. [Bug reports](#bug-reports) 44 45## Building the library and applications {#building-the-library-and-applications} 46 47### Prerequisites {#prerequisites} 48 49 1. [CMake](https://cmake.org) version 3.6 or higher. 50 2. [Git](https://git-scm.com/). 51 3. [Perl](https://www.perl.org/). 52 4. For x86 targets, [yasm](http://yasm.tortall.net/), which is preferred, or a 53 recent version of [nasm](http://www.nasm.us/). If you download yasm with 54 the intention to work with Visual Studio, please download win32.exe or 55 win64.exe and rename it into yasm.exe. DO NOT download or use vsyasm.exe. 56 5. Building the documentation requires 57 [doxygen version 1.8.10 or newer](http://doxygen.org). 58 6. Building the unit tests requires [Python](https://www.python.org/). 59 7. Emscripten builds require the portable 60 [EMSDK](https://kripken.github.io/emscripten-site/index.html). 61 62### Get the code {#get-the-code} 63 64The AV1 library source code is stored in the Alliance for Open Media Git 65repository: 66 67~~~ 68 $ git clone https://aomedia.googlesource.com/aom 69 # By default, the above command stores the source in the aom directory: 70 $ cd aom 71~~~ 72 73### Basic build {#basic-build} 74 75CMake replaces the configure step typical of many projects. Running CMake will 76produce configuration and build files for the currently selected CMake 77generator. For most systems the default generator is Unix Makefiles. The basic 78form of a makefile build is the following: 79 80~~~ 81 $ cmake path/to/aom 82 $ make 83~~~ 84 85The above will generate a makefile build that produces the AV1 library and 86applications for the current host system after the make step completes 87successfully. The compiler chosen varies by host platform, but a general rule 88applies: On systems where cc and c++ are present in $PATH at the time CMake is 89run the generated build will use cc and c++ by default. 90 91### Configuration options {#configuration-options} 92 93The AV1 codec library has a great many configuration options. These come in two 94varieties: 95 96 1. Build system configuration options. These have the form `ENABLE_FEATURE`. 97 2. AV1 codec configuration options. These have the form `CONFIG_FEATURE`. 98 99Both types of options are set at the time CMake is run. The following example 100enables ccache and disables the AV1 encoder: 101 102~~~ 103 $ cmake path/to/aom -DENABLE_CCACHE=1 -DCONFIG_AV1_ENCODER=0 104 $ make 105~~~ 106 107The available configuration options are too numerous to list here. Build system 108configuration options can be found at the top of the CMakeLists.txt file found 109in the root of the AV1 repository, and AV1 codec configuration options can 110currently be found in the file `build/cmake/aom_config_defaults.cmake`. 111 112### Dylib builds {#dylib-builds} 113 114A dylib (shared object) build of the AV1 codec library can be enabled via the 115CMake built in variable `BUILD_SHARED_LIBS`: 116 117~~~ 118 $ cmake path/to/aom -DBUILD_SHARED_LIBS=1 119 $ make 120~~~ 121 122This is currently only supported on non-Windows targets. 123 124### Debugging {#debugging} 125 126Depending on the generator used there are multiple ways of going about 127debugging AV1 components. For single configuration generators like the Unix 128Makefiles generator, setting `CMAKE_BUILD_TYPE` to Debug is sufficient: 129 130~~~ 131 $ cmake path/to/aom -DCMAKE_BUILD_TYPE=Debug 132~~~ 133 134For Xcode, mainly because configuration controls for Xcode builds are buried two 135configuration windows deep and must be set for each subproject within the Xcode 136IDE individually, `CMAKE_CONFIGURATION_TYPES` should be set to Debug: 137 138~~~ 139 $ cmake path/to/aom -G Xcode -DCMAKE_CONFIGURATION_TYPES=Debug 140~~~ 141 142For Visual Studio the in-IDE configuration controls should be used. Simply set 143the IDE project configuration to Debug to allow for stepping through the code. 144 145In addition to the above it can sometimes be useful to debug only C and C++ 146code. To disable all assembly code and intrinsics set `AOM_TARGET_CPU` to 147generic at generation time: 148 149~~~ 150 $ cmake path/to/aom -DAOM_TARGET_CPU=generic 151~~~ 152 153### Cross compiling {#cross-compiling} 154 155For the purposes of building the AV1 codec and applications and relative to the 156scope of this guide, all builds for architectures differing from the native host 157architecture will be considered cross compiles. The AV1 CMake build handles 158cross compiling via the use of toolchain files included in the AV1 repository. 159The toolchain files available at the time of this writing are: 160 161 - arm64-ios.cmake 162 - arm64-linux-gcc.cmake 163 - arm64-mingw-gcc.cmake 164 - armv7-ios.cmake 165 - armv7-linux-gcc.cmake 166 - armv7-mingw-gcc.cmake 167 - armv7s-ios.cmake 168 - mips32-linux-gcc.cmake 169 - mips64-linux-gcc.cmake 170 - x86-ios-simulator.cmake 171 - x86-linux.cmake 172 - x86-macos.cmake 173 - x86-mingw-gcc.cmake 174 - x86\_64-ios-simulator.cmake 175 - x86\_64-mingw-gcc.cmake 176 177The following example demonstrates use of the x86-macos.cmake toolchain file on 178a x86\_64 MacOS host: 179 180~~~ 181 $ cmake path/to/aom \ 182 -DCMAKE_TOOLCHAIN_FILE=path/to/aom/build/cmake/toolchains/x86-macos.cmake 183 $ make 184~~~ 185 186To build for an unlisted target creation of a new toolchain file is the best 187solution. The existing toolchain files can be used a starting point for a new 188toolchain file since each one exposes the basic requirements for toolchain files 189as used in the AV1 codec build. 190 191As a temporary work around an unoptimized AV1 configuration that builds only C 192and C++ sources can be produced using the following commands: 193 194~~~ 195 $ cmake path/to/aom -DAOM_TARGET_CPU=generic 196 $ make 197~~~ 198 199In addition to the above it's important to note that the toolchain files 200suffixed with gcc behave differently than the others. These toolchain files 201attempt to obey the $CROSS environment variable. 202 203### Sanitizers {#sanitizers} 204 205Sanitizer integration is built-in to the CMake build system. To enable a 206sanitizer, add `-DSANITIZE=<type>` to the CMake command line. For example, to 207enable address sanitizer: 208 209~~~ 210 $ cmake path/to/aom -DSANITIZE=address 211 $ make 212~~~ 213 214Sanitizers available vary by platform, target, and compiler. Consult your 215compiler documentation to determine which, if any, are available. 216 217### Microsoft Visual Studio builds {#microsoft-visual-studio-builds} 218 219Building the AV1 codec library in Microsoft Visual Studio is supported. Visual 220Studio 2017 (15.0) or later is required. The following example demonstrates 221generating projects and a solution for the Microsoft IDE: 222 223~~~ 224 # This does not require a bash shell; Command Prompt (cmd.exe) is fine. 225 # This assumes the build host is a Windows x64 computer. 226 227 # To build with Visual Studio 2019 for the x64 target: 228 $ cmake path/to/aom -G "Visual Studio 16 2019" 229 $ cmake --build . 230 231 # To build with Visual Studio 2019 for the 32-bit x86 target: 232 $ cmake path/to/aom -G "Visual Studio 16 2019" -A Win32 233 $ cmake --build . 234 235 # To build with Visual Studio 2017 for the x64 target: 236 $ cmake path/to/aom -G "Visual Studio 15 2017" -T host=x64 -A x64 237 $ cmake --build . 238 239 # To build with Visual Studio 2017 for the 32-bit x86 target: 240 $ cmake path/to/aom -G "Visual Studio 15 2017" -T host=x64 241 $ cmake --build . 242~~~ 243 244NOTE: The build system targets Windows 7 or later by compiling files with 245`-D_WIN32_WINNT=0x0601`. 246 247### Xcode builds {#xcode-builds} 248 249Building the AV1 codec library in Xcode is supported. The following example 250demonstrates generating an Xcode project: 251 252~~~ 253 $ cmake path/to/aom -G Xcode 254~~~ 255 256### Emscripten builds {#emscripten-builds} 257 258Building the AV1 codec library with Emscripten is supported. Typically this is 259used to hook into the AOMAnalyzer GUI application. These instructions focus on 260using the inspector with AOMAnalyzer, but all tools can be built with 261Emscripten. 262 263It is assumed here that you have already downloaded and installed the EMSDK, 264installed and activated at least one toolchain, and setup your environment 265appropriately using the emsdk\_env script. 266 2671. Download [AOMAnalyzer](https://people.xiph.org/~mbebenita/analyzer/). 268 2692. Configure the build: 270 271~~~ 272 $ cmake path/to/aom \ 273 -DENABLE_CCACHE=1 \ 274 -DAOM_TARGET_CPU=generic \ 275 -DENABLE_DOCS=0 \ 276 -DENABLE_TESTS=0 \ 277 -DCONFIG_ACCOUNTING=1 \ 278 -DCONFIG_INSPECTION=1 \ 279 -DCONFIG_MULTITHREAD=0 \ 280 -DCONFIG_RUNTIME_CPU_DETECT=0 \ 281 -DCONFIG_WEBM_IO=0 \ 282 -DCMAKE_TOOLCHAIN_FILE=path/to/emsdk-portable/.../Emscripten.cmake 283~~~ 284 2853. Build it: run make if that's your generator of choice: 286 287~~~ 288 $ make inspect 289~~~ 290 2914. Run the analyzer: 292 293~~~ 294 # inspect.js is in the examples sub directory of the directory in which you 295 # executed cmake. 296 $ path/to/AOMAnalyzer path/to/examples/inspect.js path/to/av1/input/file 297~~~ 298 299### Extra build flags {#extra-build-flags} 300 301Three variables allow for passing of additional flags to the build system. 302 303- AOM\_EXTRA\_C\_FLAGS 304- AOM\_EXTRA\_CXX\_FLAGS 305- AOM\_EXTRA\_EXE\_LINKER\_FLAGS 306 307The build system attempts to ensure the flags passed through the above variables 308are passed to tools last in order to allow for override of default behavior. 309These flags can be used, for example, to enable asserts in a release build: 310 311~~~ 312 $ cmake path/to/aom \ 313 -DCMAKE_BUILD_TYPE=Release \ 314 -DAOM_EXTRA_C_FLAGS=-UNDEBUG \ 315 -DAOM_EXTRA_CXX_FLAGS=-UNDEBUG 316~~~ 317 318### Build with VMAF support {#build-with-vmaf} 319 320After installing 321[libvmaf.a](https://github.com/Netflix/vmaf/tree/master/libvmaf), 322you can use it with the encoder: 323 324~~~ 325 $ cmake path/to/aom -DCONFIG_TUNE_VMAF=1 326~~~ 327 328Please note that the default VMAF model 329("/usr/local/share/model/vmaf_v0.6.1.json") 330will be used unless you set the following flag when running the encoder: 331 332~~~ 333 # --vmaf-model-path=path/to/model 334~~~ 335 336## Testing the AV1 codec {#testing-the-av1-codec} 337 338### Testing basics {#testing-basics} 339 340There are several methods of testing the AV1 codec. All of these methods require 341the presence of the AV1 source code and a working build of the AV1 library and 342applications. 343 344#### 1. Unit tests: {#1_unit-tests} 345 346The unit tests can be run at build time: 347 348~~~ 349 # Before running the make command the LIBAOM_TEST_DATA_PATH environment 350 # variable should be set to avoid downloading the test files to the 351 # cmake build configuration directory. 352 $ cmake path/to/aom 353 # Note: The AV1 CMake build creates many test targets. Running make 354 # with multiple jobs will speed up the test run significantly. 355 $ make runtests 356~~~ 357 358#### 2. Example tests: {#2_example-tests} 359 360The example tests require a bash shell and can be run in the following manner: 361 362~~~ 363 # See the note above about LIBAOM_TEST_DATA_PATH above. 364 $ cmake path/to/aom 365 $ make 366 # It's best to build the testdata target using many make jobs. 367 # Running it like this will verify and download (if necessary) 368 # one at a time, which takes a while. 369 $ make testdata 370 $ path/to/aom/test/examples.sh --bin-path examples 371~~~ 372 373#### 3. Encoder tests: {#3_encoder-tests} 374 375When making a change to the encoder run encoder tests to confirm that your 376change has a positive or negligible impact on encode quality. When running these 377tests the build configuration should be changed to enable internal encoder 378statistics: 379 380~~~ 381 $ cmake path/to/aom -DCONFIG_INTERNAL_STATS=1 382 $ make 383~~~ 384 385The repository contains scripts intended to make running these tests as simple 386as possible. The following example demonstrates creating a set of baseline clips 387for comparison to results produced after making your change to libaom: 388 389~~~ 390 # This will encode all Y4M files in the current directory using the 391 # settings specified to create the encoder baseline statistical data: 392 $ cd path/to/test/inputs 393 # This command line assumes that run_encodes.sh, its helper script 394 # best_encode.sh, and the aomenc you intend to test are all within a 395 # directory in your PATH. 396 $ run_encodes.sh 200 500 50 baseline 397~~~ 398 399After making your change and creating the baseline clips, you'll need to run 400encodes that include your change(s) to confirm that things are working as 401intended: 402 403~~~ 404 # This will encode all Y4M files in the current directory using the 405 # settings specified to create the statistical data for your change: 406 $ cd path/to/test/inputs 407 # This command line assumes that run_encodes.sh, its helper script 408 # best_encode.sh, and the aomenc you intend to test are all within a 409 # directory in your PATH. 410 $ run_encodes.sh 200 500 50 mytweak 411~~~ 412 413After creating both data sets you can use `test/visual_metrics.py` to generate a 414report that can be viewed in a web browser: 415 416~~~ 417 $ visual_metrics.py metrics_template.html "*stt" baseline mytweak \ 418 > mytweak.html 419~~~ 420 421You can view the report by opening mytweak.html in a web browser. 422 423 424### IDE hosted tests {#ide-hosted-tests} 425 426By default the generated projects files created by CMake will not include the 427runtests and testdata rules when generating for IDEs like Microsoft Visual 428Studio and Xcode. This is done to avoid intolerably long build cycles in the 429IDEs-- IDE behavior is to build all targets when selecting the build project 430options in MSVS and Xcode. To enable the test rules in IDEs the 431`ENABLE_IDE_TEST_HOSTING` variable must be enabled at CMake generation time: 432 433~~~ 434 # This example uses Xcode. To get a list of the generators 435 # available, run cmake with the -G argument missing its 436 # value. 437 $ cmake path/to/aom -DENABLE_IDE_TEST_HOSTING=1 -G Xcode 438~~~ 439 440### Downloading the test data {#downloading-the-test-data} 441 442The fastest and easiest way to obtain the test data is to use CMake to generate 443a build using the Unix Makefiles generator, and then to build only the testdata 444rule. By default the test files will be downloaded to the current directory. The 445`LIBAOM_TEST_DATA_PATH` environment variable can be used to set a 446custom one. 447 448~~~ 449 $ cmake path/to/aom -G "Unix Makefiles" 450 # 28 is used because there are 28 test files as of this writing. 451 $ make -j28 testdata 452~~~ 453 454The above make command will only download and verify the test data. 455 456### Adding a new test data file {#adding-a-new-test-data-file} 457 458First, add the new test data file to the `aom-test-data` bucket of the 459`aomedia-testing` project on Google Cloud Platform. You may need to ask someone 460with the necessary access permissions to do this for you. 461 462NOTE: When a new test data file is added to the `aom-test-data` bucket, its 463"Public access" is initially "Not public". We need to change its 464"Public access" to "Public" by using the following 465[`gsutil`](https://cloud.google.com/storage/docs/gsutil_install) command: 466~~~ 467 $ gsutil acl ch -g all:R gs://aom-test-data/test-data-file-name 468~~~ 469This command grants the `AllUsers` group READ access to the file named 470"test-data-file-name" in the `aom-test-data` bucket. 471 472Once the new test data file has been added to `aom-test-data`, create a CL to 473add the name of the new test data file to `test/test_data_util.cmake` and add 474the SHA1 checksum of the new test data file to `test/test-data.sha1`. (The SHA1 475checksum of a file can be calculated by running the `sha1sum` command on the 476file.) 477 478### Additional test data {#additional-test-data} 479 480The test data mentioned above is strictly intended for unit testing. 481 482Additional input data for testing the encoder can be obtained from: 483https://media.xiph.org/video/derf/ 484 485### Sharded testing {#sharded-testing} 486 487The AV1 codec library unit tests are built upon gtest which supports sharding of 488test jobs. Sharded test runs can be achieved in a couple of ways. 489 490#### 1. Running test\_libaom directly: {#1_running-test_libaom-directly} 491 492~~~ 493 # Set the environment variable GTEST_TOTAL_SHARDS to control the number of 494 # shards. 495 $ export GTEST_TOTAL_SHARDS=10 496 # (GTEST shard indexing is 0 based). 497 $ seq 0 $(( $GTEST_TOTAL_SHARDS - 1 )) \ 498 | xargs -n 1 -P 0 -I{} env GTEST_SHARD_INDEX={} ./test_libaom 499~~~ 500 501To create a test shard for each CPU core available on the current system set 502`GTEST_TOTAL_SHARDS` to the number of CPU cores on your system minus one. 503 504#### 2. Running the tests via the CMake build: {#2_running-the-tests-via-the-cmake-build} 505 506~~~ 507 # For IDE based builds, ENABLE_IDE_TEST_HOSTING must be enabled. See 508 # the IDE hosted tests section above for more information. If the IDE 509 # supports building targets concurrently tests will be sharded by default. 510 511 # For make and ninja builds the -j parameter controls the number of shards 512 # at test run time. This example will run the tests using 10 shards via 513 # make. 514 $ make -j10 runtests 515~~~ 516 517The maximum number of test targets that can run concurrently is determined by 518the number of CPUs on the system where the build is configured as detected by 519CMake. A system with 24 cores can run 24 test shards using a value of 24 with 520the `-j` parameter. When CMake is unable to detect the number of cores 10 shards 521is the default maximum value. 522 523## Coding style {#coding-style} 524 525We are using the Google C Coding Style defined by the 526[Google C++ Style Guide](https://google.github.io/styleguide/cppguide.html). 527 528The coding style used by this project is enforced with clang-format using the 529configuration contained in the 530[.clang-format](https://chromium.googlesource.com/webm/aom/+/master/.clang-format) 531file in the root of the repository. 532 533You can download clang-format using your system's package manager, or directly 534from [llvm.org](http://llvm.org/releases/download.html). You can also view the 535[documentation](https://clang.llvm.org/docs/ClangFormat.html) on llvm.org. 536Output from clang-format varies by clang-format version, for best results your 537version should match the one used on Jenkins. You can find the clang-format 538version by reading the comment in the `.clang-format` file linked above. 539 540Before pushing changes for review you can format your code with: 541 542~~~ 543 # Apply clang-format to modified .c, .h and .cc files 544 $ clang-format -i --style=file \ 545 $(git diff --name-only --diff-filter=ACMR '*.[hc]' '*.cc') 546~~~ 547 548Check the .clang-format file for the version used to generate it if there is any 549difference between your local formatting and the review system. 550 551Some Git installations have clang-format integration. Here are some examples: 552 553~~~ 554 # Apply clang-format to all staged changes: 555 $ git clang-format 556 557 # Clang format all staged and unstaged changes: 558 $ git clang-format -f 559 560 # Clang format all staged and unstaged changes interactively: 561 $ git clang-format -f -p 562~~~ 563 564## Submitting patches {#submitting-patches} 565 566We manage the submission of patches using the 567[Gerrit](https://www.gerritcodereview.com/) code review tool. This tool 568implements a workflow on top of the Git version control system to ensure that 569all changes get peer reviewed and tested prior to their distribution. 570 571### Login cookie {#login-cookie} 572 573Browse to [AOMedia Git index](https://aomedia.googlesource.com/) and login with 574your account (Gmail credentials, for example). Next, follow the 575`Generate Password` Password link at the top of the page. You’ll be given 576instructions for creating a cookie to use with our Git repos. 577 578### Contributor agreement {#contributor-agreement} 579 580You will be required to execute a 581[contributor agreement](http://aomedia.org/license) to ensure that the AOMedia 582Project has the right to distribute your changes. 583 584### Testing your code {#testing-your-code} 585 586The testing basics are covered in the [testing section](#testing-the-av1-codec) 587above. 588 589In addition to the local tests, many more (e.g. asan, tsan, valgrind) will run 590through Jenkins instances upon upload to gerrit. 591 592### Commit message hook {#commit-message-hook} 593 594Gerrit requires that each submission include a unique Change-Id. You can assign 595one manually using git commit --amend, but it’s easier to automate it with the 596commit-msg hook provided by Gerrit. 597 598Copy commit-msg to the `.git/hooks` directory of your local repo. Here's an 599example: 600 601~~~ 602 $ curl -Lo aom/.git/hooks/commit-msg https://chromium-review.googlesource.com/tools/hooks/commit-msg 603 604 # Next, ensure that the downloaded commit-msg script is executable: 605 $ chmod u+x aom/.git/hooks/commit-msg 606~~~ 607 608See the Gerrit 609[documentation](https://gerrit-review.googlesource.com/Documentation/user-changeid.html) 610for more information. 611 612### Upload your change {#upload-your-change} 613 614The command line to upload your patch looks like this: 615 616~~~ 617 $ git push https://aomedia-review.googlesource.com/aom HEAD:refs/for/master 618~~~ 619 620### Incorporating reviewer comments {#incorporating-reviewer-comments} 621 622If you previously uploaded a change to Gerrit and the Approver has asked for 623changes, follow these steps: 624 6251. Edit the files to make the changes the reviewer has requested. 6262. Recommit your edits using the --amend flag, for example: 627 628~~~ 629 $ git commit -a --amend 630~~~ 631 6323. Use the same git push command as above to upload to Gerrit again for another 633 review cycle. 634 635In general, you should not rebase your changes when doing updates in response to 636review. Doing so can make it harder to follow the evolution of your change in 637the diff view. 638 639### Submitting your change {#submitting-your-change} 640 641Once your change has been Approved and Verified, you can “submit” it through the 642Gerrit UI. This will usually automatically rebase your change onto the branch 643specified. 644 645Sometimes this can’t be done automatically. If you run into this problem, you 646must rebase your changes manually: 647 648~~~ 649 $ git fetch 650 $ git rebase origin/branchname 651~~~ 652 653If there are any conflicts, resolve them as you normally would with Git. When 654you’re done, reupload your change. 655 656### Viewing the status of uploaded changes {#viewing-the-status-of-uploaded-changes} 657 658To check the status of a change that you uploaded, open 659[Gerrit](https://aomedia-review.googlesource.com/), sign in, and click My > 660Changes. 661 662## Support {#support} 663 664This library is an open source project supported by its community. Please 665please email aomediacodec@jointdevelopment.kavi.com for help. 666 667## Bug reports {#bug-reports} 668 669Bug reports can be filed in the Alliance for Open Media 670[issue tracker](https://bugs.chromium.org/p/aomedia/issues/list). 671