ViEChannels without default encoders doesn't register a receive codec by
default. This makes VideoReceiver::Decode return early, causing a
high-priority thread to effectively be busy looping. This would be
expected to wreck more havoc in a more cross-platform manner than it has
visibly done. On Windows XP however it manages to bring the whole
machine to a grinding halt forcing a reboot if CPU usage hits 100%.
BUG=chromium:470013
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/48049004
Cr-Commit-Position: refs/heads/master@{#8976}
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
This fixes a variety of MSVC warnings about value truncations when implicitly
storing the 64-bit values we get back from e.g. TimeTicks in 32-bit objects, and
removes the need for a number of explicit casts.
This also moves a number of constants so they're declared right where they're used, which is easier to read and maintain, and makes some of them of integral type rather than using the "enum hack".
BUG=chromium:81439
TEST=none
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/33649004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7905 4adac7df-926f-26a2-2b94-8c16560cd09d
Removes direct VideoCodec use from the new API, exposes VideoDecoders
through webrtc/video_decoder.h similar to VideoEncoders.
Also includes some preparation for wiring up external decoders in
WebRtcVideoEngine2 by adding AllocatedDecoders that specify whether they
were allocated internally or externally.
Additionally addresses a data race in VideoReceiver that was exposed with this change.
R=mflodman@webrtc.org, stefan@webrtc.orgTBR=pthatcher@webrtc.org
BUG=2854,1667
Review URL: https://webrtc-codereview.appspot.com/27829004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7560 4adac7df-926f-26a2-2b94-8c16560cd09d
In webrtc::vcm::VideoReceiver::ResetDecoder(), the lock order is:
1. take _receiveCritSect,
2. take process_crit_sect_
This conflicts with the follow code path:
1. webrtc::vcm::VideoReceiver::Process(), take process_crit_sect_
call -> webrtc::vcm::VideoReceiver::NackList(),
2. with nackStats=kNackKeyFrameRequest, take _receiveCritSect
BUG=2861
TEST=trybots
R=sprang@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/7749004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5456 4adac7df-926f-26a2-2b94-8c16560cd09d