In order to switch Chromium to use WebRTC targets instead of
duplicated code listings in src/third_party/libjingle it must
be possible for Chromium to process webrtc/api/api.gyp. This is
currently not possible since it includes build/java.gypi, of which
the path is different in a Chromium checkout. It's not possible
to resolve this in another way since 'includes' processing takes
place early in the GYP cycle, before it's possible to use variables.
They're also processed ignoring conditional statements, resulting
in an error when api.gyp is processed.
BUG=webrtc:4256
TBR=perkj@webrtc.org
NOTRY=True
Review-Url: https://codereview.webrtc.org/2080563002
Cr-Commit-Position: refs/heads/master@{#13208}
The plan is to use CameraEnumerator as a "factory" for camera objects in
the future. This CL prepares for that by moving Camera1 specific stuff
away from CameraEnumerationAndroid to Camera1Enumerator. Because
CameraEnumerationAndroid methods were part of public API there are
deprecated mocks for now.
When making these changes, I noticed that code duplication in
CameraVideoCapturer tests implementing TestObjectFactory could be
decreased by making TestObjectFactory an abstract class that uses
CameraEnumerator.
BUG=webrtc:5519
Review-Url: https://codereview.webrtc.org/2071803002
Cr-Commit-Position: refs/heads/master@{#13185}
The Camera1 and Camera2 API use different size types. Camera1 uses
android.hardware.Camera.Size while Camera2 uses android.util.Size.
android.util.Size is only available from Lollipop forward so this CL
adds a similar Size class in CaptureFormat.
The purpose of this CL is to have a common size type that can be reused
from both Camera1 and Camera2 helper functions such as
CameraEnumerationAndroid.getClosestSupportedSize().
BUG=webrtc:5519
Review-Url: https://codereview.webrtc.org/2066773002
Cr-Commit-Position: refs/heads/master@{#13181}
This change reduces the number of times the Android hardware video
encoder is reconfigured when making an outgoing call. With this change,
the encoder should only be initialized once as opposed to the ~3 times
it happens currently.
Before the fix, the following sequence of events caused the extra
reconfigurations:
1. After the SetLocalDescription call, the WebRtcVideoSendStream is created.
All frames from the camera are dropped until the corresponding
VideoSendStream is created.
2. SetRemoteDescription() triggers the VideoSendStream creation. At
this point, the encoder is configured for the first time, with the
frame dimensions set to a low resolution default (176x144).
3. When the first video frame is received from the camera after the
VideoSendStreamIsCreated, the encoder is reconfigured to the correct
dimensions. If we are using the Android hardware encoder, the default
configuration is set to encode from a memory buffer (use_surface=false).
4. When the frame is passed down to the encoder in
androidmediaencoder_jni.cc EncodeOnCodecThread(), it may be stored in
a texture instead of a memory buffer. In this case, yet another
reconfiguration takes place to enable encoding from a texture.
5. Even if the resolution and texture flag were known at the start of
the call, there would be a reconfiguration involved if the camera is
rotated (such as when making a call from a phone in portrait orientation).
The reason for that is that at construction time, WebRtcVideoEngine2
sets the VideoSinkWants structure parameter to request frames rotated
by the source; the early frames will then arrive in portrait resolution.
When the remote description is finally set, if the rotation RTP extension
is supported by the remote receiver, the source is asked to provide
non-rotated frames. The very next frame will then arrive in landscape
resolution with a non-zero rotation value to be applied by the receiver.
Since the encoder was configured with the last (portrait) frame size,
it's going to need to be reconfigured again.
The fix makes the following changes:
1. WebRtcVideoSendStream::OnFrame() now caches the last seen frame
dimensions, and whether the frame was stored in a texture.
2. When the encoder is configured the first time
(WebRtcVideoSendStream::SetCodec()) - the last seen frame dimensions
are used instead of the default dimensions.
3. A flag that indicates if encoding is to be done from a texture has
been added to the webrtc::VideoStream and webrtc::VideoCodec structs,
and it's been wired up to be passed down all the way to the JNI code in
androidmediaencoder_jni.cc.
4. MediaCodecVideoEncoder::InitEncode is now reading the is_surface
flag from the VideoCodec structure instead of guessing the default as
false. This way we end up with the correct encoder configuration the
first time around.
5. WebRtcVideoSendStream now takes an optimistic guess and requests non-
rotated frames when the supported RtpExtensions list is not available.
This makes the "early" frames arrive non-rotated, and the cached dimensions
will be correct for the common case when the rotation extension is supported.
If the other side is an older endpoint which does not support rotation,
the encoder will have to be reconfigured - but it's better to penalize the
uncommon case rather than the common one.
Review-Url: https://codereview.webrtc.org/2067103002
Cr-Commit-Position: refs/heads/master@{#13173}
The test sent a media packet, then verified it was sent by checking the
"last packet sent"'s ID. But the last packet sent may have been
a STUN packet that came *after* the media packet.
BUG=webrtc:5978
Review-Url: https://codereview.webrtc.org/2071573002
Cr-Commit-Position: refs/heads/master@{#13156}
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}
