We must remove dependency on Chromium, i.e. we can't use Chromium's base/logging.h. That means we need to define these macros in WebRTC also when doing Chromium builds. And this causes redefinition.
Alternative solutions:
* Check if we already have defined e.g. CHECK, and don't define them in that case. This makes us depend on include order in Chromium, which is not acceptable.
* Don't allow using the macros in WebRTC headers. Error prone since if someone adds it there by mistake it may compile fine, but later break if a header in added or order is changed in Chromium. That will be confusing and hard to enforce.
* Ensure that headers that are included by an embedder don't include our macros. This would require some heavy refactoring to be maintainable and enforcable.
* Changes in Chromium for this is obviously not an option.
BUG=chromium:468375
NOTRY=true
Review URL: https://codereview.webrtc.org/1335923002
Cr-Commit-Position: refs/heads/master@{#9964}
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
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
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
