Reason for revert:
Fix gyp build
Original issue's description:
> Revert of Add a webrtc{en,de}coderfactory implementation for VideoToolbox (patchset #2 id:20001 of https://codereview.webrtc.org/2463313002/ )
>
> Reason for revert:
> Broke dependent project because the .gn changes weren't accompanied by corresponding .gyp changes.
>
> Original issue's description:
> > Add a webrtc{en,de}coderfactory implementation for VideoToolbox
> >
> > This CL removes the coupling of the VideoToolbox h264 implementation
> > to the generic h264 code. The files have been moved into sdb/obj/Framework
> > and all dependency on them has been removed from the rest of WebRTC.
> > We now add it as an external encoder via a factory supplied to the
> > CreatePeerConnectionFactory call. This also brings the iOS implementation
> > closer to what we do on Android for MediaCodec.
> >
> > BUG=webrtc:6619
> >
> > Committed: https://crrev.com/6a5047dad31f14f53dd9f8bc1ecde19e1dede2e4
> > Cr-Commit-Position: refs/heads/master@{#14953}
>
> TBR=magjed@webrtc.org,stefan@webrtc.org,kthelgason@webrtc.org
> BUG=webrtc:6619
>
> Committed: https://crrev.com/d69ad84420d9c0e1c11450c352f6c92e7c9583f1
> Cr-Commit-Position: refs/heads/master@{#14985}
R=magjed@webrtc.orgTBR=kwiberg@webrtc.org, magjed@webrtc.org, stefan@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6619
Review URL: https://codereview.webrtc.org/2487723004 .
Cr-Commit-Position: refs/heads/master@{#14992}
Reason for revert:
Broke dependent project because the .gn changes weren't accompanied by corresponding .gyp changes.
Original issue's description:
> Add a webrtc{en,de}coderfactory implementation for VideoToolbox
>
> This CL removes the coupling of the VideoToolbox h264 implementation
> to the generic h264 code. The files have been moved into sdb/obj/Framework
> and all dependency on them has been removed from the rest of WebRTC.
> We now add it as an external encoder via a factory supplied to the
> CreatePeerConnectionFactory call. This also brings the iOS implementation
> closer to what we do on Android for MediaCodec.
>
> BUG=webrtc:6619
>
> Committed: https://crrev.com/6a5047dad31f14f53dd9f8bc1ecde19e1dede2e4
> Cr-Commit-Position: refs/heads/master@{#14953}
TBR=magjed@webrtc.org,stefan@webrtc.org,kthelgason@webrtc.org
BUG=webrtc:6619
Review-Url: https://codereview.webrtc.org/2483273002
Cr-Commit-Position: refs/heads/master@{#14985}
This CL removes the coupling of the VideoToolbox h264 implementation
to the generic h264 code. The files have been moved into sdb/obj/Framework
and all dependency on them has been removed from the rest of WebRTC.
We now add it as an external encoder via a factory supplied to the
CreatePeerConnectionFactory call. This also brings the iOS implementation
closer to what we do on Android for MediaCodec.
BUG=webrtc:6619
Review-Url: https://codereview.webrtc.org/2463313002
Cr-Commit-Position: refs/heads/master@{#14953}
Reason for revert:
Breaks chrome, see https://build.chromium.org/p/chromium.webrtc.fyi/builders/Mac%20Builder/builds/19019/steps/compile/logs/stdio
Analysis: Chrome uses cricket::VideoFrame, without explicitly including webrtc/media/base/videoframe.h, and breaks when that file is no longer included by any other webrtc headers. Will reland after updating Chrome.
Original issue's description:
> Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame.
>
> Replaced with webrtc::VideoFrame.
>
> TBR=mflodman@webrtc.org
> BUG=webrtc:5682
>
> Committed: https://crrev.com/45c8b8940042bd2574c39920804ade8343cefdba
> Cr-Commit-Position: refs/heads/master@{#14885}
TBR=perkj@webrtc.org,pthatcher@webrtc.org,tkchin@webrtc.org,mflodman@webrtc.org,stefan@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5682
Review-Url: https://codereview.webrtc.org/2471783002
Cr-Commit-Position: refs/heads/master@{#14886}
This CL makes scaling and cropping lazy in AVFoundationVideoCapturer and
provides optimized paths for SW and HW encoding. For SW encoding, an
efficient NV12 -> I420 cropping and scaling is implemented in
CoreVideoFrameBuffer::NativeToI420. For HW encoding, an efficient NV12 ->
NV12 cropping and scaling is implemented in
CoreVideoFrameBuffer::CropAndScaleTo. The performance improvement over
the existing cropping and scaling is that it is now done in one step
instead of making an intermediary copy of the Y plane.
There might still be room for improvement in the HW path using some HW
support. That will be explored in a future CL.
BUG=b/30939444
Review-Url: https://codereview.webrtc.org/2394483005
Cr-Commit-Position: refs/heads/master@{#14701}
This cl now makes cricket::VideoFrame and cricket::WebRtcVideoFrame aliases for webrtc::VideoFrame.
Reason for revert:
Fixing backwards compatibility issues.
Original issue's description:
> Revert of Make cricket::VideoFrame inherit webrtc::VideoFrame. (patchset #9 id:160001 of https://codereview.webrtc.org/2315663002/ )
>
> Reason for revert:
> Breaks compile for Chromium builds:
> https://build.chromium.org/p/chromium.webrtc.fyi/builders/Linux%20Builder/builds/10761
> https://build.chromium.org/p/chromium.webrtc.fyi/builders/Mac%20Builder/builds/18142
>
> FAILED: obj/remoting/protocol/protocol/webrtc_video_renderer_adapter.o
> ../../remoting/protocol/webrtc_video_renderer_adapter.cc:110:52: error: no member named 'transport_frame_id' in 'cricket::VideoFrame'
> weak_factory_.GetWeakPtr(), frame.transport_frame_id(),
> ~~~~~ ^
> 1 error generated.
>
> Please run chromium trybots as described at https://webrtc.org/contributing/#tryjobs-on-chromium-trybots before relanding.
>
> Original issue's description:
> > Make cricket::VideoFrame inherit webrtc::VideoFrame. Delete
> > all methods but a few constructors. And similarly for the
> > subclass cricket::WebRtcVideoFrame.
> >
> > TBR=tkchin@webrtc.org # Added an include line
> > BUG=webrtc:5682
> >
> > Committed: https://crrev.com/dda6ec008a0fc8d52e118814fb779032e8931968
> > Cr-Commit-Position: refs/heads/master@{#14576}
>
> TBR=perkj@webrtc.org,pthatcher@webrtc.org,pthatcher@chromium.org,tkchin@webrtc.org,nisse@webrtc.org
> NOTRY=True
> NOPRESUBMIT=True
> BUG=webrtc:5682
>
> Committed: https://crrev.com/d36dd499c8f253cbcf37364c2a070c2e8c7100e9
> Cr-Commit-Position: refs/heads/master@{#14583}
TBR=perkj@webrtc.org,pthatcher@webrtc.org,pthatcher@chromium.org,tkchin@webrtc.org,kjellander@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:5682
Review-Url: https://codereview.webrtc.org/2411953002
Cr-Commit-Position: refs/heads/master@{#14678}
The rotation is currently incorrect for the back camera in landscape
mode. The reason is that device rotation needs to be reversed for the
back camera compared to the front camera. The camera sensor can also be
mounted with a specific orientation. So when front camera rotation goes
through: 0->90->180->270, back camera rotation goes in reverse:
180->90->0->270.
BUG=b/31984246,b/30651939
Review-Url: https://codereview.webrtc.org/2401033002
Cr-Commit-Position: refs/heads/master@{#14580}
all methods but a few constructors. And similarly for the
subclass cricket::WebRtcVideoFrame.
TBR=tkchin@webrtc.org # Added an include line
BUG=webrtc:5682
Review-Url: https://codereview.webrtc.org/2315663002
Cr-Commit-Position: refs/heads/master@{#14576}
It eliminates the need for hardcoded enumerations of the supported presets.
Hopefully it enables us to support slightly bigger set of resolutions and make the code slightly cleaner.
BUG=webrtc:6355
Review-Url: https://codereview.webrtc.org/2349223002
Cr-Commit-Position: refs/heads/master@{#14547}
The clang static analyzer seems unable to resolve cpp locks in ObjC code.
As of current time, the clang analyzer has known limitations documented
http://clang.llvm.org/docs/ThreadSafetyAnalysis.html#known-limitations.
From the documentation: "The analysis currently does not do any checking
inside constructors or destructors.
In other words, every constructor and destructor is treated
as if it was annotated with NO_THREAD_SAFETY_ANALYSIS."
This is 'probably' why the analyzer is unable to resolve the lock when
used in ObjC land (the cpp works fine).
The lock can be removed by using atomic property instead.
It's not on performance critical path and we expect updates on just one queue and reads from others. That's why the thread assurance atomic properties bring is enough.
The CL removes rtc_sdk_peerconnection_objc_warnings_config as well as it's no longer needed.
BUG=webrtc:6308
Review-Url: https://codereview.webrtc.org/2372513004
Cr-Commit-Position: refs/heads/master@{#14450}
This is to avoid a naming conflict with webrtc::RTCStatsReport that is
surfaced if you try to include it in peerconnectioninterface.h.
Background: The current stats is very much non-spec-compliant. A new
stats collection API is underway that is meant to be spec-compliant.
Some classes in Chromium and webrtc/sdk/objc have spec-compliant names
but non-spec-compliant behavior. These are being renamed to "Legacy" so
that new spec-compliant classes can be added with the correct names.
BUG=chromium:627816
TBR=tkchin@webrtc.org
NOTRY=True
Review-Url: https://codereview.webrtc.org/2313943002
Cr-Commit-Position: refs/heads/master@{#14150}
WebRTC no longer has any restriction on what thread frames should be
delivered on. One possible problem with this CL is that NV21->I420
conversion and scaling is done on the thread that delivers frames, which
might cause fps regressions.
R=nisse@webrtc.org, perkj@webrtc.org, tkchin@webrtc.org
Review URL: https://codereview.webrtc.org/2137503003 .
Cr-Commit-Position: refs/heads/master@{#14021}
The rotation is currently always applied by AVFoundation by
reconfiguring the capture connection video orientation. This CL sets the
rotation field in the frame instead. This avoids the current flash in
the video when the device is rotated, and also avoids reconfiguring the
local encoder and remote decoder when the device is rotated.
BUG=b/30651939
Review-Url: https://codereview.webrtc.org/2271583003
Cr-Commit-Position: refs/heads/master@{#13916}
We've seen some cases of nonrecoverable runtime error when entering the foreground. This is a theoretical fix to see if we can restart after willEnterForeground in didBecomeActive instead.
NOTRY=True
BUG=
Review-Url: https://codereview.webrtc.org/2258583004
Cr-Commit-Position: refs/heads/master@{#13903}
Theoretical fix to address some EAGLContext issues from other UIImageViews that could be active.
NOTRY=True
BUG=
Review-Url: https://codereview.webrtc.org/2259513002
Cr-Commit-Position: refs/heads/master@{#13806}
RTCPeerConnectionFactory.createPeerConnection did not check the return
value of the native createPeerConnection() - so when the native PC
fails to be created, it could end up attempting to use a null pointer.
The change makes it return nil when the creation fails. The application
can then detect and respond to the failure.
Review-Url: https://codereview.webrtc.org/2240633004
Cr-Commit-Position: refs/heads/master@{#13732}
This CL handles frame rotation by updating the OpenGL vertex data in
RTCOpenGLVideoRenderer, instead of calling the expensive
libyuv::I420Rotate that will rotate the actual memory. Also, we can
handle rotated native frames instead of falling back to
NativeToI420Buffer.
Review-Url: https://codereview.webrtc.org/2176623002
Cr-Commit-Position: refs/heads/master@{#13715}
This CL adds support in RTCEAGLVideoView for rendering CVPixelBuffers as
OpenGL ES textures directly, compared to the current code that first
converts the CVPixelBuffers to I420, and then reuploads them as
textures. This is only supported on iOS with the use of a
CVOpenGLESTextureCache.
The I420 rendering and native rendering are separated in two different
implementations of a simple shader interface:
@protocol Shader
- (BOOL)drawFrame:(RTCVideoFrame*)frame;
@end
GL resources are allocated when the shader is instantiated and released
when the shader is destroyed. RTCEAGLVideoView will lazily instantiate
the necessary shader when it receives the first frame of that kind. This
is primarily done to avoid allocating GL resources for both I420 and
native rendering.
Some other changes are:
- Print GL shader compilation errors.
- Remove updateTextureSizesForFrame() function. The textures will
resize automatically anyway when the texture data is uploaded with
glTexImage2D().
patch from issue 2154243002 at patchset 140001 (http://crrev.com/2154243002#ps140001)
Continuing magjed@'s work since he is OOO this week.
BUG=
Review-Url: https://codereview.webrtc.org/2202823004
Cr-Commit-Position: refs/heads/master@{#13668}
Scaling causes us to work the CPU too much, which very quickly degrades quality. This causes us to at least behave better on good networks.
NOTRY=True
BUG=
Review-Url: https://codereview.webrtc.org/2205763002
Cr-Commit-Position: refs/heads/master@{#13630}
Passing transport_frame_id() to VideoSink will allow to identify incoming video
frames, which will make it possible to correlate video frames on the
sender and on the receiver.
BUG=chromium:621691
R=mflodman@webrtc.org, stefan@webrtc.org
Review URL: https://codereview.webrtc.org/2088953002 .
Cr-Commit-Position: refs/heads/master@{#13596}
