There was one .h file that didn't have to be public. :-)
BUG=webrtc:8159, webrtc:8255
Change-Id: I0998f0340384c57f52affdde30f6b4eb2eaa712b
Reviewed-on: https://webrtc-review.googlesource.com/2400
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19915}
StreamConfig is not integral to RTC-event logging in general, but rather to specific events. Therefore, the dependency on it should not be exported through rtc_event_log.h.
BUG=webrtc:8111
TBR=stefan@webrtc.org
Change-Id: I1ece0830cd05fd12220c8c717490e15942bacec9
Reviewed-on: https://webrtc-review.googlesource.com/1238
Commit-Queue: Elad Alon <eladalon@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Reviewed-by: Elad Alon <eladalon@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19911}
The track-level stats are currently implemented in terms of the stream-
level stats. Which is a problem if multiple unsignaled streams map to the
same track (see bug for more details). This CL fixes the problem
partially, but only returning stats for one of the unsignaled streams.
A better solution would be to return stats for both streams, but update
the track-level stats independently somehow. But that would require more
extensive changes, and it's not yet clear how we want to do it.
BUG=webrtc:8158
Review-Url: https://codereview.webrtc.org/3008373002
Cr-Commit-Position: refs/heads/master@{#19907}
The support of fallback from DTLS to SDES is removed in this CL.
Setting an SDP with both DTLS fingerprint and SDES crypto would fail.
BUG=webrtc:8266
Review-Url: https://codereview.webrtc.org/3011133002
Cr-Commit-Position: refs/heads/master@{#19903}
The goal of this CL is to separate Obj-C/Obj-C++ code from targets
which have also C++ code (see
https://bugs.chromium.org/p/webrtc/issues/detail?id=7743 for more
information).
To achieve this we have created 2 targets (desktop_capture_objc and
desktop_capture_generic) and desktop_capture will act as a proxy
between these targets (this way we can avoid a circular dependency
between desktop_capture_generic and desktop_capture_objc).
NOTRY=True
Bug: webrtc:7743
Change-Id: I19f8bb8719cfc6af259819e2089cebea72b5d531
Reviewed-on: https://webrtc-review.googlesource.com/2220
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Henrik Kjellander <kjellander@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19899}
Reason for revert:
This seems to be causing some video freezes. See https://bugs.chromium.org/p/webrtc/issues/detail?id=8251
Original issue's description:
> Completed the functionalities of SrtpTransport.
>
> The SrtpTransport takes the SRTP responsibilities from the BaseChannel
> and SrtpFilter. SrtpTransport is now responsible for setting the crypto
> keys, protecting and unprotecting the packets. SrtpTransport doesn't know
> if the keys are from SDES or DTLS handshake.
>
> BaseChannel is now only responsible setting the offer/answer for SDES
> or extracting the key from DtlsTransport and configuring the
> SrtpTransport.
>
> SrtpFilter is used by BaseChannel as a helper for SDES negotiation.
>
> BUG=webrtc:7013
>
> Review-Url: https://codereview.webrtc.org/2997983002
> Cr-Commit-Position: refs/heads/master@{#19636}
> Committed: e683c6871fTBR=deadbeef@webrtc.org,pthatcher@google.com,zhihuang@webrtc.org
Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:7013
Review-Url: https://codereview.webrtc.org/3018513002
Cr-Commit-Position: refs/heads/master@{#19895}
After the migration from serc/webrtc to src/ this entry in the
include_dirs list is not needed anymore.
Bug: chromium:611808
Change-Id: I17c87509b73b8a44f758d59ada28d366da664649
Reviewed-on: https://webrtc-review.googlesource.com/1920
Reviewed-by: Henrik Kjellander <kjellander@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19894}
This CL also implements support for getting the native context on
EGL 1.4. It's a bit tricker to get the native handle for EGL 1.0 so it
will be done in a separate CL.
Bug: webrtc:8257
Change-Id: I269e75c357f19507098180077fa9d1b1ac4dce23
Reviewed-on: https://webrtc-review.googlesource.com/1880
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Commit-Queue: Magnus Jedvert <magjed@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19890}
After moving WebRTC from src/webrtc to src/ we can remove -webrtc from
the checkdeps configuration.
In this CL I also remove "+voice_engine_configurations.h" because this
header does not exist anymore.
NOTRY= True
Bug: chromium:611808
Change-Id: I4de427c51d78707f8107dd2dd1f834362d1c4da2
Reviewed-on: https://webrtc-review.googlesource.com/1845
Reviewed-by: Henrik Kjellander <kjellander@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19888}
This check has been skipped during the migration from src/webrtc to
src. It was also reporting false positives. Now it should be fixed.
NOTRY=True
Bug: chromium:611808
Change-Id: Id8567dd92099e75ac35351f053829deebf28a9d1
Reviewed-on: https://webrtc-review.googlesource.com/1580
Reviewed-by: Henrik Kjellander <kjellander@webrtc.org>
Reviewed-by: Henrik Kjellander <kjellander@google.com>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19887}
Reason for revert:
Speculative revert since all Android bots on WebRTC FYI started to fail when this CL landed.
https://build.chromium.org/p/chromium.webrtc.fyi/builders/Android%20Tests%20%28dbg%29%20%28L%20Nexus6%29
Original issue's description:
> If SRTP sessions exist, don't create new ones when applying answer.
>
> Instead, call the "Update" methods of SrtpSession, which will just call
> srtp_update, instead of wiping out the session state completely.
>
> This was causing decryption to stop working when subsequent
> offers/answers are applied. We don't know enough about SRTP to
> understand the root cause, and I wasn't able to write an integration
> test that reproduces the issue... But at least this fixes the bug that
> can be reproduced reliably using Hangouts.
>
> BUG=webrtc:8251
>
> Review-Url: https://codereview.webrtc.org/3019443002
> Cr-Commit-Position: refs/heads/master@{#19874}
> Committed: https://webrtc.googlesource.com/src/+/5ada7acf603e90e71990e9d4ff8f49389f24958cTBR=zhihuang@webrtc.org,deadbeef@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:8251
NOTRY=TRUE
Review-Url: https://codereview.webrtc.org/3017543002
Cr-Commit-Position: refs/heads/master@{#19882}
The number of concealment events. This counter increases every time a concealed sample is
synthesized after a non-concealed sample. That is, multiple consecutive concealed samples
will increase the concealedSamples count multiple times but is a single concealment event.
Bug: webrtc:8246
Change-Id: I7ef404edab765218b1f11e3128072c5391e83049
Reviewed-on: https://webrtc-review.googlesource.com/1221
Commit-Queue: Gustaf Ullberg <gustaf@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Fredrik Solenberg <solenberg@webrtc.org>
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19881}
Even with the right credentials in place, git-cl will default to
using autogenerated GCE credentials when on a GCE machine. Tell
it to use the appropriate .gitcookies every time.
TBR=ehmaldonado@webrtc.org, kjellander@webrtc.org
NOTRY=True
Bug: chromium:765231
Change-Id: I761db91dde7db0c945e50e961c5687c835602dc4
Reviewed-on: https://webrtc-review.googlesource.com/1700
Commit-Queue: Edward Lemur <ehmaldonado@webrtc.org>
Reviewed-by: Edward Lemur <ehmaldonado@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19879}
By making RtcEventLogImpl's ctor public, we remove the necessity to make the function a friend. Visibility of RtcEventLogImpl is still limited to the .cc file.
BUG=webrtc:8111
Change-Id: I774d2e93620a8d9f24299ef2a94f7593b490839d
Reviewed-on: https://webrtc-review.googlesource.com/1237
Commit-Queue: Elad Alon <eladalon@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19876}
There was a test for deserialization but not serialization. This was
probably always broken and no one noticed. I only noticed while
debugging something else.
BUG=None
TBR=pthatcher@webrtc.org
Review-Url: https://codereview.webrtc.org/3012383002
Cr-Commit-Position: refs/heads/master@{#19875}
Instead, call the "Update" methods of SrtpSession, which will just call
srtp_update, instead of wiping out the session state completely.
This was causing decryption to stop working when subsequent
offers/answers are applied. We don't know enough about SRTP to
understand the root cause, and I wasn't able to write an integration
test that reproduces the issue... But at least this fixes the bug that
can be reproduced reliably using Hangouts.
BUG=webrtc:8251
Review-Url: https://codereview.webrtc.org/3019443002
Cr-Commit-Position: refs/heads/master@{#19874}
I'm not sure why we ever had this in the first place, and it confuses
people on a nearly weekly basis, so let's get rid of it. The protocols
are enabled right after the corresponding gathering is done, so the only
real effect it has is to produce confusing log messages (first
"candidate not signaled because protocol not enabled", then "protocol
enabled, signaling candidate" right afterwards).
BUG=None
Review-Url: https://codereview.webrtc.org/3018483002
Cr-Commit-Position: refs/heads/master@{#19873}
Many of the tests follow a pattern of "wait for N candidates to be
gathered, then (without waiting) assert that gathering is complete". But
this only works if the "gathering complete" signal happens in the same
task as the last candidate being gathered, which isn't an API guarantee.
So the tests will be less fragile if they do the reverse: "wait for
gathering to be complete, then (without waiting) assert that N candidates
were gathered".
Also fixing some somewhat unrelated issues elsewhere. Like a test that
was supposed to be waiting for some period of time and ensuring no
additional candidates were gathered, but wasn't actually waiting at all.
BUG=None
Review-Url: https://codereview.webrtc.org/3018493002
Cr-Commit-Position: refs/heads/master@{#19872}
This CL adds an offset to the delay estimation used in AEC3 for
determining the alignment between the render and capture signals.
This ensures that there is no possibility for the capture loss to
cause the delay estimation to miss aligning the signals.
BUG=webrtc:8247, chromium:765242
Change-Id: I526dc7971b13425a28e99d69168fd3722a4cfdae
Reviewed-on: https://webrtc-review.googlesource.com/1232
Reviewed-by: Alex Loiko <aleloi@webrtc.org>
Commit-Queue: Per Åhgren <peah@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19871}
The limit on logs is not specific to the implementation of the logs, but is rather shared between all possible logs.
Also, by making it local to the .cc, not a member, we reduce the necessity of making RtcEventLog::Create a friend of the implementation. This necessity is removed completely by a following CL.
BUG=webrtc:8111
NOPRESUBMIT=True
Change-Id: I03044ed55ceeaf0064d5207b7407926571590699
Reviewed-on: https://webrtc-review.googlesource.com/1236
Commit-Queue: Elad Alon <eladalon@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19870}
rtc_event_log2text doesn't currently handle all possible RtcEvent-s.
1. Previous CL - to make sure events are not forgotten in the future, change the succession of if-statements to a switch, so that the compiler would complain if events are ever added, but are not handled here.
2. This CL - add handling of currently-unhandled events.
BUG=webrtc:8111
Change-Id: I5c726c077483b5d85cf8060674c8191a90cb84cc
Reviewed-on: https://webrtc-review.googlesource.com/1244
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Elad Alon <eladalon@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19869}
Wrapper pattern is widely used in DesktopCapturer implementations. So this
change adds DesktopCapturerWrapper and CaptureResultDesktopCapturerWrapper as
the base classes of other wrappers. Implementing a new wrapper should become
easy, the implementation does not need to care about the uninteresting
overrides.
Bug: chromium:764258
Change-Id: If91c1b5e778805906f7f77854ea5600aa61bf64a
Reviewed-on: https://webrtc-review.googlesource.com/1420
Commit-Queue: Zijie He <zijiehe@google.com>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#19868}
