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
DecodedImageCallback is allowed to be called on a thread different from decoding thread. To avoid the deadlock in VCMDecodedFrameCallback::Decoded, VCMDecodedFrameCallback::_critSect should not be held while calling VCMReceiveCallback::FrameToRender.
BUG=1832
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1570004
Patch from Wu-Cheng Li <wuchengli@chromium.org>.
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4162 4adac7df-926f-26a2-2b94-8c16560cd09d
- Pad packets (empty) were often NACKed even though they were received.
- Padding only frames (empty) were didn't properly update the decoding state,
and would therefore be NACKed even though they were received.
This is a recommit of r3183. Extensive testing suggest that this may have been caused by virtual machine flakiness.
TBR=mflodman@webrtc.org
BUG=1150
Review URL: https://webrtc-codereview.appspot.com/971011
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3200 4adac7df-926f-26a2-2b94-8c16560cd09d
- Pad packets (empty) were often NACKed even though they were received.
- Padding only frames (empty) were didn't properly update the decoding state,
and would therefore be NACKed even though they were received.
TEST=trybots
BUG=1150
Review URL: https://webrtc-codereview.appspot.com/929031
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3183 4adac7df-926f-26a2-2b94-8c16560cd09d
- Pad packets (empty) were often NACKed even though they were received.
- Padding only frames (empty) didn't properly update the decoding state,
and would therefore be NACKed even though they were received.
TEST=trybots
BUG=1150
Review URL: https://webrtc-codereview.appspot.com/966026
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3181 4adac7df-926f-26a2-2b94-8c16560cd09d
