Specifically: without this fix, icecc + clang users will hit this clang bug when compiling stdatomics.h:
https://bugs.llvm.org/show_bug.cgi?id=26828
MozReview-Commit-ID: BJUN82HyXpF
--HG--
extra : rebase_source : 3f06d3401198de45240aa9f0c7c865e048f90b89
Specifically: without this fix, icecc + clang users will hit this clang bug when compiling stdatomics.h:
https://bugs.llvm.org/show_bug.cgi?id=26828
MozReview-Commit-ID: BJUN82HyXpF
--HG--
extra : rebase_source : dde23b590c3eebe9fb56dba2d81738059efde654
The system ffmpeg will be used instead or libvpx if not found.
MozReview-Commit-ID: GX5WWPOhPq9
--HG--
extra : rebase_source : 3eec2ee1bc3b66d88653b913d6d1b3ad1a5d5acd
It was incorrectly disabled during the last resync.
MozReview-Commit-ID: IP0T4Aq5Q2q
--HG--
extra : rebase_source : 77b3c792ddabfc5536b8c680010d0438a22699be
This mostly removes static strings declaration, replacing them with null pointers.
It does cause to switch to algorithms that are more geared toward space saving than speed gain. However, those are mostly in hash calculations, which the FLAC decoder doesn't use.
MozReview-Commit-ID: 6Kl6xxlBOnw
--HG--
extra : rebase_source : 051ac58cd1ed3b617684cda0bd4a93687bbc9924
Remove the VP8 and VP9 decoder and the subsequently unused functions.
This drops the size to libmozavcodec to around 1MB down from 4MB.
MozReview-Commit-ID: Ge57fauG35L
--HG--
extra : rebase_source : 3f667d7bf89036e9b059727d846af2504ce488b3
For now this is a C decoder only and FFmpeg isn't optimised to only decode flac (both vp8 and vp9 C decoders code is included, however they aren't enabled).
MozReview-Commit-ID: 7ulwvJDJqVg
--HG--
extra : rebase_source : 7090eee32ba394224ef8c3c1c31abf1543b69975
All the flac parser jobs are done by FlacDemuxer
MozReview-Commit-ID: L7VZG64gi52
--HG--
extra : rebase_source : 31cca110abd9f049923bf9d579cb2781ad38bedf
Structure of code was slightly modified so that it should be no longer necessary to re-generate the config_*.h files, greatly simplifying the resync process.
MozReview-Commit-ID: Ap6HpJAANT6
--HG--
extra : rebase_source : 52e5e3b9b2401644dc536d746219e5f3864c600c
This partially reverts commit e99d6caa3a3778c0bb1f2fa9f2b4222bba2eeafereverts
FFmpeg requires specific default values in AVCodecContext to be set. It is quickly becoming too complicated to track what those should be. AVOptions automatically set all the values to their default.
MozReview-Commit-ID: lDFeUvwTMg
--HG--
extra : rebase_source : 04c5df11e485bcbae4fbf41d8b5ed512316b4d1b
Since I am already poking around in ffvpxcommon.mozbuild's CFLAGS, also suppress these clang -Wvisibility and -Wstring-conversion warnings:
media/ffvpx/libavutil/dummy_funcs.c:83:34 [-Wvisibility] declaration of 'struct AVBufferRef' will not be visible outside of this function
media/ffvpx/libavutil/dummy_funcs.c:83:67 [-Wvisibility] declaration of 'struct AVFrame' will not be visible outside of this function
media/ffvpx/libavutil/utils.c:119:26 [-Wstring-conversion] implicit conversion turns string literal into bool: 'char [19]' to '_Bool'
And remove -Wno-logical-op-parentheses because clang does not currently report any -Wlogical-op-parentheses warnings for ffvpx.
MozReview-Commit-ID: 1kEwEHeD1PC
--HG--
extra : rebase_source : 133fa139f5389467919b88b96b8cbbf632bf002d
clang doesn't support gcc warning options -Wdiscarded-qualifiers or -Wmaybe-uninitialized in media/ffvpxcommon.mozbuild (added in bug 1369791), so only suppress those warnings for real gcc.
warning: unknown warning option '-Wno-discarded-qualifiers'; did you mean '-Wno-ignored-qualifiers'? [-Wunknown-warning-option]
warning: unknown warning option '-Wno-maybe-uninitialized'; did you mean '-Wno-uninitialized'? [-Wunknown-warning-option]
MozReview-Commit-ID: JUEqa6AN59x
--HG--
extra : rebase_source : 45e3c43d57e58119170700f7a339d1f2dfacff2c
extra : source : ee4a75aeb3585719700e1700746ce55984eba6fa
Both of these libraries call into libm for various reasons, but by
linking with the C++ compiler on most platforms, they never had to
declare their dependency on libm. Future changes will make these
libraries link with the C compiler, which won't automatically link with
libm, so we need to make the dependency explicit prior to that change.
clang-cl's <intrin.h> is not completely compatible with MSVC's
<intrin.h> by default, as clang-cl's version does not include all the
Intel intrinsic headers by default. clang-cl does this to make
<intrin.h> as small as possible, as this was shown to have significant
wins for compile time. Compiling with modules, however, includes all
the Intel intrinsic headers by default, so while upstream decides on a
general solution, we need to compile with modules locally.
MozReview-Commit-ID: BC1uureeQrx
--HG--
extra : rebase_source : f1127e909d0f9d3de99959933bcbc54af21fc6e2
