- 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
