* Move constants into the files/functions that use them
* Declare variables in the narrowest scope possible
* Use correct (expected, actual) order for gtest macros
* Remove unused functions
* Untabify
* 80-column limit
* Avoid C-style casts
* Prefer true typed constants to "enum hack" constants
* Print size_t using the right format macro
* Shorten and simplify code
* Other random cleanup bits and style fixes
BUG=none
TEST=none
R=henrik.lundin@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/36179004
Cr-Commit-Position: refs/heads/master@{#8467}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8467 4adac7df-926f-26a2-2b94-8c16560cd09d
This cl just moves the logic form the default module
SetTargetSendBitrates to PayloadRouter. There might be glitch / mismatch
in size between trate the vector and rtp modules. This was the same in
the default module and is quite hard to protect from before we have the
new video API.
I also removed some test form rtp_rtcp_impl_unittest that were affected
by this change. The test tests code that isn't implemented, hence the
DISABLED_, and this will never be implemented in the RTP module, rather
the payload router in the future.
BUG=769
R=pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42419004
Cr-Commit-Position: refs/heads/master@{#8453}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8453 4adac7df-926f-26a2-2b94-8c16560cd09d
There is a potential race when deleting a channel and there is a frame
in the encoder. ViEEncoder::SendData can be called after
ViEEncoder::StopThreadsAndRemovePayloadRouter and payload_router is
then already removed.
Until we have the new API in place, use scoped_refptr in ViEChannel and
ViEEncoder and deregister channel/encoder before deleting.
BUG=769
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42019004
Cr-Commit-Position: refs/heads/master@{#8443}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8443 4adac7df-926f-26a2-2b94-8c16560cd09d
Fetching the current codec for sake of gathering stats, is frequently blocked since it's done by acquiring the same lock as is held while encoding frames. This can mean tens of milliseconds.
To improve this, I'm taking advantage of the fact that the codec information is set on the same thread as is used to query the information. This means that locking isn't needed for querying this information. I'm adding checks to make sure debug builds will crash if this isn't followed.
An alternative to this approach could be to add one more lock that is specifically used for the codec information variable. This would also decouple querying codec information from the encoder itself, but still requires a lock.
This patch depends on making ThreadChecker part of rtc_base_approved:
https://webrtc-codereview.appspot.com/40539004/
BUG=2822
R=mflodman@webrtc.org, pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/37779004
Cr-Commit-Position: refs/heads/master@{#8435}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8435 4adac7df-926f-26a2-2b94-8c16560cd09d
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
Moving functionality to get max payload length from default RTP module
to the payload router.
I'll make a follow up CL changing asserts to DCHECK in rtp_rtcp_impl.cc.
BUG=769
TEST=New unittest and existing sender mtu test
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/36119004
Cr-Commit-Position: refs/heads/master@{#8345}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8345 4adac7df-926f-26a2-2b94-8c16560cd09d
ViECapturer is always calling DeliverFrame with an empty CSRC vector, so
this is basically a dead path already. I added a DCHECK in ViEEncoder to
verify this is true.
BUG=769
TEST=Manually verified in Chromium.
R=pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/39059004
Cr-Commit-Position: refs/heads/master@{#8335}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8335 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
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
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
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
* 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
The surrounding similar methods all used unsigned char, using unsigned int in
this case looks like an accident, especially since the function passes on the
value in question to a function expecting a uint8.
BUG=none
TEST=none
R=mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/40529004
Cr-Commit-Position: refs/heads/master@{#8228}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8228 4adac7df-926f-26a2-2b94-8c16560cd09d
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/33129004TBR=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/34079004
Cr-Commit-Position: refs/heads/master@{#8206}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8206 4adac7df-926f-26a2-2b94-8c16560cd09d
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
Cr-Commit-Position: refs/heads/master@{#8203}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8203 4adac7df-926f-26a2-2b94-8c16560cd09d
Make a few member variables in the Transport class officially const so that it's clear that locking isn't needed for access. There are getters for some of these (e.g. content_name()) that don't have locking or checking, so making the variables const is at least a way to guard against regressions. Also making the clock_ member in overuse_frame_detector.h const for clarity that it doesn't require a lock for access.
No code change.
Review URL: https://webrtc-codereview.appspot.com/35949004
Cr-Commit-Position: refs/heads/master@{#8186}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8186 4adac7df-926f-26a2-2b94-8c16560cd09d
