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
For now:
java_helpers - JNI convenience functions etc. Can in theory be moved to libjingle / webrtc general one day.
classreferenceholder - app/webrtc specific Java class loader.
androidvideocapturer_jni - the jni part of the video capturer I added.
peerconnection_jni - all the rest.
This also move all jni specifics into ns webrtc_jni to avoid naming collision.
R=glaznev@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/38099004
Cr-Commit-Position: refs/heads/master@{#8363}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8363 4adac7df-926f-26a2-2b94-8c16560cd09d
The macro is in C defined as
#define WEBRTC_SPL_MUL_16_16(a, b) ((int32_t) (((int16_t)(a)) * ((int16_t)(b))))
(For definition on ARMv7 and MIPS, see common_audio/signal_processing/include/spl_inl_armv7.h and common_audio/signal_processing/include/spl_inl_mips.h)
The replacement consists of
- avoiding casts to int16_t if inputs already are int16_t
- adding explicit cast to <type> if result is assigned to <type> (other than int or int32_t)
Some other minor code cleanup also exists.
BUG=3348, 3353
TESTED=locally on Mac and trybots
R=henrik.lundin@webrtc.org, kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/34179004
Cr-Commit-Position: refs/heads/master@{#8358}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8358 4adac7df-926f-26a2-2b94-8c16560cd09d
Removes lock-order inversion formed by RTPSenderAudio->RTPSender calls
by doing a lot shorter locking which fetches a current state of
RTPSenderAudio variables before sending.
Thread annotates locked variables and removes one lock in
RTPSenderAudio, bonus fixes data races reported in voe_auto_test
--automated under TSan (DTMF data race).
Also includes some bonus cleanup of RTPSenderVideo which removes the
send critsect completely as all methods using it was always called
from RTPSender under its send_critsect.
R=henrik.lundin@webrtc.org, stefan@webrtc.org, tommi@webrtc.org
BUG=3001, chromium:454654
Review URL: https://webrtc-codereview.appspot.com/41869004
Cr-Commit-Position: refs/heads/master@{#8348}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8348 4adac7df-926f-26a2-2b94-8c16560cd09d
Moving functionality to get max payload length from default RTP module
to the payload router.
I'll make a follow up CL changing asserts to DCHECK in rtp_rtcp_impl.cc.
BUG=769
TEST=New unittest and existing sender mtu test
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/36119004
Cr-Commit-Position: refs/heads/master@{#8345}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8345 4adac7df-926f-26a2-2b94-8c16560cd09d
PeerConnectionTest.java currently works, but only on a device with
network interfaces up. This is not a problem for desktop, but it is a
problem when running on Android devices since the devices in the lab
generally don't have network (due to the chaotic radio environment in
the device labs, devices are simply kept in flight mode).
The test does work if one modifies this line in the file
webrtc/base/network.cc:
bool ignored = ((cursor->ifa_flags & IFF_LOOPBACK) ||
IsIgnoredNetwork(*network));
If we remove the IFF_LOOPBACK clause, the test starts working on
an Android device in flight mode. This is nice - we're running the
call and packets interact with the OS network stack, which is good
for this end-to-end test. We can't just remove the clause though since
having loopback is undesirable for everyone except the test (right)?
so we need to make this behavior configurable.
This CL takes a stab at a complete solution where we pass a boolean
all the way through the Java PeerConnectionFactory down to the
BasicNetworkManager. This comes as a heavy price in interface
changes though. It's pretty out of proportion, but fundamentally we
need some way of telling the network manager that it is on Android
and in test mode. Passing the boolean all the way through is one way.
Another way might be to put the loopback filter behind an ifdef and
link a custom libjingle_peerconnection.so with the test. That is hacky
but doesn't pollute the interfaces. Not sure how to solve that in GYP
but it could mean some duplication between the production and
test .so files.
It would have been perfect to use flags here, but then we need to
hook up gflags parsing to some main() somewhere to make sure the
flag gets parsed, and make sure to pass that flag in our tests.
I'm not sure how that can be done.
Making the loopback filtering conditional is exactly how we solved the
equivalent problem in content_browsertests in Chrome, and it worked
great.
That's all I could think of.
BUG=4181
R=perkj@webrtc.org, pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/36769004
Cr-Commit-Position: refs/heads/master@{#8344}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8344 4adac7df-926f-26a2-2b94-8c16560cd09d
This change switches from the old codec wrapper ACMISAC to the new
AudioEncoderIsac wrapped in an ACMGenericCodecWrapper.
This is also the CL where the old codec for producing redundancy (RED)
is inactivated. All RED payloads are now produces through the
AudioEncoderCopyRed or AudioEncoderIsacRed classes.
BUG=4228
TEST=Please, try the iSAC codec extensively.
COAUTHOR=kwiberg@webrtc.orgR=tina.legrand@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/33249005
Cr-Commit-Position: refs/heads/master@{#8342}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8342 4adac7df-926f-26a2-2b94-8c16560cd09d
ViECapturer is always calling DeliverFrame with an empty CSRC vector, so
this is basically a dead path already. I added a DCHECK in ViEEncoder to
verify this is true.
BUG=769
TEST=Manually verified in Chromium.
R=pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/39059004
Cr-Commit-Position: refs/heads/master@{#8335}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8335 4adac7df-926f-26a2-2b94-8c16560cd09d
It's OK that state is kDown when a thread is woken after being
signalled; another tread might also have woken and already set the state
to kDown.
Even if this waking and aquiring lock has been delayed until other
threads have set state to kDown and then subsequently to kUp again with
a new Set() call, it's OK to just set kDown and return since this thread
is returning kEventSignaled after the (new) Set() has ben called.
R=pbos@webrtc.orgTBR=tommi@webrtc.org
BUG=
Review URL: https://webrtc-codereview.appspot.com/36109004
Cr-Commit-Position: refs/heads/master@{#8334}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8334 4adac7df-926f-26a2-2b94-8c16560cd09d
