Make resilience configurable in video processor integration tests.
BUG=webrtc:6783
Review-Url: https://codereview.webrtc.org/2919803002
Cr-Commit-Position: refs/heads/master@{#18493}
Track perf for a test using 200kbps link, 5% packet loss and queue
length of 30 packets. This currently performs poorly.
BUG=webrtc:7694
Review-Url: https://codereview.webrtc.org/2930703002
Cr-Commit-Position: refs/heads/master@{#18488}
Reason for revert:
Compile Error.
Original issue's description:
> The simulator puts into action the schedule of speech turns encoded in a MultiEndCall instance. The output is a set of audio track pairs. There is one set for each speaker and each set contains one near-end and one far-end audio track. The tracks are directly written into wav files instead of creating them in memory. To speed up the creation of the output wav files, *all* the source audio tracks (i.e., the atomic speech turns) are pre-loaded.
>
> The ConversationalSpeechTest.MultiEndCallSimulator unit test defines a conversational speech sequence and creates two wav files (with pure tones at 440 and 880 Hz) that are used as atomic speech turn tracks.
>
> This CL also patches MultiEndCall in order to allow input audio tracks with same sample rate and single channel only.
>
> BUG=webrtc:7218
>
> Review-Url: https://codereview.webrtc.org/2790933002
> Cr-Commit-Position: refs/heads/master@{#18480}
> Committed: 6b648c4697TBR=minyue@webrtc.org,alessiob@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:7218
Review-Url: https://codereview.webrtc.org/2925123003
Cr-Commit-Position: refs/heads/master@{#18481}
The ConversationalSpeechTest.MultiEndCallSimulator unit test defines a conversational speech sequence and creates two wav files (with pure tones at 440 and 880 Hz) that are used as atomic speech turn tracks.
This CL also patches MultiEndCall in order to allow input audio tracks with same sample rate and single channel only.
BUG=webrtc:7218
Review-Url: https://codereview.webrtc.org/2790933002
Cr-Commit-Position: refs/heads/master@{#18480}
This CL makes sure the real VideoTrackSourceInterface implementation is
destroyed on the signaling thread and marshals all method calls to the
signaling thread. This is done using VideoTrackSourceProxy.
Bug: webrtc:7767
Change-Id: Iba3b67bb32a684ba289bc8b9981585ea58084359
Reviewed-on: https://chromium-review.googlesource.com/526634
Commit-Queue: Magnus Jedvert <magjed@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#18476}
Reason for revert:
Breaks some Call perf tests that are not run by the try bots....
Original issue's description:
> Fix bug in vie_encoder.cc which caused channel parameters not to be updated at regular intervals, as it was intended.
>
> That however exposes a bunch of failed test, so this CL also fixed a few other things:
> * FakeEncoder should trust the configured FPS value rather than guesstimating itself based on the realtime clock, so as not to completely undershoot targets in offline mode. Also, compensate for key-frame overshoots when outputting delta frames.
> * FrameDropper should not assuming incoming frame rate is 0 if no frames have been seen.
> * Fix a bunch of test cases that started failing because they were relying on the fake encoder undershooting.
> * Fix test
>
> BUG=7664
>
> Review-Url: https://codereview.webrtc.org/2883963002
> Cr-Commit-Position: refs/heads/master@{#18473}
> Committed: 6431e21da6TBR=stefan@webrtc.org,holmer@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=7664
Review-Url: https://codereview.webrtc.org/2923993002
Cr-Commit-Position: refs/heads/master@{#18475}
That however exposes a bunch of failed test, so this CL also fixed a few other things:
* FakeEncoder should trust the configured FPS value rather than guesstimating itself based on the realtime clock, so as not to completely undershoot targets in offline mode. Also, compensate for key-frame overshoots when outputting delta frames.
* FrameDropper should not assuming incoming frame rate is 0 if no frames have been seen.
* Fix a bunch of test cases that started failing because they were relying on the fake encoder undershooting.
* Fix test
BUG=7664
Review-Url: https://codereview.webrtc.org/2883963002
Cr-Commit-Position: refs/heads/master@{#18473}
This build target was used by webrtc/base:webrtc_base which is not a
build target anymore. Instead we have webrtc/base:rtc_base which depends
directly on third_party/boringssl.
BUG=None
NOTRY=True
Review-Url: https://codereview.webrtc.org/2926703003
Cr-Commit-Position: refs/heads/master@{#18472}
We want the example app to only link agains the framework. This ensures
that we are actually testing the framework, and that AppRTCMobile
doesn't require any other parts of WebRTC not included in the framework.
Bug: webrtc:7759
Change-Id: Ib04aae0bc3ab2a1a508eaf4a4f15c2d37f521598
Reviewed-on: https://chromium-review.googlesource.com/522722
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Commit-Queue: Kári Tristan Helgason <kthelgason@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#18470}
Return false if ReadBits fails.
Prevents GetQp from returning true with a qp of zero.
BUG=webrtc:7662
Review-Url: https://codereview.webrtc.org/2911013002
Cr-Commit-Position: refs/heads/master@{#18462}
Reason for revert:
Breaks fuzzer.
Original issue's description:
> Only compare sequence numbers from the same SSRC in ForwardErrorCorrection.
>
> Prior to this CL, the ForwardErrorCorrection state would be reset whenever
> the difference in sequence numbers of the last recovered media packet
> and the new packet (media or FEC) was too large. This comparison did not
> take into account that FlexFEC uses a different SSRC for the FEC packets,
> meaning that the the state would be reset very frequently when FlexFEC
> is used. This should not have led to any major problems, except for a
> decreased decoding efficiency.
>
> This CL verifies that whenever we compare sequence numbers in
> ForwardErrorCorrection, they do indeed belong to the same SSRC.
>
> BUG=webrtc:5654
>
> Review-Url: https://codereview.webrtc.org/2893293003
> Cr-Commit-Position: refs/heads/master@{#18399}
> Committed: 1476a9d789TBR=stefan@webrtc.org,holmer@google.com
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2919313005
Cr-Commit-Position: refs/heads/master@{#18446}
Code should implement BBR which is the congestion controlling algorithm. BBR tries to estimate two values bottle-neck bandwidth(bw) and round trip time(rtt),then use these two values to set two control parameters pacing rate(pacing_rate),the rate at which data should be sent and congestion window size (cwnd), cwnd is the upper bound for data in flight,data_in_flight <= cwnd at all time.
BBR has four modes:
1)Startup-ramping up throughput discovering estimated bw.
2)Drain-after Startup decrease throughput to drain queues.
3)Probe Bandwidth-most of the time BBR should be in this mode,
sending data at the rate of estimated bw, while sometimes trying to discover new bandwidth.
4)Probe Rtt-in this mode BBR tries to discover new rtt for the connection.
The key moment in BBR is when we receive feedback from the receiver,as this is the only moment which should effect our two estimators. At this moment all the switches between modes should happen, except switch to ProbeRtt mode (switching to ProbeRtt mode should happen when current min_rtt value expires).
This cl serves to emphasize the structure of Bbr, when switches happen and what key classes/functions should be implemented for proper functionality.
BUG=webrtc:7713
NOTRY=True
Review-Url: https://codereview.webrtc.org/2904183002
Cr-Commit-Position: refs/heads/master@{#18444}
These interfaces will be used by the future refactoring that will
allow clients to provide custom codec implementations.
Change-Id: If199bc2807e1c27094c05983c62fa43d2eec5700
Bug: webrtc:7760
Reviewed-on: https://chromium-review.googlesource.com/522065
Commit-Queue: Sami Kalliomäki <sakal@webrtc.org>
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#18441}
Color distortion also happens on Android L. Tested on the Mi 4.
BUG=webrtc:7681
Review-Url: https://codereview.webrtc.org/2894643003
Cr-Commit-Position: refs/heads/master@{#18423}
Reason for revert:
Broken downstream project.
Original issue's description:
> Adds PeerConnectionInterface::UpdateCallBitrate to give clients more control of the bandwidth estimator. PeerConnection implements this method by passing a BitrateConfigMask to its associated Call, which is combined with the existing BitrateConfig and passed on to the SendSideCongestionController as necessary. The existing BitrateConfig generally comes from the x-google-{min,start,max}-bitrate params in the SDP.
>
> BUG=webrtc:7395
>
> Review-Url: https://codereview.webrtc.org/2888303005
> Cr-Commit-Position: refs/heads/master@{#18417}
> Committed: 9641c13327TBR=deadbeef@webrtc.org,stefan@webrtc.org,kwiberg@webrtc.org,solenberg@webrtc.org,holmer@google.com,zstein@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:7395
Review-Url: https://codereview.webrtc.org/2914413002
Cr-Commit-Position: refs/heads/master@{#18420}
BoringSSL (or OpenSSL) require that when SSL_write fails due to the
underlying socket being blocked, it's retried with the same parameters
until it succeeds. But we weren't doing this, and our socket
abstraction doesn't have an equivalent requirement. So when this was
occurring, we would just end up trying to send the next RTP or STUN
packet (instead of the packet that couldn't be sent), and BoringSSL
doesn't like that.
So, when this condition occurs now, we'll simply enter a "pending write"
mode and buffer the data that couldn't be completely sent. When the
underlying socket becomes writable again, or if Send is called again
before that happens, we retry sending the buffered data. Making both
BoringSSL and the upper layer of code that expects normal TCP socket
behavior happy.
Also adding some more logging, and fixing an issue with VirtualSocketServer
that made it behave slightly differently than PhysicalSocketServer when a
TCP packet is only partially read.
BUG=webrtc:7753
Review-Url: https://codereview.webrtc.org/2915243002
Cr-Commit-Position: refs/heads/master@{#18416}
Reason for revert:
Breaks tests in downstream projects.
Original issue's description:
> Protect new header extension by field trial experiment to allow hardcoding it in SDP
>
> BUG=chrome:718738
>
> Review-Url: https://codereview.webrtc.org/2922683002
> Cr-Commit-Position: refs/heads/master@{#18409}
> Committed: cafa1d6bbeTBR=sprang@webrtc.org,asapersson@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chrome:718738
Review-Url: https://codereview.webrtc.org/2922723002
Cr-Commit-Position: refs/heads/master@{#18414}
- Reads and dispatches buffers from a video file, along the lines of
camera capturer.
- Initial purpose of this class will be for testing.
BUG=webrtc:7581
Review-Url: https://codereview.webrtc.org/2887673002
Cr-Commit-Position: refs/heads/master@{#18412}
Use RTC_CHECK to crash if attempting to set an RSID whose name's length exceeds the maximum.
BUG=None
Review-Url: https://codereview.webrtc.org/2915913003
Cr-Commit-Position: refs/heads/master@{#18405}
This new VideoFrame class closesly matches the C++ webrtc::VideoFrame
and webrtc::VideoFrameBuffer classes. It's supposed to replace the
existing VideoRenderer.I420Frame. The purpose is to clean up the code
and support more frame formats.
BUG=webrtc:7749
Review-Url: https://codereview.webrtc.org/2915083002
Cr-Commit-Position: refs/heads/master@{#18404}
Move it to include path of the rtp_rtcp module to indicate it is ok to include it outside of the module.
Renamed to match the class it introduce and to reduce confusion with rtp_header_extensions.h
Bug: webrtc:5565
Change-Id: Ic4b4e9f6b75cb9275e23539cd6e88632c1e7c8d2
Reviewed-on: https://chromium-review.googlesource.com/520947
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#18402}
Prior to this CL, the ForwardErrorCorrection state would be reset whenever
the difference in sequence numbers of the last recovered media packet
and the new packet (media or FEC) was too large. This comparison did not
take into account that FlexFEC uses a different SSRC for the FEC packets,
meaning that the the state would be reset very frequently when FlexFEC
is used. This should not have led to any major problems, except for a
decreased decoding efficiency.
This CL verifies that whenever we compare sequence numbers in
ForwardErrorCorrection, they do indeed belong to the same SSRC.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2893293003
Cr-Commit-Position: refs/heads/master@{#18399}
Before 10.12, OSX may report 1X cursor on Retina screen. (See crbug.com/632995.)
After 10.12, OSX may report 2X cursor on non-Retina screen. (See
crbug.com/671436.) So scaling the cursor if the image size doesn't meet the
expected size on either Retina or non-Retina screen.
Also corrects the cursor caching and change detection, so we can only do scalingat cursor changing for better performance.
As to screen capture on OSX, the captured frame already contains the current
cursor. So the MouseCursorMonitorMac is not needed for ScreenCapture for
performance purpose.
BUG=671436
Review-Url: https://codereview.webrtc.org/2908853002
Cr-Commit-Position: refs/heads/master@{#18393}
