Reason for revert:
Relanding after known downstream breakages have been fixed.
Original issue's description:
> Revert of Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. (patchset #7 id:120001 of https://codereview.webrtc.org/2383093002/ )
>
> 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
>
> Committed: https://crrev.com/7341ab8e2505c9763d208e069bda269018357e7d
> Cr-Commit-Position: refs/heads/master@{#14886}
TBR=perkj@webrtc.org,pthatcher@webrtc.org,tkchin@webrtc.org,mflodman@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/2487633002
Cr-Commit-Position: refs/heads/master@{#15039}
Chrome coding standard now discourages use of references to smart
pointers. This cl updates some recent methods to the new conventions.
BUG=webrtc:6672
Review-Url: https://codereview.webrtc.org/2477233004
Cr-Commit-Position: refs/heads/master@{#15028}
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 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 original landed cl is in patchset 1.
The following patchset fix VideoQualityTest as well as fix the case where max_bitrate is set in the SendParams. A unit test is added for that as well.
Original cl description:
Let ViEEncoder handle resolution changes.
This cl move codec reconfiguration due to video frame size changes from WebRtcVideoSendStream to ViEEncoder.
With this change, many variables in WebRtcVideoSendStream no longer need to be locked.
BUG=webrtc:5687, webrtc:6371, webrtc:5332
Review-Url: https://codereview.webrtc.org/2386573002
Cr-Commit-Position: refs/heads/master@{#14467}
This cl move codec reconfiguration due to video frame size changes from WebRtcVideoSendStream to ViEEncoder.
With this change, many variables in WebRtcVideoSendStream no longer need to be locked.
BUG=webrtc:5687, webrtc:6371, webrtc:5332
Review-Url: https://codereview.webrtc.org/2351633002
Cr-Commit-Position: refs/heads/master@{#14445}
Replaces render_time_ms_, but old accessors are kept for
compatibility.
Also short-circuit timestamp translation in
WebRtcVideoChannel2::WebRtcVideoSendStream::OnFrame.
BUG=webrtc:5682, webrtc:5740
Review-Url: https://codereview.webrtc.org/2282713002
Cr-Commit-Position: refs/heads/master@{#14062}
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}
This CL adds support for an extension on RTP frames to allow the sender
to specify the minimum and maximum playout delay limits.
The receiver makes a best-effort attempt to keep the capture-to-render delay
within this range. This allows different types of application to specify
different end-to-end delay goals. For example gaming can support rendering
of frames as soon as received on receiver to minimize delay. A movie playback
application can specify a minimum playout delay to allow fixed buffering
in presence of network jitter.
There are no tests at this time and most of testing is done with chromium
webrtc prototype.
On chromoting performance tests, this extension helps bring down end-to-end
delay by about 150 ms on small frames.
BUG=webrtc:5895
Review-Url: https://codereview.webrtc.org/2007743003
Cr-Commit-Position: refs/heads/master@{#13059}
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}
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}
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}
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}
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}
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}
Reason for revert:
Breaks downstream compilation. Please make non-breaking API changes for the reland or coordinate fixing downstream code quickly with the sheriff.
Original issue's description:
> Cleanup of webrtc::VideoFrame.
>
> Delete EqualsFrame method, used only by tests. Delete one of the
> CreateFrame methods. Drop return value for CreateEmptyFrame, CreateFrame
> and CopyFrame.
>
> BUG=webrtc:5426
>
> Committed: https://crrev.com/208019637bfed975f8f13b16d40b90e200763cd6
> Cr-Commit-Position: refs/heads/master@{#11783}
TBR=pbos@webrtc.org,perkj@webrtc.org,pthatcher@webrtc.org,mflodman@webrtc.org,marpan@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:5426
Review URL: https://codereview.webrtc.org/1743613002
Cr-Commit-Position: refs/heads/master@{#11789}
Delete EqualsFrame method, used only by tests. Delete one of the
CreateFrame methods. Drop return value for CreateEmptyFrame, CreateFrame
and CopyFrame.
BUG=webrtc:5426
Review URL: https://codereview.webrtc.org/1679323002
Cr-Commit-Position: refs/heads/master@{#11783}
The FFmpeg video decoder requires up to 8 additional bytes to be allocated for its encoded image buffer input, due to optimized byte readers over-reading on some platforms.
We plan to use FFmpeg for a soon-to-land H.264 enc/dec.
This CL adds support for padding encoded image buffers based on codec type, and makes sure calls to VCMEncodedFrame::VerifyAndAllocate use the padding.
All padding constants are 0 but making H.264 pad with 8 bytes will be a one-line change.
Also, added -framework CoreFoundation to webrtc_h264_video_toolbox which was missing.
BUG=chromium:468365
BUG=https://bugs.chromium.org/p/webrtc/issues/detail?id=5424
NOTRY=True
Review URL: https://codereview.webrtc.org/1602523004
Cr-Commit-Position: refs/heads/master@{#11337}
The unit test will run the pure C denoiser and SSE2/NEON denoiser (based
on the CPU detection) and compare the denoised frames to ensure the bit
exact.
TBR=tommi@webrtc.org
BUG=webrtc:5255
Review URL: https://codereview.webrtc.org/1492053003
Cr-Commit-Position: refs/heads/master@{#11216}
To avoid breaking downstream, the "interface" directories were copied
into a new "common_video/include" dir. The old headers got pragma
warnings added about deprecation (a very short deprecation since I plan
to remove them as soon downstream is updated).
The header guards are also identical to avoid mixing them up in the transition.
BUG=webrtc:5095
TESTED=Passing compile-trybots with --clobber flag:
git cl try --clobber --bot=win_compile_rel --bot=linux_compile_rel --bot=android_compile_rel --bot=mac_compile_rel --bot=ios_rel --bot=linux_gn_rel --bot=win_x64_gn_rel --bot=mac_x64_gn_rel --bot=android_gn_rel -m tryserver.webrtc
Review URL: https://codereview.webrtc.org/1418913006
Cr-Commit-Position: refs/heads/master@{#10659}
- "WebRTC.Video.BandwidthLimitedResolutionInPercent"
If the frame is bandwidth limited, the average number of disabled resolutions is logged:
- "WebRTC.Video.BandwidthLimitedResolutionsDisabled"
BUG=
Review URL: https://codereview.webrtc.org/1311533012
Cr-Commit-Position: refs/heads/master@{#10333}
- "WebRTC.Video.QualityLimitedResolutionInPercent"
and if a frame is downscaled, the average number of times the frame is downscaled:
- "WebRTC.Video.QualityLimitedResolutionDownscales"
BUG=
Review URL: https://codereview.webrtc.org/1325153009
Cr-Commit-Position: refs/heads/master@{#10319}
Since padding is no longer sent on Encoded() callbacks, dummy callbacks
aren't required to generate padding. This skip-frame behavior can then
be removed to get rid of dummy callbacks though nothing was encoded. As
frames don't have to be generated for frames that don't have to be sent
we skip encoding frames that aren't intended to be sent either, reducing
CPU load.
BUG=
R=mflodman@webrtc.org, stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1369923005 .
Cr-Commit-Position: refs/heads/master@{#10181}
We must remove dependency on Chromium, i.e. we can't use Chromium's base/logging.h. That means we need to define these macros in WebRTC also when doing Chromium builds. And this causes redefinition.
Alternative solutions:
* Check if we already have defined e.g. CHECK, and don't define them in that case. This makes us depend on include order in Chromium, which is not acceptable.
* Don't allow using the macros in WebRTC headers. Error prone since if someone adds it there by mistake it may compile fine, but later break if a header in added or order is changed in Chromium. That will be confusing and hard to enforce.
* Ensure that headers that are included by an embedder don't include our macros. This would require some heavy refactoring to be maintainable and enforcable.
* Changes in Chromium for this is obviously not an option.
BUG=chromium:468375
NOTRY=true
Review URL: https://codereview.webrtc.org/1335923002
Cr-Commit-Position: refs/heads/master@{#9964}
