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
The modification only uses the unique part of the spectrum (as is done for the C and asm code). It passes
byte to byte conformance test, and the single function performance
(if not specified, the code is compiled by GCC 4.6) on different
platforms:
| run 100k times | cortex-a7 | cortex-a9 | cortex-a15 |
| use C as the base on each | (1.2Ghz) | (1.0Ghz) | (1.7Ghz) |
| CPU target | | | |
|----------------------------+-----------+-----------+------------|
| C | 100% | 100% | 100% |
| Neon asm | 18% | 14% | 19% |
| Neon inline asm | 31% | 25% | 27% |
| Neon intrinsic (GCC 4.6) | 33% | 27% | 42% |
| Neon intrinscis (GCC 4.8) | 17% | 14% | 19% |
| Neon intrinsics (LLVM 3.3) | 15% | 13% | 18% |
BUG=
R=andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/13739004
Patch from Joe Yu <joe.yu@arm.com>.
git-svn-id: http://webrtc.googlecode.com/svn/trunk@6920 4adac7df-926f-26a2-2b94-8c16560cd09d
Propose of this CL: Close the camera properly on MacOS in order to allow other apps to use it.
Changes in this CL:
1. video_capture_qtkit_info_objc.mm _captureDevicesInfo is never released. I have found this memory leak using Instruments from XCode. The patch is releasing it in dealloc.
2. In video_capture_qtkit_objc.h:
a) _captureDeviceName is not needed. Is allocated in the class but never used.
b) I don't see the role of the NSAutoreleasePool. also if you use it you have to release it when the class is destroyed. Otherwise you will leak memory. Libjingle has for each thread a pool on mac os.
3. In video_capture_qtkit_objc.mm
a) the camera is not stopped properly . See the changes from dealloc. NOTE : If you don't call [[_captureVideoDeviceInput device] close] other apps will not be able to use the camera since you are not closing your app
b) Removed QTCaptureDevice* videoDevice = (QTCaptureDevice*)[_captureDevices objectAtIndex:0]; I don't know why this because the desired camera is opened in setCaptureDeviceById and can be different than position 0 in the camera array. At this moment if you have two cameras and user want to pick the one on index 1 the app also locks the one on 0 .
Other changes I have done to improve (and are not in this CL):
a) I have set the FPS properly to the desired. I have succeeded to reduce the CPU with 3 % doing this. The current code for setting FPS is commented in webrtc
b) I have removed _rLock from the equation. I don't know if it's good or not but I hadn't understood what exactly we are trying to protect with this. Anyway in the current implementation is never released.
Review URL: https://webrtc-codereview.appspot.com/1097014
Patch from Silviu Caragea <silviu.cpp@gmail.com>.
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3886 4adac7df-926f-26a2-2b94-8c16560cd09d
