Removes buffer/texture path separation inside WebRtcVideoEngine and
DeliverTextureFrame(). This unifies frame delivery with
WebRtcVideoEngine2 which is expected to automagically work with texture
frames after this change.
BUG=1788
R=magjed@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/38069005
Cr-Commit-Position: refs/heads/master@{#8326}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8326 4adac7df-926f-26a2-2b94-8c16560cd09d
This is a big refactoring of the existing C++/JNI/Java support for audio recording in native WebRTC:
- Removes unused code and old WEBRTC logging macros
- Now uses optimal sample rate and buffer size in Java AudioRecord (used hard-coded sample rate before)
- Makes code more inline with the implementation in Chrome
- Adds helper methods for JNI handling to improve readability
- Changes the threading model (high-prio audio thread now lives in Java-land and C++ only works as proxy)
- Adds basic thread checks
- Removes all locks in C++ land
- Removes all locks in Java
- Improves construction/destruction
- Additional cleanup
Tested using AppRTCDemo and WebRTCDemo APKs on N6, N5, N7, Samsung Galaxy S4 and
Samsung Galaxy S4 mini (which uses 44.1kHz as native sample rate).
BUG=NONE
R=magjed@webrtc.org, perkj@webrtc.org, pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/33969004
Cr-Commit-Position: refs/heads/master@{#8325}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8325 4adac7df-926f-26a2-2b94-8c16560cd09d
This CL performs the following renames of targets to
make GYP and GN more unified and make the targets that
have the same name as the module and include the external
render/capture implementation (the internal one is only
used by WebRTC tests).
This makes it natural to declare dependencies in GN
without having to specify the target.
Summary of the renames:
GYP:
video_render_module_impl -> video_render (new target)
video_capture_module_impl -> video_capture (new target)
GN:
video_capture -> video_capture_module (now identical to the GYP target)
video_capture_impl -> video_capture
video_render -> video_render_module (now identical to the GYP target)
video_render_impl -> video_render
BUG=456815
R=andresp@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/35099004
Cr-Commit-Position: refs/heads/master@{#8323}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8323 4adac7df-926f-26a2-2b94-8c16560cd09d
As part of the review, refactored AudioConverter into internal derived
classes, each focused on one type of conversion. A factory method
returns the correct converter (or chain of converters, via
CompositionConverter).
BUG=b/18938079
R=rojer@google.com
Review URL: https://webrtc-codereview.appspot.com/35699004
Cr-Commit-Position: refs/heads/master@{#8322}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8322 4adac7df-926f-26a2-2b94-8c16560cd09d
Now the ChannelBuffer has 2 separate arrays, one for the full-band data and one for the splitted one. The corresponding accessors are added to the ChannelBuffer.
This is done to avoid having to refresh the bands pointers in AudioBuffer. It will also allow us to have a general accessor like data()[band][channel][sample].
All the files using the ChannelBuffer needed to be re-factored.
Tested with modules_unittests, common_audio_unittests, audioproc, audioproc_f, voe_cmd_test.
R=andrew@webrtc.org, kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/36999004
Cr-Commit-Position: refs/heads/master@{#8318}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8318 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/35069004
Cr-Commit-Position: refs/heads/master@{#8311}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8311 4adac7df-926f-26a2-2b94-8c16560cd09d
This CL moves the pacer out from the regular module process thread to
instead use one thread per pacer. This is to get better accuracy for the
paced packets and to avoid overusing the module process thread.
BUG=
TEST=existing tests
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/41839004
Cr-Commit-Position: refs/heads/master@{#8308}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8308 4adac7df-926f-26a2-2b94-8c16560cd09d
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
