And redefine rtc::Buffer as
using Buffer = BufferT<uint8_t>;
(In the long run, I'd like to remove the type alias and rename the
template to just rtc::Buffer, but that requires all current users of
Buffer to start saying Buffer<uint8_t> instead, and since Buffer is
used in the API, we can't do that in one step.)
The immediate reason for the new template is that we'd like to use
BufferT<int16_t> in the AudioDecoder interface.
BUG=webrtc:5801
Review-Url: https://codereview.webrtc.org/1929903002
Cr-Commit-Position: refs/heads/master@{#12564}
This change builds on top of the refactoring in https://codereview.webrtc.org/1841083008/, and enables WebRTC client applications to control the max send bitrate for every audio stream through RtpParameters.
The AudioSendStream now stores the last codec spec, and whenever a global or per-stream bitrate limit changes, the effective limit (smaller of the two) is recomputed and the codec is reconfigured with that bitrate.
TBR=pthatcher
BUG=
Review URL: https://codereview.webrtc.org/1847353004
Cr-Commit-Position: refs/heads/master@{#12290}
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}
It appears that the adapt_frame_drops, effects_frame_drops, and capturer_frame_time statistics are never used. They are collected by cricket::VideoCapturer, and copied into VideoSenderInfo by the VideoMediaChannel::GetStats method.
So delete the code to generate the statistics, and the VariableInfo template which had no other uses.
BUG=webrtc:5426
R=pbos@webrtc.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/1804133003 .
Cr-Commit-Position: refs/heads/master@{#12032}
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}
At the top level, setting a track on an RtpSender is equivalent to
setting a source (previously called a renderer)
on a voice send stream. An RtpSender without a track
is not supposed to send data (not even muted data), so a send stream without
a source shouldn't send data.
Also replacing SendFlags with a boolean and implementing "Start"
and "Stop" methods on AudioSendStream, which was planned anyway
and simplifies this CL.
R=pthatcher@webrtc.org, solenberg@webrtc.org
Review URL: https://codereview.webrtc.org/1741933002 .
Cr-Commit-Position: refs/heads/master@{#11918}
Multiple sources with the same names forces ugly GYP hacks in
Chromium's libjingle.gyp. Rename the sources in WebRTC to
enable cleaning this up in Chromium.
To summarize:
webrtc/media/base/constants.{cc,h} -> mediaconstants.{cc,h}
webrtc/p2p/base/constants.{cc,h} -> p2pconstants.{cc,h}
This CL will require coordinating landing a roll in Chromium.
BUG=webrtc:4256
NOTRY=True
Review URL: https://codereview.webrtc.org/1750593002
Cr-Commit-Position: refs/heads/master@{#11842}
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}
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}
I removed the 'libjingle' target in talk/libjingle.gyp and replaced
all users of it with base/base.gyp:rtc_base. It seems the jsoncpp
and expat dependencies were not used by it's previous references.
The files in talk/media/testdata were uploaded to Google Storage and
added .sha1 files in resources/media instead of simply moving them.
The previously disabled warnings that were inherited from
talk/build/common.gypi are now replaced by target-specific disabling
of only the failing warnings. Additional disabling was needed since the stricter
compilation warnings that applies to code in webrtc/.
License headers will be updated in a follow-up CL in order to not
break Git history.
Other modifications:
* Updated the header guards.
* Sorted the includes using chromium/src/tools/sort-headers.py
except for these files:
talk/app/webrtc/peerconnectionendtoend_unittest.cc
talk/app/webrtc/java/jni/androidmediadecoder_jni.cc
talk/app/webrtc/java/jni/androidmediaencoder_jni.cc
webrtc/media/devices/win32devicemanager.cc.
* Unused GYP reference to libjingle_tests_additional_deps was removed.
* Removed duplicated GYP entries of
webrtc/base/testutils.cc
webrtc/base/testutils.h
The HAVE_WEBRTC_VIDEO and HAVE_WEBRTC_VOICE defines were used by only talk/media,
so they were moved to the media.gyp.
I also checked that none of
EXPAT_RELATIVE_PATH,
FEATURE_ENABLE_VOICEMAIL,
GTEST_RELATIVE_PATH,
JSONCPP_RELATIVE_PATH,
LOGGING=1,
SRTP_RELATIVE_PATH,
FEATURE_ENABLE_SSL,
FEATURE_ENABLE_VOICEMAIL,
FEATURE_ENABLE_PSTN,
HAVE_SCTP,
HAVE_SRTP,
are used by the talk/media code.
For Chromium, the following changes will need to be applied to the roll CL that updates the
DEPS for WebRTC and libjingle: https://codereview.chromium.org/1604303002/
BUG=webrtc:5420
NOPRESUBMIT=True
TBR=tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1587193006
Cr-Commit-Position: refs/heads/master@{#11495}
