The RtpReceiverObserverInterface is created.
The SignalFirstPacketReceived will be forwarded from BaseChannel to WebRtcSession.
WebRtcSession will forward SignalFirstAudioPacketReceived and SignalFirstVideoPacketReceived to the RtpReceiverInterface.
The application can listen to the Signal by implementing and registering a RtpReceiverObserver.
Review-Url: https://codereview.webrtc.org/1999853002
Cr-Commit-Position: refs/heads/master@{#13139}
Added the plumbing necessary to get two different lists of codecs from
WebRtcVoiceEngine up to MediaSessionDescriptionFactory.
This should be the last step in this set of CLs. Once
https://codereview.webrtc.org/1991233004/ has landed, it's possible to
implement the ReceiveCodecs getter with the info from the
AudioDecoderFactory. The factory needs to be updated to actually
produce the correct list, as well.
BUG=webrtc:5805
Review-Url: https://codereview.webrtc.org/2013053002
Cr-Commit-Position: refs/heads/master@{#13131}
Camera1 tests are now separated from general CameraVideoCapturer tests.
Main motivation behind these changes is that Camera2 implementation can
be tested using the same tests.
CL also reduces code duplication on tests using textures.
BUG=webrtc:5519
Review-Url: https://codereview.webrtc.org/2024843002
Cr-Commit-Position: refs/heads/master@{#13130}
Added initial support for MediaSessionDescriptionFactory to pick different codecs based on communications direction (sendrecv, sendonly, recvonly, inactive) specifically for audio.
This adds some more degradation options for the answer: depending on answer options, it's now possible to degrade to INACTIVE from any offer, as well as to either RECVONLY or SENDONLY from a SENDRECV offer.
The set of "codecs" used for testing the answer was compiled using this spreadsheet:
https://docs.google.com/a/google.com/spreadsheets/d/1nVIfZLsFo5YK10_e80BCAADZnnRQ1devwwwAGmqJPow/edit?usp=sharing
I should probably condense it into a smaller table and put in the source.
BUG=webrtc:5805
Review-Url: https://codereview.webrtc.org/1956343002
Cr-Commit-Position: refs/heads/master@{#13126}
Earlier, no statistics were reported if no frames were being delivered
for encoding. This makes statics always be reported regardless of if
there are frames being delivered to the encoder.
Review-Url: https://codereview.webrtc.org/2051403002
Cr-Commit-Position: refs/heads/master@{#13122}
BUG=webrtc:5949
TESTED=Built and ran the tests on Mac.
NOTRY=True
Review-Url: https://codereview.webrtc.org/2054413002
Cr-Commit-Position: refs/heads/master@{#13116}
CreatePeerConnectionFactory does not yet expose the ability to set the
factory from the outside.
Added notry due to android_dbg being broken.
NOTRY=True
BUG=webrtc:5805
Review-Url: https://codereview.webrtc.org/1991233004
Cr-Commit-Position: refs/heads/master@{#13112}
Introduce a new method I420Buffer::CropAndScale, and a static
convenience helper I420Buffer::CenterCropAndScale. Use them for almost
all scaling needs.
Delete the Scaler class and the cricket::VideoFrame::Stretch* methods.
BUG=webrtc:5682
R=pbos@webrtc.org, perkj@webrtc.org, stefan@webrtc.org
Review URL: https://codereview.webrtc.org/2020593002 .
Cr-Commit-Position: refs/heads/master@{#13110}
Every message will now be traced with the location from which it was
posted, including function name, file and line number.
This CL also writes a normal LOG message when the dispatch took more
than a certain amount of time (currently 50ms).
This logging should help us identify messages that are taking
longer than expected to be dispatched.
R=pthatcher@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/2019423006 .
Cr-Commit-Position: refs/heads/master@{#13104}
This CL turns nativeConfiguration into createNativeConfiguration returning a
pointer or nil on failure. This method's certificate generation is updated to
use the new API and reports failure (nil) if unsuccessful instead of relying on
the default certificate. We also remove the implicit assumption (now incorrect)
that RSA is the default. This is the same type of changes as was done in
https://codereview.webrtc.org/1965313002 but this file
(RTCPeerConnectionInterface.mm) was forgotten.
With no more usages of kIdentityName it and dtlsidentitystore.cc is removed.
Also removes unnecessary #include in peerconnectioninterface.h that was still
remnant due to an indirect include of kIdentityName.
RTCConfiguration+Private.h now lists method nativeEncryptionKeyTypeForKeyType
which was added in the above mentioned prior CL.
BUG=webrtc:5707, webrtc:5708
Review-Url: https://codereview.webrtc.org/2035473004
Cr-Commit-Position: refs/heads/master@{#13089}
In org.webrtc.VideoCapturerAndroidTest#startWhileCameraIsAlreadyOpenAndCloseCamera,
use a video renderer instead of a capture observer. The video renderer
automatically returns the texture buffers, which resolves the bug.
There shouldn't be any changes to the effectiveness of the test.
BUG=webrtc:5982
Review-Url: https://codereview.webrtc.org/2042283004
Cr-Commit-Position: refs/heads/master@{#13085}
This moves the implementation specific methods to separate classes
(RtpSenderInternal/RtpReceiverInternal) so that the interface classes
represent the interface that external applications can rely on.
The reason this wasn't done earlier was that PeerConnection needed
to store proxy pointers, but also needed to access implementation-
specific methods on the underlying objects. This is now possible
by using "RtpSenderProxyWithInternal<RtpSenderInternal>", which is a proxy
that implements RtpSenderInterface but also provides direct access
to an RtpSenderInternal.
Review-Url: https://codereview.webrtc.org/2023373002
Cr-Commit-Position: refs/heads/master@{#13056}
When the fake clock's time is advanced, it now ensures all pending
queued messages have been dispatched. This allows us to write a
"SIMULATED_WAIT" macro that ticks the simulated clock by milliseconds up
until the target time.
Useful in this case, where we know the STUN timeout should take a total
of 9500ms, but it would be overly complex to write test code that waits
for each individual timeout, ensures a STUN packet has been
retransmited, etc.
(The test described above *should* be written, but it belongs in
p2ptransportchannel_unittest.cc, not webrtcsession_unittest.cc).
Review-Url: https://codereview.webrtc.org/2024813004
Cr-Commit-Position: refs/heads/master@{#13052}
Reason for revert:
There seems to be a TSan warning that wasn't caught by the trybot: https://build.chromium.org/p/client.webrtc/builders/Linux%20Tsan%20v2/builds/6732/steps/peerconnection_unittests/logs/stdio
Apparently a thread is still alive even after destroying WebRTCSession. Need to think of a way to fix this, without adding a critical section around g_clock (since that would hurt performance).
Original issue's description:
> Improving the fake clock and using it to fix a flaky STUN timeout test.
>
> When the fake clock's time is advanced, it now ensures all pending
> queued messages have been dispatched. This allows us to write a
> "SIMULATED_WAIT" macro that ticks the simulated clock by milliseconds up
> until the target time.
>
> Useful in this case, where we know the STUN timeout should take a total
> of 9500ms, but it would be overly complex to write test code that waits
> for each individual timeout, ensures a STUN packet has been
> retransmited, etc.
>
> (The test described above *should* be written, but it belongs in
> p2ptransportchannel_unittest.cc, not webrtcsession_unittest.cc).
>
> Committed: https://crrev.com/ffbe0e17e2c9b7fe101023acf40574dc0c95631a
> Cr-Commit-Position: refs/heads/master@{#13043}
TBR=pthatcher@webrtc.org,tommi@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.webrtc.org/2038213002
Cr-Commit-Position: refs/heads/master@{#13045}
When the fake clock's time is advanced, it now ensures all pending
queued messages have been dispatched. This allows us to write a
"SIMULATED_WAIT" macro that ticks the simulated clock by milliseconds up
until the target time.
Useful in this case, where we know the STUN timeout should take a total
of 9500ms, but it would be overly complex to write test code that waits
for each individual timeout, ensures a STUN packet has been
retransmited, etc.
(The test described above *should* be written, but it belongs in
p2ptransportchannel_unittest.cc, not webrtcsession_unittest.cc).
Review-Url: https://codereview.webrtc.org/2024813004
Cr-Commit-Position: refs/heads/master@{#13043}
With the current order of stop capture processing on Android,
OnMemoryBufferFrame and OnTextureFrame may be called halfway through
Stop(). They must therefore check for the case of a null capturer_.
There used to be such checks, but they were accidantally removed in
commit #12895, cl https://codereview.webrtc.org/1973873003.
BUG=webrtc:5966
R=perkj@webrtc.org, sakal@webrtc.org
Review URL: https://codereview.webrtc.org/2033943004 .
Cr-Commit-Position: refs/heads/master@{#13031}
The only thing that differs from the previous attempt in
https://codereview.webrtc.org/1979933002/ is that none of
the new targets are not hooked up to the webrtc target in
webrtc/BUILD.gn, which should make it not break the
chromium.webrtc.fyi bots.
Add BUILD.gn files for webrtc/{api,media,libjingle,p2p,pc} in
preparation for removing src/third_party/libjingle in Chromium.
Changes between previous attempt and the one before that
(https://codereview.webrtc.org/1973313002) are:
* Added libstunprober target
* Adjusted warnings for Chromium's clang plugins
* webrtc/pc/externalhmac.{h,cc} added for Chromium builds.
BUG=webrtc:4256
NOTRY=True
NOPRESUBMIT=True
TBR=perkj@webrtc.org, tommi@webrtc.org
Review-Url: https://codereview.webrtc.org/2037983002
Cr-Commit-Position: refs/heads/master@{#13030}
This means there's only one thread hop to the worker thread.
At the video engine level, SetOptions and SetSource
are combined into one method (all within the same critical section)
which ensures that no frame will be encoded while SetVideoSend
is only partially finished.
BUG=webrtc:5691
Review-Url: https://codereview.webrtc.org/1838413002
Cr-Commit-Position: refs/heads/master@{#13022}
The DtlsIdentityStoreInterface has been replaced by
RTCCertificateGenerator. Due to previous CLs, neither the
DtlsIdentityStoreImpl or RTCCertificateGeneratorStoreWrapper are used.
DtlsIdentityStoreInterface is still implemented by
PeerConnectionIdentityStore in Chromium and is not removed, but it will
be soon.
BUG=webrtc:5708
R=tommi@webrtc.org
Review URL: https://codereview.webrtc.org/2028033002 .
Cr-Commit-Position: refs/heads/master@{#13004}
Add sent_ping_requests, recv_ping_responses to ConnectionInfo.
recv_ping_responses_ will be incremented when OnConnectionRequestResponse() is called.
ent_ping_requests_ will be incremented when OnConnectionRequestSent() is called.
BUG=webrtc:5695
Review-Url: https://codereview.webrtc.org/1940493002
Cr-Commit-Position: refs/heads/master@{#13001}
Clean-up.
The idea behind the factory having a certificate generator was that it would
reuse it with any peer connection it creates unless otherwise specified. This
generator was originally a DtlsIdentityStoreImpl store which preemptively
generated RSA-1024 in the background, giving any peer connection using RSA-1024
a head-start (generate before requesting). But now that 1) the store has been
replaced by a generator that does not do preemptive generation and 2) the
default is ECDSA, not RSA-1024, it is unnecessary for the factory to have this
code.
BUG=webrtc:5707, webrtc:5708
R=tommi@webrtc.org
Review URL: https://codereview.webrtc.org/2021663002 .
Cr-Commit-Position: refs/heads/master@{#12993}
By not providing the default implementation of the metrics API
it becomes possible for users of rtc_media to choose which
implementation to use. The dependency is moved into each test
target that uses it instead.
NOTRY=True
NOPRESUBMIT=True
Review-Url: https://codereview.webrtc.org/2026223002
Cr-Commit-Position: refs/heads/master@{#12991}
This is one less DtlsIdentityStoreInterface implementation, and one step closer
to removing this interface in favor of RTCCertificateGeneratorInterface.
This also removes PeerConnectionInterface::CreatePeerConnectionWithStore which
is no longer needed.
BUG=webrtc:5707, webrtc:5708
R=tommi@webrtc.org
Review URL: https://codereview.webrtc.org/2020623002 .
Cr-Commit-Position: refs/heads/master@{#12990}
Reason for revert:
Too many errors to address showed up when trying to land this with Chromium changes in https://codereview.chromium.org/2022833002/.
Will address them separately before relanding.
Original issue's description:
> Reland of GN: Add BUILD.gn files for webrtc/{api,media,libjingle,p2p,pc}
>
> Add BUILD.gn files for webrtc/{api,media,libjingle,p2p,pc} in
> preparation for removing src/third_party/libjingle in Chromium.
>
> Changes from previous attempt:
> * Added libstunprober target
> * Adjusted warnings for Chromium's clang plugins
> * webrtc/pc/externalhmac.{h,cc} added for Chromium builds.
>
> As soon this has landed a roll including the changes in
> https://codereview.chromium.org/2022833002/ is needed to make
> Chromium build cleanly.
>
> BUG=webrtc:4256
> NOTRY=True
> NOPRESUBMIT=True
>
> Committed: https://crrev.com/164e978f981c7810c4260c4184f41e26bae90230
> Cr-Commit-Position: refs/heads/master@{#12983}
TBR=perkj@webrtc.org,tommi@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:4256
Review-Url: https://codereview.webrtc.org/2023233002
Cr-Commit-Position: refs/heads/master@{#12988}
The store was used in WebRtcSessionDescriptionFactory to generate certificates,
now a generator is used instead (new API). PeerConnection[Factory][Interface],
and WebRtcSession are updated to pass generators all the way down to the
WebRtcSessionDescriptionFactory instead of stores.
The webrtc implementation of a generator, RTCCertificateGenerator, is used as
the default generator (peerconnectionfactory.cc:189) instead of the webrtc
implementation of a store, DtlsIdentityStoreImpl.
The generator is fully parameterized and does not generate RSA-1024 unless you
ask for it (which makes sense not to do beforehand since ECDSA is now default).
The store was not fully parameterized (known filed bug).
The "top" layer, PeerConnectionFactoryInterface::CreatePeerConneciton, is
updated to take a generator instead of a store.
Many unittests still use a store, to allow them to continue to do so the
factory gets CreatePeerConnectionWithStore which uses the old function
signature (and invokes the new signature by wrapping the store in an
RTCCertificateGeneratorStoreWrapper). As soon as the FakeDtlsIdentityStore is
turned into a certificate generator instead of a store, the unittests will be
updated and we can remove CreatePeerConnectionWithStore.
This is a reupload of https://codereview.webrtc.org/2013523002/ with minor
changes.
BUG=webrtc:5707, webrtc:5708
R=tommi@webrtc.org
Review URL: https://codereview.webrtc.org/2017943002 .
Cr-Commit-Position: refs/heads/master@{#12984}
Add BUILD.gn files for webrtc/{api,media,libjingle,p2p,pc} in
preparation for removing src/third_party/libjingle in Chromium.
Changes from previous attempt:
* Added libstunprober target
* Adjusted warnings for Chromium's clang plugins
* webrtc/pc/externalhmac.{h,cc} added for Chromium builds.
As soon this has landed a roll including the changes in
https://codereview.chromium.org/2022833002/ is needed to make
Chromium build cleanly.
BUG=webrtc:4256
NOTRY=True
NOPRESUBMIT=True
Review-Url: https://codereview.webrtc.org/1979933002
Cr-Commit-Position: refs/heads/master@{#12983}
removeCallbacksAndMessages() is called on the camera thread handler
before setting it to null to remove all pending runnables. The purpose
is to make sure *OnCameraThread methods are not executed when the
camera is stopped, but this does not seem to work reliably. This CL
resorts to a belt and braces approach and checks that the the handler is
still alive in all *OnCameraThread methods.
BUG=b/29015569
R=sakal@webrtc.org
Review URL: https://codereview.webrtc.org/2028643002 .
Cr-Commit-Position: refs/heads/master@{#12981}
Reason for revert:
Fixed gyp bug.
Original issue's description:
> Revert of Android: Change camera fps range selection (patchset #4 id:100001 of https://codereview.webrtc.org/2013413002/ )
>
> Reason for revert:
> Breaks chromium fyi:
> https://build.chromium.org/p/chromium.webrtc.fyi/builders/Mac%20Builder/builds/13565
> on step 'generate_build_files':
> gyp: /b/build/slave/Mac_Builder/build/src/third_party/build/android/test_runner.gypi not found
>
> Original issue's description:
> > Android: Change camera fps range selection
> >
> > This CL changes the logic in
> > CameraEnumerationAndroid.getClosestSupportedFramerateRange() to prefer
> > fps ranges with a low lower bound so the camera can adjust for
> > brightness conditions.
> >
> > To test the functionality of the fps range selection, JUnit tests are
> > added. This required a new target in api_tests.gyp. JUnit tests are
> > preferable over instrumentation tests
> > (libjingle_peerconnection_android_unittest) because they are faster and
> > simpler.
> >
> > R=kjellander@webrtc.org, sakal@webrtc.org
> >
> > Committed: https://crrev.com/b4ddb5c3d3706b1c02437f6a538576f3552ab908
> > Cr-Commit-Position: refs/heads/master@{#12964}
>
> TBR=sakal@webrtc.org,kjellander@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
>
> Committed: https://crrev.com/b3f208d0ba45f140272e3e705b5cdadc3c76514b
> Cr-Commit-Position: refs/heads/master@{#12966}
TBR=sakal@webrtc.org,kjellander@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.webrtc.org/2028583002
Cr-Commit-Position: refs/heads/master@{#12980}
This allows webrtc to not gather on cellular networks if wifi or
other low cost networks are present.
BUG=
Review-Url: https://codereview.webrtc.org/1987833002
Cr-Commit-Position: refs/heads/master@{#12979}
This will make it much less likely for application developers to not
realize the object is reference counted.
It also fixes a bug in the Java PeerConnection binding, by allowing a
reference to be transferred in the OnRemoveStream call via std::move.
BUG=webrtc:5128
R=pthatcher@webrtc.org, tkchin@webrtc.org
Review URL: https://codereview.webrtc.org/1972793003 .
Cr-Commit-Position: refs/heads/master@{#12976}
We plan to add junit tests running with Robolectric
so naming these files "apk" is slightly confusing.
NOTRY=True
Review-Url: https://codereview.webrtc.org/2020213002
Cr-Commit-Position: refs/heads/master@{#12971}
This CL removes compile warnings such as:
[4520/4630] ACTION Compiling java for libjingle_peerconnection_android_unittest
androidtests/src/org/webrtc/VideoCapturerAndroidTestFixtures.java:13: warning: [deprecation] Camera in android.hardware has been deprecated
import android.hardware.Camera;
Review-Url: https://codereview.webrtc.org/2024083002
Cr-Commit-Position: refs/heads/master@{#12970}
Reason for revert:
Breaks chromium fyi:
https://build.chromium.org/p/chromium.webrtc.fyi/builders/Mac%20Builder/builds/13565
on step 'generate_build_files':
gyp: /b/build/slave/Mac_Builder/build/src/third_party/build/android/test_runner.gypi not found
Original issue's description:
> Android: Change camera fps range selection
>
> This CL changes the logic in
> CameraEnumerationAndroid.getClosestSupportedFramerateRange() to prefer
> fps ranges with a low lower bound so the camera can adjust for
> brightness conditions.
>
> To test the functionality of the fps range selection, JUnit tests are
> added. This required a new target in api_tests.gyp. JUnit tests are
> preferable over instrumentation tests
> (libjingle_peerconnection_android_unittest) because they are faster and
> simpler.
>
> R=kjellander@webrtc.org, sakal@webrtc.org
>
> Committed: https://crrev.com/b4ddb5c3d3706b1c02437f6a538576f3552ab908
> Cr-Commit-Position: refs/heads/master@{#12964}
TBR=sakal@webrtc.org,kjellander@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.webrtc.org/2021233002
Cr-Commit-Position: refs/heads/master@{#12966}
This CL changes the logic in
CameraEnumerationAndroid.getClosestSupportedFramerateRange() to prefer
fps ranges with a low lower bound so the camera can adjust for
brightness conditions.
To test the functionality of the fps range selection, JUnit tests are
added. This required a new target in api_tests.gyp. JUnit tests are
preferable over instrumentation tests
(libjingle_peerconnection_android_unittest) because they are faster and
simpler.
R=kjellander@webrtc.org, sakal@webrtc.org
Review URL: https://codereview.webrtc.org/2013413002 .
Cr-Commit-Position: refs/heads/master@{#12964}
Reason for revert:
Updated signature to work with other JNI versions. We would need to compile it differently in order to catch failures like this in WebRTC in the future.
Original issue's description:
> Revert of Android: Add FramerateRange class (patchset #2 id:60001 of https://codereview.webrtc.org/2010763003/ )
>
> Reason for revert:
> Breaks downstream Android tests:
> java.lang.NoSuchFieldError: no field with name='framerate' signature='org/webrtc/CameraEnumerationAndroid$CaptureFormat$FramerateRange' in class Lorg/webrtc/CameraEnumerationAndroid$CaptureFormat;
>
> We should have a similar test in WebRTC so we can catch such errors pre-commit.
>
> Original issue's description:
> > Android: Add FramerateRange class
> >
> > The Camera1 and Camera2 API use different framerate range types. Camera1
> > uses int[2] and Camera2 uses Range<Integer>. Range<Integer> is
> > unfortunately only available on Lollipop and later, so this CL adds a
> > similar FramerateRange class in CaptureFormat.
> >
> > The purpose with this CL is to have a common framerate range type that can
> > be reused from both Camera1 and Camera2 in helper functions such as
> > CameraEnumerationAndroid.getClosestSupportedFramerateRange().
> >
> > BUG=webrtc:5519
> > R=sakal@webrtc.org
> >
> > Committed: https://crrev.com/94cb67d6df1a78e7fa25e469f719c1a8809dc583
> > Cr-Commit-Position: refs/heads/master@{#12942}
>
> TBR=sakal@webrtc.org,magjed@webrtc.org
> NOTRY=True
> BUG=webrtc:5519
>
> Committed: https://crrev.com/bd5621f065fd25e0a77307f10dc9ddaf76e7945f
> Cr-Commit-Position: refs/heads/master@{#12956}
TBR=sakal@webrtc.org,kjellander@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5519
Review-Url: https://codereview.webrtc.org/2019333002
Cr-Commit-Position: refs/heads/master@{#12957}
Reason for revert:
Breaks downstream Android tests:
java.lang.NoSuchFieldError: no field with name='framerate' signature='org/webrtc/CameraEnumerationAndroid$CaptureFormat$FramerateRange' in class Lorg/webrtc/CameraEnumerationAndroid$CaptureFormat;
We should have a similar test in WebRTC so we can catch such errors pre-commit.
Original issue's description:
> Android: Add FramerateRange class
>
> The Camera1 and Camera2 API use different framerate range types. Camera1
> uses int[2] and Camera2 uses Range<Integer>. Range<Integer> is
> unfortunately only available on Lollipop and later, so this CL adds a
> similar FramerateRange class in CaptureFormat.
>
> The purpose with this CL is to have a common framerate range type that can
> be reused from both Camera1 and Camera2 in helper functions such as
> CameraEnumerationAndroid.getClosestSupportedFramerateRange().
>
> BUG=webrtc:5519
> R=sakal@webrtc.org
>
> Committed: https://crrev.com/94cb67d6df1a78e7fa25e469f719c1a8809dc583
> Cr-Commit-Position: refs/heads/master@{#12942}
TBR=sakal@webrtc.org,magjed@webrtc.org
NOTRY=True
BUG=webrtc:5519
Review-Url: https://codereview.webrtc.org/2024573002
Cr-Commit-Position: refs/heads/master@{#12956}
When this test was updated to use separate worker/signaling threads,
the virtual socket server wasn't moved over to the worker thread. So it
was set on the signaling thread and wasn't being used.
Review-Url: https://codereview.webrtc.org/2015763002
Cr-Commit-Position: refs/heads/master@{#12951}
Reason for revert:
There are more CreatePeerConnection calls than I anticipated/had found in Chromium, like remoting/protocol/webrtc_transport.cc. Reverting due to broken Chromium FYI bots.
Original issue's description:
> Replacing DtlsIdentityStoreInterface with RTCCertificateGeneratorInterface.
>
> The store was used in WebRtcSessionDescriptionFactory to generate certificates,
> now a generator is used instead (new API). PeerConnection[Factory][Interface],
> and WebRtcSession are updated to pass generators all the way down to the
> WebRtcSessionDescriptionFactory instead of stores.
>
> The webrtc implementation of a generator, RTCCertificateGenerator, is used as
> the default generator (peerconnectionfactory.cc:189) instead of the webrtc
> implementation of a store, DtlsIdentityStoreImpl.
> The generator is fully parameterized and does not generate RSA-1024 unless you
> ask for it (which makes sense not to do beforehand since ECDSA is now default).
> The store was not fully parameterized (known filed bug).
>
> The "top" layer, PeerConnectionFactoryInterface::CreatePeerConnection, is
> updated to take a generator instead of a store. But as to not break Chromium,
> the old function signature taking a store is kept. It is implemented to invoke
> the generator version by wrapping the store in an
> RTCCertificateGeneratorStoreWrapper. As soon as Chromium is updated to use the
> new function signature we can remove the old CreatePeerConnection.
> Due to having multiple CreatePeerConnection signatures, some calling places
> are updated to resolve the ambiguity introduced.
>
> BUG=webrtc:5707, webrtc:5708
> R=phoglund@webrtc.org, tommi@webrtc.org
> TBR=tkchin@webrc.org
>
> Committed: 400781a209TBR=tkchin@webrtc.org,tommi@webrtc.org,phoglund@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5707, webrtc:5708
Review-Url: https://codereview.webrtc.org/2020633002
Cr-Commit-Position: refs/heads/master@{#12948}
The store was used in WebRtcSessionDescriptionFactory to generate certificates,
now a generator is used instead (new API). PeerConnection[Factory][Interface],
and WebRtcSession are updated to pass generators all the way down to the
WebRtcSessionDescriptionFactory instead of stores.
The webrtc implementation of a generator, RTCCertificateGenerator, is used as
the default generator (peerconnectionfactory.cc:189) instead of the webrtc
implementation of a store, DtlsIdentityStoreImpl.
The generator is fully parameterized and does not generate RSA-1024 unless you
ask for it (which makes sense not to do beforehand since ECDSA is now default).
The store was not fully parameterized (known filed bug).
The "top" layer, PeerConnectionFactoryInterface::CreatePeerConnection, is
updated to take a generator instead of a store. But as to not break Chromium,
the old function signature taking a store is kept. It is implemented to invoke
the generator version by wrapping the store in an
RTCCertificateGeneratorStoreWrapper. As soon as Chromium is updated to use the
new function signature we can remove the old CreatePeerConnection.
Due to having multiple CreatePeerConnection signatures, some calling places
are updated to resolve the ambiguity introduced.
BUG=webrtc:5707, webrtc:5708
R=phoglund@webrtc.org, tommi@webrtc.orgTBR=tkchin@webrc.org
Review URL: https://codereview.webrtc.org/2013523002 .
Cr-Commit-Position: refs/heads/master@{#12947}
This CL makes the ctor public and externally usable by changing the
camera id argument from an int to a String.
The main purpose with this change is to get rid of the
CameraEnumerationAndroid.setEnumerator() hack. If an external app wants
to have a custom format enumeration, they can just override
getSupportedFormats() instead.
BUG=webrtc:5519
Review-Url: https://codereview.webrtc.org/2012193003
Cr-Commit-Position: refs/heads/master@{#12945}
The Camera1 and Camera2 API use different framerate range types. Camera1
uses int[2] and Camera2 uses Range<Integer>. Range<Integer> is
unfortunately only available on Lollipop and later, so this CL adds a
similar FramerateRange class in CaptureFormat.
The purpose with this CL is to have a common framerate range type that can
be reused from both Camera1 and Camera2 in helper functions such as
CameraEnumerationAndroid.getClosestSupportedFramerateRange().
BUG=webrtc:5519
R=sakal@webrtc.org
Review URL: https://codereview.webrtc.org/2010763003 .
Cr-Commit-Position: refs/heads/master@{#12942}
