WebRTC binds to individual NICs and listens for incoming Stun packets. Sending stun through this specific NIC binding could make OS route the packet differently hence exposing non-VPN public IP.
The fix here is
1. to bind to any address (0:0:0:0) instead. This way, the routing will be the same as how chrome/http is.
2. also, remove the any all 0s addresses which happens when we bind to all 0s.
BUG=4276
R=juberti@webrtc.org
Committed: https://code.google.com/p/webrtc/source/detail?r=8418
Review URL: https://webrtc-codereview.appspot.com/39129004
Cr-Commit-Position: refs/heads/master@{#8419}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8419 4adac7df-926f-26a2-2b94-8c16560cd09d
WebRTC binds to individual NICs and listens for incoming Stun packets. Sending stun through this specific NIC binding could make OS route the packet differently hence exposing non-VPN public IP.
The fix here is
1. to bind to any address (0:0:0:0) instead. This way, the routing will be the same as how chrome/http is.
2. also, remove the any all 0s addresses which happens when we bind to all 0s.
BUG=4276
R=juberti@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/39129004
Cr-Commit-Position: refs/heads/master@{#8418}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8418 4adac7df-926f-26a2-2b94-8c16560cd09d
* Only compare actual pixel data, not the padding between width and stride.
* When creating a frame from raw buffers with excessive size, do not assume that the frame’s allocated size will be as excessive as the input buffers.
* The arrays in TestI420VideoFrame.CopyFrame and TestI420VideoFrame.CloneFrame are too small, and we currently memcpy out of bounds.
I think this CL should land regardless, but the main purpose is to pave the way for for planned changes to I420VideoFrame. See https://review.webrtc.org/38879004.
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/34199004
Cr-Commit-Position: refs/heads/master@{#8416}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8416 4adac7df-926f-26a2-2b94-8c16560cd09d
This reverts commit 1c3e728aa9b886fd3ee008a5aed956759bc3f82d.
Reason: Fails test running on Nexus 9 bots - org.webrtc.VideoCapturerAndroidTest#testStartStopWithDifferentResolutions.
Note that all other tests pass so it seems like there is resolution supported by the device that can't use YV12.
TBR=glaznev@webrtc.org
BUG=4011
Review URL: https://webrtc-codereview.appspot.com/42389004
Cr-Commit-Position: refs/heads/master@{#8414}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8414 4adac7df-926f-26a2-2b94-8c16560cd09d
The old AcmOpusTest depends on the ACMOpus class, but this class was
obsoleted by AudioEncoderOpus. In this CL, the test code is re-written
to use AudioEncoderOpus and ACMGenericCodecWrapper instead of
ACMOpus. Most of the test functionality is preserved, except for the
packet loss rate tests, which where already transferred to
AudioEncoderOpusTest in r8244.
R=kwiberg@webrtc.org, minyue@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/40029004
Cr-Commit-Position: refs/heads/master@{#8410}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8410 4adac7df-926f-26a2-2b94-8c16560cd09d
Although sample_rate_hz(), num_channels(), and rtp_timestamp_rate_hz()
are simple accessors for almost all implementations of AudioEncoder,
they are virtual and not guaranteed to be just simple accessors. Thus,
it makes more sense to use the normal CamelCase naming scheme.
BUG=4235
R=henrik.lundin@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/34239004
Cr-Commit-Position: refs/heads/master@{#8407}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8407 4adac7df-926f-26a2-2b94-8c16560cd09d
Instead of sending a black frame that's the size of the VideoFormat send
a black frame in the format we're already sending. This prevents
expensive encoder reconfiguration when the sending format is a different
resolution. This speeds up setting a null capturer (removing the
capturer) significantly as it doesn't entail an encoder reconfiguration.
R=mflodman@webrtc.org, pthatcher@webrtc.org
BUG=1788
Review URL: https://webrtc-codereview.appspot.com/39179004
Cr-Commit-Position: refs/heads/master@{#8405}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8405 4adac7df-926f-26a2-2b94-8c16560cd09d
It’s possible to implement cricket::VideoFrame::CopyToBuffer using the virtual interface. This removes the need for subclasses to implement their own versions. This CL also fixes a bug in cricket::VideoFrame::CopyToPlanes which currently assumes that GetUPitch() == GetVPitch(), otherwise it may segfault.
I think this CL should land regardless, but the main purpose is to pave the way for for planned changes to I420VideoFrame. See https://review.webrtc.org/38879004.
R=fbarchard@google.com, perkj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/39889004
Cr-Commit-Position: refs/heads/master@{#8403}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8403 4adac7df-926f-26a2-2b94-8c16560cd09d
Unblocks pending threads (render thread + decoder thread) when
destroying renderers and shutting down decoders.
Speeds up SetLocalDescription significantly (10x or so) under
WebRtcVideoEngine2 but also shutdown times in ~ViEChannel and
~ViEReceiver in general.
BUG=1788
R=mflodman@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/41959004
Cr-Commit-Position: refs/heads/master@{#8387}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8387 4adac7df-926f-26a2-2b94-8c16560cd09d
Bitrate controller is used in VoiceEngine to smoothen the fraction loss
from RTCP report blocks. This CL removes the usage of the
BitrateController and calculates its own fraction loss average insted.
This introduces some duplicated code between BitrateController and
Channel, but removes processing overhead and the incorrect bandwidth
estimation numbers reported by the bitrate controller.
BUG=4310
TEST=voe_cmd_test with network simulator
R=minyue@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/39999004
Cr-Commit-Position: refs/heads/master@{#8386}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8386 4adac7df-926f-26a2-2b94-8c16560cd09d
Modifies WebRtcVideoSendStream to use a default width/height of 16px.
This significantly reduces SetRemoteDescription time under
WebRtcVideoEngine2. Also preventing (expensive) reconfigurations due to
incoming frames when the channel is not sending yet.
Tests have been modified to generate a frame before expecting a certain
encoder size to have been configured.
Also adding tracing to WebRtcVideoSendStream::InputFrame as it can lead
to reconfigurations of the encoder which is expensive and it should show
up in chrome://tracing.
BUG=1788
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42369004
Cr-Commit-Position: refs/heads/master@{#8381}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8381 4adac7df-926f-26a2-2b94-8c16560cd09d
In some cases it was not possible to set another payload type for CNG
than the default one. This CL fixes this. The problem was also
dependent on whether the comfort noise codec was registered before or
after the speech codec.
A test is implement to expose the bug, registering comfort noise at a
non-default payload type, and both before and after the speech codec.
BUG=4228
R=kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/35199004
Cr-Commit-Position: refs/heads/master@{#8380}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8380 4adac7df-926f-26a2-2b94-8c16560cd09d
