Now that DeviceManager and DeviceInfo are gone, this code is unused.
BUG=webrtc:5579
Review URL: https://codereview.webrtc.org/1715043002
Cr-Commit-Position: refs/heads/master@{#12040}
Changed the channel unittest to use locking when reading/writing the
result variable. To do this, I had to move the result into the thread
object, which in turn required me to properly handle the lifetime of the
thread object, since it cannot disappear while we want to read the
result.
It is still possible to have the result being written to a local
variable, but it will only be updated as the thread object is
destroyed. It is used to for the implementation of
CallOnThreadAndWaitForDone. The old CallOnThread is gone and replaced by
ScopedCallThread instead.
BUG=webrtc:5524
Review URL: https://codereview.webrtc.org/1736763006
Cr-Commit-Position: refs/heads/master@{#12027}
When the iOS application is not in the foreground, the hardware encoder and
decoder become invalidated. There doesn't seem to be a way to query their state
so we don't know they're invalid until we get an error code after an
encode/decode request. To solve the issue, we just don't encode/decode when the
app is not active, and reinitialize the encoder/decoder when the app is active
again.
Also fixes a leak in the decoder.
BUG=webrtc:4081
Review URL: https://codereview.webrtc.org/1732953003
Cr-Commit-Position: refs/heads/master@{#11916}
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}
This is the only failing test of the currently deployed
at the iOS Simulator bots. Let's disable it so we can promote
the passing tests to the main waterfall and the trybots.
BUG=4755
TBR=henrika@webrtc.org
Review URL: https://codereview.webrtc.org/1722523002 .
Cr-Commit-Position: refs/heads/master@{#11703}
Since SSRCs can no longer change on the fly, SSRC code can be made a lot
simpler (and faster). Resulting code has less and shorter locking.
BUG=webrtc:5494
R=danilchap@webrtc.org
Review URL: https://codereview.webrtc.org/1713683003 .
Cr-Commit-Position: refs/heads/master@{#11691}
With this change the following tests have been successfully
passing in the iOS Simulator for iPhone 5 and iOS 9:
* audio_decoder_unittests
* common_video_unittests
* modules_tests
* rtc_api_objc_tests
* rtc_pc_unittests
* system_wrappers_unittests
* voice_engine_unittests
The modules_unittests and common_audio_unittests are
handled in https://codereview.webrtc.org/1698033002/
BUG=webrtc:4755
NOTRY=True
Review URL: https://codereview.webrtc.org/1694353003
Cr-Commit-Position: refs/heads/master@{#11646}
This reverts "iOS: Add mb_type config for GYP builders."
and also removes Goma from these builders, as it will not work for WebRTC
since MB's GYP mode is hardcoded to use gyp_chromium.
MB should be working for GN since it's a stand-alone tool.
Goma doesn't work since $(goma_dir) in the JSON throws an error during
compile. So let's turn off Goma for these bots for now.
BUG=chromium:498746
NOTRY=True
TBR=smut@google.com
Review URL: https://codereview.webrtc.org/1685683007
Cr-Commit-Position: refs/heads/master@{#11578}
The PRESUBMIT code is basically a stripped-down copy of the code in
Chromium's src/PRESUBMIT.py.
BUG=chromium:498746
TESTED=I verified with 'git cl presubmit' that the existing
error was found. Then I ran it again after fixing it, with
presubmit passing.
NOTRY=True
Review URL: https://codereview.webrtc.org/1682393002
Cr-Commit-Position: refs/heads/master@{#11572}
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}
Reason for revert:
I've decided to not aim for implementing analyze and focus on getting Swarming done instead, so I'm cleaning this up.
Original issue's description:
> Analyze support in gyp_webrtc
>
> BUG=chromium:482463
> TESTED=Manually tested using the JSON files attached to https://code.google.com/p/chromium/issues/detail?id=482463#c2 and:
> webrtc/build/gyp_webrtc --analyzer nothing-files.json nothing-files-RESULT.json
> webrtc/build/gyp_webrtc --analyzer everything-files.json everything-files-RESULT.json
> webrtc/build/gyp_webrtc --analyzer test_support_unittests-files.json test_support_unittests-files-RESULT.json
> Then I verified the result-json contained the expected output.
>
> R=phoglund@webrtc.org
>
> Committed: https://crrev.com/8108764552e20d657c0a6f75a6200b93de486659
> Cr-Commit-Position: refs/heads/master@{#10097}
TBR=phoglund@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:482463
Review URL: https://codereview.webrtc.org/1681023003
Cr-Commit-Position: refs/heads/master@{#11532}
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}
