Also renames "peerconnection_unittests" to "peerconnection_integrationtests",
and moves the ICE URL parsing code to separate files.
The main problem previously was that the test assertions
occurred in various places in the main test class, and this shared test
code was overly complex and stateful. As a result, it was difficult to
tell what a test even does, let alone what assertions it's meant to be
making. And writing a new test that does what you want can be a
frustrating ordeal.
The new code still uses helper methods, but they have intuitive names
and a smaller role; all of the important parts of the test's logic are
in the test case itself.
We're planning on merging PeerConnection and WebRtcSession at some point
soon, so it seemed valuable to do this, so that the WebRtcSession tests
can be rewritten as PeerConnection tests using better patterns.
BUG=None
Review-Url: https://codereview.webrtc.org/2738353003
Cr-Commit-Position: refs/heads/master@{#17458}
This seems to be the preferred way to pass flags to tests running on Swarming.
Add --quick flag to the low_bandwidth_audio_test and support for 'args' keyword
(similar to upstream Chromium's mb.py).
Change the type of the test to non_parallel_console_test_launcher to avoid
running with gtest-parallel, since it will swallow the stdout output.
BUG=webrtc:7229
NOTRY=True
TBR=ehmaldonado@webrtc.org
Review-Url: https://codereview.webrtc.org/2763323003
Cr-Commit-Position: refs/heads/master@{#17353}
Add tests for inital probing and mid-call probing by reconfiguring max bitrate.
BUG=none
Review-Url: https://codereview.webrtc.org/2760623002
Cr-Commit-Position: refs/heads/master@{#17316}
The --purify flag can now be passed to remove the temporary
files and directories created while building the iOS Framework or static
library. That way, only the final result(s) are taking up space in the
output folder.
BUG=None
NOTRY=True
Review-Url: https://codereview.webrtc.org/2740923003
Cr-Commit-Position: refs/heads/master@{#17224}
Reason for revert:
Trying to fix this skipping the check if we are building webrtc within chromium.
Original issue's description:
> Revert of Setting is_component_build to false by default (patchset #5 id:80001 of https://codereview.webrtc.org/2728643003/ )
>
> Reason for revert:
> Breaks chrome rolls
>
> Original issue's description:
> > Setting is_component_build to false by default
> >
> > Webrtc does not support component builds so we want to override
> > the chromium default value (which can be true on debug builds if the
> > os is different from iOS).
> >
> > Please note that the user can set this value to true in two ways:
> >
> > - using --args (e.g.: gn gen out/default --args='is_component_build=true'
> > - changing the value in the args.gn file
> >
> > But in both cases the value will be ignored because we don't use the
> > 'component' template but we rely directly on 'rtc_static_library' and
> > 'rtc_shared_library'.
> >
> > BUG=webrtc:6975
> > NOTRY=True
> >
> > Review-Url: https://codereview.webrtc.org/2728643003
> > Cr-Commit-Position: refs/heads/master@{#17020}
> > Committed: 2cb3944ba7
>
> TBR=kjellander@webrtc.org,mbonadei@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:6975
>
> Review-Url: https://codereview.webrtc.org/2731703004
> Cr-Commit-Position: refs/heads/master@{#17025}
> Committed: 2d9e7685a5TBR=kjellander@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:6975
Review-Url: https://codereview.webrtc.org/2729243003
Cr-Commit-Position: refs/heads/master@{#17027}
Reason for revert:
Breaks chrome rolls
Original issue's description:
> Setting is_component_build to false by default
>
> Webrtc does not support component builds so we want to override
> the chromium default value (which can be true on debug builds if the
> os is different from iOS).
>
> Please note that the user can set this value to true in two ways:
>
> - using --args (e.g.: gn gen out/default --args='is_component_build=true'
> - changing the value in the args.gn file
>
> But in both cases the value will be ignored because we don't use the
> 'component' template but we rely directly on 'rtc_static_library' and
> 'rtc_shared_library'.
>
> BUG=webrtc:6975
> NOTRY=True
>
> Review-Url: https://codereview.webrtc.org/2728643003
> Cr-Commit-Position: refs/heads/master@{#17020}
> Committed: 2cb3944ba7TBR=kjellander@webrtc.org,mbonadei@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6975
Review-Url: https://codereview.webrtc.org/2731703004
Cr-Commit-Position: refs/heads/master@{#17025}
Webrtc does not support component builds so we want to override
the chromium default value (which can be true on debug builds if the
os is different from iOS).
Please note that the user can set this value to true in two ways:
- using --args (e.g.: gn gen out/default --args='is_component_build=true'
- changing the value in the args.gn file
But in both cases the value will be ignored because we don't use the
'component' template but we rely directly on 'rtc_static_library' and
'rtc_shared_library'.
BUG=webrtc:6975
NOTRY=True
Review-Url: https://codereview.webrtc.org/2728643003
Cr-Commit-Position: refs/heads/master@{#17020}
Mostly just copied from Chromium, replacing instances of "chromium" with
"webrtc".
BUG=None
NOTRY=True
Review-Url: https://codereview.webrtc.org/2725233002
Cr-Commit-Position: refs/heads/master@{#16988}
Reason for revert:
Fixing issues with the framework builder.
Original issue's description:
> Revert of Do not produce dSYM file for the iOS Frameworks with bitcode (patchset #2 id:20001 of https://codereview.webrtc.org/2705163007/ )
>
> Reason for revert:
> Looks like this caused the iOS API Framework Builder to fail.
>
> https://build.chromium.org/p/client.webrtc/builders/iOS%20API%20Framework%20Builder/builds/3487/steps/zip%20archive/logs/stdio
>
> Zipping /b/rr/tmpkIyP1e/w/webrtc_ios_api_framework.zip...
> Traceback (most recent call last):
> File "/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py", line 144, in <module>
> sys.exit(main())
> File "/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py", line 130, in main
> exit_code = zip_with_subprocess(root, output, entries)
> File "/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py", line 43, in zip_with_subprocess
> assert os.path.isdir(path), path
> AssertionError: /b/c/b/iOS_API_Framework_Builder/src/out_ios_libs/WebRTC.dSYM/
> step returned non-zero exit code: 1
> @@@STEP_FAILURE@@@
>
> Original issue's description:
> > Do not produce dSYM file for the iOS Frameworks with bitcode
> >
> > Though dSYM files can be generated when building applications or libraries
> > with bitcode. They cannot be used to symbolicate crash reports from
> > applications. Instead, developers need to grab the real dSYM files, which
> > are generated for each specific device type after uploading an iOS / tvOS
> > application to App Store (or to a device using Xcode). Apple clearly warns
> > about it in its documentation:
> >
> > https://developer.apple.com/library/content/technotes/tn2151/_index.html#//apple_ref/doc/uid/DTS40008184-CH1-SYMBOLICATION-BITCODE
> >
> > With that in mind, I believe that it would be better to not confuse
> > developers by giving them dSYM files that are not very helpful with
> > the bitcode-enabled framework. Thus, proposing the following modification
> > to the building script, to generate dSYM by default only without
> > the bitcode option. However, if some developers still want to get
> > the dSYM files as a build-process artifact, when enabling bitcode,
> > they can explicitly add --extra-gn-args enable_dsyms=true to the script.
> >
> > Let me know if it lgty.
> >
> > NOTRY=True
> > BUG=None
> >
> > Review-Url: https://codereview.webrtc.org/2705163007
> > Cr-Commit-Position: refs/heads/master@{#16836}
> > Committed: d74517c52a
>
> TBR=kjellander@webrtc.org,kthelgason@webrtc.org,VladimirTechMan@gmail.com
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=None
> NOTRY=True
>
> Review-Url: https://codereview.webrtc.org/2719773002
> Cr-Commit-Position: refs/heads/master@{#16844}
> Committed: da00077cfaTBR=kjellander@webrtc.org,vladimirtechman@gmail.com,tommi@webrtc.org
NOTRY=true
BUG=None
Review-Url: https://codereview.webrtc.org/2718983002
Cr-Commit-Position: refs/heads/master@{#16924}
Sorry for all small changes. I tried the scripts on a clean device and
realized that some parts had worked before because files existed on the
device already. Should be OK now.
NOTRY=TRUE
TBR=kjellander
BUG=NONE
Review-Url: https://codereview.webrtc.org/2718103002
Cr-Commit-Position: refs/heads/master@{#16874}
Ensures that perf_update works after inital perf_setup.sh call.
NOTRY=TRUE
TBR=kjellander
BUG=NONE
Review-Url: https://codereview.webrtc.org/2719033002
Cr-Commit-Position: refs/heads/master@{#16868}
Reason for revert:
Looks like this caused the iOS API Framework Builder to fail.
https://build.chromium.org/p/client.webrtc/builders/iOS%20API%20Framework%20Builder/builds/3487/steps/zip%20archive/logs/stdio
Zipping /b/rr/tmpkIyP1e/w/webrtc_ios_api_framework.zip...
Traceback (most recent call last):
File "/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py", line 144, in <module>
sys.exit(main())
File "/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py", line 130, in main
exit_code = zip_with_subprocess(root, output, entries)
File "/b/rr/tmpkIyP1e/rw/checkout/scripts/slave/recipe_modules/zip/resources/zip.py", line 43, in zip_with_subprocess
assert os.path.isdir(path), path
AssertionError: /b/c/b/iOS_API_Framework_Builder/src/out_ios_libs/WebRTC.dSYM/
step returned non-zero exit code: 1
@@@STEP_FAILURE@@@
Original issue's description:
> Do not produce dSYM file for the iOS Frameworks with bitcode
>
> Though dSYM files can be generated when building applications or libraries
> with bitcode. They cannot be used to symbolicate crash reports from
> applications. Instead, developers need to grab the real dSYM files, which
> are generated for each specific device type after uploading an iOS / tvOS
> application to App Store (or to a device using Xcode). Apple clearly warns
> about it in its documentation:
>
> https://developer.apple.com/library/content/technotes/tn2151/_index.html#//apple_ref/doc/uid/DTS40008184-CH1-SYMBOLICATION-BITCODE
>
> With that in mind, I believe that it would be better to not confuse
> developers by giving them dSYM files that are not very helpful with
> the bitcode-enabled framework. Thus, proposing the following modification
> to the building script, to generate dSYM by default only without
> the bitcode option. However, if some developers still want to get
> the dSYM files as a build-process artifact, when enabling bitcode,
> they can explicitly add --extra-gn-args enable_dsyms=true to the script.
>
> Let me know if it lgty.
>
> NOTRY=True
> BUG=None
>
> Review-Url: https://codereview.webrtc.org/2705163007
> Cr-Commit-Position: refs/heads/master@{#16836}
> Committed: d74517c52aTBR=kjellander@webrtc.org,kthelgason@webrtc.org,VladimirTechMan@gmail.com
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=None
NOTRY=True
Review-Url: https://codereview.webrtc.org/2719773002
Cr-Commit-Position: refs/heads/master@{#16844}
This CL adds the following interfaces:
* RtpTransportController
* RtpTransport
* RtpSender
* RtpReceiver
They're implemented on top of the "BaseChannel" object, which is normally used
in a PeerConnection, and roughly corresponds to an SDP "m=" section. As a result
of this, there are several limitations:
* You can only have one of each type of sender and receiver (audio/video) on top
of the same transport controller.
* The sender/receiver with the same media type must use the same RTP transport.
* You can't change the transport after creating the sender or receiver.
* Some of the parameters aren't supported.
Later, these "adapter" objects will be gradually replaced by real objects that don't
have these limitations, as "BaseChannel", "MediaChannel" and related code is
restructured. In this CL, we essentially have:
ORTC adapter objects -> BaseChannel -> Media engine
PeerConnection -> BaseChannel -> Media engine
And later we hope to have simply:
PeerConnection -> "Real" ORTC objects -> Media engine
See the linked bug for more context.
BUG=webrtc:7013
TBR=stefan@webrtc.org
Review-Url: https://codereview.webrtc.org/2675173003
Cr-Commit-Position: refs/heads/master@{#16842}
Though dSYM files can be generated when building applications or libraries
with bitcode. They cannot be used to symbolicate crash reports from
applications. Instead, developers need to grab the real dSYM files, which
are generated for each specific device type after uploading an iOS / tvOS
application to App Store (or to a device using Xcode). Apple clearly warns
about it in its documentation:
https://developer.apple.com/library/content/technotes/tn2151/_index.html#//apple_ref/doc/uid/DTS40008184-CH1-SYMBOLICATION-BITCODE
With that in mind, I believe that it would be better to not confuse
developers by giving them dSYM files that are not very helpful with
the bitcode-enabled framework. Thus, proposing the following modification
to the building script, to generate dSYM by default only without
the bitcode option. However, if some developers still want to get
the dSYM files as a build-process artifact, when enabling bitcode,
they can explicitly add --extra-gn-args enable_dsyms=true to the script.
Let me know if it lgty.
NOTRY=True
BUG=None
Review-Url: https://codereview.webrtc.org/2705163007
Cr-Commit-Position: refs/heads/master@{#16836}
See bug for more info. This race is benign, and only exists because a
method is virtual so it can be mocked for testing.
BUG=webrtc:7221
NOTRY=True
TBR=hbos@webrtc.org
Review-Url: https://codereview.webrtc.org/2711783005
Cr-Commit-Position: refs/heads/master@{#16813}
The documentation for AsyncInvoker states that it owns the lifetime of
calls, and when its destructor is called, all in-flight calls are
cancelled or finish executing. The "cancelled" part is working, but if
a call is in the middle of executing, the destructor does *not* wait.
This is fixed by keeping a count of pending invocations, which is
decremented when a call is either cleared from a message queue or
finishes executing.
BUG=webrtc:3914, webrtc:3911
Review-Url: https://codereview.webrtc.org/2694723004
Cr-Commit-Position: refs/heads/master@{#16811}
