- TCPPort::~TCPPort() was leaking incoming_ sockets; now they are deleted.
- PeerConnection::RemoveStream() now removes streams even if the
PeerConnection::IsClosed(). Previously such streams would never get removed.
- Gave MediaStreamTrackInterface a virtual destructor to ensure deletes on base
pointers are dispatched virtually.
- VideoTrack.dispose() delegates to super.dispose() (instead of leaking)
- PeerConnection.dispose() now removes streams before disposing of them.
- MediaStream.dispose() now removes tracks before disposing of them.
- VideoCapturer.dispose() only unowned VideoCapturers (mirroring C++ API)
- AppRTCDemo.disconnectAndExit() now correctly .dispose()s its
VideoSource and PeerConnectionFactory.
- CHECK that Release()d objects are deleted when expected to (i.e. no ref-cycles
or missing .dispose() calls) in the Java API.
- Create & Return webrtc::Traces at factory birth/death to be able to assert
that _all_ threads started during the test are collected by the end.
- Name threads attached to the JVM more informatively for debugging.
- Removed a bunch of unnecessary scoped_refptr instances in
peerconnection_jni.cc whose only job was messing with refcounts.
RISK=P2
TESTED=AppRTCDemo can be ended and restarted just fine instead of crashing on camera unavailability. No more post-app-exit logcat lines. PCTest.java now asserts that all threads are collected before exit.
BUG=2183
R=wu@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2005004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4534 4adac7df-926f-26a2-2b94-8c16560cd09d
When VideoDecoder::Decode, Reset, or Release is called,
VideoCodingModuleImpl::_receiveCritSect may have been
acquired. Decode callback needs to acquire the same lock
in ViEChannel::FrameToRender. It is not a problem for
SW decode because decode callback is run on the same
WebRTC decoding thread and the lock is re-entrant. But
for HW decode, decode callback is run on a thread different
from WebRTC decoding thread. Decode callback gets the locks
in the opposite order. Deadlock can happen.
BUG=http://crbug.com/170345
TEST=Try apprtc.appspot.com/?debug=loopback on ARM Chromebook Daisy.
Run libjingle_peerconnection_unittest.
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1997005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4523 4adac7df-926f-26a2-2b94-8c16560cd09d
Running with a network thread provides a more realistic simulation. Like
a real network, packets are handed off to a socket, or buffer, and then
the call returns. This prevents weird scenarios when both the sending
side and receiving side are on the call stack simultaneously, which can
cause deadlocks as locks could otherwise be taken simultaneously in both
the sender and receiver order by the same thread.
BUG=
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2000005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4522 4adac7df-926f-26a2-2b94-8c16560cd09d
This version of LoopBackTransport hands packets over to a network thread
which will deliver them instead. This allows SendRTP and SendRTCP to
always be able to return, preventing deadlocks in voe_auto_test. The
previous case did not represent actual network usage. Now the send and
receive side can run concurrently with the receiving side. Previously
the sender thread also drove the receiving side, which does not
represent the regular use case where packets are put on a network
socket.
BUG=1568,2081,2178
TEST=Ran VoiceEngine RtpRtcpTest.*, known for deadlocking, 100+ times.
R=xians@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1985005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4516 4adac7df-926f-26a2-2b94-8c16560cd09d
When VideoDecoder::Decode, Reset, or Release is called,
VideoCodingModuleImpl::_receiveCritSect may have been
acquired. Decode callback needs to acquire the same lock
in ViEChannel::FrameToRender. It is not a problem for
SW decode because decode callback is run on the same
WebRTC decoding thread and the lock is re-entrant. But
for HW decode, decode callback is run on a thread different
from WebRTC decoding thread. Decode callback gets the locks
in the opposite order. Deadlock can happen.
BUG=http://crbug.com/170345
TEST=Try apprtc.appspot.com/?debug=loopback on ARM Chromebook Daisy.
R=stefan@webrtc.org, wu@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1977004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4509 4adac7df-926f-26a2-2b94-8c16560cd09d
The complexity of the last ChannelManager and potentially usage of it as well caused race conditions and deadlocks in loopback voe_auto_test. This ref-counted solution takes no long-term locks, uses less locks overall and is significantly easier to understand.
ScopedChannel has been split up into a ChannelOwner with a reference to a channel and an Iterator over ChannelManager. Previous code was really used for both things. ChannelOwner is used as a shared pointer to a channel object, while an Iterator should work as expected.
BUG=2081
R=tommi@webrtc.org, xians@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1802004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4502 4adac7df-926f-26a2-2b94-8c16560cd09d
The test works by randomly dropping small bursts of packets until enough
NACKs have been sent back by the receiver. Retransmitted packets are
never dropped in order to assure that all packets are eventually
delivered. When enough NACK packets have been received and all dropped
packets retransmitted, the test waits for the receiving side to send a
number of RTCP packets without NACK lists to assure that the receiving
side stops sending NACKs once packets have been retransmitted.
BUG=2043
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1934004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4482 4adac7df-926f-26a2-2b94-8c16560cd09d
