Removes AddRenderCallback from ViERenderer and implements
VideoReceiveStream on top of DeliverI420Frame like WebRtcVideoEngine
currently does today.
Also adds ::IsTextureSupported() to the VideoRenderer interface to
permit querying whether an external renderer supports texture rendering.
R=stefan@webrtc.orgTBR=mflodman@webrtc.org
BUG=1667
Review URL: https://webrtc-codereview.appspot.com/34169004
Cr-Commit-Position: refs/heads/master@{#8299}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8299 4adac7df-926f-26a2-2b94-8c16560cd09d
This makes it possible to build more flexible simulations, and makes it easier to implement bi-directional simulations. This also removes support for generating baseline files and comparing against a baseline, which hasn't turned out to be particuarly useful.
BUG=4173
R=pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/34989004
Cr-Commit-Position: refs/heads/master@{#8297}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8297 4adac7df-926f-26a2-2b94-8c16560cd09d
This fixes occasional hangs we've been seeing in the past few days. I'm using rtc::Event instead of the EventWrapper, so I'll wait with landing this cl until I've made that change in a separate cl.
BUG=2822,4282
R=pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/38009004
Cr-Commit-Position: refs/heads/master@{#8293}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8293 4adac7df-926f-26a2-2b94-8c16560cd09d
The issue that was causing the thread checker to report error, turned out to be unrelated.
> Revert 8203 "Reducing locking in OveruseFrameDetector and increa..."
>
> Broke tests in Chrome for some reason:
>
> [ RUN ] WebRtcAecDumpBrowserTest.CallWithAecDump
> [80131:1287:0129/074432:30561723987517:ERROR:vt_video_decode_accelerator.cc(132)] Failed to create VTDecompressionSession: codecOpenErr (-8973)
> [80129:1287:0129/074432:30562276677373:INFO:CONSOLE(64)] "Looking at video in element remote-view-1", source: http://127.0.0.1:61401/media/webrtc_test_utilities.js (64)
> [80129:1287:0129/074432:30562281435788:INFO:CONSOLE(64)] "Looking at video in element remote-view-2", source: http://127.0.0.1:61401/media/webrtc_test_utilities.js (64)
> [80129:1287:0129/074432:30562315329399:INFO:CONSOLE(800)] "Negotiating call...", source: http://127.0.0.1:61401/media/peerconnection-call.html (800)
> [80133:29187:0129/074432:30562402039578:FATAL:overuse_frame_detector.cc(388)] Check failed: processing_thread_.CalledOnValidThread().
> 0 libbase.dylib 0x000000010dfd688f base::debug::StackTrace::StackTrace() + 47
> 1 libbase.dylib 0x000000010dfd68e3 base::debug::StackTrace::StackTrace() + 35
> 2 libbase.dylib 0x000000010e030076 logging::LogMessage::~LogMessage() + 70
> 3 libbase.dylib 0x000000010e02f0c3 logging::LogMessage::~LogMessage() + 35
> 4 libcontent.dylib 0x000000011d8c0cd5 webrtc::OveruseFrameDetector::TimeUntilNextProcess() + 245
> 5 libcontent.dylib 0x000000011d31ddfd webrtc::ProcessThreadImpl::Process() + 525
> 6 libcontent.dylib 0x000000011d31d836 webrtc::ProcessThreadImpl::Run(void*) + 38
> 7 libcontent.dylib 0x000000011d10c390 webrtc::ThreadPosix::Run() + 288
> 8 libcontent.dylib 0x000000011d10c076 webrtc::StartThread(void*) + 38
> 9 libsystem_pthread.dylib 0x00007fff8e667899 _pthread_body + 138
> 10 libsystem_pthread.dylib 0x00007fff8e66772a _pthread_struct_init + 0
> 11 libsystem_pthread.dylib 0x00007fff8e66bfc9 thread_start + 13
>
>
> > Reducing locking in OveruseFrameDetector and increasing constness.
> >
> > I also added a few TODOs there to see what we can do to reduce the chance of contention.
> > To catch regressions, I've started using the ThreadChecker class on the processing thread but it might also be a good idea to add similar checks for other known threads such as the thread we receive frames on. I'm sure we can reduce locking even further.
> >
> > BUG=2822
> > R=asapersson@webrtc.org
> >
> > Review URL: https://webrtc-codereview.appspot.com/33129004
>
> TBR=tommi@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/34079004TBR=tommi@webrtc.org
BUG=
Review URL: https://webrtc-codereview.appspot.com/35029004
Cr-Commit-Position: refs/heads/master@{#8287}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8287 4adac7df-926f-26a2-2b94-8c16560cd09d
We apparently hit an obscure problem on mac where seemingly an unaligned mutex causes memory corruption.
The effect was that the |modules_| list became corrupt and we crashed. At this point I'm not exactly
sure what the alignment requirements are but for now, I've fixed up the layout in a way that doesn't cause these same issues.
I'm also changing auto->proper type at the request of drive by reviewers from my previous cl in the same file.
TBR=pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/38989004
Cr-Commit-Position: refs/heads/master@{#8286}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8286 4adac7df-926f-26a2-2b94-8c16560cd09d
Like PlatformThreadId, this type is borrowed from Chromium.
The difference between the two is that PlatformThreadRef is pthread_t on posix platforms.
On Windows PlatformThreadRef and PlatformThreadId are the same thing.
The reason for this switch is pretty crazy. On Chromium's "Mac 10.9 dbg" bot,
we have been seeing the following code:
ThreadCheckerImpl::ThreadCheckerImpl() : valid_thread_(CurrentThreadId()) {
fprintf(stderr, "*** valid=%d\n", valid_thread_);
valid_thread_ = CurrentThreadId();
fprintf(stderr, "*** valid after=%d\n", valid_thread_);
}
print this:
*** valid=946872320
*** valid after=5647
This is for the same thread checker instance.
What's worse is that printing out what CurrentThreadId was returning, yielded that it was always returning 5647.
After switching over to pthread_t on Mac, this stopped happening.
So, to remove the current hack, reinstate the class on Mac and take a look at the next problem, I'm switching to pthread_t.
Really looking forward to truly getting to the bottom of this.
Tbr-ing since the build is essentially broken (we can't roll).
TBR=pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/37199004
Cr-Commit-Position: refs/heads/master@{#8283}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8283 4adac7df-926f-26a2-2b94-8c16560cd09d
I'm reverting the patch due to compilation issues. It would be great if we could make sure Chromium is ready for the patch before we land it in WebRTC.
As is, we're trying to roll webrtc into Chromium and we can't (this is not the only reason though). I might reland this after the roll, depending on how that goes though.
Here's an example failure:
e:\b\build\slave\win_gn\build\src\jingle\glue\channel_socket_adapter_unittest.cc(77) : error C2259: 'jingle_glue::MockTransportChannel' : cannot instantiate abstract class
due to following members:
'bool cricket::TransportChannel::GetSslCipher(std::string *)' : is abstract
e:\b\build\slave\win_gn\build\src\third_party\webrtc\p2p\base\transportchannel.h(107) : see declaration of 'cricket::TransportChannel::GetSslCipher'
ninja: build stopped: subcommand failed.
> This CL adds an API to the SSL stream adapters and transport channels to get the SSL cipher that was negotiated with the remote peer.
>
> BUG=3976
> R=davidben@chromium.org, juberti@webrtc.org, pthatcher@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/26009004TBR=pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/40689004
Cr-Commit-Position: refs/heads/master@{#8282}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8282 4adac7df-926f-26a2-2b94-8c16560cd09d
Failed on Linux_Memcheck bot.
http://chromegw/i/client.webrtc/builders/Linux%20Memcheck/builds/3182
> VirtualSocketServer out-of-order issue with closing TCP sockets
>
> https://webrtc-codereview.appspot.com/41449004 added a TURN TCP
> allocation release test which was disabled as it triggered an assert
> in the turnserver.
>
> This was caused by VirtualSockerServer delivering the last TCP packet
> after closing the connection. Calling
> VirtualSocketServer::SendTcp
> and
> VirtualSocket::Close
> from TestTurnTCPReleaseAllocation led to the following order of
> messages in VirtualSocket::OnMessage:
> MSG_ID_DISCONNECT
> MSG_ID_PACKET
>
> This is out of order and triggers an assert in turnserver.cc since the
> socket from which the message arrives has already been discarded,
> subsequently breaking the test.
>
> In VirtualSocketServer::Disconnect the MSG_ID_DISCONNECT is posted to the
> msg_queue immediately, thus getting ahead of any (slightly delayed)
> actual packets.
>
> Maybe PostAt(network_delay_ + 1, ...) would be better?
>
> Re-enables TestTurnTCPReleaseAllocation.
>
> BUG=
> R=juberti@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/34759004TBR=pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/38979004
Cr-Commit-Position: refs/heads/master@{#8280}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8280 4adac7df-926f-26a2-2b94-8c16560cd09d
Previously only mic level calculated by the legacy agc was logged in aecdebug dumps.
Now we log it for any agc.
In addition, it is now possible to turn on and off debug recording in the test tool voe_cmd_test.
BUG=4274
TESTED=verified using voe_cmd_test
R=andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/39839004
Cr-Commit-Position: refs/heads/master@{#8274}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8274 4adac7df-926f-26a2-2b94-8c16560cd09d
https://webrtc-codereview.appspot.com/41449004 added a TURN TCP
allocation release test which was disabled as it triggered an assert
in the turnserver.
This was caused by VirtualSockerServer delivering the last TCP packet
after closing the connection. Calling
VirtualSocketServer::SendTcp
and
VirtualSocket::Close
from TestTurnTCPReleaseAllocation led to the following order of
messages in VirtualSocket::OnMessage:
MSG_ID_DISCONNECT
MSG_ID_PACKET
This is out of order and triggers an assert in turnserver.cc since the
socket from which the message arrives has already been discarded,
subsequently breaking the test.
In VirtualSocketServer::Disconnect the MSG_ID_DISCONNECT is posted to the
msg_queue immediately, thus getting ahead of any (slightly delayed)
actual packets.
Maybe PostAt(network_delay_ + 1, ...) would be better?
Re-enables TestTurnTCPReleaseAllocation.
BUG=
R=juberti@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/34759004
Cr-Commit-Position: refs/heads/master@{#8271}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8271 4adac7df-926f-26a2-2b94-8c16560cd09d
In order to figure out the issue with the Mac 10.9 debug bot, this patch disables the ThreadChecker class on Mac in debug builds. For diagnostic purposes, it instead prints out when there's a thread mismatch. I'm also adding a DCHECK in case fetching the current thread id ever returns 0.
R=magjed@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/40679004
Cr-Commit-Position: refs/heads/master@{#8269}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8269 4adac7df-926f-26a2-2b94-8c16560cd09d
This change switches from the old codec wrappers ACMPCMU and ACMPCMA
to the new AudioEncoderPcmU and AudioEncoderPcmA wrapped in an
ACMGenericCodecWrapper. RED and CNG is also switched to using their
AudioEncoder implementations (AudioEncoderCopyRed and AudioEncoderCng,
respectively), when RED and/or CNG is combined with PCM u/A.
This is the first in a series of changes that will switch all codecs
to use the new AudioEncoder interface.
BUG=4228
COAUTHOR=kwiberg@webrtc.orgR=minyue@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/33209004
Cr-Commit-Position: refs/heads/master@{#8268}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8268 4adac7df-926f-26a2-2b94-8c16560cd09d
sending RTP module for the specified simulcast layer a frame belongs to.
This CL also removes the corresponding functionality from the RTP RTCP
module and fixes lint warnings in the files touched.
BUG=769
TEST=New unittest and manual tests
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/39629004
Cr-Commit-Position: refs/heads/master@{#8267}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8267 4adac7df-926f-26a2-2b94-8c16560cd09d
The new format instantiates the RemoteBitrateEstimator at the send-side and feeds back all packet arrival timestamps and sequence numbers to the sender, where inter-arrival deltas are calculated.
Next step will be to make feedback packets part of regular packets and send them over the network. This also requires bi-directional simulations.
BUG=4173
R=mflodman@webrtc.org, sprang@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/37109004
Cr-Commit-Position: refs/heads/master@{#8264}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8264 4adac7df-926f-26a2-2b94-8c16560cd09d
* Add a new WakeUp method that gives a module a chance to be called back right away on the worker thread.
* Wrote unit tests for the class.
* Significantly reduce the amount of locking.
- ProcessThreadImpl itself does a lot less locking.
- Reimplemented the way we keep track of when to make calls to Process.
This reduces the amount of calls to TimeUntilNextProcess and since most implementations of that function grab a lock, this means less locking.
* Renamed ProcessThread::CreateProcessThread to ProcessThread::Create.
* Added thread checks for Start/Stop. Threading model of other functions is now documented.
* We now log an error if an implementation of TimeUntilNextProcess returns a negative value (some implementations do, but the method should only return a positive nr of ms).
* Removed the DestroyProcessThread method and instead force callers to use scoped_ptr<> to maintain object lifetime.
BUG=2822
R=henrika@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/35999004
Cr-Commit-Position: refs/heads/master@{#8261}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8261 4adac7df-926f-26a2-2b94-8c16560cd09d
