Reason for revert:
Breaking google3 projects
Original issue's description:
> Opus implementation of the AudioEncoderFactoryTemplate API
>
> Now the templated AudioEncoderFactory can create Opus encoders!
>
> BUG=webrtc:7831
>
> Review-Url: https://codereview.webrtc.org/2930243003
> Cr-Commit-Position: refs/heads/master@{#18645}
> Committed: fe1aa82c63TBR=ossu@webrtc.org,solenberg@webrtc.org,kwiberg@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:7831
Review-Url: https://codereview.webrtc.org/2947563002
Cr-Commit-Position: refs/heads/master@{#18649}
This CL makes the WebRTC Java Wrapper more modular and allows the android
users to build WebRTC without audio and video(DataChannel only).
The BUILD file in sdk/android/ is modified to support modular WebRTC.
The peerconnection_jni.cc is split into peerconnection_jni.cc, video_jni.cc,
video_renderer_jni.cc and ownedfactoryandthreads.h/cc.
Add new modular build targets to JNI layer: audio_jni, video_jni,
null_audio_jni, null_video_jni. The users can link with different
targets to for different WebRTC functionalities.
This is split from CL: https://codereview.webrtc.org/2854123003/TBR=magjed@webrtc.org
BUG=webrtc:7613
Review-Url: https://codereview.webrtc.org/2939203002
Cr-Commit-Position: refs/heads/master@{#18647}
Now the templated AudioEncoderFactory can create Opus encoders!
BUG=webrtc:7831
Review-Url: https://codereview.webrtc.org/2930243003
Cr-Commit-Position: refs/heads/master@{#18645}
Now the templated AudioEncoderFactory can create G722 encoders!
BUG=webrtc:7833
Review-Url: https://codereview.webrtc.org/2934833002
Cr-Commit-Position: refs/heads/master@{#18644}
Now the templated AudioDecoderFactory can create G722 decoders!
BUG=webrtc:7839
Review-Url: https://codereview.webrtc.org/2940833002
Cr-Commit-Position: refs/heads/master@{#18643}
In this case it wasn't an issue, because only one result would be found
by remove_if, but might as well fix it just in case.
BUG=None
TBR=pthatcher@webrtc.org
Review-Url: https://codereview.webrtc.org/2945723002
Cr-Commit-Position: refs/heads/master@{#18641}
No real encoder implements the correct API yet, so we're just testing
dummies.
BUG=webrtc:7823
Review-Url: https://codereview.webrtc.org/2935643002
Cr-Commit-Position: refs/heads/master@{#18637}
Adds the VideoEncoderFactory interface and implements it for use with HardwareVideoEncoder. This uses MediaCodecVideoEncoder's initialization code as an example.
BUG=webrtc:7760
Change-Id: I9fbc93ce9ac4ad866750a4386c4f15e800a3073e
Reviewed-on: https://chromium-review.googlesource.com/530063
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Reviewed-by: Peter Thatcher <pthatcher@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#18636}
1. To make the files conform to chromium-style guidelines, and stop the compiler from complaing:
1.1. Move constructors out of .h file.
1.2. Move destructors out of .h file.
1.3. Move virtual functions out of .h file.
2. BlockLength() and Create() did not have consistent access modifiers in the various subclasses of RtcpPacket. Change the access level to public throughout.
3. Reorder BlockLength() and Create() where necessary, to reflect the order defined in the parent class (RtcpPacket).
BUG=None
Review-Url: https://codereview.webrtc.org/2937403002
Cr-Commit-Position: refs/heads/master@{#18633}
These methods have the same behavior as their counterparts in std::optional, except that rtc::Optional::value() requires that the value exists whereas std::optional::value() throws an exception.
BUG=webrtc:7843
Review-Url: https://codereview.webrtc.org/2942203002
Cr-Commit-Position: refs/heads/master@{#18631}
There are some functions in packet_router.cc and modules/congestion_controller that could be used by different threads, but they're protected using rtc::ThreadChecker which doesn't allow them to be called by more than one thread even if the calls are synchronised. This CL replaces those with rtc::RaceChecker, which allows serialized access of the functions from multiple threads.
BUG=webrtc:7826
Review-Url: https://codereview.webrtc.org/2940133003
Cr-Commit-Position: refs/heads/master@{#18628}
All setting switches except "Loopback mode" is now in the Settings
screen instead of the main screen. They are also persisted across app
launches.
Bug: webrtc:7748
Change-Id: Iafd84e5e39639770118e2503148d1bf7fb9c3d8d
Reviewed-on: https://chromium-review.googlesource.com/527034
Commit-Queue: Magnus Jedvert <magjed@webrtc.org>
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#18626}
Guarded by field trial - similar to high profile encoder.
If high profile is requested, but device do not support it
then fallback to baseline profile.
BUG=b/34816463
Review-Url: https://codereview.webrtc.org/2936313002
Cr-Commit-Position: refs/heads/master@{#18619}
This CL makes the WebRTC more modular and allows the users to build
WebRTC without audio and video(DataChannel only).
The BUILD files in call/, logging/, media/ and pc/ are modified to
support modular WebRTC.
The dependencies on Call and RtcEventLog are removed from the
PeerConnection. Instead of being created internally, they would be
passed in by the PeerConnectionFactory.
Add the CreateModularPeerConnectionFactory function which allow the
users to create a PeerConnectionFactory with the modules they need.
If the users want to build WebRTC without audio and video, they can
pass in null pointers for modules they don't need. (MediaEngine,
VideoEncoderFactory etc.)
BUG=webrtc:7613
Review-Url: https://codereview.webrtc.org/2854123003
Cr-Commit-Position: refs/heads/master@{#18617}
This eliminates a thread hop in PeerConnectionFactory initialization,
and will allow some code to be simplified.
BUG=None
Review-Url: https://codereview.webrtc.org/2934103002
Cr-Commit-Position: refs/heads/master@{#18613}
Currently there is a hard limit for the estimated captured frame
interval of 45ms. As the encoder utilization is calculated as
(input frame interval)/(encode time), overuse signals can be triggered
even though there is plenty of time to go around if the fps is low.
However, in order to avoid falsly estimating low encode usage in case
the capturer has a dynamic frame rate, set the frame interval based on
the actual current max framerate.
BUG=webrtc:4172
Review-Url: https://codereview.webrtc.org/2918143003
Cr-Commit-Position: refs/heads/master@{#18610}
The following changes have been made:
- command line args wired,
- user output added,
- final polishing.
BUG=webrtc:7218
Review-Url: https://codereview.webrtc.org/2808053002
Cr-Commit-Position: refs/heads/master@{#18609}
