* 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 1c3e728aa9.
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
VirtualSocketServer, when binding to any address (all 0s), will assign a unique IP address by incrementing the IP address, resulted in 0.0.0.1. However, this breaks the testing of 4276 where we bind to all 0s and expect the local address should remain all 0s.
BUG=4276
R=pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/35189004
Cr-Commit-Position: refs/heads/master@{#8370}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8370 4adac7df-926f-26a2-2b94-8c16560cd09d
There are only 2 things that prevent the output to be bit-exact:
* The zero initialization of the postfilter_mask_ and high_pass_postfilter_mask_, which only afects the first blocks.
* The re-tuning of the target presence estimation, since only the bins between low_average_start_bin_ and high_average_end_bin_ are of interest.
This latter was not taken into account before.
R=andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/35139004
Cr-Commit-Position: refs/heads/master@{#8368}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8368 4adac7df-926f-26a2-2b94-8c16560cd09d
