This will enable more warnings for Android ARM64 build.
The main purpose is to clean up clutter in the warnings config.
BUG=webrtc:6653
NOTRY=True
Review-Url: https://codereview.webrtc.org/2479533002
Cr-Commit-Position: refs/heads/master@{#14917}
Now that Chromium has taken libsrtp2, remove any compatibility bridge code in WebRTC that was only needed for libsrtp1.
Remove SRTP_RELATIVE_PATH now that Google's internal copy of libsrtp and the Chromium copy have the same directory structure.
Fix some include orderings per the Chromium C++ style guide.
Remove the `extern "C"` blocks now that the libsrtp headers include them (https://github.com/cisco/libsrtp/pull/195).
BUG=webrtc:6376
Review-Url: https://codereview.webrtc.org/2447893002
Cr-Commit-Position: refs/heads/master@{#14776}
This CL removes the use_objc_h264 flag. This means that the VideoToolbox
H264 encoder and decoder will always be built.
BUG=webrtc:4081
NOTRY=TRUE
Review-Url: https://codereview.webrtc.org/2366443003
Cr-Commit-Position: refs/heads/master@{#14372}
Currently, the aec_debug_dump buildflag can and is used to store data in the whole of
the audio processing module. Therefore a more appropriate name is apm_debug_dump which
also matches the names of the data dumping functionality. This CL makes that name change.
The CL also changes the WEBRTC_AEC_DEBUG_DUMP define to
WEBRTC_APM_DEBUG_DUMP == 1
Furthermore, this CL moves the buildflag to a more appropriate place.
BUG=webrtc:5298
Review-Url: https://codereview.webrtc.org/2300813004
Cr-Commit-Position: refs/heads/master@{#14026}
Conceptually, dummy audio file devices are a "platform", like
win/mac/linux, and so the conditional slots under
include_internal_audio_device. When enabled, use_dummy_audio_file_devices
disables whatever platform-specific audio layer would have been used and
turns on dummy file device support.
BUG=
Review-Url: https://codereview.webrtc.org/2250483002
Cr-Commit-Position: refs/heads/master@{#13790}
We plan to add junit tests running with Robolectric
so naming these files "apk" is slightly confusing.
NOTRY=True
Review-Url: https://codereview.webrtc.org/2020213002
Cr-Commit-Position: refs/heads/master@{#12971}
This is a reland of https://codereview.webrtc.org/1847013002/
with the following changes:
* _USE_32BIT_TIME_T is no longer set: it was removed from Chromium
in https://codereview.chromium.org/1862443003/.
Setting it in target_defaults was likely the reason to
remoting_unittests failing in the previous attempt to land this.
* Added define for FreeBSD platform.
* Added corresponding GN changes.
Copy the defines from the target_defaults section of Chromium's
src/third_party/libjingle.gyp into our webrtc/build/common.gypi
in order to ensure the same defines are used for the Chromium build
when removing the source listings in src/third_party/libjingle.gyp.
With this CL landed, it should be possible to replace them with
dependencies on:
* webrtc/api/api.gyp:libjingle_peerconnections
* webrtc/media/media.gyp:rtc_media
* webrtc/pc/pc.gyp:rtc_pc
* webrtc/pp2/p2p.gyp:rtc_p2p
* webrtc/libjingle/xmpp/xmpp.gyp:rtc_xmpp
Not ported (Windows specific):
* Precompiled headers (build/win_precompile.gypi):
since it only seems to offer a compile speedup. Will be landed
for all of WebRTC in separate CL.
BUG=webrtc:4256
NOTRY=True
Review-Url: https://codereview.webrtc.org/1924663003
Cr-Commit-Position: refs/heads/master@{#12959}
Chrome does not detect NEON instruction set at runtime in WebRTC code starting
with M50, which is now in Stable. Remove support for runtime detection for
simplicity.
The only remaining piece of Chrome that will continue to depend on runtime
detection is /net, where devices with _broken_ neon support are also detected,
and it is not configurable via GYP/GN.
BUG=522035
NOPRESUBMIT=true
Review-Url: https://codereview.webrtc.org/1955413003
Cr-Commit-Position: refs/heads/master@{#12778}
MJPEG capture is not used on Android. Therefore, disable jpeg support to
reduce libjingle_peerconnection_so file size by removing dependency to
libjpeg_turbo.
Also, remove unused build_libjpeg and rtc_build_libjpeg variables.
Review-Url: https://codereview.webrtc.org/1978243002
Cr-Commit-Position: refs/heads/master@{#12777}
We're now ready https://codereview.webrtc.org/1984503002/ downstream,
so make sure we can enable libevent but still choose which libevent
implementation to use. This follows the common pattern where an enable_
flag controls whether we should use the feature at all, whereas build_
controls if we should use the dependency from our DEPS file or
something else.
NOTRY=True
Review-Url: https://codereview.webrtc.org/1980003002
Cr-Commit-Position: refs/heads/master@{#12772}
New task queueing primitive for async tasks: TaskQueue.
TaskQueue is a new way to asynchronously execute tasks sequentially
in a thread safe manner with minimal locking. The implementation
uses OS supported APIs to do this that are compatible with async IO
notifications from things like sockets and files.
This class is a part of rtc_base_approved, so can be used by both
the webrtc and libjingle parts of the WebRTC library. Moving forward,
we can replace rtc::Thread and webrtc::ProcessThread with this implementation.
NOTE: It should not be assumed that all tasks that execute on a TaskQueue,
run on the same thread. E.g. on Mac and iOS, we use GCD dispatch queues
which means that tasks might execute on different threads depending on
what's the most efficient thing to do.
TBR=perkj@webrtc.org,phoglund@webrtc.org
Review-Url: https://codereview.webrtc.org/1984503002
Cr-Commit-Position: refs/heads/master@{#12749}
Wires up existing libvpx_build_vp9==0 GYP flag into WebRTC and makes VP9
optional. Change is GYP only for now since libvpx's GN files build VP9
unconditionally.
BUG=webrtc:5884
R=kjellander@webrtc.org
Review URL: https://codereview.webrtc.org/1970343002 .
Cr-Commit-Position: refs/heads/master@{#12741}
Reason for revert:
sigh. Have to revert again as there seems to have have been some change made for pnacl and CrOS.
Original issue's description:
> Reland of New task queueing primitive for async tasks: TaskQueue. (patchset #1 id:1 of https://codereview.webrtc.org/1935483002/ )
>
> New task queueing primitive for async tasks: TaskQueue.
> TaskQueue is a new way to asynchronously execute tasks sequentially
> in a thread safe manner with minimal locking. The implementation
> uses OS supported APIs to do this that are compatible with async IO
> notifications from things like sockets and files.
>
> This class is a part of rtc_base_approved, so can be used by both
> the webrtc and libjingle parts of the WebRTC library. Moving forward,
> we can replace rtc::Thread and webrtc::ProcessThread with this implementation.
>
> NOTE: It should not be assumed that all tasks that execute on a TaskQueue,
> run on the same thread. E.g. on Mac and iOS, we use GCD dispatch queues
> which means that tasks might execute on different threads depending on
> what's the most efficient thing to do.
>
> TBR=perkj@webrtc.org
>
> Committed: https://crrev.com/65d1f2aba216d077c6d22488f03e56984aef1c68
> Cr-Commit-Position: refs/heads/master@{#12737}
TBR=perkj@webrtc.org,phoglund@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.webrtc.org/1981573002
Cr-Commit-Position: refs/heads/master@{#12738}
New task queueing primitive for async tasks: TaskQueue.
TaskQueue is a new way to asynchronously execute tasks sequentially
in a thread safe manner with minimal locking. The implementation
uses OS supported APIs to do this that are compatible with async IO
notifications from things like sockets and files.
This class is a part of rtc_base_approved, so can be used by both
the webrtc and libjingle parts of the WebRTC library. Moving forward,
we can replace rtc::Thread and webrtc::ProcessThread with this implementation.
NOTE: It should not be assumed that all tasks that execute on a TaskQueue,
run on the same thread. E.g. on Mac and iOS, we use GCD dispatch queues
which means that tasks might execute on different threads depending on
what's the most efficient thing to do.
TBR=perkj@webrtc.org
Review-Url: https://codereview.webrtc.org/1927133004
Cr-Commit-Position: refs/heads/master@{#12737}
Reason for revert:
Downstream users updated now.
Original issue's description:
> Partial revert of Enable -Winconsistent-missing-override flag. (patchset #5 id:80001 of https://codereview.webrtc.org/1921653002/ )
>
> Reason for revert:
> This CL breaks the google3 import (but not the import bot).
> This partial revert only reverts the build files. A full revert no longer cleanly applies to ToT, so this was done instead.
>
> Original issue's description:
> > Enable -Winconsistent-missing-override flag.
> >
> > The problem with gmock is worked around by commenting out any other override declarations in classes using gmock.
> >
> > NOPRESUBMIT=True
> > BUG=webrtc:3970
> >
> > Committed: https://crrev.com/ef8b61e11062295365f11b9942f18a08a8b3ec60
> > Cr-Commit-Position: refs/heads/master@{#12563}
>
> TBR=mflodman@webrtc.org,kjellander@webrtc.org,nisse@webrtc.org
> BUG=webrtc:3970
>
> Committed: https://crrev.com/053f91774149a5367ddd531999d4ca69a57dbaa3
> Cr-Commit-Position: refs/heads/master@{#12624}
TBR=kjellander@webrtc.org,mflodman@webrtc.org,ivoc@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:3970
NOTRY=True
Review-Url: https://codereview.webrtc.org/1959353002
Cr-Commit-Position: refs/heads/master@{#12678}
Reason for revert:
This CL breaks the google3 import (but not the import bot).
This partial revert only reverts the build files. A full revert no longer cleanly applies to ToT, so this was done instead.
Original issue's description:
> Enable -Winconsistent-missing-override flag.
>
> The problem with gmock is worked around by commenting out any other override declarations in classes using gmock.
>
> NOPRESUBMIT=True
> BUG=webrtc:3970
>
> Committed: https://crrev.com/ef8b61e11062295365f11b9942f18a08a8b3ec60
> Cr-Commit-Position: refs/heads/master@{#12563}
TBR=mflodman@webrtc.org,kjellander@webrtc.org,nisse@webrtc.org
BUG=webrtc:3970
Review-Url: https://codereview.webrtc.org/1944273002
Cr-Commit-Position: refs/heads/master@{#12624}
Reason for revert:
Breaks downstream gtest usage.
Original issue's description:
> Remove the rtc_relative_path GYP variable and similar defines
>
> This is a reland of https://codereview.webrtc.org/1903553003/ but with
> the SRTP changes removed, since they're needed downstream.
>
> The defines that can be used to alter the include paths for Expat and gtest
> are no longer needed in WebRTC or Chromium. Remove them to simplify GYP.
>
> Removed defines:
> EXPAT_RELATIVE_PATH
> GTEST_RELATIVE_PATH
>
> They're all set in the Chromium build so this shouldn't affect Chromium:
> https://code.google.com/p/chromium/codesearch#chromium/src/third_party/libjingle/libjingle.gyp
>
> BUG=webrtc:4256
> NOTRY=True
> NOPRESUBMIT=True
> TBR=perkj@webrtc.org
>
> Committed: https://crrev.com/081254f2c62037d016f9fc961764c6f01cb095da
> Cr-Commit-Position: refs/heads/master@{#12536}
TBR=perkj@webrtc.org,kjellander@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:4256
Review-Url: https://codereview.webrtc.org/1945803003
Cr-Commit-Position: refs/heads/master@{#12622}
The problem with gmock is worked around by commenting out any other override declarations in classes using gmock.
NOPRESUBMIT=True
BUG=webrtc:3970
Review-Url: https://codereview.webrtc.org/1921653002
Cr-Commit-Position: refs/heads/master@{#12563}
Reason for revert:
Breaks downstream for SRTP include paths. Will rework this and reland without that one.
Original issue's description:
> Remove the rtc_relative_path GYP variable and similar defines
>
> The defines that can be used to alter the include paths for Expat, SRTP
> and gtest are no longer needed in WebRTC or Chromium. Let's remove them
> to simplify the GYP a little.
>
> Removed defines:
> EXPAT_RELATIVE_PATH
> GTEST_RELATIVE_PATH
> SRTP_RELATIVE_PATH
>
> They're all set in the Chromium build so this shouldn't affect Chromium:
> https://code.google.com/p/chromium/codesearch#chromium/src/third_party/libjingle/libjingle.gyp
>
> BUG=webrtc:4256
> NOTRY=True
> NOPRESUBMIT=True
>
> Committed: https://crrev.com/e19cf59eb6ee44fd4d7e7fbcfdd1a6ea75063605
> Cr-Commit-Position: refs/heads/master@{#12467}
TBR=pthatcher@webrtc.org,perkj@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:4256
Review URL: https://codereview.webrtc.org/1913043003
Cr-Commit-Position: refs/heads/master@{#12468}
The defines that can be used to alter the include paths for Expat, SRTP
and gtest are no longer needed in WebRTC or Chromium. Let's remove them
to simplify the GYP a little.
Removed defines:
EXPAT_RELATIVE_PATH
GTEST_RELATIVE_PATH
SRTP_RELATIVE_PATH
They're all set in the Chromium build so this shouldn't affect Chromium:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/libjingle/libjingle.gyp
BUG=webrtc:4256
NOTRY=True
NOPRESUBMIT=True
Review URL: https://codereview.webrtc.org/1903553003
Cr-Commit-Position: refs/heads/master@{#12467}
Reason for revert:
This breaks remoting_unittests on Windows in Chromium:
[5116:2536:0404/012329:5457156:ERROR:webrtcsession.cc(1388)] ConnectDataChannel called when data_channel_ is NULL.
[5116:2536:0404/012329:5457187:ERROR:opensslidentity.cc(154)] Generating certificate: error:0c000071:ASN.1 encoding routines:OPENSSL_internal:ERROR_GETTING_TIME
[5116:2536:0404/012329:5457218:ERROR:opensslidentity.cc(154)] Generating certificate: error:0c000071:ASN.1 encoding routines:OPENSSL_internal:ERROR_GETTING_TIME
[5116:2536:0404/012329:5457218:WARNING:dtlsidentitystore.cc(221)] Failed to generate DTLS identity.
[
Original issue's description:
> Set defines for Chromium build.
>
> Copy the defines from the target_defaults section of Chromium's
> src/third_party/libjingle.gyp into our webrtc/build/common.gypi
> in order to ensure the same defines are used for the Chromium build
> when removing the source listings in src/third_party/libjingle.gyp.
> With this CL landed, it should be possible to replace them with
> dependencies on:
> * webrtc/api/api.gyp:libjingle_peerconnections
> * webrtc/media/media.gyp:rtc_media
> * webrtc/pc/pc.gyp:rtc_pc
> * webrtc/pp2/p2p.gyp:rtc_p2p
> * webrtc/libjingle/xmpp/xmpp.gyp:rtc_xmpp
>
> Not ported (Windows specific):
> * Precompiled headers (build/win_precompile.gypi):
> since it only seems to offer a compile speedup. Will be landed
> for all of WebRTC in separate CL.
>
> BUG=webrtc:4256
> NOTRY=True
> R=perkj@webrtc.org, tommi@webrtc.org
>
> Committed: 9266cc0668TBR=perkj@webrtc.org,tommi@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:4256
Review URL: https://codereview.webrtc.org/1861603002
Cr-Commit-Position: refs/heads/master@{#12229}
Copy the defines from the target_defaults section of Chromium's
src/third_party/libjingle.gyp into our webrtc/build/common.gypi
in order to ensure the same defines are used for the Chromium build
when removing the source listings in src/third_party/libjingle.gyp.
With this CL landed, it should be possible to replace them with
dependencies on:
* webrtc/api/api.gyp:libjingle_peerconnections
* webrtc/media/media.gyp:rtc_media
* webrtc/pc/pc.gyp:rtc_pc
* webrtc/pp2/p2p.gyp:rtc_p2p
* webrtc/libjingle/xmpp/xmpp.gyp:rtc_xmpp
Not ported (Windows specific):
* Precompiled headers (build/win_precompile.gypi):
since it only seems to offer a compile speedup. Will be landed
for all of WebRTC in separate CL.
BUG=webrtc:4256
NOTRY=True
R=perkj@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1847013002 .
Cr-Commit-Position: refs/heads/master@{#12212}
Chromium doesn't use the device managment code in webrtc/media
so we need a way to turn it off in order to eliminate Chromium's
src/third_party/libjingle/libjingle.gyp
BUG=webrtc:4256
NOTRY=True
TESTED=Trybots + successfully compiled with
GYP_DEFINES=include_internal_device_management=0 webrtc/build/gyp_webrtc
ninja -C out/Debug rtc_media
Review URL: https://codereview.webrtc.org/1693803002
Cr-Commit-Position: refs/heads/master@{#11816}
The previously disabled warnings that were inherited from
talk/build/common.gypi are now replaced by target-specific disabling
of only the failing warnings. Additional disabling was needed since the stricter
compilation warnings that applies to code in webrtc/.
License headers will be updated in a follow-up CL.
Other modifications:
* Updated the header guards.
* Sorted the includes using chromium/src/tools/sort-headers.py
except for these files:
talk/app/webrtc/peerconnectionendtoend_unittest.cc
talk/app/webrtc/java/jni/androidmediadecoder_jni.cc
talk/app/webrtc/java/jni/androidmediaencoder_jni.cc
webrtc/media/devices/win32devicemanager.cc
The HAVE_SCTP define was added for the peerconnection_unittests target
in api_tests.gyp.
I also checked that none of
SRTP_RELATIVE_PATH
HAVE_SRTP
HAVE_WEBRTC_VIDEO
HAVE_WEBRTC_VOICE
were used by the talk/app/webrtc code.
For Chromium, the following changes will need to be applied to the roll CL that updates the
DEPS for WebRTC and libjingle:
https://codereview.chromium.org/1615433002
BUG=webrtc:5418
NOPRESUBMIT=True
R=deadbeef@webrtc.org, pthatcher@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1610243002 .
Cr-Commit-Position: refs/heads/master@{#11545}
if not on Android/iOS.
This is a re-land of https://codereview.webrtc.org/1674103002/.
The reason Chromium FYI turned red was due to deps not
being relative. See kjellander's CL:
https://codereview.webrtc.org/1681493002/.
This means proprietary_codecs=1 && ffmpeg_branding=Chrome
can be used to enable this H.264 enc/dec implementation
instead of rtc_use_h264=1 && ffmpeg_branding=Chrome.
This is used by both Chromium trybots (but not default
Chromium build) and offical Chrome build, meaning we will
be able to test and enable H.264 in chromium.
This change would otherwise be enough to launch this
feature in Chrome, but because we do not want to do that
before we have chromium browser tests and are ready to flip
the switch, this CL prevents chromium from using H.264 just
yet: https://codereview.chromium.org/1641163002/ (landing
this after that CL).
Third time's the charm?
TBR=kjellander@webrtc.org
BUG=chromium:500605, chromium:468365
Review URL: https://codereview.webrtc.org/1675143003
Cr-Commit-Position: refs/heads/master@{#11523}
Reason for revert:
Chromium FYI turns red.
Original issue's description:
> Default build flag |rtc_use_h264| to |proprietary_codecs|
> if not on Android/iOS.
>
> This means proprietary_codecs=1 && ffmpeg_branding=Chrome
> can be used to enable this H.264 enc/dec implementation
> instead of rtc_use_h264=1 && ffmpeg_branding=Chrome.
> This is used by both Chromium trybots (but not default
> Chromium build) and offical Chrome build, meaning we will
> be able to test and enable H.264 in chromium.
>
> This change would otherwise be enough to launch this
> feature in Chrome, but because we do not want to do that
> before we have chromium browser tests and are ready to flip
> the switch, this CL prevents chromium from using H.264 just
> yet: https://codereview.chromium.org/1641163002/ (landing
> this after that CL).
>
> Note: This is a re-land of
> https://codereview.webrtc.org/1660403004/. Reverting it
> was not necessary.
>
> TBR=kjellander@webrtc.org
> BUG=chromium:500605, chromium:468365
>
> Committed: https://crrev.com/10b9dd7ab1a8c3f80b2d2924be658e43131a4fbe
> Cr-Commit-Position: refs/heads/master@{#11517}
TBR=kjellander@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:500605, chromium:468365
Review URL: https://codereview.webrtc.org/1675113002
Cr-Commit-Position: refs/heads/master@{#11518}
if not on Android/iOS.
This means proprietary_codecs=1 && ffmpeg_branding=Chrome
can be used to enable this H.264 enc/dec implementation
instead of rtc_use_h264=1 && ffmpeg_branding=Chrome.
This is used by both Chromium trybots (but not default
Chromium build) and offical Chrome build, meaning we will
be able to test and enable H.264 in chromium.
This change would otherwise be enough to launch this
feature in Chrome, but because we do not want to do that
before we have chromium browser tests and are ready to flip
the switch, this CL prevents chromium from using H.264 just
yet: https://codereview.chromium.org/1641163002/ (landing
this after that CL).
Note: This is a re-land of
https://codereview.webrtc.org/1660403004/. Reverting it
was not necessary.
TBR=kjellander@webrtc.org
BUG=chromium:500605, chromium:468365
Review URL: https://codereview.webrtc.org/1674103002
Cr-Commit-Position: refs/heads/master@{#11517}
The files that are built when use_gtk==1 are not included in the Chromium build
(webrtc/media/devices/gtkvideorenderer.cc and webrtc/media/devices/gtkvideorenderer.h)
so to preserve previous behavior in Chromium before/after
https://codereview.webrtc.org/1587193006, this is the right thing to do.
The reason this was discovered was that a Chrome OS build started failing, since
it was lacking the gtk+2.0 package.
NOTRY=True
BUG=chromium:584722
TBR=tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1677693002
Cr-Commit-Position: refs/heads/master@{#11510}
Reason for revert:
Trybots red? Don't have time to intvestigate
Original issue's description:
> Default build flag |rtc_use_h264| to |proprietary_codecs|
> if not on Android/iOS.
>
> This means proprietary_codecs=1 && ffmpeg_branding=Chrome
> can be used to enable this H.264 enc/dec implementation
> instead of rtc_use_h264=1 && ffmpeg_branding=Chrome.
> This is used by both Chromium trybots (but not default
> Chromium build) and offical Chrome build, meaning we will
> be able to test and enable H.264 in chromium.
>
> This change would otherwise be enough to launch this
> feature in Chrome, but because we do not want to do that
> before we have chromium browser tests and are ready to flip
> the switch, this CL prevents chromium from using H.264 just
> yet: https://codereview.chromium.org/1641163002/ (landing
> this after that CL).
>
> BUG=chromium:500605, chromium:468365
>
> Committed: https://crrev.com/7cd94f66ebfe5bf808d7dcb8da069d35f4a2b31a
> Cr-Commit-Position: refs/heads/master@{#11506}
TBR=kjellander@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:500605, chromium:468365
Review URL: https://codereview.webrtc.org/1677623002
Cr-Commit-Position: refs/heads/master@{#11508}
if not on Android/iOS.
This means proprietary_codecs=1 && ffmpeg_branding=Chrome
can be used to enable this H.264 enc/dec implementation
instead of rtc_use_h264=1 && ffmpeg_branding=Chrome.
This is used by both Chromium trybots (but not default
Chromium build) and offical Chrome build, meaning we will
be able to test and enable H.264 in chromium.
This change would otherwise be enough to launch this
feature in Chrome, but because we do not want to do that
before we have chromium browser tests and are ready to flip
the switch, this CL prevents chromium from using H.264 just
yet: https://codereview.chromium.org/1641163002/ (landing
this after that CL).
BUG=chromium:500605, chromium:468365
Review URL: https://codereview.webrtc.org/1660403004
Cr-Commit-Position: refs/heads/master@{#11506}
I removed the 'libjingle' target in talk/libjingle.gyp and replaced
all users of it with base/base.gyp:rtc_base. It seems the jsoncpp
and expat dependencies were not used by it's previous references.
The files in talk/media/testdata were uploaded to Google Storage and
added .sha1 files in resources/media instead of simply moving them.
The previously disabled warnings that were inherited from
talk/build/common.gypi are now replaced by target-specific disabling
of only the failing warnings. Additional disabling was needed since the stricter
compilation warnings that applies to code in webrtc/.
License headers will be updated in a follow-up CL in order to not
break Git history.
Other modifications:
* Updated the header guards.
* Sorted the includes using chromium/src/tools/sort-headers.py
except for these files:
talk/app/webrtc/peerconnectionendtoend_unittest.cc
talk/app/webrtc/java/jni/androidmediadecoder_jni.cc
talk/app/webrtc/java/jni/androidmediaencoder_jni.cc
webrtc/media/devices/win32devicemanager.cc.
* Unused GYP reference to libjingle_tests_additional_deps was removed.
* Removed duplicated GYP entries of
webrtc/base/testutils.cc
webrtc/base/testutils.h
The HAVE_WEBRTC_VIDEO and HAVE_WEBRTC_VOICE defines were used by only talk/media,
so they were moved to the media.gyp.
I also checked that none of
EXPAT_RELATIVE_PATH,
FEATURE_ENABLE_VOICEMAIL,
GTEST_RELATIVE_PATH,
JSONCPP_RELATIVE_PATH,
LOGGING=1,
SRTP_RELATIVE_PATH,
FEATURE_ENABLE_SSL,
FEATURE_ENABLE_VOICEMAIL,
FEATURE_ENABLE_PSTN,
HAVE_SCTP,
HAVE_SRTP,
are used by the talk/media code.
For Chromium, the following changes will need to be applied to the roll CL that updates the
DEPS for WebRTC and libjingle: https://codereview.chromium.org/1604303002/
BUG=webrtc:5420
NOPRESUBMIT=True
TBR=tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1587193006
Cr-Commit-Position: refs/heads/master@{#11495}
New flag: rtc_initialize_ffmpeg, default value = !build_with_chromium.
In WebRTC standalone we initialize FFmpeg by default, in Chromium we don't by default.
Chromium is an external project that also use FFmpeg. If both projects do FFmpeg initialization code things will break. The flag makes it possible for other external projects than chromium to decide whether or not WebRTC should initialize FFmpeg.
BUG=chromium:500605, chromium:468365, webrtc:5427
Review URL: https://codereview.webrtc.org/1639273002
Cr-Commit-Position: refs/heads/master@{#11456}
