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}
Passing the call through JNI is unnecessary.
Bug: webrtc:7730
Change-Id: Icf1ecd7e2ea54033342120311c70d47b4a4f7c9a
Reviewed-on: https://chromium-review.googlesource.com/521050
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Commit-Queue: Sami Kalliomäki <sakal@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#18408}
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}
