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}
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}
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}
This makes it clearer that the C++ SurfaceTextureHelper owns its associated java object it.
In addition, arrange so that the SurfaceTextureHelper.stopListening
method (in java) can be called from any thread.
BUG=
Review-Url: https://codereview.webrtc.org/1988043002
Cr-Commit-Position: refs/heads/master@{#12941}
Splits VideoCapturer::OnFrameCaptured into helper methods,
which enables use of the VideoAdaptation logic without
using a frame factory.
Refactors AndroidVideoCapturer to make adaptation decision
earlier, so we can crop and rotate using
NV12ToI420Rotate.
BUG=webrtc:5682
Review-Url: https://codereview.webrtc.org/1973873003
Cr-Commit-Position: refs/heads/master@{#12895}
This CL makes the loop stop when all frames have been delivered and
start again when a new frame is inserted.
BUG=webrtc:5680
Review-Url: https://codereview.webrtc.org/2000103002
Cr-Commit-Position: refs/heads/master@{#12860}
Check for dropped frames by instead checking the
frame_buffer pointer directly.
Also add RTC_DCHECK to verify that a webrtc::VideoFrame never
has video_frame_buffer_ set to nullptr (except by the default
constructor).
BUG=webrtc:5682
Review-Url: https://codereview.webrtc.org/1995343002
Cr-Commit-Position: refs/heads/master@{#12859}
We're now supposed to accept incoming frames from any thread.
BUG=webrtc:5902
Review-Url: https://codereview.webrtc.org/1987663002
Cr-Commit-Position: refs/heads/master@{#12844}
if the network monitor detects it after the native code does.
Also set the network cost for ethernet, wifi, unknown, cellular network type to be 0, 10, 50, 900,
so that unknown networks will have lower precedence than known networks with low cost (like Wifi) but higher precedence than known networks with high cost.
And third, infer network type based on limited name matching in Android if there is no network monitor or network monitor did not find the type.
BUG=webrtc:5890
R=pthatcher@chromium.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1976683003 .
Cr-Commit-Position: refs/heads/master@{#12833}
GetWidth and GetHeight (renamed to width and height),
GetNativeHandle (replaced by video_frame_buffer()->native_handle).
TBR=tkchin@webrtc.org (trivial changes to objc RTCVideoFrame and VideoRendererAdapter)
BUG=webrtc:5682
Review-Url: https://codereview.webrtc.org/1990063005
Cr-Commit-Position: refs/heads/master@{#12822}
Reason for revert:
Should work after cl https://codereview.webrtc.org/1985693002/ is landed, which initializes the frames used by FakeWebRtcVideoCaptureModule. So intend to reland after that, with no changes.
Original issue's description:
> Revert of Delete webrtc::VideoFrame methods buffer and stride. (patchset #2 id:290001 of https://codereview.webrtc.org/1963413004/ )
>
> Reason for revert:
> Speculative revert to see if failures on the DrMemory bot are related to this cl. See e.g. here:
> https://build.chromium.org/p/client.webrtc/builders/Win%20DrMemory%20Full/builds/4243
>
> UNINITIALIZED READ: reading 0x04980040-0x04980060 32 byte(s) within 0x04980040-0x04980060
> # 0 CopyRow_AVX
> # 1 CopyPlane
> # 2 I420Copy
> # 3 webrtc::ExtractBuffer
> # 4 cricket::WebRtcVideoCapturer::SignalFrameCapturedOnStartThread
> # 5 cricket::WebRtcVideoCapturer::OnIncomingCapturedFrame
> # 6 FakeWebRtcVideoCaptureModule::SendFrame
> # 7 WebRtcVideoCapturerTest_TestCaptureVcm_Test::TestBody
> # 8 testing::internal::HandleSehExceptionsInMethodIfSupported<>
>
> Original issue's description:
> > Reland of Delete webrtc::VideoFrame methods buffer and stride. (patchset #1 id:1 of https://codereview.webrtc.org/1935443002/ )
> >
> > Reason for revert:
> > I plan to reland this change in a week or two, after downstream users are updated.
> >
> > Original issue's description:
> > > Revert of Delete webrtc::VideoFrame methods buffer and stride. (patchset #14 id:250001 of https://codereview.webrtc.org/1900673002/ )
> > >
> > > Reason for revert:
> > > Breaks chrome FYI bots.
> > >
> > > Original issue's description:
> > > > Delete webrtc::VideoFrame methods buffer and stride.
> > > >
> > > > To make the HasOneRef/IsMutable hack work, also had to change the
> > > > video_frame_buffer method to return a const ref to a scoped_ref_ptr,
> > > > to not imply an AddRef.
> > > >
> > > > BUG=webrtc:5682
> > >
> > > TBR=perkj@webrtc.org,magjed@webrtc.org,pbos@webrtc.org,pthatcher@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
> > >
> > > Committed: https://crrev.com/5b3c443d301f2c2f18dac5b02652c08b91ea3828
> > > Cr-Commit-Position: refs/heads/master@{#12558}
> >
> > TBR=perkj@webrtc.org,magjed@webrtc.org,pbos@webrtc.org,pthatcher@webrtc.org,stefan@webrtc.org
> > # Not skipping CQ checks because original CL landed more than 1 days ago.
> > BUG=webrtc:5682
> >
> > Committed: https://crrev.com/d0dc66e0ea30c8614001e425a4ae0aa7dd56c2a7
> > Cr-Commit-Position: refs/heads/master@{#12721}
>
> TBR=perkj@webrtc.org,magjed@webrtc.org,pbos@webrtc.org,pthatcher@webrtc.org,stefan@webrtc.org,nisse@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:5682
>
> Committed: https://crrev.com/d49c30cd2fe442f2b5b4ecec8d5cbaa430464725
> Cr-Commit-Position: refs/heads/master@{#12745}
TBR=perkj@webrtc.org,magjed@webrtc.org,pbos@webrtc.org,pthatcher@webrtc.org,stefan@webrtc.org,tommi@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:5682
Review-Url: https://codereview.webrtc.org/1979193003
Cr-Commit-Position: refs/heads/master@{#12773}
This is similar to how a "receive" method is used to apply
RtpParameters to an RtpReceiver in ORTC. Currently, SetParameters
doesn't allow changing the parameters, so the main use of the API is
to retrieve the set of configured codecs. But other uses will likely
be made possible in the future.
R=glaznev@webrtc.org, pthatcher@webrtc.org, tkchin@webrtc.org
Review URL: https://codereview.webrtc.org/1917193008 .
Cr-Commit-Position: refs/heads/master@{#12761}
Reason for revert:
Speculative revert to see if failures on the DrMemory bot are related to this cl. See e.g. here:
https://build.chromium.org/p/client.webrtc/builders/Win%20DrMemory%20Full/builds/4243
UNINITIALIZED READ: reading 0x04980040-0x04980060 32 byte(s) within 0x04980040-0x04980060
# 0 CopyRow_AVX
# 1 CopyPlane
# 2 I420Copy
# 3 webrtc::ExtractBuffer
# 4 cricket::WebRtcVideoCapturer::SignalFrameCapturedOnStartThread
# 5 cricket::WebRtcVideoCapturer::OnIncomingCapturedFrame
# 6 FakeWebRtcVideoCaptureModule::SendFrame
# 7 WebRtcVideoCapturerTest_TestCaptureVcm_Test::TestBody
# 8 testing::internal::HandleSehExceptionsInMethodIfSupported<>
Original issue's description:
> Reland of Delete webrtc::VideoFrame methods buffer and stride. (patchset #1 id:1 of https://codereview.webrtc.org/1935443002/ )
>
> Reason for revert:
> I plan to reland this change in a week or two, after downstream users are updated.
>
> Original issue's description:
> > Revert of Delete webrtc::VideoFrame methods buffer and stride. (patchset #14 id:250001 of https://codereview.webrtc.org/1900673002/ )
> >
> > Reason for revert:
> > Breaks chrome FYI bots.
> >
> > Original issue's description:
> > > Delete webrtc::VideoFrame methods buffer and stride.
> > >
> > > To make the HasOneRef/IsMutable hack work, also had to change the
> > > video_frame_buffer method to return a const ref to a scoped_ref_ptr,
> > > to not imply an AddRef.
> > >
> > > BUG=webrtc:5682
> >
> > TBR=perkj@webrtc.org,magjed@webrtc.org,pbos@webrtc.org,pthatcher@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
> >
> > Committed: https://crrev.com/5b3c443d301f2c2f18dac5b02652c08b91ea3828
> > Cr-Commit-Position: refs/heads/master@{#12558}
>
> TBR=perkj@webrtc.org,magjed@webrtc.org,pbos@webrtc.org,pthatcher@webrtc.org,stefan@webrtc.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=webrtc:5682
>
> Committed: https://crrev.com/d0dc66e0ea30c8614001e425a4ae0aa7dd56c2a7
> Cr-Commit-Position: refs/heads/master@{#12721}
TBR=perkj@webrtc.org,magjed@webrtc.org,pbos@webrtc.org,pthatcher@webrtc.org,stefan@webrtc.org,nisse@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/1983583002
Cr-Commit-Position: refs/heads/master@{#12745}
The caller can set a negative or zero file size to avoid using a limit.
BUG=
Review-Url: https://codereview.webrtc.org/1974453002
Cr-Commit-Position: refs/heads/master@{#12730}
Reason for revert:
I plan to reland this change in a week or two, after downstream users are updated.
Original issue's description:
> Revert of Delete webrtc::VideoFrame methods buffer and stride. (patchset #14 id:250001 of https://codereview.webrtc.org/1900673002/ )
>
> Reason for revert:
> Breaks chrome FYI bots.
>
> Original issue's description:
> > Delete webrtc::VideoFrame methods buffer and stride.
> >
> > To make the HasOneRef/IsMutable hack work, also had to change the
> > video_frame_buffer method to return a const ref to a scoped_ref_ptr,
> > to not imply an AddRef.
> >
> > BUG=webrtc:5682
>
> TBR=perkj@webrtc.org,magjed@webrtc.org,pbos@webrtc.org,pthatcher@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
>
> Committed: https://crrev.com/5b3c443d301f2c2f18dac5b02652c08b91ea3828
> Cr-Commit-Position: refs/heads/master@{#12558}
TBR=perkj@webrtc.org,magjed@webrtc.org,pbos@webrtc.org,pthatcher@webrtc.org,stefan@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:5682
Review-Url: https://codereview.webrtc.org/1963413004
Cr-Commit-Position: refs/heads/master@{#12721}
BUG=webrtc:5874
TEST=Manually throw an exception inside the SurfaceTextureHelper ctor and run AppRTCDemo.
Review-Url: https://codereview.webrtc.org/1840193007
Cr-Commit-Position: refs/heads/master@{#12665}
The problem with gmock is worked around by commenting out any other override declarations in classes using gmock.
NOPRESUBMIT=True
BUG=webrtc:3970
Review-Url: https://codereview.webrtc.org/1921653002
Cr-Commit-Position: refs/heads/master@{#12563}
Reason for revert:
Chrome has been updated, cl https://codereview.chromium.org/1919283005/
Original issue's description:
> Revert of Delete cricket::VideoFrame methods GetYPlane and GetYPitch. (patchset #5 id:80001 of https://codereview.webrtc.org/1901973002/ )
>
> Reason for revert:
> GetYPlane, GetYPitch etc is used by Chromium.
>
> Original issue's description:
> > Delete cricket::VideoFrame methods GetYPlane and GetYPitch.
> >
> > (And similarly for U and V). Also change video_frame_buffer method to
> > return a const ref to a scoped_ref_ptr.
> >
> > This cl is analogous to https://codereview.webrtc.org/1900673002/,
> > which delete corresponding methods in webrtc::VideoFrame.
> >
> > BUG=webrtc:5682
> >
> > Committed: https://crrev.com/1c27c6bf4cf0476dd2f09425509afaae4cdfe599
> > Cr-Commit-Position: refs/heads/master@{#12492}
>
> TBR=magjed@webrtc.org,perkj@webrtc.org,pbos@webrtc.org,pthatcher@webrtc.org,nisse@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:5682
>
> Committed: https://crrev.com/b05f994bb6f3055c852891c8acb531aee916a668
> Cr-Commit-Position: refs/heads/master@{#12494}
TBR=magjed@webrtc.org,perkj@webrtc.org,pbos@webrtc.org,pthatcher@webrtc.org,terelius@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:5682
Review-Url: https://codereview.webrtc.org/1923903002
Cr-Commit-Position: refs/heads/master@{#12559}
Reason for revert:
Breaks chrome FYI bots.
Original issue's description:
> Delete webrtc::VideoFrame methods buffer and stride.
>
> To make the HasOneRef/IsMutable hack work, also had to change the
> video_frame_buffer method to return a const ref to a scoped_ref_ptr,
> to not imply an AddRef.
>
> BUG=webrtc:5682
TBR=perkj@webrtc.org,magjed@webrtc.org,pbos@webrtc.org,pthatcher@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/1935443002
Cr-Commit-Position: refs/heads/master@{#12558}
To make the HasOneRef/IsMutable hack work, also had to change the
video_frame_buffer method to return a const ref to a scoped_ref_ptr,
to not imply an AddRef.
BUG=webrtc:5682
Review-Url: https://codereview.webrtc.org/1900673002
Cr-Commit-Position: refs/heads/master@{#12557}
But keep #including scoped_ptr.h in .h files, so as not to break
WebRTC users who expect those .h files to give them rtc::scoped_ptr.
BUG=webrtc:5520
Review URL: https://codereview.webrtc.org/1930463002
Cr-Commit-Position: refs/heads/master@{#12530}
Removes data race inside QualityScaler which were called both from the
codec thread and the invoking thread at the same time.
BUG=webrtc:5678
R=glaznev@webrtc.org
Review URL: https://codereview.webrtc.org/1919883002 .
Cr-Commit-Position: refs/heads/master@{#12517}
Any file that uses the RTC_DISALLOW_* macros should #include
"webrtc/base/constructormagic.h", but a shocking number of them don't.
This causes trouble when we try to wean files off of #including
scoped_ptr.h, since a bunch of files get their constructormagic macros
only from there.
Rather than fixing these errors one by one as they turn up, this CL
simply ensures that every file in the WebRTC tree that uses the
RTC_DISALLOW_* macros #includes "webrtc/base/constructormagic.h".
BUG=webrtc:5520
Review URL: https://codereview.webrtc.org/1917043005
Cr-Commit-Position: refs/heads/master@{#12509}
Framerate-reduction code is disabled on all platforms, and this code
adds complexity. It's necessary to react fast, especially on mobile
platforms or other bad network conditions and framerate reduction adds
another step between HD and QVGA.
BUG=webrtc:5678, webrtc:5830
R=jackychen@webrtc.org, mflodman@webrtc.org
Review URL: https://codereview.webrtc.org/1885893002 .
Cr-Commit-Position: refs/heads/master@{#12503}
This propagated into various other places. Also had to #include headers that
were implicitly pulled by "scoped_ptr.h".
BUG=webrtc:5520
Review URL: https://codereview.webrtc.org/1920043002
Cr-Commit-Position: refs/heads/master@{#12501}
Reason for revert:
GetYPlane, GetYPitch etc is used by Chromium.
Original issue's description:
> Delete cricket::VideoFrame methods GetYPlane and GetYPitch.
>
> (And similarly for U and V). Also change video_frame_buffer method to
> return a const ref to a scoped_ref_ptr.
>
> This cl is analogous to https://codereview.webrtc.org/1900673002/,
> which delete corresponding methods in webrtc::VideoFrame.
>
> BUG=webrtc:5682
>
> Committed: https://crrev.com/1c27c6bf4cf0476dd2f09425509afaae4cdfe599
> Cr-Commit-Position: refs/heads/master@{#12492}
TBR=magjed@webrtc.org,perkj@webrtc.org,pbos@webrtc.org,pthatcher@webrtc.org,nisse@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/1921493004
Cr-Commit-Position: refs/heads/master@{#12494}
(And similarly for U and V). Also change video_frame_buffer method to
return a const ref to a scoped_ref_ptr.
This cl is analogous to https://codereview.webrtc.org/1900673002/,
which delete corresponding methods in webrtc::VideoFrame.
BUG=webrtc:5682
Review URL: https://codereview.webrtc.org/1901973002
Cr-Commit-Position: refs/heads/master@{#12492}
This fix a potential race where the rotation information of a sent frame does not match the encoded frame.
BUG=webrtc:5783
TEST= Run ApprtcDemo on IOs and Android with and without capture to texture and both VP8 and H264.
R=magjed@webrtc.org, pbos@webrtc.org, tkchin@webrtc.org
TBR=tkchin_webrtc // For IOS changes.
Review URL: https://codereview.webrtc.org/1886113003 .
Cr-Commit-Position: refs/heads/master@{#12426}
Increases measure time for downscale back to 5 seconds, this is required
to not over-react on hand-waving or quick device rotations.
Also increase max thresholds for QP a bit to not overreact when quality
still looks somewhat OK. Min thresholds for H264 seemed very low and are
increased to be sure that we can go back up again. The window is still
quite big with the increased max QP.
Also changes libvpx thresholds to use the same thresholds as the
encoder, they were excessively low before and wouldn't adapt on bad QPs
at all before (but rely on >60% framedropping based on bitrates to go
down).
BUG=webrtc:5678
R=stefan@webrtc.orgTBR=glaznev@webrtc.org
Review URL: https://codereview.webrtc.org/1894083002 .
Cr-Commit-Position: refs/heads/master@{#12403}
Instead, use the corresponding method on VideoFrameBuffer. In the process,
reduce code duplication in frame comparison functions used in
the test code.
Make FramesEqual use FrameBufsEqual. Make the latter support texture frames.
The cl also refactors VideoFrame::CopyFrame to use I420Buffer::Copy. This
has possibly undesired side effects of never reusing the frame buffer of
the destination frame, and producing a frame buffer which may use different
stride than the source frame.
BUG=webrtc:5682
Review URL: https://codereview.webrtc.org/1881953002
Cr-Commit-Position: refs/heads/master@{#12373}
