Reason for revert:
I unfortunately have to revert this since trybots are still trying to run these tests and now they fail because the tests aren't there :-/ Before relanding, can you work with engprod to make sure we don't run them?
Original issue's description:
> Removes a test suite that is no longer used or maintained.
>
> BUG=NONE
>
> Review-Url: https://codereview.webrtc.org/2716843002
> Cr-Commit-Position: refs/heads/master@{#16825}
> Committed: bb5136f940TBR=solenberg@webrtc.org,nisse@webrtc.org,henrika@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=NONE
Review-Url: https://codereview.webrtc.org/2721433002
Cr-Commit-Position: refs/heads/master@{#16845}
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}
The issue was that VideoCapturerTrackSource was adding a reference
to itself, causing it to not be deleted even after no external objects
reference it. The objects underneath it (threads for instance) may
then be destroyed before the object dereferences them.
BUG=webrtc:6487
Review-Url: https://codereview.webrtc.org/2717023002
Cr-Commit-Position: refs/heads/master@{#16841}
In some rare circumstances, capturing a reference may be undesired. For
example, when creating an asynchronous task owned by the object itself,
the object may not need or want this task to keep itself alive.
BUG=None
Review-Url: https://codereview.webrtc.org/2711113008
Cr-Commit-Position: refs/heads/master@{#16840}
Reason for revert:
Looks like webrtc_perf_test started failing on linux, mac and windows after this cl landed.
Example failure:
https://build.chromium.org/p/client.webrtc.perf/builders/Linux%20Trusty/builds/1386/steps/webrtc_perf_tests/logs/stdio
[ RUN ] CallPerfTest.ReceivesCpuOveruseAndUnderuse
../../webrtc/call/call_perf_tests.cc:522: Failure
Value of: Wait()
Actual: false
Expected: true
Timed out before receiving an overuse callback.
[ FAILED ] CallPerfTest.ReceivesCpuOveruseAndUnderuse (120056 ms)
Original issue's description:
> Set scaling limit at 320 * 180 for all implementations.
>
> The MediaCodec decoder on android has trouble decoding video at
> so low resolutions. We set the limit a bit higher for all implementations
> pending a robust software fallback implementation for MediaCodec.
>
> BUG=webrtc:7206
>
> Review-Url: https://codereview.webrtc.org/2709153002
> Cr-Commit-Position: refs/heads/master@{#16798}
> Committed: 560ddb7321TBR=magjed@webrtc.org,sprang@webrtc.org,kthelgason@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:7206
Review-Url: https://codereview.webrtc.org/2711913007
Cr-Commit-Position: refs/heads/master@{#16839}
I'd like to make a change to rtc::Bind in another CL, and that will
be easier if there are fewer lines of code to modify.
BUG=None
Review-Url: https://codereview.webrtc.org/2719683002
Cr-Commit-Position: refs/heads/master@{#16838}
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}
Created an Obj-C wrapper for the callback OnAddTrack in this CL since it has been added to native C++ API
The callback function is called when a track is signaled by remote side and a new RtpReceiver is created.
The application can tell when tracks are added to the streams by listening to this callback.
BUG=webrtc:6112
Review-Url: https://codereview.webrtc.org/2513063003
Cr-Commit-Position: refs/heads/master@{#16835}
Reason for revert:
Reverting this change since it didn't affect the perf regressions we were seeing and actually seems to have caused more regressions as per comment in the bug.
Original issue's description:
> Use sched_yield on all POSIX platforms in PlatformThread.
> (not only MacOS)
>
> This is a test to see if perf regressions we're seeing may be related to the use of nanosleep().
>
> BUG=695438
> TBR=solenberg@webrtc.org
>
> Review-Url: https://codereview.webrtc.org/2716683002 .
> Cr-Commit-Position: refs/heads/master@{#16807}
> Committed: 384498abb5TBR=solenberg@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=695438
Review-Url: https://codereview.webrtc.org/2712133003
Cr-Commit-Position: refs/heads/master@{#16833}
Reason for revert:
Buildbot issues have been fixed.
Original issue's description:
> Revert of Remove some warning suppressions from SocketRocket. (patchset #1 id:1 of https://codereview.webrtc.org/2704383004/ )
>
> Reason for revert:
> Breaks buildbot
>
> Original issue's description:
> > Remove some warning suppressions from SocketRocket.
> >
> > These warnings started appearing on a clang update. This CL patches the
> > vendored library and removes the supression. We assert on the return as
> > we're not equipped to deal with failures there anyway.
> >
> > BUG=webrtc:6396
> > NOTRY=true
> >
> > Review-Url: https://codereview.webrtc.org/2704383004
> > Cr-Commit-Position: refs/heads/master@{#16820}
> > Committed: 49990e88fb
>
> TBR=kjellander@webrtc.org,magjed@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:6396
>
> Review-Url: https://codereview.webrtc.org/2714123002
> Cr-Commit-Position: refs/heads/master@{#16822}
> Committed: e47de1a69cTBR=kjellander@webrtc.org,magjed@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6396
Review-Url: https://codereview.webrtc.org/2718653002
Cr-Commit-Position: refs/heads/master@{#16823}
Reason for revert:
Breaks buildbot
Original issue's description:
> Remove some warning suppressions from SocketRocket.
>
> These warnings started appearing on a clang update. This CL patches the
> vendored library and removes the supression. We assert on the return as
> we're not equipped to deal with failures there anyway.
>
> BUG=webrtc:6396
> NOTRY=true
>
> Review-Url: https://codereview.webrtc.org/2704383004
> Cr-Commit-Position: refs/heads/master@{#16820}
> Committed: 49990e88fbTBR=kjellander@webrtc.org,magjed@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6396
Review-Url: https://codereview.webrtc.org/2714123002
Cr-Commit-Position: refs/heads/master@{#16822}
These warnings started appearing on a clang update. This CL patches the
vendored library and removes the supression. We assert on the return as
we're not equipped to deal with failures there anyway.
BUG=webrtc:6396
NOTRY=true
Review-Url: https://codereview.webrtc.org/2704383004
Cr-Commit-Position: refs/heads/master@{#16820}
This avoids adding an additional test target. Plus, everything in
rtc_api_unittests is (and likely will be) simple utility classes akin to
what's already being tested in rtc_unittests.
BUG=None
TBR=kjellander@webrtc.org
Review-Url: https://codereview.webrtc.org/2709573003
Cr-Commit-Position: refs/heads/master@{#16819}
A bug has been reported to complaint the ScreenCapturerWinDirectx cannot capture
the first frame, which is used in "Report an issue" page.
A simple solution here is to skip the first frame.
This change also removes the friend relationship between
DxgiDuplicatorController / DxgiAdapterDuplicator / DxgiOutputDuplicator, which
is not really necessary.
BUG=682112
Review-Url: https://codereview.webrtc.org/2703123002
Cr-Commit-Position: refs/heads/master@{#16815}
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}
This is a short term solution to change the volume of a RTCAudioTrack (which contains an RTCAudioSource property) until applyConstraints for RTCMediaStreamTracks has been implemented.
This CL adds one new Objective-C method to AudioSourceInterface's wrapper: -(void)setVolume:(double)volume
BUG=webrtc:6533, webrtc:6805
This is my first CL for Chromium/WebRTC, so please let me know if I did something wrong.
Review-Url: https://codereview.webrtc.org/2534843002
Cr-Commit-Position: refs/heads/master@{#16809}
When textures are not enabled and we are using byte buffer outputs, the
decoder is currently crashing for odd heights because of an RTC_CHECK.
This CL removes the check and handles the pointer offset to the chroma
planes for the odd height case instead.
This has been verified to work correctly on a Pixel device.
BUG=webrtc:6651
Review-Url: https://codereview.webrtc.org/2709923005
Cr-Commit-Position: refs/heads/master@{#16805}
Explicit initialization of const member of new EchoCanceller 3
submodule.
NOTRY=True
BUG=webrtc:6018
Review-Url: https://codereview.webrtc.org/2715573003
Cr-Commit-Position: refs/heads/master@{#16802}
calculating frame sizes. Added actual_bitrate metric which also accounts
for TL and SL info. Metric encoded_frame_size calculation is cleaned up. Perf alerts should be ignored.
BUG=webrtc:7095
Review-Url: https://codereview.webrtc.org/2709483009
Cr-Commit-Position: refs/heads/master@{#16800}
The MediaCodec decoder on android has trouble decoding video at
so low resolutions. We set the limit a bit higher for all implementations
pending a robust software fallback implementation for MediaCodec.
BUG=webrtc:7206
Review-Url: https://codereview.webrtc.org/2709153002
Cr-Commit-Position: refs/heads/master@{#16798}
