Previously, the matrix in VideoFrame was used to crop and scale the
frame. This caused complications because webrtc::VideoFrame doesn't
include a matrix. cropAndScale method is added to VideoBuffer class for
cropping and scaling instead.
BUG=webrtc:7749, webrtc:7760
Review-Url: https://codereview.webrtc.org/2990583002
Cr-Commit-Position: refs/heads/master@{#19179}
When you create multiple "PeerConnectionFactory"s, they end up using
the same NetworkMonitor singleton. But the second one's
"AndroidNetworkMonitor" class (in C++) wasn't getting the expected
network list update, and as a result it wasn't binding sockets to
networks successfully, acting as if the networks didn't exist.
The solution is just to move "updateActiveNetworkList" to
"startMonitoring". This CL also does some other minor
cleanup/refactoring, and fixes a more corner-casey issue where, if the
first PeerConnection is destroyed, the second one would stop receiving
network updates.
BUG=webrtc:7946
Review-Url: https://codereview.webrtc.org/2990693002
Cr-Commit-Position: refs/heads/master@{#19156}
During a call, with both phones in horizontal or landscape mode, rapidly switching between the front and back camera sometimes causes the remote video to be shown upside down.
There seems to be a race condition when setting the rotation based on the orientation of the device and which camera we're using.
So use the active input's camera to check instead of the client state.
BUG=webrtc:7898
Review-Url: https://codereview.webrtc.org/2964703002
Cr-Commit-Position: refs/heads/master@{#19139}
Reason for revert:
Relanding after fixing issues with no video.
Original issue's description:
> Revert of Injectable Obj-C video codecs (patchset #2 id:370001 of https://codereview.webrtc.org/2979983002/ )
>
> Reason for revert:
> Still having problems with no video. Reverting.
> Once no video is visible, no video is available from then on even if the callee app is in the foreground.
>
>
> Original issue's description:
> > Reland of Injectable Obj-C video codecs (patchset #1 id:1 of https://codereview.webrtc.org/2979973002/ )
> >
> > Reason for revert:
> > Fix the broken build file
> >
> > Original issue's description:
> > > Revert of Injectable Obj-C video codecs (patchset #3 id:400001 of https://codereview.webrtc.org/2981583002/ )
> > >
> > > Reason for revert:
> > > Breaks bots. Build file incorrect.
> > >
> > > Original issue's description:
> > > > Reland of Injectable Obj-C video codecs (patchset #1 id:1 of https://codereview.webrtc.org/2975963002/ )
> > > >
> > > > Reason for revert:
> > > > New CL for fixing the issues
> > > >
> > > > Original issue's description:
> > > > > Revert of Injectable Obj-C video codecs (patchset #8 id:140001 of https://codereview.webrtc.org/2966023002/ )
> > > > >
> > > > > Reason for revert:
> > > > > Causes no video in certain scenarios. Please come up with a test plan or unit test to prevent such problems in the future.
> > > > >
> > > > > Original issue's description:
> > > > > > Injectable Obj-C video codecs
> > > > > >
> > > > > > Initial CL for this effort, with a working RTCVideoEncoder/Decoder for H264
> > > > > > (wrapping the VideoToolbox codec).
> > > > > >
> > > > > > Some notes / things left to do:
> > > > > > - There are some hard-coded references to codec types that are supported by
> > > > > > webrtc::VideoCodec, cricket::VideoCodec, webrtc::CodecSpecificInfo etc
> > > > > > since we need to convert to/from these types in ObjCVideoEncoder/Decoder.
> > > > > > These types would need to be more codec agnostic to avoid this.
> > > > > > - Most interfaces are borrowed from the design document for injectable
> > > > > > codecs in Android. Some data in the corresponding C++ classes is discarded
> > > > > > when converting to the Obj-C version, since it has fewer fields. I have not
> > > > > > verified whether all data that we do keep is needed, or whether we might be
> > > > > > losing anything useful in these conversions.
> > > > > > - Implement the VideoToolbox codec code directly in the RTCVideoEncoderH264
> > > > > > classes, instead of wrapping webrtc::H264VideoToolboxEncoder / decoder.
> > > > > > Eliminates converting between ObjC/C++ types outside the ObjCVideoEncoder/
> > > > > > Decoder wrapper classes.
> > > > > > - List the injected codec factory's supported codecs in the list of codecs in
> > > > > > AppRTCMobile.
> > > > > >
> > > > > > BUG=webrtc:7924
> > > > > > R=magjed@webrtc.org
> > > > > >
> > > > > > Review-Url: https://codereview.webrtc.org/2966023002 .
> > > > > > Cr-Commit-Position: refs/heads/master@{#18928}
> > > > > > Committed: a0349c138d
> > > > >
> > > > > TBR=magjed@webrtc.org,andersc@webrtc.org
> > > > > # Not skipping CQ checks because original CL landed more than 1 days ago.
> > > > > BUG=webrtc:7924
> > > > > NOTRY=true
> > > > >
> > > > > Review-Url: https://codereview.webrtc.org/2975963002
> > > > > Cr-Commit-Position: refs/heads/master@{#18979}
> > > > > Committed: 1095ada7ad
> > > >
> > > > R=magjed@webrtc.org
> > > > TBR=tkchin@webrtc.org
> > > > # Skipping CQ checks because original CL landed less than 1 days ago.
> > > > NOPRESUBMIT=true
> > > > NOTREECHECKS=true
> > > > NOTRY=true
> > > > BUG=webrtc:7924
> > > >
> > > > Review-Url: https://codereview.webrtc.org/2981583002 .
> > > > Cr-Commit-Position: refs/heads/master@{#19002}
> > > > Committed: a5f1de1e65
> > >
> > > TBR=magjed@webrtc.org,tkchin@webrtc.org,jtteh@webrtc.org,andersc@webrtc.org
> > > # Skipping CQ checks because original CL landed less than 1 days ago.
> > > NOPRESUBMIT=true
> > > NOTREECHECKS=true
> > > NOTRY=true
> > > BUG=webrtc:7924
> > >
> > > Review-Url: https://codereview.webrtc.org/2979973002
> > > Cr-Commit-Position: refs/heads/master@{#19004}
> > > Committed: 81d40ee149
> >
> > TBR=magjed@webrtc.org,tkchin@webrtc.org,jtteh@webrtc.org,sprang@webrtc.org
> > BUG=webrtc:7924
> >
> > Review-Url: https://codereview.webrtc.org/2979983002
> > Cr-Commit-Position: refs/heads/master@{#19005}
> > Committed: 732a3437da
>
> TBR=magjed@webrtc.org,tkchin@webrtc.org,sprang@webrtc.org,haysc@webrtc.org,andersc@webrtc.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=webrtc:7924
>
> Review-Url: https://codereview.webrtc.org/2980173002
> Cr-Commit-Position: refs/heads/master@{#19036}
> Committed: 860f729816TBR=magjed@webrtc.org,tkchin@webrtc.org,sprang@webrtc.org,haysc@webrtc.org,andersc@webrtc.org,jtteh@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:7924
Review-Url: https://codereview.webrtc.org/2977213002
Cr-Commit-Position: refs/heads/master@{#19135}
"error: values of type 'NSInteger' should not be used as format arguments; add an explicit cast to 'long' instead"
Casting to long is already a common practice in the code base.
This has been blocking the Chromium roll which contains an update to clang 6.0.0
BUG=None
Review-Url: https://codereview.webrtc.org/2987693002
Cr-Commit-Position: refs/heads/master@{#19127}
All downstream code have been updated to the new location.
In PRESUBMIT.py:
* Remove webrtc/rtc_base from CPP_BLACKLIST
* Add webrtc/rtc_base to LEGACY_API_DIRS
Fix some duplicated paths in
webrtc/modules/audio_processing/test/conversational_speech/BUILD.gn
BUG=webrtc:7634
TBR=kwiberg@webrtc.org
Review-Url: https://codereview.webrtc.org/2976293002
Cr-Commit-Position: refs/heads/master@{#19094}
HardwareVideoEncoderFactory can now take an EglBase.Context on creation.
When it does, it creates video encoders in texture mode. It uses the
COLOR_FormatSurface colorFormat. It passes the EglBase.Context to the
HardwareVideoEncoder.
The HardwareVideoEncoder sets up an input surface for its codec and handles
incoming frames by drawing them onto the input surface.
BUG=webrtc:7760
R=pthatcher@webrtc.org, sakal@webrtc.org
Review-Url: https://codereview.webrtc.org/2977153003 .
Cr-Commit-Position: refs/heads/master@{#19083}
HardwareVideoDecoder is now a listener for SurfaceTextureHelper. It takes a
SurfaceTextureHelper on construction. If it is non-null, it operates in texture
mode instead of byte-buffer mode.
When in texture mode, the HardwareVideoDecoder renders output frames to a Surface,
listens for the texture frame to become available, wraps it in a VideoFrame, and
pushes it to the decoder callback.
As in MediaCodecVideoDecoder, it may queue up to three buffers while waiting for
the surface to become available for rendering. If more buffers are queued, it will
drop the oldest.
This change also implements the VideoFrame.TextureBuffer and reorganizes code
for wrapping an existing ByteBuffer into an I420Buffer. This makes it easier
to implement the texture buffer's ToI420() method.
BUG=webrtc:7760
R=pthatcher@webrtc.org, sakal@webrtc.org
Review-Url: https://codereview.webrtc.org/2977643002 .
Cr-Commit-Position: refs/heads/master@{#19081}
The surface view renderer size was set to match parent so it couldn't
adjust based on the frame size. The size is now set to wrap_content
which allows the renderer to adjust. The root element of the call
activity is changed to FrameLayout to allow the renderer to center.
requestLayout is added to SurfaceView setScalingType so onMeasure gets
called again.
BUG=webrtc:7901
Review-Url: https://codereview.webrtc.org/2978173002
Cr-Commit-Position: refs/heads/master@{#19073}
Bug: webrtc:7969
Change-Id: I3fbb723d35fa6cc4c7b92aa1e155b974e9fb0b55
Reviewed-on: https://chromium-review.googlesource.com/567698
Commit-Queue: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Alex Glaznev <glaznev@chromium.org>
Reviewed-by: Peter Thatcher <pthatcher@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19062}
Reason for revert:
Still having problems with no video. Reverting.
Once no video is visible, no video is available from then on even if the callee app is in the foreground.
Original issue's description:
> Reland of Injectable Obj-C video codecs (patchset #1 id:1 of https://codereview.webrtc.org/2979973002/ )
>
> Reason for revert:
> Fix the broken build file
>
> Original issue's description:
> > Revert of Injectable Obj-C video codecs (patchset #3 id:400001 of https://codereview.webrtc.org/2981583002/ )
> >
> > Reason for revert:
> > Breaks bots. Build file incorrect.
> >
> > Original issue's description:
> > > Reland of Injectable Obj-C video codecs (patchset #1 id:1 of https://codereview.webrtc.org/2975963002/ )
> > >
> > > Reason for revert:
> > > New CL for fixing the issues
> > >
> > > Original issue's description:
> > > > Revert of Injectable Obj-C video codecs (patchset #8 id:140001 of https://codereview.webrtc.org/2966023002/ )
> > > >
> > > > Reason for revert:
> > > > Causes no video in certain scenarios. Please come up with a test plan or unit test to prevent such problems in the future.
> > > >
> > > > Original issue's description:
> > > > > Injectable Obj-C video codecs
> > > > >
> > > > > Initial CL for this effort, with a working RTCVideoEncoder/Decoder for H264
> > > > > (wrapping the VideoToolbox codec).
> > > > >
> > > > > Some notes / things left to do:
> > > > > - There are some hard-coded references to codec types that are supported by
> > > > > webrtc::VideoCodec, cricket::VideoCodec, webrtc::CodecSpecificInfo etc
> > > > > since we need to convert to/from these types in ObjCVideoEncoder/Decoder.
> > > > > These types would need to be more codec agnostic to avoid this.
> > > > > - Most interfaces are borrowed from the design document for injectable
> > > > > codecs in Android. Some data in the corresponding C++ classes is discarded
> > > > > when converting to the Obj-C version, since it has fewer fields. I have not
> > > > > verified whether all data that we do keep is needed, or whether we might be
> > > > > losing anything useful in these conversions.
> > > > > - Implement the VideoToolbox codec code directly in the RTCVideoEncoderH264
> > > > > classes, instead of wrapping webrtc::H264VideoToolboxEncoder / decoder.
> > > > > Eliminates converting between ObjC/C++ types outside the ObjCVideoEncoder/
> > > > > Decoder wrapper classes.
> > > > > - List the injected codec factory's supported codecs in the list of codecs in
> > > > > AppRTCMobile.
> > > > >
> > > > > BUG=webrtc:7924
> > > > > R=magjed@webrtc.org
> > > > >
> > > > > Review-Url: https://codereview.webrtc.org/2966023002 .
> > > > > Cr-Commit-Position: refs/heads/master@{#18928}
> > > > > Committed: a0349c138d
> > > >
> > > > TBR=magjed@webrtc.org,andersc@webrtc.org
> > > > # Not skipping CQ checks because original CL landed more than 1 days ago.
> > > > BUG=webrtc:7924
> > > > NOTRY=true
> > > >
> > > > Review-Url: https://codereview.webrtc.org/2975963002
> > > > Cr-Commit-Position: refs/heads/master@{#18979}
> > > > Committed: 1095ada7ad
> > >
> > > R=magjed@webrtc.org
> > > TBR=tkchin@webrtc.org
> > > # Skipping CQ checks because original CL landed less than 1 days ago.
> > > NOPRESUBMIT=true
> > > NOTREECHECKS=true
> > > NOTRY=true
> > > BUG=webrtc:7924
> > >
> > > Review-Url: https://codereview.webrtc.org/2981583002 .
> > > Cr-Commit-Position: refs/heads/master@{#19002}
> > > Committed: a5f1de1e65
> >
> > TBR=magjed@webrtc.org,tkchin@webrtc.org,jtteh@webrtc.org,andersc@webrtc.org
> > # Skipping CQ checks because original CL landed less than 1 days ago.
> > NOPRESUBMIT=true
> > NOTREECHECKS=true
> > NOTRY=true
> > BUG=webrtc:7924
> >
> > Review-Url: https://codereview.webrtc.org/2979973002
> > Cr-Commit-Position: refs/heads/master@{#19004}
> > Committed: 81d40ee149
>
> TBR=magjed@webrtc.org,tkchin@webrtc.org,jtteh@webrtc.org,sprang@webrtc.org
> BUG=webrtc:7924
>
> Review-Url: https://codereview.webrtc.org/2979983002
> Cr-Commit-Position: refs/heads/master@{#19005}
> Committed: 732a3437daTBR=magjed@webrtc.org,tkchin@webrtc.org,sprang@webrtc.org,haysc@webrtc.org,andersc@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:7924
Review-Url: https://codereview.webrtc.org/2980173002
Cr-Commit-Position: refs/heads/master@{#19036}
This reverts commit 93adc3209b5ff10adaba54d5eab6b53bc2780685.
Reverted originally because it depended on a CL which was reverted.
That CL has been reinstated in:
https: //chromium-review.googlesource.com/#/c/572070/
Bug: webrtc:7969
Change-Id: I608bbeaaba02e84908433c8260cf236df0307a97
Reviewed-on: https://chromium-review.googlesource.com/572405
Reviewed-by: Zeke Chin <tkchin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#19035}
This is a partial re-land. The change doesn't make the default Thread ctor protected anymore but it does mark it as deprecated and updates all use of it in WebRTC.
Original issue's description:
Make the default ctor of rtc::Thread, protected.
The goal is to force use of Thread::Create or Thread::CreateWithSocketServer.
The default constructor constructs a 'default' socket server, which is usually a 'physical' socket server, but not always. Not every instance of Thread actually needs to have network support, so it's better to have this be explicit instead of unknowingly instantiate one.
BUG=none
Review-Url: https://codereview.webrtc.org/2977953002
Cr-Commit-Position: refs/heads/master@{#19031}
If a SurfaceViewRenderer is reinitialized, the onFirstFrameRendered
callback is not fired.
Ensure that we reset the flag when the SurfaceViewRenderer is
initialized.
BUG=webrtc:7985
Review-Url: https://codereview.webrtc.org/2981793002
Cr-Commit-Position: refs/heads/master@{#19016}
Reason for revert:
Fix the broken build file
Original issue's description:
> Revert of Injectable Obj-C video codecs (patchset #3 id:400001 of https://codereview.webrtc.org/2981583002/ )
>
> Reason for revert:
> Breaks bots. Build file incorrect.
>
> Original issue's description:
> > Reland of Injectable Obj-C video codecs (patchset #1 id:1 of https://codereview.webrtc.org/2975963002/ )
> >
> > Reason for revert:
> > New CL for fixing the issues
> >
> > Original issue's description:
> > > Revert of Injectable Obj-C video codecs (patchset #8 id:140001 of https://codereview.webrtc.org/2966023002/ )
> > >
> > > Reason for revert:
> > > Causes no video in certain scenarios. Please come up with a test plan or unit test to prevent such problems in the future.
> > >
> > > Original issue's description:
> > > > Injectable Obj-C video codecs
> > > >
> > > > Initial CL for this effort, with a working RTCVideoEncoder/Decoder for H264
> > > > (wrapping the VideoToolbox codec).
> > > >
> > > > Some notes / things left to do:
> > > > - There are some hard-coded references to codec types that are supported by
> > > > webrtc::VideoCodec, cricket::VideoCodec, webrtc::CodecSpecificInfo etc
> > > > since we need to convert to/from these types in ObjCVideoEncoder/Decoder.
> > > > These types would need to be more codec agnostic to avoid this.
> > > > - Most interfaces are borrowed from the design document for injectable
> > > > codecs in Android. Some data in the corresponding C++ classes is discarded
> > > > when converting to the Obj-C version, since it has fewer fields. I have not
> > > > verified whether all data that we do keep is needed, or whether we might be
> > > > losing anything useful in these conversions.
> > > > - Implement the VideoToolbox codec code directly in the RTCVideoEncoderH264
> > > > classes, instead of wrapping webrtc::H264VideoToolboxEncoder / decoder.
> > > > Eliminates converting between ObjC/C++ types outside the ObjCVideoEncoder/
> > > > Decoder wrapper classes.
> > > > - List the injected codec factory's supported codecs in the list of codecs in
> > > > AppRTCMobile.
> > > >
> > > > BUG=webrtc:7924
> > > > R=magjed@webrtc.org
> > > >
> > > > Review-Url: https://codereview.webrtc.org/2966023002 .
> > > > Cr-Commit-Position: refs/heads/master@{#18928}
> > > > Committed: a0349c138d
> > >
> > > TBR=magjed@webrtc.org,andersc@webrtc.org
> > > # Not skipping CQ checks because original CL landed more than 1 days ago.
> > > BUG=webrtc:7924
> > > NOTRY=true
> > >
> > > Review-Url: https://codereview.webrtc.org/2975963002
> > > Cr-Commit-Position: refs/heads/master@{#18979}
> > > Committed: 1095ada7ad
> >
> > R=magjed@webrtc.org
> > TBR=tkchin@webrtc.org
> > # Skipping CQ checks because original CL landed less than 1 days ago.
> > NOPRESUBMIT=true
> > NOTREECHECKS=true
> > NOTRY=true
> > BUG=webrtc:7924
> >
> > Review-Url: https://codereview.webrtc.org/2981583002 .
> > Cr-Commit-Position: refs/heads/master@{#19002}
> > Committed: a5f1de1e65
>
> TBR=magjed@webrtc.org,tkchin@webrtc.org,jtteh@webrtc.org,andersc@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:7924
>
> Review-Url: https://codereview.webrtc.org/2979973002
> Cr-Commit-Position: refs/heads/master@{#19004}
> Committed: 81d40ee149TBR=magjed@webrtc.org,tkchin@webrtc.org,jtteh@webrtc.org,sprang@webrtc.org
BUG=webrtc:7924
Review-Url: https://codereview.webrtc.org/2979983002
Cr-Commit-Position: refs/heads/master@{#19005}
Reason for revert:
Breaks bots. Build file incorrect.
Original issue's description:
> Reland of Injectable Obj-C video codecs (patchset #1 id:1 of https://codereview.webrtc.org/2975963002/ )
>
> Reason for revert:
> New CL for fixing the issues
>
> Original issue's description:
> > Revert of Injectable Obj-C video codecs (patchset #8 id:140001 of https://codereview.webrtc.org/2966023002/ )
> >
> > Reason for revert:
> > Causes no video in certain scenarios. Please come up with a test plan or unit test to prevent such problems in the future.
> >
> > Original issue's description:
> > > Injectable Obj-C video codecs
> > >
> > > Initial CL for this effort, with a working RTCVideoEncoder/Decoder for H264
> > > (wrapping the VideoToolbox codec).
> > >
> > > Some notes / things left to do:
> > > - There are some hard-coded references to codec types that are supported by
> > > webrtc::VideoCodec, cricket::VideoCodec, webrtc::CodecSpecificInfo etc
> > > since we need to convert to/from these types in ObjCVideoEncoder/Decoder.
> > > These types would need to be more codec agnostic to avoid this.
> > > - Most interfaces are borrowed from the design document for injectable
> > > codecs in Android. Some data in the corresponding C++ classes is discarded
> > > when converting to the Obj-C version, since it has fewer fields. I have not
> > > verified whether all data that we do keep is needed, or whether we might be
> > > losing anything useful in these conversions.
> > > - Implement the VideoToolbox codec code directly in the RTCVideoEncoderH264
> > > classes, instead of wrapping webrtc::H264VideoToolboxEncoder / decoder.
> > > Eliminates converting between ObjC/C++ types outside the ObjCVideoEncoder/
> > > Decoder wrapper classes.
> > > - List the injected codec factory's supported codecs in the list of codecs in
> > > AppRTCMobile.
> > >
> > > BUG=webrtc:7924
> > > R=magjed@webrtc.org
> > >
> > > Review-Url: https://codereview.webrtc.org/2966023002 .
> > > Cr-Commit-Position: refs/heads/master@{#18928}
> > > Committed: a0349c138d
> >
> > TBR=magjed@webrtc.org,andersc@webrtc.org
> > # Not skipping CQ checks because original CL landed more than 1 days ago.
> > BUG=webrtc:7924
> > NOTRY=true
> >
> > Review-Url: https://codereview.webrtc.org/2975963002
> > Cr-Commit-Position: refs/heads/master@{#18979}
> > Committed: 1095ada7ad
>
> R=magjed@webrtc.org
> TBR=tkchin@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:7924
>
> Review-Url: https://codereview.webrtc.org/2981583002 .
> Cr-Commit-Position: refs/heads/master@{#19002}
> Committed: a5f1de1e65TBR=magjed@webrtc.org,tkchin@webrtc.org,jtteh@webrtc.org,andersc@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:7924
Review-Url: https://codereview.webrtc.org/2979973002
Cr-Commit-Position: refs/heads/master@{#19004}
Reason for revert:
Break projects.
Original issue's description:
> Make the default ctor of rtc::Thread, protected.
> The goal is to force use of Thread::Create or Thread::CreateWithSocketServer.
>
> The default constructor constructs a 'default' socket server, which is usually a 'physical' socket server, but not always. Not every instance of Thread actually needs to have network support, so it's better to have this be explicit instead of unknowingly instantiate one.
>
> BUG=none
>
> Review-Url: https://codereview.webrtc.org/2981623002
> Cr-Commit-Position: refs/heads/master@{#19001}
> Committed: a8a3515997TBR=kthelgason@webrtc.org,tommi@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=none
Review-Url: https://codereview.webrtc.org/2979963002
Cr-Commit-Position: refs/heads/master@{#19003}
Reason for revert:
New CL for fixing the issues
Original issue's description:
> Revert of Injectable Obj-C video codecs (patchset #8 id:140001 of https://codereview.webrtc.org/2966023002/ )
>
> Reason for revert:
> Causes no video in certain scenarios. Please come up with a test plan or unit test to prevent such problems in the future.
>
> Original issue's description:
> > Injectable Obj-C video codecs
> >
> > Initial CL for this effort, with a working RTCVideoEncoder/Decoder for H264
> > (wrapping the VideoToolbox codec).
> >
> > Some notes / things left to do:
> > - There are some hard-coded references to codec types that are supported by
> > webrtc::VideoCodec, cricket::VideoCodec, webrtc::CodecSpecificInfo etc
> > since we need to convert to/from these types in ObjCVideoEncoder/Decoder.
> > These types would need to be more codec agnostic to avoid this.
> > - Most interfaces are borrowed from the design document for injectable
> > codecs in Android. Some data in the corresponding C++ classes is discarded
> > when converting to the Obj-C version, since it has fewer fields. I have not
> > verified whether all data that we do keep is needed, or whether we might be
> > losing anything useful in these conversions.
> > - Implement the VideoToolbox codec code directly in the RTCVideoEncoderH264
> > classes, instead of wrapping webrtc::H264VideoToolboxEncoder / decoder.
> > Eliminates converting between ObjC/C++ types outside the ObjCVideoEncoder/
> > Decoder wrapper classes.
> > - List the injected codec factory's supported codecs in the list of codecs in
> > AppRTCMobile.
> >
> > BUG=webrtc:7924
> > R=magjed@webrtc.org
> >
> > Review-Url: https://codereview.webrtc.org/2966023002 .
> > Cr-Commit-Position: refs/heads/master@{#18928}
> > Committed: a0349c138d
>
> TBR=magjed@webrtc.org,andersc@webrtc.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=webrtc:7924
> NOTRY=true
>
> Review-Url: https://codereview.webrtc.org/2975963002
> Cr-Commit-Position: refs/heads/master@{#18979}
> Committed: 1095ada7adR=magjed@webrtc.orgTBR=tkchin@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:7924
Review-Url: https://codereview.webrtc.org/2981583002 .
Cr-Commit-Position: refs/heads/master@{#19002}
The goal is to force use of Thread::Create or Thread::CreateWithSocketServer.
The default constructor constructs a 'default' socket server, which is usually a 'physical' socket server, but not always. Not every instance of Thread actually needs to have network support, so it's better to have this be explicit instead of unknowingly instantiate one.
BUG=none
Review-Url: https://codereview.webrtc.org/2981623002
Cr-Commit-Position: refs/heads/master@{#19001}
Reason for revert:
Causes no video in certain scenarios. Please come up with a test plan or unit test to prevent such problems in the future.
Original issue's description:
> Injectable Obj-C video codecs
>
> Initial CL for this effort, with a working RTCVideoEncoder/Decoder for H264
> (wrapping the VideoToolbox codec).
>
> Some notes / things left to do:
> - There are some hard-coded references to codec types that are supported by
> webrtc::VideoCodec, cricket::VideoCodec, webrtc::CodecSpecificInfo etc
> since we need to convert to/from these types in ObjCVideoEncoder/Decoder.
> These types would need to be more codec agnostic to avoid this.
> - Most interfaces are borrowed from the design document for injectable
> codecs in Android. Some data in the corresponding C++ classes is discarded
> when converting to the Obj-C version, since it has fewer fields. I have not
> verified whether all data that we do keep is needed, or whether we might be
> losing anything useful in these conversions.
> - Implement the VideoToolbox codec code directly in the RTCVideoEncoderH264
> classes, instead of wrapping webrtc::H264VideoToolboxEncoder / decoder.
> Eliminates converting between ObjC/C++ types outside the ObjCVideoEncoder/
> Decoder wrapper classes.
> - List the injected codec factory's supported codecs in the list of codecs in
> AppRTCMobile.
>
> BUG=webrtc:7924
> R=magjed@webrtc.org
>
> Review-Url: https://codereview.webrtc.org/2966023002 .
> Cr-Commit-Position: refs/heads/master@{#18928}
> Committed: a0349c138dTBR=magjed@webrtc.org,andersc@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:7924
NOTRY=true
Review-Url: https://codereview.webrtc.org/2975963002
Cr-Commit-Position: refs/heads/master@{#18979}
Suppressing lint errors using comments is an undocumented feature of the
linter, and suppressing using the tools:ignore attribute should be
preferred.
Suppressing using comments becomes a problem when using the manifest
merger introduced in
6ada47bc79
as it reformats the comments slightly:
<!--suppress MissingPrefix -->
becomes
<!-- supress MissingPrefix -->
which causes the linter to disregard the suppression.
Bug: 740657
Change-Id: I8e365744d089271c390254e7c958b24b81043766
Reviewed-on: https://chromium-review.googlesource.com/566860
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Commit-Queue: Ingemar Ådahl <ingemara@opera.com>
Cr-Commit-Position: refs/heads/master@{#18971}
All downstream code have been updated to the new location.
In PRESUBMIT.py:
* Remove webrtc/rtc_base from CPP_BLACKLIST
* Add webrtc/rtc_base to LEGACY_API_DIRS
Fix some duplicated paths in
webrtc/modules/audio_processing/test/conversational_speech/BUILD.gn
BUG=webrtc:7634
TBR=kwiberg@webrtc.org
Review-Url: https://codereview.webrtc.org/2973183002
Cr-Commit-Position: refs/heads/master@{#18948}
Initial CL for this effort, with a working RTCVideoEncoder/Decoder for H264
(wrapping the VideoToolbox codec).
Some notes / things left to do:
- There are some hard-coded references to codec types that are supported by
webrtc::VideoCodec, cricket::VideoCodec, webrtc::CodecSpecificInfo etc
since we need to convert to/from these types in ObjCVideoEncoder/Decoder.
These types would need to be more codec agnostic to avoid this.
- Most interfaces are borrowed from the design document for injectable
codecs in Android. Some data in the corresponding C++ classes is discarded
when converting to the Obj-C version, since it has fewer fields. I have not
verified whether all data that we do keep is needed, or whether we might be
losing anything useful in these conversions.
- Implement the VideoToolbox codec code directly in the RTCVideoEncoderH264
classes, instead of wrapping webrtc::H264VideoToolboxEncoder / decoder.
Eliminates converting between ObjC/C++ types outside the ObjCVideoEncoder/
Decoder wrapper classes.
- List the injected codec factory's supported codecs in the list of codecs in
AppRTCMobile.
BUG=webrtc:7924
R=magjed@webrtc.org
Review-Url: https://codereview.webrtc.org/2966023002 .
Cr-Commit-Position: refs/heads/master@{#18928}
I used a command like this to update the paths:
perl -pi -e "s/webrtc\/base/webrtc\/rtc_base/g" `find webrtc/rtc_base -name "*.cc" -o -name "*.h"`
BUG=webrtc:7634
NOPRESUBMIT=True # cpplint errors that aren't caused by this CL.
Review-Url: https://codereview.webrtc.org/2969623003
Cr-Commit-Position: refs/heads/master@{#18870}
Linking external ObjC / Swift apps fails when the app code is using any
of the new frame-buffer classes RTCI420Buffer, RTCMutableI420Buffer, or
RTCCVPixelBuffer. To fix, we need to add the appropriate attribute to
the classes (e.g. using the RTC_EXPORT macro).
BUG=None
Review-Url: https://codereview.webrtc.org/2961293002
Cr-Commit-Position: refs/heads/master@{#18840}
[This CL is a rebase of an original CL by solenberg@:
https://codereview.webrtc.org/2948763002/ which in turn was a
rebase of an original CL by peah@:
https://chromium-review.googlesource.com/c/527032/]
Allow an external audio processing module to be used in WebRTC
This CL adds support for optionally using an externally created audio
processing module in a peerconnection. The ownership is shared
between the peerconnection and the external creator of the module.
As part of this the internal ownership of the audio processing module
is moved from VoiceEngine to WebRtcVoiceEngine.
BUG=webrtc:7775
Review-Url: https://codereview.webrtc.org/2961723004
Cr-Commit-Position: refs/heads/master@{#18837}
In most cases we can just return a frame referencing the buffer
returned by the decoder.
Bug: webrtc:7760
Change-Id: I0b42ab9662b39149e42a3c83adfd38a9d80e0e30
Reviewed-on: https://chromium-review.googlesource.com/544299
Commit-Queue: Sami Kalliomäki <sakal@webrtc.org>
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#18824}
Reland the base->rtc_base without adding stub headers (will be
done in follow-up CL). This preserves git blame history of all files.
BUG=webrtc:7634
NOTRY=True
TBR=kwiberg@webrtc.org
Change-Id: Iea3bb6f3f67b8374c96337b63e8f5aa3e6181012
Reviewed-on: https://chromium-review.googlesource.com/554611
Reviewed-by: Henrik Kjellander <kjellander@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#18821}
Will reland in two different commits to preserve git blame history.
BUG=webrtc:7634
NOTRY=True
TBR=kwiberg@webrtc.org
Change-Id: I550da8525aeb9c5b8f96338fcf1c9714f3dcdab1
Reviewed-on: https://chromium-review.googlesource.com/554610
Reviewed-by: Henrik Kjellander <kjellander@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#18820}
Reorganized the targets in webrtc/sdk/BUILD.gn so that the applications which use
WebRTC DataChannel only can depend on the "peerconnection_factory_no_media"
instead of "rtc_sdk_objc" to reduce the binary size.
Provided a no-media implementation of RTCPeerConnectionFactory using the macro
"HAVE_NO_MEDIA".
BUG=webrtc:7613
Review-Url: https://codereview.webrtc.org/2944643002
Cr-Commit-Position: refs/heads/master@{#18819}
This refactoring takes a careful approach to avoid rushing the change:
* stub headers are left in all the old locations of webrtc/base
* existing GN targets are kept and now just forward to the moved ones
using public_deps.
The only exception to the above is the base_java target and its .java files,
which were moved to webrtc/rtc_base right away since it's not possible
to use public_deps for android_library.
To avoid breaking builds, a temporary Dummy.java file was added to
the new intermediate target in webrtc/rtc_base:base_java as well to avoid
hitting a GN assert in the android_library template.
The above approach should make the transition smooth without breaking
downstream.
A helper script was created (https://codereview.webrtc.org/2879203002/)
and was run like this:
stub-headers.py -s webrtc/base -d webrtc/rtc_base -i 7634
stub-headers.py -s webrtc/base/numerics -d webrtc/rtc_base/numerics -i 7634
Fixed invalid header guards in the following files:
webrtc/base/base64.h
webrtc/base/cryptstring.h
webrtc/base/event.h
webrtc/base/flags.h
webrtc/base/httpbase.h
webrtc/base/httpcommon-inl.h
webrtc/base/httpcommon.h
webrtc/base/httpserver.h
webrtc/base/logsinks.h
webrtc/base/macutils.h
webrtc/base/nattypes.h
webrtc/base/openssladapter.h
webrtc/base/opensslstreamadapter.h
webrtc/base/pathutils.h
webrtc/base/physicalsocketserver.h
webrtc/base/proxyinfo.h
webrtc/base/sigslot.h
webrtc/base/sigslotrepeater.h
webrtc/base/socket.h
webrtc/base/socketaddresspair.h
webrtc/base/socketfactory.h
webrtc/base/stringutils.h
webrtc/base/testbase64.h
webrtc/base/testutils.h
webrtc/base/transformadapter.h
webrtc/base/win32filesystem.h
Added new header guards to:
sslroots.h
testbase64.h
BUG=webrtc:7634
NOTRY=True
NOPRESUBMIT=True
R=kwiberg@webrtc.org
Review-Url: https://codereview.webrtc.org/2877023002 .
Cr-Commit-Position: refs/heads/master@{#18816}
