The webrtc/supplement.gypi contains a source listing of the
suppressions for TSan and LSan, which are located in source files.
It makes the presubmit fail when it's updated, which is confusing.
NOTRY=True
TESTED=Edited webrtc/supplement.gypi and ran "git cl presubmit" without an error.
Review URL: https://codereview.webrtc.org/1649423002
Cr-Commit-Position: refs/heads/master@{#11457}
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}
For example, when the TURN port has an ALLOCATE_MISMATCH error.
BUG=webrtc:5432
Review URL: https://codereview.webrtc.org/1595613004
Cr-Commit-Position: refs/heads/master@{#11453}
- Add extra logging for Android HW codec corner cases
when frames are dropped or resolution is changed.
- Use presentation timestamps for decoded frame logging.
- Enable key frame sending on long frame gap for
H.264 codec.
BUG=b/26504665
Review URL: https://codereview.webrtc.org/1653523003
Cr-Commit-Position: refs/heads/master@{#11452}
Some WebRTC client had a problem with the change "Removing webrtc::AudioFrame::energy_". Now it is solved.
This reverts commit 2bdcfadc8abd418a30dd5cdf54ba45a429d3d9bf.
BUG=webrtc:3315
Review URL: https://codereview.webrtc.org/1638553003
Cr-Commit-Position: refs/heads/master@{#11448}
A couple of mutables were added after last removal of mutables, so
removing those. rtc::CriticalSection is const-lockable.
BUG=
R=tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1652983002
Cr-Commit-Position: refs/heads/master@{#11447}
Reason for revert:
May be the reason for mac_asan timeout
Original issue's description:
> Changed test to validate rtp timstamps not just in RTP packets but also in RTCP Sender Reports.
> Altered it to accept negative value since it is normal for RTCP packet coming before RTP packet to have slightly later time.
>
> BUG=webrtc:5433
>
> Committed: https://crrev.com/f4b9c775122b463db7eb2c4101603759a0d00caf
> Cr-Commit-Position: refs/heads/master@{#11417}
TBR=pbos@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:5433
Review URL: https://codereview.webrtc.org/1652973002
Cr-Commit-Position: refs/heads/master@{#11446}
This makes it possible to handle send and receive streams with the same SSRC, which is currently the case in some peer connection tests.
Also moves sending transport feedback to the pacer thread.
BUG=webrtc:5263
Review URL: https://codereview.webrtc.org/1628683002
Cr-Commit-Position: refs/heads/master@{#11443}
We have seen an instance of flakiness of the perf tests where it looked
like timestamp wraparound could be an issue. Better safe...
BUG=
Review URL: https://codereview.webrtc.org/1645463002
Cr-Commit-Position: refs/heads/master@{#11440}
Visual Studio 2015 balks at the implicit truncation of values. Easily fixed with an explicit cast.
Fixed redefinition of CLOCKS_PER_SEC when using Visual Studio 2015 and the Windows 10 SDK. CLOCKS_PER_SEC is also defined in "<WIN10 SDK DIR>\include\10.0.10240.0\ucrt\time.h" and also has the value of 1000
Hiding snprintf definition if building with Visual Studio 2015
Fixed C4573 compiler complaint in audio_processing_impl_locking_unittest.cc.
BUG=webrtc:5183
Review URL: https://codereview.webrtc.org/1412653006
Cr-Commit-Position: refs/heads/master@{#11434}
If it still handle packets, when a ping arrives, it will pass the packet to p2ptransportchannel, eventually causing an ASSERT error there (when p2ptransportchannel tries to create a connection from the ping request from unknown address).
BUG=
Review URL: https://codereview.webrtc.org/1649493006
Cr-Commit-Position: refs/heads/master@{#11430}
including options related to experimental constraints which are
recognized but never applied.
BUG=webrtc:5426
Review URL: https://codereview.webrtc.org/1642513002
Cr-Commit-Position: refs/heads/master@{#11424}
It's never used anywhere, so it only causes confusion between
itself and SessionDescriptionInterface::candidates.
Review URL: https://codereview.webrtc.org/1642733002
Cr-Commit-Position: refs/heads/master@{#11420}
This argument is never used as a reference and the pointer that's bound
to the const reference may be nullptr. This is undefined behavior and
barks under UBSan.
BUG=webrtc:5124
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1642863003 .
Cr-Commit-Position: refs/heads/master@{#11418}
Altered it to accept negative value since it is normal for RTCP packet coming before RTP packet to have slightly later time.
BUG=webrtc:5433
Review URL: https://codereview.webrtc.org/1633843003
Cr-Commit-Position: refs/heads/master@{#11417}
The plan is that this interface should be used by all classes which receive a stream of video frames, and replace the two generic classes webrtc::VideoRendererInterface and cricket::VideoRenderer.
And the list goes on, there's a dozen of different classes which act as video frame sinks.
At some point, we will likely add some method to handle sink properties like, e.g, maximum useful width and height. But hopefully this can be done while keeping the interface very simple.
BUG=webrtc:5426
R=perkj@webrtc.org, pthatcher@webrtc.org
Committed: https://crrev.com/a862d4563fbc26e52bed442de784094ae1dfe5ee
Cr-Commit-Position: refs/heads/master@{#11396}
Review URL: https://codereview.webrtc.org/1594973006
Cr-Commit-Position: refs/heads/master@{#11414}
This is somewhat easier than looking up the media type by iterating pc.getLocalStreams / pc.getRemoteStreams and all tracks. Temporary until stats get revamped to conform to the spec obviously.
BUG=webrtc:4117
Review URL: https://codereview.webrtc.org/1307633007
Cr-Commit-Position: refs/heads/master@{#11412}
The level of the error signal after linear echo cancellation was based on non-buffered signal while that of the near-end and far-end signal based on buffered signal. This discrepancy made the comparison of them unfair.
This CL is to make calculating the error level rely on the same buffering.
BUG=
Review URL: https://codereview.webrtc.org/1510873004
Cr-Commit-Position: refs/heads/master@{#11408}
