Part of work removing dependency on Chromium's base.
Only adds "= delete". From https://codereview.chromium.org/1151443003 :
"This will guarantee the error to be at compile time, and not rely on the call visibility (private)."
In consequence of that change, fixed an illegal copy and removed a bunch of unused variables.
BUG=chromium:468375 (in particular comment #37)
NOTRY=true
Review URL: https://codereview.webrtc.org/1316363005
Cr-Commit-Position: refs/heads/master@{#9913}
These were accidentally disabled due to checking ssrcs_.size() (which
includes RTX SSRCs) instead of rtp.ssrcs.size() to determine whether a
stream is simulcast or not.
BUG=webrtc:4965
R=asapersson@webrtc.org
Review URL: https://codereview.webrtc.org/1318193003 .
Cr-Commit-Position: refs/heads/master@{#9907}
An option was added to voe_cmd_test to make a RtcEventLog dump.
BUG=webrtc:4741
Review URL: https://codereview.webrtc.org/1267683002
Cr-Commit-Position: refs/heads/master@{#9901}
Is now set to:
<= 320x240: 600kbps
<= 640x480: 1.7Mbps
<= 960x540: 2Mbps
> 960x540: 2.5Mbps
For QVGA and VGA, the qp was around 10 at the selected thresholds when running some tests. The change in qp declined above the selected bitrates.
BUG=
R=mflodman@webrtc.org, pbos@webrtc.org, stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1297373003 .
Cr-Commit-Position: refs/heads/master@{#9878}
This CL contains major modifications of the audio output parts for WebRTC on iOS:
- general code cleanup
- improves thread handling (added thread checks, remove critical section, atomic ops etc.)
- reduces loopback latency of iPhone 6 from ~90ms to ~60ms ;-)
- improves selection of audio parameters on iOS
- reduces complexity by removing complex and redundant delay estimates
- now instead uses fixed delay estimates if for some reason the SW EAC must be used
- adds AudioFineBuffer to compensate for differences in native output buffer size and
the 10ms size used by WebRTC. Same class as is used today on Android and we have unit tests for
this class (the old code was buggy and we have several issue reports of crashes related to it)
Similar improvements will be done for the recording sid as well in a separate CL.
I will also add support for 48kHz in an upcoming CL since that will improve Opus performance.
BUG=webrtc:4796,webrtc:4817,webrtc:4954, webrtc:4212
TEST=AppRTC demo and iOS modules_unittests using --gtest_filter=AudioDevice*
R=pbos@webrtc.org, tkchin@webrtc.org
Review URL: https://codereview.webrtc.org/1254883002 .
Cr-Commit-Position: refs/heads/master@{#9875}
This generates incorrect -lX11 with use_x11=0 in our other build system,
which causes the standalone libjingle_media target to not build.
This patch should fix that. I could remove -lX11 completely, and
libjingle still links fine. So does Chrome if I do the corresponding
change there, so I think this change is safe to make.
BUG=None
Review URL: https://codereview.webrtc.org/1306243013
Cr-Commit-Position: refs/heads/master@{#9869}
Reason for revert:
It looks like this broke the FYI bots. I tried updating libjingle_nacl.gyp, but the IOS build still failed because in Chrome it's configured to use NSS. See https://codereview.chromium.org/1316863012/.
Original issue's description:
> purge nss files and dependencies
>
> BUG=webrtc:4497
>
> Committed: https://crrev.com/5647a2cf3db888195c928a1259d98f72f6ecbc15
> Cr-Commit-Position: refs/heads/master@{#9862}
TBR=tommi@webrtc.org,kjellander@webrtc.org,torbjorng@webrtc.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:4497
Review URL: https://codereview.webrtc.org/1311843006
Cr-Commit-Position: refs/heads/master@{#9867}
Enumerating using android.hardware.camera2 is 10x faster than enumerating using android.hardware.camera, but they don't list exactly the same formats. android.hardware.camera2 support higher resolutions for some cameras, and also different framerates.
R=tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1321893003 .
Cr-Commit-Position: refs/heads/master@{#9861}
The purpose with this CL is to remove some code bloat. A subtle change is that GL_TEXTURE_MIN_FILTER in MediaCodecVideoDecoder is changed from GL_NEAREST to GL_LINEAR. This may lead to slightly worse performance when the decoded video is rendered minified, but with better visual quality. After reading https://crbug.com/351458 and the fix https://codereview.chromium.org/713603002 I think this is the right choice.
BUG=webrtc:4742
R=hbos@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1303373005 .
Cr-Commit-Position: refs/heads/master@{#9845}
of decoder factory class.
- Add new Peer connection factory method to initialize shared
EGL context.
This provides an option to use single peer connection factory
in the application and create peer connections from the same
factory and reinitialize shared EGL context for video
decoding HW acceleration.
R=wzh@webrtc.org
Review URL: https://codereview.webrtc.org/1304063011 .
Cr-Commit-Position: refs/heads/master@{#9838}
Enumerating camera capabilities in the deprecated android.hardware.Camera interface is really slow because of the need to open and release the camera. By making getSupportedFormats() an interface, we allow apps the opportunity to inject their own implementation, such as storing the supported formats offline in the device's internal storage. It will also be possible to add an implementation of getSupportedFormats() using the new android.hardware.Camera2 interface in a follow-up CL.
R=tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1321903002 .
Cr-Commit-Position: refs/heads/master@{#9819}
This CL makes the Java render interface asynchronous by requiring every call to renderFrame() to be followed by an explicit renderFrameDone() call. In JNI, this is implemented with cricket::VideoFrame::Copy() before calling renderFrame(), and a corresponding call to delete in renderFrameDone(). This CL is primarily done to prepare for a new renderer implementation.
BUG=webrtc:4742, webrtc:4909
R=glaznev@webrtc.org
Review URL: https://codereview.webrtc.org/1313563002 .
Cr-Commit-Position: refs/heads/master@{#9814}
This is handled by Android itself and may result in GL errors
when trying to release shaders when Activity is destroyed.
R=wzh@webrtc.org
Review URL: https://codereview.webrtc.org/1322703004 .
Cr-Commit-Position: refs/heads/master@{#9811}
webrtc::VideoSource resolves the kMaxFrameRate constraint by capping the desired framerate to kMaxFrameRate. That framerate is then passed into cricket::VideoCapturer::GetBestCaptureFormat(). The default implementation will choose a format from the supported formats list. Instead, we should override this function in AndroidVideoCapturer to give VideoCapturerAndroid.java the opportunity to choose a suitable framerate range.
BUG=webrtc:4938
R=glaznev@webrtc.org
Review URL: https://codereview.webrtc.org/1308953004 .
Cr-Commit-Position: refs/heads/master@{#9805}
