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
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
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
* 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 reverts commit 1c3e728aa9b886fd3ee008a5aed956759bc3f82d.
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
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
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
