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 fixes a problem where "b=AS" and "x-google-start-bitrate" can't
be used together. It also starts taking the minimum of "b=AS" and
"x-google-max-bitrate", instead of just letting "b=AS" win.
BUG=webrtc:5811
R=pbos@webrtc.org
Review URL: https://codereview.webrtc.org/1904063003 .
Cr-Commit-Position: refs/heads/master@{#12519}
Whether two streams get 300k or 150k as initial bitrate is flaky, since
InitEncode may happen asynchronously either before or after two streams
have shared the 300k, meaning that the first sender either thinks it
should start at 300k or at 150k.
This should ideally be fixed by reconfiguring encoders to use QVGA if a
lower estimate arrives before the first frame is encoded, but right now
that would require reconfigure logic in all VideoEncoder wrappers, which
is also less than ideal. It would be good to revisit this once
QualityScaler moves outside the VideoEncoder implementations (into
GenericEncoder).
BUG=webrtc:5678
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1902413002 .
Cr-Commit-Position: refs/heads/master@{#12448}
Reason for revert:
RTCVideoEncoder has been updated to not make assumptions on calling threads/post back to a worker thread. This should now be landable again.
Original issue's description:
> Revert of Initialize/configure video encoders asychronously. (patchset #4 id:60001 of https://codereview.webrtc.org/1757313002/ )
>
> Reason for revert:
> Breaks RTCVideoEncoder which has incorrect assumptions on where InitEncode etc. is called from. Temporarily reverting until RTCVideoEncoder has been updated.
>
> Original issue's description:
> > Initialize/configure video encoders asychronously.
> >
> > Greatly speeds up setRemoteDescription() by moving encoder initialization
> > off the main worker thread, which is free to move onto gathering ICE
> > candidates and other tasks while InitEncode() is performed. It also
> > un-blocks PeerConnection GetStats() which is no longer blocked on
> > encoder initialization.
> >
> > BUG=webrtc:5410
> > R=stefan@webrtc.org
> >
> > Committed: fb647a67be
>
> R=stefan@webrtc.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=chromium:595274, chromium:595308, webrtc:5410
>
> Committed: https://crrev.com/81cbd924447d507559dbd6e6d1f9fe439fcf2716
> Cr-Commit-Position: refs/heads/master@{#12086}
TBR=stefan@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:595274, chromium:595308, webrtc:5410
Review URL: https://codereview.webrtc.org/1896413002
Cr-Commit-Position: refs/heads/master@{#12446}
This field only existed as an implementation detail for getting the
codecs sorted, so it doesn't need to be in the public interface.
It cluttered the code and undesirably affected codec comparisons,
causing the video encoder to be reconfigured if a codec's preference
changed but nothing else did.
BUG=webrtc:5690
Review URL: https://codereview.webrtc.org/1845673002
Cr-Commit-Position: refs/heads/master@{#12349}
Unit tests are updated to test that screen share is not adapted but it does not change the VideoSinkWants in WebRtcVideoEngine2::SendStream due to a switch to screen share. The reason is that it works anyway and sprang is looking into how to do adaptation based on frame rate as well and use the adapter for screen share as well.
BUG=webrtc:5688, webrtc:5426
R=nisse@webrtc.org, pbos@webrtc.org, sprang@google.com
Review URL: https://codereview.webrtc.org/1836043004 .
Cr-Commit-Position: refs/heads/master@{#12240}
- Remove WVoE::SetAudioDeviceModule() - the ADM is now supplied in ctor.
- Remove WVoE::Init() and WVoE::Terminate().
- Remove MediaEngineInterface::Terminate().
BUG=webrtc:4690
Review URL: https://codereview.webrtc.org/1830213002
Cr-Commit-Position: refs/heads/master@{#12173}
This will allow a sender to stop/start sending media on the
application's demand.
Among other things, this can allow an application to set a track on a
sender while the encoding(s) are inactive, allowing the encoder to be
initialized for that track, then later set the encodings to "active"
to instantly start sending the track.
Review URL: https://codereview.webrtc.org/1822923002
Cr-Commit-Position: refs/heads/master@{#12094}
This change enables voice-only calls to keep track of the network state.
This is only a partial fix - the last modality to change state controls
the state for the entire call, so a call with a failed video transport
will also stop sending audio packets. Handling this condition correctly
would require the call to keep track of network state for each media
type separately, and take care of conditions such as a failed video
channel getting removed, while a functioning audio channel remains.
BUG=webrtc:5307
Review URL: https://codereview.webrtc.org/1757683002
Cr-Commit-Position: refs/heads/master@{#12093}
Reason for revert:
Breaks RTCVideoEncoder which has incorrect assumptions on where InitEncode etc. is called from. Temporarily reverting until RTCVideoEncoder has been updated.
Original issue's description:
> Initialize/configure video encoders asychronously.
>
> Greatly speeds up setRemoteDescription() by moving encoder initialization
> off the main worker thread, which is free to move onto gathering ICE
> candidates and other tasks while InitEncode() is performed. It also
> un-blocks PeerConnection GetStats() which is no longer blocked on
> encoder initialization.
>
> BUG=webrtc:5410
> R=stefan@webrtc.org
>
> Committed: fb647a67beR=stefan@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=chromium:595274, chromium:595308, webrtc:5410
Review URL: https://codereview.webrtc.org/1821983002 .
Cr-Commit-Position: refs/heads/master@{#12086}
webrtc::VideoRenderer class, replacing it by rtc::VideoSinkInterface.
The next step is to convert all places where a renderer is attached to
rtc::VideoSourceInterface, and at that point, the
SmoothsRenderedFrames method can be replaced by a flag
rtc::VideoSinkWants::smoothed_frames.
Delete unused method IsTextureSupported.
Delete unused time argument to RenderFrame.
Let webrtc::VideoRenderer inherit rtc::VideoSinkInterface. Rename RenderFrame --> OnFrame.
TBR=kjellander@webrtc.org
BUG=webrtc:5426
Review URL: https://codereview.webrtc.org/1814763002
Cr-Commit-Position: refs/heads/master@{#12070}
This CL removes copy and assign support from Buffer and changes various
parameters from Buffer to CopyOnWriteBuffer so they can be passed along
and copied without actually copying the underlying data.
With this changed some parameters to be "const" and fixed an issue when
creating a CopyOnWriteBuffer with empty data.
BUG=webrtc:5155
Review URL: https://codereview.webrtc.org/1823503002
Cr-Commit-Position: refs/heads/master@{#12062}
Reason for revert:
I'm really sorry for having to revert this but it seems this hit an unexpected compile error downstream:
webrtc/media/sctp/sctpdataengine.cc: In function 'void cricket::VerboseLogPacket(const void*, size_t, int)':
webrtc/media/sctp/sctpdataengine.cc:172:37: error: invalid conversion from 'const void*' to 'void*' [-fpermissive]
data, length, direction)) != NULL) {
^
In file included from webrtc/media/sctp/sctpdataengine.cc:20:0:
third_party/usrsctp/usrsctplib/usrsctp.h:964:1: error: initializing argument 1 of 'char* usrsctp_dumppacket(void*, size_t, int)' [-fpermissive]
usrsctp_dumppacket(void *, size_t, int);
^
I'm sure you can fix this easily and just re-land this CL, while I'm going to look into how to add this warning at the public bots (on Monday).
Original issue's description:
> Use CopyOnWriteBuffer instead of Buffer to avoid unnecessary copies.
>
> This CL removes copy and assign support from Buffer and changes various
> parameters from Buffer to CopyOnWriteBuffer so they can be passed along
> and copied without actually copying the underlying data.
>
> With this changed some parameters to be "const" and fixed an issue when
> creating a CopyOnWriteBuffer with empty data.
>
> BUG=webrtc:5155
>
> Committed: https://crrev.com/944c39006f1c52aee20919676002dac7a42b1c05
> Cr-Commit-Position: refs/heads/master@{#12058}
TBR=kwiberg@webrtc.org,tkchin@webrtc.org,tommi@webrtc.org,pthatcher@webrtc.org,jbauch@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5155
Review URL: https://codereview.webrtc.org/1817753003
Cr-Commit-Position: refs/heads/master@{#12060}
This CL removes copy and assign support from Buffer and changes various
parameters from Buffer to CopyOnWriteBuffer so they can be passed along
and copied without actually copying the underlying data.
With this changed some parameters to be "const" and fixed an issue when
creating a CopyOnWriteBuffer with empty data.
BUG=webrtc:5155
Review URL: https://codereview.webrtc.org/1785713005
Cr-Commit-Position: refs/heads/master@{#12058}
This change allows the application to limit the bitrate of the outgoing
audio and video streams at runtime. The API roughly follows the WebRTC
API draft, defining the RTCRtpParameters structure witn exactly one
encoding (simulcast streams are not exposed in the API for now).
(https://www.w3.org/TR/webrtc/#idl-def-RTCRtpParameters)
BUG=
Review URL: https://codereview.webrtc.org/1788583004
Cr-Commit-Position: refs/heads/master@{#12025}
Greatly speeds up setRemoteDescription() by moving encoder initialization
off the main worker thread, which is free to move onto gathering ICE
candidates and other tasks while InitEncode() is performed. It also
un-blocks PeerConnection GetStats() which is no longer blocked on
encoder initialization.
BUG=webrtc:5410
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1757313002 .
Cr-Commit-Position: refs/heads/master@{#11983}
Permits sending faster when having an attached track before actually
sending since the configured stream is ready to encode as soon as a call
is accepted.
BUG=webrtc:5410
R=deadbeef@webrtc.org
Review URL: https://codereview.webrtc.org/1790703002 .
Cr-Commit-Position: refs/heads/master@{#11963}
This cl copies the value of cricket::VideoCapturer::IsScreencast into
a flag in VideoOptions. It is passed on via the chain
VideortpSender::SetVideoSend
WebRtcVideoChannel2::SetVideoSend
WebRtcVideoChannel2::SetOptions
WebRtcVideoChannel2::WebRtcVideoSendStream::SetOptions
Where it's used, in
WebRtcVideoChannel2::WebRtcVideoSendStream::OnFrame, we can look it up
in parameters_, instead of calling capturer_->IsScreencast().
Doesn't touch screencast logic related to cpu adaptation, since that
code is in flux in a different cl.
Also drop the is_screencast flag from the Dimensions struct, and drop separate options argument from ConfigureVideoEncoderSettings and SetCodecAndOptions, instead always using the options recorded in VideoSendStreamParameters::options.
In the tests, changed FakeVideoCapturer::is_screencast to be a construction time flag. Generally, unittests of screencast have to both use a capturer configured for screencast, and set the screencast flag using SetSendParameters. Since the automatic connection via VideoSource and VideoRtpSender isn't involved in the unit tests.
Note that using SetSendParameters to set the screencast flag doesn't make sense, since it's not per-stream. SetVideoSend would be more appropriate. That should be fixed if/when we drop VideoOptions from SetSendParameters.
BUG=webrtc:5426
R=pbos@webrtc.org, perkj@webrtc.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1711763003 .
Cr-Commit-Position: refs/heads/master@{#11837}
Rename SetCodecAndOptions to SetCodec, it no longer sets or uses the
VideoOptions. In MediaConfig, collect the video-related flags into a
struct.
As a followup, it should be possible to delete VideoOptions from
VideoSendParameters and VideoSendStreamParameters.
TBR=pthatcher@webrtc.org
BUG=webrtc:5426
Review URL: https://codereview.webrtc.org/1745003002
Cr-Commit-Position: refs/heads/master@{#11828}
The purose of this cl is to remove dependency on cricket::VideoCapturer from WebRtcVideoChannel2.
This cl change CPU adaptation to use a new VideoSinkWants.Resolution
Cl is WIP and uploaded to start the discussion.
Tested on a N5 with hw acceleration turned off.
BUG=webrtc:5426
Review URL: https://codereview.webrtc.org/1695263002
Cr-Commit-Position: refs/heads/master@{#11804}
For audio, the flag is apparently unused. For video, the flag is moved to
VideoSendParameters, with the intention to keep only per-stream flags in
VideoOptions. The flag is used for the webrtcvideoengine2 logic commented like
// Conference mode screencast uses 2 temporal layers split at 100kbit.
// For screenshare in conference mode, tl0 and tl1 bitrates are piggybacked
// on the VideoCodec struct as target and max bitrates, respectively.
// See eg. webrtc::VP8EncoderImpl::SetRates().
BUG=webrtc:5426
Review URL: https://codereview.webrtc.org/1697163002
Cr-Commit-Position: refs/heads/master@{#11651}
