This is to fix a race that occurs in unit tests when the tests inherit
from the engine class that also implements the callback interface for
tracing. If tracing happens while the most derived class is still being
constructed, we're in trouble.
So, instead, factoring out the TraceCallback implementation.
R=pbos@webrtc.org
BUG=
Review URL: https://webrtc-codereview.appspot.com/43489004
Cr-Commit-Position: refs/heads/master@{#8562}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8562 4adac7df-926f-26a2-2b94-8c16560cd09d
- Add front/back camera switch test.
- Add video source stop and restart test to simulate
application going into background.
- Add a loopback test for 3 video codecs - VP8, VP8, H.264.
- Add a loopback test for voice only call.
R=wzh@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/43459004
Cr-Commit-Position: refs/heads/master@{#8560}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8560 4adac7df-926f-26a2-2b94-8c16560cd09d
Instead enforcing that a voice engine is set on construction. Apart from
simplifying the class this permits tracing to be set up in the
constructor without worrying about racing sets from SetVoiceEngine
later.
BUG=
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/44489004
Cr-Commit-Position: refs/heads/master@{#8555}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8555 4adac7df-926f-26a2-2b94-8c16560cd09d
This is an interface change only at this point which will be followed up by a matching change in Chromium that removes the dependency on the 'value' member variable. Once that's been done, I'll add native support for non-string types in the Value class.
R=magjed@webrtc.org
BUG=2822
Review URL: https://webrtc-codereview.appspot.com/40139004
Cr-Commit-Position: refs/heads/master@{#8550}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8550 4adac7df-926f-26a2-2b94-8c16560cd09d
This CL makes sure the project compiles, it does not ensure the parameters now used are correct!
There may be something strange going on with the build files. I was previously able to recompile the whole project despite of the incorrect code, until I changed the file and tried again.
The changes made are just so that it will compile. The code should likely be updated by someone who knows what he/she is doing.
TBR=glaznev@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/45369004
Cr-Commit-Position: refs/heads/master@{#8526}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8526 4adac7df-926f-26a2-2b94-8c16560cd09d
Mostly, it's about moving constructors and descructors to the .cc
files, so that they won't be inlined everywhere.
The reason this CL is so big is that a lot of code was using
common_types.h without declaring a dependency on webrtc_common, which
broke the build once common_types.h started to depend on
common_types.cc.
BUG=163
R=kjellander@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/26089004
Cr-Commit-Position: refs/heads/master@{#8516}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8516 4adac7df-926f-26a2-2b94-8c16560cd09d
Peer connection may generate answer and ICE candidates before
websocket client is registered. Remove check from sendAnswer()
and sendLocalIceCandidate() functions and allow websocket client
to accumulate messages and send them later once it will be
registered.
R=wzh@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/44379004
Cr-Commit-Position: refs/heads/master@{#8508}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8508 4adac7df-926f-26a2-2b94-8c16560cd09d
Add some const safety by DCHECK(HasOneRef()) in non-const GetYPlane. This CL also replaces all incorrect non-const calls with const calls for pixel data access in cricket::VideoFrame. It's easy to call the non-const version of e.g. GetYPlane by mistake, even if only const-access is needed. For example:
const scoped_ptr<cricket::VideoFrame> foo;
const uint8_t* y = foo->GetYPlane();
will actually call the non-const version of GetYPlane.
R=mflodman@webrtc.org, perkj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/39079004
Cr-Commit-Position: refs/heads/master@{#8507}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8507 4adac7df-926f-26a2-2b94-8c16560cd09d
It looks like it is being used single threadedly, except that in some cases it is created and/or destroyed in threads other than the one running its operations. As such, CaptureManager() contains 'thread_checker_.DetachFromThread()' and ~CaptureManager() does not have a DCHECK.
BUG=
R=perkj@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/36279004
Cr-Commit-Position: refs/heads/master@{#8498}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8498 4adac7df-926f-26a2-2b94-8c16560cd09d
With this cl, video buffers are now allocated using direct buffers.
These buffers are guaranteed to live as long as the capturer is running.
We can now post frames in c++ from the Java thread to the c++ worker thread and let c++ post the buffers back when it has finished
processing them.
This cl also reverts back to make Stop asynchronouse so that it is guaranteed that the c++ worker thread is not used and no frames are delivered to VideoCapturerAndroid after Stop completes.
BUG=4318
TESTED= On a N5, N6, N9 and Samsung device.
R=glaznev@webrtc.org, magjed@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/43369004
Cr-Commit-Position: refs/heads/master@{#8493}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8493 4adac7df-926f-26a2-2b94-8c16560cd09d
- Qualcomm H.264 HW decoder on KK and older requires
a few video frames before it can generate output. Increase
maximum allowed pending frames for H.264 decoder to 30.
Plus changes in the logging to track decoder buffers
timestamps.
R=wzh@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/36319004
Cr-Commit-Position: refs/heads/master@{#8490}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8490 4adac7df-926f-26a2-2b94-8c16560cd09d
- Add a setting option to disable outgoing video in a call.
- Add an option to select audio codec.
- Add an option to specify audio bitrate for Opus codec.
- Plus add an option to select H.264 as default video codec.
R=wzh@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42449004
Cr-Commit-Position: refs/heads/master@{#8468}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8468 4adac7df-926f-26a2-2b94-8c16560cd09d
* 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
- Allow to configure MediaCodec Java wrapper to use VP8
and H.264 codec.
- Save H.264 config frames with SPS and PPS NALUs and append them to every key frame.
- Correctly handle the case when one encoded frame may generate several output NALUs.
- Add code to find H.264 start codes.
- Add a flag (non configurable yet) to use H.264 in AppRTCDemo.
- Improve MediaCodec logging.
R=wzh@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/43379004
Cr-Commit-Position: refs/heads/master@{#8465}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8465 4adac7df-926f-26a2-2b94-8c16560cd09d
This CL is part II in a major refactoring effort. See https://webrtc-codereview.appspot.com/33969004 for part I.
- Removes unused code and old WEBRTC logging macros
- Now uses optimal sample rate and buffer size in Java AudioTrack (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)
- Simplified the delay estimate
- 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
Review URL: https://webrtc-codereview.appspot.com/39169004
Cr-Commit-Position: refs/heads/master@{#8460}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8460 4adac7df-926f-26a2-2b94-8c16560cd09d
The Codec class is a big class and objects of the Codec class are passed
around by value. That means that inlined operations would be duplicated
at many places, in particular inside STL.
By not inlining Codec methods, webrtc shrinks by 50 KB in
a Linux x64 clang build.
Total change: -54147 bytes
==========================
+2810 - Source: /home/bratell/src/chromium/src/third_party/libjingle/source/talk/media/base/codec.cc - (gained 2920, lost 110)
-1003 - Source: /home/bratell/src/chromium/src/third_party/libjingle/source/talk/media/base/codec.h - (gained 0, lost 1003)
-1129 - Source: /home/bratell/src/chromium/src/third_party/libjingle/source/talk/media/sctp/sctpdataengine.cc - (gained 1660, lost 2789)
-1190 - Source: /home/bratell/src/chromium/src/third_party/libjingle/source/talk/media/base/rtpdataengine.cc - (gained 1408, lost 2598)
-1747 - Source: /home/bratell/src/chromium/src/third_party/libjingle/source/talk/session/media/mediasession.cc - (gained 803, lost 2550)
-2141 - Source: /home/bratell/src/chromium/src/third_party/libjingle/source/talk/media/webrtc/webrtcvideoengine.cc - (gained 1679, lost 3820)
-2250 - Source: /home/bratell/src/chromium/src/third_party/libjingle/source/talk/app/webrtc/webrtcsdp.cc - (gained 1224, lost 3474)
-2927 - Source: /usr/include/c++/4.8/bits/stl_vector.h - (gained 0, lost 2927)
-3729 - Source: /home/bratell/src/chromium/src/third_party/libjingle/source/talk/media/webrtc/webrtcvideoengine2.cc - (gained 10925, lost 14654)
-6369 - Source: /usr/include/c++/4.8/bits/vector.tcc - (gained 0, lost 6369)
-10582 - Source: /usr/include/c++/4.8/bits/stl_heap.h - (gained 0, lost 10582)
-19324 - Source: /usr/include/c++/4.8/bits/stl_algo.h - (gained 743, lost 20067)
BUG=
R=juberti@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/40729005
Cr-Commit-Position: refs/heads/master@{#8436}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8436 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
This reverts commit 1c3e728aa9.
Reason: Fails test running on Nexus 9 bots - org.webrtc.VideoCapturerAndroidTest#testStartStopWithDifferentResolutions.
Note that all other tests pass so it seems like there is resolution supported by the device that can't use YV12.
TBR=glaznev@webrtc.org
BUG=4011
Review URL: https://webrtc-codereview.appspot.com/42389004
Cr-Commit-Position: refs/heads/master@{#8414}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8414 4adac7df-926f-26a2-2b94-8c16560cd09d
Instead of sending a black frame that's the size of the VideoFormat send
a black frame in the format we're already sending. This prevents
expensive encoder reconfiguration when the sending format is a different
resolution. This speeds up setting a null capturer (removing the
capturer) significantly as it doesn't entail an encoder reconfiguration.
R=mflodman@webrtc.org, pthatcher@webrtc.org
BUG=1788
Review URL: https://webrtc-codereview.appspot.com/39179004
Cr-Commit-Position: refs/heads/master@{#8405}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8405 4adac7df-926f-26a2-2b94-8c16560cd09d
It’s possible to implement cricket::VideoFrame::CopyToBuffer using the virtual interface. This removes the need for subclasses to implement their own versions. This CL also fixes a bug in cricket::VideoFrame::CopyToPlanes which currently assumes that GetUPitch() == GetVPitch(), otherwise it may segfault.
I think this CL should land regardless, but the main purpose is to pave the way for for planned changes to I420VideoFrame. See https://review.webrtc.org/38879004.
R=fbarchard@google.com, perkj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/39889004
Cr-Commit-Position: refs/heads/master@{#8403}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8403 4adac7df-926f-26a2-2b94-8c16560cd09d
Modifies WebRtcVideoSendStream to use a default width/height of 16px.
This significantly reduces SetRemoteDescription time under
WebRtcVideoEngine2. Also preventing (expensive) reconfigurations due to
incoming frames when the channel is not sending yet.
Tests have been modified to generate a frame before expecting a certain
encoder size to have been configured.
Also adding tracing to WebRtcVideoSendStream::InputFrame as it can lead
to reconfigurations of the encoder which is expensive and it should show
up in chrome://tracing.
BUG=1788
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42369004
Cr-Commit-Position: refs/heads/master@{#8381}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8381 4adac7df-926f-26a2-2b94-8c16560cd09d
For now:
java_helpers - JNI convenience functions etc. Can in theory be moved to libjingle / webrtc general one day.
classreferenceholder - app/webrtc specific Java class loader.
androidvideocapturer_jni - the jni part of the video capturer I added.
peerconnection_jni - all the rest.
This also move all jni specifics into ns webrtc_jni to avoid naming collision.
R=glaznev@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/38099004
Cr-Commit-Position: refs/heads/master@{#8363}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8363 4adac7df-926f-26a2-2b94-8c16560cd09d
PeerConnectionTest.java currently works, but only on a device with
network interfaces up. This is not a problem for desktop, but it is a
problem when running on Android devices since the devices in the lab
generally don't have network (due to the chaotic radio environment in
the device labs, devices are simply kept in flight mode).
The test does work if one modifies this line in the file
webrtc/base/network.cc:
bool ignored = ((cursor->ifa_flags & IFF_LOOPBACK) ||
IsIgnoredNetwork(*network));
If we remove the IFF_LOOPBACK clause, the test starts working on
an Android device in flight mode. This is nice - we're running the
call and packets interact with the OS network stack, which is good
for this end-to-end test. We can't just remove the clause though since
having loopback is undesirable for everyone except the test (right)?
so we need to make this behavior configurable.
This CL takes a stab at a complete solution where we pass a boolean
all the way through the Java PeerConnectionFactory down to the
BasicNetworkManager. This comes as a heavy price in interface
changes though. It's pretty out of proportion, but fundamentally we
need some way of telling the network manager that it is on Android
and in test mode. Passing the boolean all the way through is one way.
Another way might be to put the loopback filter behind an ifdef and
link a custom libjingle_peerconnection.so with the test. That is hacky
but doesn't pollute the interfaces. Not sure how to solve that in GYP
but it could mean some duplication between the production and
test .so files.
It would have been perfect to use flags here, but then we need to
hook up gflags parsing to some main() somewhere to make sure the
flag gets parsed, and make sure to pass that flag in our tests.
I'm not sure how that can be done.
Making the loopback filtering conditional is exactly how we solved the
equivalent problem in content_browsertests in Chrome, and it worked
great.
That's all I could think of.
BUG=4181
R=perkj@webrtc.org, pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/36769004
Cr-Commit-Position: refs/heads/master@{#8344}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8344 4adac7df-926f-26a2-2b94-8c16560cd09d
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
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
with stride > width.
Recent libvpx update generates output video frames with stride
value greater than width, which was not supported by Android OpenGL
video renderer (Android GLES2 doesn't have GL_UNPACK_ROW_LENGTH
to provide stride information for buffer in glTexImage2D call).
Fix it by implementing native frame copying for Java
VideoRenderer.I420Frame implementation.
BUG=4248
R=braveyao@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/40639004
Cr-Commit-Position: refs/heads/master@{#8252}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8252 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
* Remove "dead" and "alive" variables.
* Remove critical section
* Skip synchronizing with the worker thread to verify startup (no need).
* Remove implementation of SetNotAlive()
* Always set thread name
* Add thread checks for correct usage.
Also added some TODOs for myself for the ThreadWrapper interface.
I'm removing the HasNoMonitorThread test since it is no longer relevant and ends up checking the wrong thing (ProcessThread - a generic thread type) in the wrong way (parsing a debug log) :) I think it served a purpose some years ago, but things have changed since.
BUG=2902
R=henrika@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/37069004
Cr-Commit-Position: refs/heads/master@{#8220}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8220 4adac7df-926f-26a2-2b94-8c16560cd09d
This fixes a two year old TODO of deleting dead code :)
In cases where the _id or id_ member variable is being used for tracing,
I changed the member to at least be const.
It doesn't look like id's are that useful anymore so maybe the next step is to get rid of them.
BUG=
R=henrika@webrtc.org, perkj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/37849004
Cr-Commit-Position: refs/heads/master@{#8201}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8201 4adac7df-926f-26a2-2b94-8c16560cd09d
Accept incoming pings before remote answer is set, to reduce connection latency.
Set ICE connection state to 'checking' after setting the remote answer, so that it can transition into 'connected' if the peer reflexive connection is up before any remote candidate is set. See more details in crbug/446908
BUG=4068, crbug/446908
R=juberti@webrtc.org, pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/38709004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8141 4adac7df-926f-26a2-2b94-8c16560cd09d
This is something I stumbled upon while looking at string copying we do (in spades) and did a simple change to not be constantly copying things around needlessly. There's a lot more that can be done in these files of course so this is sort of a reminder for future code edits that it's possible to design interfaces/function in a way that's more performance aware and avoid forcing creation of copies, while still being very simple. Also, we can use lambdas now :)
BUG=
R=perkj@webrtc.org, pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/41589004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8131 4adac7df-926f-26a2-2b94-8c16560cd09d
Summary of changes:
* We're now using an enum for types instead of strings which both eliminates unecessary string creations+copies and further restricts the type to a known set at compile time.
* IDs are now a separate type instead of a string, copying of Values is not possible and values are const to allow grabbing references outside of the statscollector.
* StatsReport member variables are no longer public.
* Consolidated code in StatsCollector (e.g. merged PrepareLocalReport and PrepareRemoteReport).
* Refactored methods that forced copies of string (e.g. ExtractValueFromReport).
* More asserts for thread correctness.
* Using std::list for the StatsSet instead of a set since order is not important and updates are more efficient in list<>.
BUG=2822
R=hta@webrtc.org, perkj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/40439004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8110 4adac7df-926f-26a2-2b94-8c16560cd09d
> Update StatsCollector's interface in preparation of more changes.
>
> This CL is the first of three and this one contains interface additions (not deletion for backwards compatibility) as well as a few necessary updates to internal code.
>
> The next CL will be in Chromium to consume the new new methods and remove dependency on the old ones.
>
> The third CL will then contain the bulk of the updates and improvements and be compatible with this interface.
>
> BUG=2822
> R=perkj@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/36829004TBR=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/37669004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8096 4adac7df-926f-26a2-2b94-8c16560cd09d
This CL is the first of three and this one contains interface additions (not deletion for backwards compatibility) as well as a few necessary updates to internal code.
The next CL will be in Chromium to consume the new new methods and remove dependency on the old ones.
The third CL will then contain the bulk of the updates and improvements and be compatible with this interface.
BUG=2822
R=perkj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/36829004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8095 4adac7df-926f-26a2-2b94-8c16560cd09d
Current maximum encoder width and height for Android is
hard-coded to 1280x720, so if device is rotated to portrait
orientation only part 720x1280 camera frame is extracted and
scaled to 1280x720. Increasing maximum height to 1280 allows
feeding video encoder with rotated 720x1280 frames directly
without scaling.
R=pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/35739004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8042 4adac7df-926f-26a2-2b94-8c16560cd09d
In order to do that, the signaling thread is also changed to wrap the current thread unless an external signaling thread thread is specified in the call to CreatePeerConnectionFactory.
This cleans up the PeerConnectionFactory and makes sure a user of the API will always access the factory on the signaling thread.
Note that both Chrome and the Android implementation use an external signaling thread.
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/35429004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8039 4adac7df-926f-26a2-2b94-8c16560cd09d
Reasons for revert:
1. glaznev discovered potentially related problems using the Android AppRTCDemo.
2. We're trying to do an M41 webrtc roll in Chromium, and this CL is risky.
> Support associated payload type when registering Rtx payload type.
>
> Major changes include,
> - Add associated payload type for SetRtxSendPayloadType & SetRtxReceivePayloadType.
> - Receiver: Restore RTP packets by the new RTX-APT map.
> - Sender: Send RTP packets by checking RTX-APT map.
> - Add RTX payload type for RED in the default codec list.
>
> BUG=4024
> R=pbos@webrtc.org, stefan@webrtc.org
> TBR=mflodman@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/26259004
>
> Patch from Changbin Shao <changbin.shao@intel.com>.
TBR=pbos@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/33829004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8033 4adac7df-926f-26a2-2b94-8c16560cd09d
This reverts r7980.
It was causing the ICE connected state to happen while still in the new state rather than going through the checking state, which was causing an ASSERT to fire, which was causing a crash.
Review URL: https://webrtc-codereview.appspot.com/41429004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8031 4adac7df-926f-26a2-2b94-8c16560cd09d
- Add separate looper threads for peer connection and websocket
signaling classes.
- To improve the connection speed start peer connection factory
initialization once EGL context is ready in parallel with the room
connection.
- Add asynchronious http request class and start using it in
webscoket signaling and room parameters extractor.
- Add helper looper based executor class.
- Port some of henrika changes from
https://webrtc-codereview.appspot.com/36629004/ to fix sensor
crashes on non L devices - will remove the change if CL will
be submitted soon.
R=jiayl@webrtc.org, wzh@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/41369004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8006 4adac7df-926f-26a2-2b94-8c16560cd09d
This enables OpenSSL by default for Windows, see
8e72e1d..271c6cc/build/common.gypi
which required libjingle_tests.gyp to be updated since the
targets in third_party/nss/nss.gyp was moved into a condition in
https://codereview.chromium.org/694643002.
New Android dependencies are required due to being introduced in
build/android/pylib/remote/device/remote_device_test_run.py
of 5c49978f09
This should also fix Android test execution that started failing after
https://codereview.chromium.org/815213002 was submitted, since
it's based on e2a338fac9
Relevant other changes:
* src/buildtools: 535aff2..23a4e2f
* src/third_party/android_tools: 4f723e2..8fe116f
* src/third_party/boringssl/src: 00505ec..306e520
* src/third_party/icu: 53ecf0f..51c1a4c
* src/third_party/libvpx: 9fbec81..d3f3dce
* src/tools/swarming_client: 1d4965c..119b084
Details: 8e72e1d..271c6cc/DEPS
Clang version updated 218707:223108:
8e72e1d..271c6cc/tools/clang/scripts/update.sh
Due to this, we had to disable deadlock detection for TSan
due to a bug in Clang (see webrtc:
BUG=4106
R=pbos@webrtc.org, pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/36459004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8003 4adac7df-926f-26a2-2b94-8c16560cd09d
First unit test will create peer connection client, run
for a few second, close it and verify that there were
no any errors and local video was rendered.
Second unit test will run peer connection in a loopback mode.
To run the test from command line install AppRTCDemoTest.apk
and execute the command:
adb shell am instrument -w org.appspot.apprtc.test/android.test.InstrumentationTestRunner
R=jiayl@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/33609004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7991 4adac7df-926f-26a2-2b94-8c16560cd09d
