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}
It works on all platforms except Android and iOS (FFmpeg limitation).
Implemented behind compile time flags, off by default.
The plan is to have it enabled in Chrome (see bug), but not in Chromium/webrtc by default.
Flags to turn it on:
- rtc_use_h264 = true
- ffmpeg_branding = "Chrome" (or other brand that includes H.264 decoder)
Tests using H264:
- video_loopback --codec=H264
- screenshare_loopback --codec=H264
- video_engine_tests (EndToEndTest.SendsAndReceivesH264)
NOTRY=True
BUG=500605, 468365
BUG=https://bugs.chromium.org/p/webrtc/issues/detail?id=5424
Review URL: https://codereview.webrtc.org/1306813009
Cr-Commit-Position: refs/heads/master@{#11390}
That these declarations were missing was a bug, which apparently
didn't actually cause build problems in either Chromium or WebRTC
standalone. (Presumably, because rent_a_codec was always linked
together with other build targets that did declare such dependencies.)
BUG=webrtc:5435
Review URL: https://codereview.webrtc.org/1607463002
Cr-Commit-Position: refs/heads/master@{#11303}
This makes it possible to use protobuffers with
an external protobuf library instead of the one that
comes with the WebRTC code.
NOTRY=True
Review URL: https://codereview.webrtc.org/1589433002
Cr-Commit-Position: refs/heads/master@{#11236}
Defining use_third_party_h264 directly, and indirectly defining use_openh264 (from third_party/openh264) and ffmpeg_branding (from third_party/ffmpeg).
These will be used in a follow-up CL that adds an encoder and decoder implementation.
The flags are added in this CL so that they can be used by trybots/waterfall bots in GN without "Build argument had no effect" errors. Equivalent GYP changes are also added.
BUG=468365
Review URL: https://codereview.webrtc.org/1575913003
Cr-Commit-Position: refs/heads/master@{#11204}
This will make it possible to remove the build_with_libjingle=1 and key=''
GYP_DEFINES the bots are using (https://codereview.chromium.org/1450313002/).
It will also pave the road for enabling more WebRTC native tests on iOS.
BUG=webrtc:4755,webrtc:3185,webrtc:5165
TESTED=git cl try -c --bot=android_compile_rel --bot=linux_compile_rel --bot=win_compile_rel --bot=mac_compile_rel --bot=ios_rel --bot=linux_gn_rel --bot=win_x64_gn_rel --bot=mac_x64_gn_rel --bot=android_gn_rel -m tryserver.webrtc
Local compilation with:
GYP_DEFINES='OS=ios target_arch=arm' webrtc/build/gyp_webrtc
ninja -C out/Release-iphoneos
GYP_DEFINES='OS=ios target_arch=arm chromium_ios_signing=0' webrtc/build/gyp_webrtc
ninja -C out/Release-iphoneos
GYP_DEFINES='OS=ios target_arch=arm64' webrtc/build/gyp_webrtc
ninja -C out/Release-iphoneos
GYP_DEFINES='OS=ios target_arch=ia32' webrtc/build/gyp_webrtc
ninja -C out/Release-iphonesimulator
GYP_DEFINES='OS=ios target_arch=x64' webrtc/build/gyp_webrtc
ninja -C out/Release-iphonesimulator
R=henrika@webrtc.org
Review URL: https://codereview.webrtc.org/1457053003 .
Cr-Commit-Position: refs/heads/master@{#10711}
JNI already has jstring<->UTF8 string conversion, so using that should
save ~1mb off android binaries (ICU is *large*), probably around
300-400k after compression.
BUG=
Review URL: https://codereview.webrtc.org/1430023005
Cr-Commit-Position: refs/heads/master@{#10545}
We used to link with all audio codecs unconditionally (except Opus);
this patch makes gyp and gn only link to the ones that are used.
This unfortunately fails to have a measurable impact on Chromium
binary size, at least on x86_64 Linux; it turns out that iLBC and iSAC
fix were already being excluded from Chromium by some other means,
likely just the linker omitting compilation units with no incoming
references.
(This was previously landed as revisions 10046 and 10060, and got
reverted because it broke several of the Chromium FYI bots.)
BUG=webrtc:4557
Review URL: https://codereview.webrtc.org/1368843003
Cr-Commit-Position: refs/heads/master@{#10127}
Our perf test suite webrtc_perf_tests timed out, which caused most
of the delay landing this (https://crbug.comn/535973 and
https://codereview.chromium.org/1370133004).
Other problems with executing Android tests also needed to be
resolved in order to land this (http://crbug.com/534849).
Libvpx has moved from third_party/libvpx to third_party/libvpx_new
as of https://codereview.chromium.org/1323333002/
Android GN was blocking this roll due to a problem that ended up
being caused by a bug (http://crbug.com/534849).
Relevant changes:
* src/buildtools: f7310ee..8d89c1b
* src/third_party/boringssl/src: 1d128f3..4c60d35
* src/third_party/icu: 6b3ce81..423fc7e
* src/third_party/libjpeg_turbo: 631e2dd..e4e7503
* src/third_party/libvpx: ac1772e..70db223
* src/third_party/libyuv: fcacbfb..62c49dc
* src/tools/gyp: 5d01a8c..01528c7
* src/tools/swarming_client: 77f720b..6e5d2b2
Details: 310ea93..8cf53d6/DEPS
Clang version changed 245965:247874
Details: 310ea93..8cf53d6/tools/clang/scripts/update.sh
BUG=481034, 535973
TBR=marpan@webrtc.org
Review URL: https://codereview.webrtc.org/1355083002
Cr-Commit-Position: refs/heads/master@{#10101}
Reason for revert:
Breaking Chromium FYI bots.
Original issue's description:
> Don't link with audio codecs that we don't use
>
> We used to link with all audio codecs unconditionally (except Opus);
> this patch makes gyp and gn only link to the ones that are used.
>
> (This unfortunately fails to have a measurable impact on Chromium
> binary size, at least on x86_64 Linux; it turns out that iLBC and iSAC
> fix were already being excluded from Chromium by some other means
> (likely just the linker omitting compilation units with no incoming
> references).)
>
> BUG=webrtc:4557
>
> Committed: https://crrev.com/f66a9251424351ea6d631c54dd1feb64cc13d809
> Cr-Commit-Position: refs/heads/master@{#10046}
TBR=henrik.lundin@webrtc.org,tina.legrand@webrtc.org,kjellander@webrtc.org,kwiberg@webrtc.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:4557
Review URL: https://codereview.webrtc.org/1368933002
Cr-Commit-Position: refs/heads/master@{#10069}
