This brings QualityScaler much more in line with OveruseFrameDetector.
The two classes are conceptually similar, and should be used in the
same way. The biggest changes in this CL are:
- Quality scaling is now only done in ViEEncoder and not in each
encoder implementation separately.
- QualityScaler now checks the average QP asynchronously, instead of
having to be polled on each frame.
- QualityScaler is no longer responsible for actually scaling the frames,
but has a callback to ViEEncoder that it uses to express it's desire
for lower resolution.
BUG=webrtc:6495
Review-Url: https://codereview.webrtc.org/2398963003
Cr-Commit-Position: refs/heads/master@{#15286}
There's no longer any need to make the two arguments have the same
signedness, so we can drop the "u" suffix on literal integer
arguments.
NOPRESUBMIT=true
BUG=webrtc:6645
Review-Url: https://codereview.webrtc.org/2535593002
Cr-Commit-Position: refs/heads/master@{#15280}
Now ProbeController can send periodic bandwidth probes when in
application-limited region. This will allow to maintain correct
bottleneck bandwidth estimate, even not all bandwidth is being used.
The feature is not enabled by default, but can be enabled with a flag.
Interval between probes is currently set to 5 seconds.
BUG=webrtc:6332
Review-Url: https://codereview.webrtc.org/2504023002
Cr-Commit-Position: refs/heads/master@{#15279}
Pass the selected cricket::VideoCodec to H264EncoderImpl::H264EncoderImpl. The cricket::VideoCodec contains relevant information for H264 about selected profile and packetization mode.
BUG=chromium:600254,webrtc:6402, webrtc:6337
Review-Url: https://codereview.webrtc.org/2474993002
Cr-Commit-Position: refs/heads/master@{#15270}
transport.h defines an interface for sending rtp and rtcp packets,
which is used by MediaChannel in webrtc/media/engine,
{Audio|Video}{Send|Receive}Stream and in a few other
places. It was part of the build target //webrtc:webrtc, which is a monolithic target with
all webrtc production code. This CL moves the header to its own target in webrtc/api
and deprecates the old location.
Targets in webrtc/api should in general only depend on other
targets in webrtc/api. The target webrtc/api:call_api depends on
transport.h. This change also makes webrtc/voice_engine pass GN's header
include checker and is needed in order for webrtc/api:call_api to pass
it.
transport.h will be completely removed in a follow-up CL in a few weeks
after clients have updated their includes.
NOTRY=True
BUG=webrtc:5589, webrtc:5878, webrtc:6785
Review-Url: https://codereview.webrtc.org/2426563003
Cr-Commit-Position: refs/heads/master@{#15267}
A WebRtcVideoEngine2 object seems to be reused between PeerConnections,
which means that the field trial added in
https://codereview.webrtc.org/2511703002/ may not activate/deactivate
as intended between calls. This CL removes the caching of video codecs,
which gets rid of this problem.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2521393004
Cr-Commit-Position: refs/heads/master@{#15265}
It will be necessary to keep the H264 profile information in
VideoReceiveStream::Decoder. I think it will be easier now and for the
future to just store all of the codec parameters unmodified in
VideoReceiveStream::Decoder instead of extracting a subset of them to an
ad hoc class.
BUG=webrtc:6743,webrtc:5948
Review-Url: https://codereview.webrtc.org/2523773003
Cr-Commit-Position: refs/heads/master@{#15239}
Previously ProbeController was starting probing as soon as SetBitrates()
is called. As result these probes would often timeout while connection
is being established. Now ProbeController receives notifications about
network route changes. This allows to start probing only when transport
is connected. This also makes it possible to restart probing whenever
transport route changes (will be done in a separate change).
BUG=webrtc:6332
R=honghaiz@webrtc.org, philipel@webrtc.org, stefan@webrtc.org
Review URL: https://codereview.webrtc.org/2458863002 .
Committed: https://crrev.com/5c99c76255ee7bface3c742c25fb5617748ac86e
Cr-Original-Commit-Position: refs/heads/master@{#15094}
Cr-Commit-Position: refs/heads/master@{#15204}
the APM parameters to the high-pass filter.
The introduction will be done in three steps:
1) This CL which introduces the new scheme and
changes the code in webrtcvoiceengine.cc to use it.
2) Introduce the scheme into upstream code.
3) Remove the HighPassFilter interface in APM.
BUG=webrtc::6220, webrtc::6296, webrtc::6297, webrtc::6181, webrtc::5298
Review-Url: https://codereview.webrtc.org/2415403002
Cr-Commit-Position: refs/heads/master@{#15197}
This CL interfaces the SDP information (payload types and
SSRCs) about FlexFEC with the corresponding configs at the
Call layer. It also adds a field trial, which when active
will expose FlexFEC in the default codec list, thus showing
up in the default SDP.
BUG=webrtc:5654
R=magjed@webrtc.org, stefan@webrtc.orgCC=perkj@webrtc.org
Review-Url: https://codereview.webrtc.org/2511703002
Cr-Commit-Position: refs/heads/master@{#15184}
The class VideoDecoderSoftwareFallbackWrapper is an implementation
detail of webrtc/media/engine/webrtcvideoengine2.cc and should not be
directly under webrtc/video_decoder.h. The main purpose is to improve
the dependency graph in WebRTC so that VideoDecoderSoftwareFallbackWrapper
can depend on cricket::VideoCodec.
The test for VideoDecoderSoftwareFallbackWrapper is also moved from
webrtc/video/video_decoder_unittest.cc to
webrtc/media/engine/videodecodersoftwarefallbackwrapper_unittest.cc.
BUG=webrtc:6743
TBR=stefan@webrtc.org
Review-Url: https://codereview.webrtc.org/2518263003
Cr-Commit-Position: refs/heads/master@{#15180}
the previously specified setting is changed if it is specified to be changed,
and otherwise the previously specified setting is kept as it is.
This CL replicates this functionality for the way that the new APM
parameter scheme is used.
BUG=webrtc::6220, webrtc::6296, webrtc::6297, webrtc::6181, webrtc::5298
Review-Url: https://codereview.webrtc.org/2489343002
Cr-Commit-Position: refs/heads/master@{#15167}
Reason for revert:
The WebRtcBrowserTest.NegotiateUnsupportedVideoCodec test has been fixed in Chromium with the following change:
function removeVideoCodec(offerSdp) {
- offerSdp = offerSdp.replace('a=rtpmap:100 VP8/90000\r\n',
- 'a=rtpmap:100 XVP8/90000\r\n');
+ offerSdp = offerSdp.replace(/a=rtpmap:(\d+)\ VP8\/90000\r\n/,
+ 'a=rtpmap:$1 XVP8/90000\r\n');
return offerSdp;
}
Original issue's description:
> Revert of Stop using hardcoded payload types for video codecs (patchset #6 id:210001 of https://codereview.webrtc.org/2493133002/ )
>
> Reason for revert:
> Breaks chromium.fyi test:
> WebRtcBrowserTest.NegotiateUnsupportedVideoCodec
>
> Original issue's description:
> > Stop using hardcoded payload types for video codecs
> >
> > This CL stops using hardcoded payload types for different video codecs
> > and will dynamically assign them payload types incrementally from 96 to
> > 127 instead.
> >
> > This CL:
> > * Replaces 'std::vector<VideoCodec> DefaultVideoCodecList()' in
> > webrtcvideoengine2.cc with an explicit WebRtcVideoEncoderFactory for
> > internally supported software codecs instead. The purpose is to
> > streamline the payload type assignment in webrtcvideoengine2.cc which
> > will now have two encoder factories of the same
> > WebRtcVideoEncoderFactory type; one internal and one external.
> > * Removes webrtc::VideoEncoder::EncoderType and use cricket::VideoCodec
> > instead.
> > * Removes 'static VideoEncoder* Create(EncoderType codec_type)' and
> > moves the create function to the internal encoder factory instead.
> > * Removes video_encoder.cc. webrtc::VideoEncoder is now just an
> > interface without any static functions.
> > * The function GetSupportedCodecs in webrtcvideoengine2.cc unifies
> > the internal and external codecs and assigns them payload types
> > incrementally from 96 to 127.
> > * Updates webrtcvideoengine2_unittest.cc and removes assumptions about
> > what payload types will be used.
> >
> > BUG=webrtc:6677,webrtc:6705
> > R=hta@webrtc.org, ossu@webrtc.org, stefan@webrtc.org
> >
> > Committed: https://crrev.com/42043b95872b51321f508bf255d804ce3dff366b
> > Cr-Commit-Position: refs/heads/master@{#15135}
>
> TBR=hta@webrtc.org,stefan@webrtc.org,ossu@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:6677,webrtc:6705
>
> Committed: https://crrev.com/eacbaea920797ff751ca83050d140821f5055591
> Cr-Commit-Position: refs/heads/master@{#15140}
TBR=hta@webrtc.org,stefan@webrtc.org,ossu@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6677,webrtc:6705
Review-Url: https://codereview.webrtc.org/2511933002
Cr-Commit-Position: refs/heads/master@{#15148}
Payload type -> RtpCodecParameters maps added for sender and receiver.
This is a follow-up to https://codereview.webrtc.org/2484193002/ which
did the same thing for VideoMediaInfo. This information will be used to
produce RTCCodecStats[1].
Voice[Sender/Receiver]Info is updated with current codec payload type
for every stream which can be used to look up the codec in
VoiceMediaInfo.
[1] https://w3c.github.io/webrtc-stats/#codec-dict*
BUG=chromium:659117
Review-Url: https://codereview.webrtc.org/2503383002
Cr-Commit-Position: refs/heads/master@{#15144}
Reason for revert:
Breaks chromium.fyi test:
WebRtcBrowserTest.NegotiateUnsupportedVideoCodec
Original issue's description:
> Stop using hardcoded payload types for video codecs
>
> This CL stops using hardcoded payload types for different video codecs
> and will dynamically assign them payload types incrementally from 96 to
> 127 instead.
>
> This CL:
> * Replaces 'std::vector<VideoCodec> DefaultVideoCodecList()' in
> webrtcvideoengine2.cc with an explicit WebRtcVideoEncoderFactory for
> internally supported software codecs instead. The purpose is to
> streamline the payload type assignment in webrtcvideoengine2.cc which
> will now have two encoder factories of the same
> WebRtcVideoEncoderFactory type; one internal and one external.
> * Removes webrtc::VideoEncoder::EncoderType and use cricket::VideoCodec
> instead.
> * Removes 'static VideoEncoder* Create(EncoderType codec_type)' and
> moves the create function to the internal encoder factory instead.
> * Removes video_encoder.cc. webrtc::VideoEncoder is now just an
> interface without any static functions.
> * The function GetSupportedCodecs in webrtcvideoengine2.cc unifies
> the internal and external codecs and assigns them payload types
> incrementally from 96 to 127.
> * Updates webrtcvideoengine2_unittest.cc and removes assumptions about
> what payload types will be used.
>
> BUG=webrtc:6677,webrtc:6705
> R=hta@webrtc.org, ossu@webrtc.org, stefan@webrtc.org
>
> Committed: https://crrev.com/42043b95872b51321f508bf255d804ce3dff366b
> Cr-Commit-Position: refs/heads/master@{#15135}
TBR=hta@webrtc.org,stefan@webrtc.org,ossu@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6677,webrtc:6705
Review-Url: https://codereview.webrtc.org/2513633002
Cr-Commit-Position: refs/heads/master@{#15140}
This CL stops using hardcoded payload types for different video codecs
and will dynamically assign them payload types incrementally from 96 to
127 instead.
This CL:
* Replaces 'std::vector<VideoCodec> DefaultVideoCodecList()' in
webrtcvideoengine2.cc with an explicit WebRtcVideoEncoderFactory for
internally supported software codecs instead. The purpose is to
streamline the payload type assignment in webrtcvideoengine2.cc which
will now have two encoder factories of the same
WebRtcVideoEncoderFactory type; one internal and one external.
* Removes webrtc::VideoEncoder::EncoderType and use cricket::VideoCodec
instead.
* Removes 'static VideoEncoder* Create(EncoderType codec_type)' and
moves the create function to the internal encoder factory instead.
* Removes video_encoder.cc. webrtc::VideoEncoder is now just an
interface without any static functions.
* The function GetSupportedCodecs in webrtcvideoengine2.cc unifies
the internal and external codecs and assigns them payload types
incrementally from 96 to 127.
* Updates webrtcvideoengine2_unittest.cc and removes assumptions about
what payload types will be used.
BUG=webrtc:6677,webrtc:6705
R=hta@webrtc.org, ossu@webrtc.org, stefan@webrtc.org
Review URL: https://codereview.webrtc.org/2493133002 .
Cr-Commit-Position: refs/heads/master@{#15135}
This is a refactoring change in preparation for enabling AudioMixer
with the goal to have a small CL as possible for passing audio through
the new audio mixer in WebRTC. The dependent CL https://codereview.webrtc.org/2436033002/
enables the mixer.
An object of class AudioState is shared across different webrtc audio
connections. It is created in tests and in
WebRTCVoiceEngine. AudioState is constructed by passing a Config
struct, where one argument is scoped_refptr<AudioMixer>.
Populating this field has now been mandatory. Tests and
WebRTCVoiceEngine create and pass either a AudioMixerImpl.
WebRTCVoiceEngine passes a real AudioMixer, which is
currently unused.
An alternative would have tests pass a mocked audio mixer. We
chose not to do that, because we believe that tests should use
the real thing unless there are reasons against it. Construction
time is not an issue, because the real mixer is relatively
lightweight.
We couldn't find a way to test any mixer-related changes in AudioState
before the mixes is connected. The next dependent CL
https://codereview.webrtc.org/2436033002/ contains unit tests for
mixer usage.
BUG=webrtc:6346
Review-Url: https://codereview.webrtc.org/2469743002
Cr-Commit-Position: refs/heads/master@{#15134}
We support multiple payload types, and one which matches the audio codec the closest, is picked (or the one with lowest clock rate, if no perfect match is found).
The exact clock rate is then ignored and DTMF packets are time stamped with the rate of the current audio codec. This is exactly the way the code has worked up to this point, but until now we have been under the impression that we were in fact sending 8k DTMF.
In other words, this is an improvement over the current situation, since we will most likely find a payload type which matches the codec clock rate.
This CL also does a little cleaning of the DTMFQueue and RTPSenderAudio classes.
BUG=webrtc:2795
Review-Url: https://codereview.webrtc.org/2392883002
Cr-Commit-Position: refs/heads/master@{#15129}
This is yet another reland of https://codereview.webrtc.org/2434073003/
including two fixes:
1. SimulcastRateAllocator did not handle the screenshare settings properly for numSimulcastStreams = 1. Additional test case was added for that.
2. In VideoSender, when rate allocation is updated after setting a new VideoCodec config, only update the state of the EncoderParameters, but don't actually run SetRateAllocation on the encoder itself. This caused some problems upstreams.
Please review only the changes after patch set 1.
Original description:
Extract bitrate allocation of spatial/temporal layers out of codec impl.
This CL makes a number of intervowen changes:
* Add BitrateAllocation struct, that contains a codec independent view
of how the target bitrate is distributed over spatial and temporal
layers.
* Adds the BitrateAllocator interface, which takes a bitrate and frame
rate and produces a BitrateAllocation.
* A default (non layered) implementation is added, and
SimulcastRateAllocator is extended to fully handle VP8 allocation.
This includes capturing TemporalLayer instances created by the
encoder.
* ViEEncoder now owns both the bitrate allocator and the temporal layer
factories for VP8. This allows allocation to happen fully outside of
the encoder implementation.
This refactoring will make it possible for ViEEncoder to signal the
full picture of target bitrates to the RTCP module.
BUG=webrtc:6301
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/2510583002 .
Cr-Commit-Position: refs/heads/master@{#15105}
Reason for revert:
It broke downstream test.
Original issue's description:
> Start probes only after network is connected.
>
> Previously ProbeController was starting probing as soon as SetBitrates()
> is called. As result these probes would often timeout while connection
> is being established. Now ProbeController receives notifications about
> network route changes. This allows to start probing only when transport
> is connected. This also makes it possible to restart probing whenever
> transport route changes (will be done in a separate change).
>
> BUG=webrtc:6332
>
> Committed: https://crrev.com/5c99c76255ee7bface3c742c25fb5617748ac86e
> Cr-Commit-Position: refs/heads/master@{#15094}
TBR=philipel@webrtc.org,stefan@webrtc.org,sergeyu@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6332
Review-Url: https://codereview.webrtc.org/2504783002
Cr-Commit-Position: refs/heads/master@{#15098}
Previously ProbeController was starting probing as soon as SetBitrates()
is called. As result these probes would often timeout while connection
is being established. Now ProbeController receives notifications about
network route changes. This allows to start probing only when transport
is connected. This also makes it possible to restart probing whenever
transport route changes (will be done in a separate change).
BUG=webrtc:6332
Review-Url: https://codereview.webrtc.org/2458863002
Cr-Commit-Position: refs/heads/master@{#15094}
The class VideoEncoderSoftwareFallbackWrapper is an implementation
detail of webrtc/media/engine/webrtcvideoengine2.cc and should not be
directly under webrtc/video_encoder.h. The main purpose is to improve
the dependency graph in WebRTC so that VideoEncoderSoftwareFallbackWrapper
can depend on cricket::VideoCodec.
The test for VideoEncoderSoftwareFallbackWrapper is also moved from
webrtc/video/video_encoder_unittest.cc to
webrtc/media/engine/videoencodersoftwarefallbackwrapper_unittest.cc.
BUG=webrtc:6337
Review-Url: https://codereview.webrtc.org/2484863009
Cr-Commit-Position: refs/heads/master@{#15085}
- Functionality now implemented in AudioReceiveStream and Call.
- Added some missing function to MockChannelProxy.
BUG=webrtc:4690
Review-Url: https://codereview.webrtc.org/2461523002
Cr-Commit-Position: refs/heads/master@{#15072}
Payload type -> RtpCodecParameters maps added for sender and receiver
side. It contains information that will be needed for RTCCodecStats[1]
dictionaries.
Video[Sender/Receiver]Info is updated with current codec payload type
for every stream which can be used to look up the codec in
VideoMediaInfo.
A similar change should be made for VoiceMediaInfo and
Voice[Sender/Receiver]Info.
[1] https://w3c.github.io/webrtc-stats/#codec-dict*
BUG=chromium:659117
Review-Url: https://codereview.webrtc.org/2484193002
Cr-Commit-Position: refs/heads/master@{#15060}
This CL will start to distinguish H264 profiles during SDP negotiation.
We currently don't look at the H264 profile at all and assume they are
all Constrained Baseline Level 3.1. This CL will start to check profiles
for equality when matching, and will generate the correct answer H264
level.
Each local supported H264 profile needs to be listed explicitly in the
list of local supported codecs, even if they are redundant. For example,
Baseline profile should be listed explicitly even though another profile
that is a superset of Baseline is also listed. The reason for this is to
simplify the code and avoid profile intersection during matching. So
VideoCodec::Matches will check for profile equality, and not check if
one codec is a subset of the other. This also leads to the nice property
that VideoCodec::Matches is symmetric, i.e. iif a.Matches(b) then
b.Matches(a).
BUG=webrtc:6337
TBR=tkchin@webrtc.org
Review-Url: https://codereview.webrtc.org/2483173002
Cr-Commit-Position: refs/heads/master@{#15051}
In older Chrome versions, the associated payload type in the RTX header
of retransmitted packets was always set to be the original media payload type,
regardless of the actual payload type of the packet. This meant that packets
encapsulated with RED headers had incorrect payload type information in the
RTX header. Due to an assumption in the receiver, this incorrect payload type
information would effectively be undone, leading to a working system.
Albeit working, this behaviour was undesired, and thus removed. In the interim,
several workarounds were introduced to not destroy interop between old and
new Chrome versions:
(1) https://codereview.webrtc.org/1649493004
- If no payload type mapping existed for RED over RTX, the payload type
of the underlying media would be used.
- If RED had been negotiated, received RTX packets would always be
assumed to contain RED.
(2) https://codereview.webrtc.org/1964473002
- If RED was removed from the remote description answer, it would be
disabled in the local receiver as well.
(3) https://codereview.webrtc.org/2033763002
- If RED was negotiated in the SDP, it would always be used, regardless
if ULPFEC was negotiated and used, or not.
Since the Chrome versions that exhibited the original bug now are very old,
this CL removes the workarounds from (1) and (2). In particular, after this
change, we will have the following behaviour:
- We assume that a payload type mapping for RED over RTX always is set.
If this is not the case, the RTX packet is not sent.
- The associated payload type of received RTX packets will always be obeyed.
- The (non)-existence of RED in the remote description does not affect the
local receiver.
The workaround in (3) still needs to exist, in order to interop with receivers
that did not have the workarounds in (1) and (2) removed. The change in (3)
can be removed in a couple of Chrome versions.
TESTED=Using AppRTC between patched Chrome (connected to ethernet) and standard Chrome M54 (connected to lossy internal Google WiFi), with and without FEC turned off using AppRTC flag. Also using "Munge SDP" sample on patched Chrome over loopback interface, with 100ms delay and 5% packet loss simulated using tc.
BUG=webrtc:6650
Review-Url: https://codereview.webrtc.org/2469093003
Cr-Commit-Position: refs/heads/master@{#15038}
Reason for revert:
Seems to be causing flakiness in perf test:
FullStackTest.ScreenshareSlidesVP8_2TL_LossyNet
Original issue's description:
> Reland of Issue 2434073003: Extract bitrate allocation ...
>
> This is a reland of https://codereview.webrtc.org/2434073003/ including
> some fixes for failing test cases.
>
> Original description:
>
> Extract bitrate allocation of spatial/temporal layers out of codec impl.
>
> This CL makes a number of intervowen changes:
>
> * Add BitrateAllocation struct, that contains a codec independent view
> of how the target bitrate is distributed over spatial and temporal
> layers.
>
> * Adds the BitrateAllocator interface, which takes a bitrate and frame
> rate and produces a BitrateAllocation.
>
> * A default (non layered) implementation is added, and
> SimulcastRateAllocator is extended to fully handle VP8 allocation.
> This includes capturing TemporalLayer instances created by the
> encoder.
>
> * ViEEncoder now owns both the bitrate allocator and the temporal layer
> factories for VP8. This allows allocation to happen fully outside of
> the encoder implementation.
>
> This refactoring will make it possible for ViEEncoder to signal the
> full picture of target bitrates to the RTCP module.
>
> BUG=webrtc:6301
>
> Committed: https://crrev.com/647bf43dcb2fd16fccf276bd94dc4400728bb405
> Cr-Commit-Position: refs/heads/master@{#15023}
TBR=mflodman@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6301
Review-Url: https://codereview.webrtc.org/2491393002
Cr-Commit-Position: refs/heads/master@{#15026}
This is a reland of https://codereview.webrtc.org/2434073003/ including
some fixes for failing test cases.
Original description:
Extract bitrate allocation of spatial/temporal layers out of codec impl.
This CL makes a number of intervowen changes:
* Add BitrateAllocation struct, that contains a codec independent view
of how the target bitrate is distributed over spatial and temporal
layers.
* Adds the BitrateAllocator interface, which takes a bitrate and frame
rate and produces a BitrateAllocation.
* A default (non layered) implementation is added, and
SimulcastRateAllocator is extended to fully handle VP8 allocation.
This includes capturing TemporalLayer instances created by the
encoder.
* ViEEncoder now owns both the bitrate allocator and the temporal layer
factories for VP8. This allows allocation to happen fully outside of
the encoder implementation.
This refactoring will make it possible for ViEEncoder to signal the
full picture of target bitrates to the RTCP module.
BUG=webrtc:6301
Review-Url: https://codereview.webrtc.org/2488833004
Cr-Commit-Position: refs/heads/master@{#15023}
Reason for revert:
This CL probably broke Chromium FYI.
Original issue's description:
> Stop caching supported codecs in WebRtcVideoEngine2
>
> We currently cache the result of GetSupportedCodecs in a member variable
> |video_codecs_| in WebRtcVideoEngine2. This means we need to keep
> |video_codecs_| and the result of GetSupportedCodecs in sync, which is
> error prone. It's simpler to just call GetSupportedCodecs when we need
> it, and we actually end up making fewer calls, so it's faster as well.
> This CL also returns all std::vectors by-value instead of by-ref. Move
> semantic together with in-place filtering of codecs actually end up with
> fewer copies, and it's also simpler to not return references.
>
> BUG=webrtc:6337
>
> Committed: https://crrev.com/9f71ec5a3e3175751f4475b126cfda89767363f2
> Cr-Commit-Position: refs/heads/master@{#15007}
TBR=tommi@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6337
Review-Url: https://codereview.webrtc.org/2489173004
Cr-Commit-Position: refs/heads/master@{#15014}
We currently cache the result of GetSupportedCodecs in a member variable
|video_codecs_| in WebRtcVideoEngine2. This means we need to keep
|video_codecs_| and the result of GetSupportedCodecs in sync, which is
error prone. It's simpler to just call GetSupportedCodecs when we need
it, and we actually end up making fewer calls, so it's faster as well.
This CL also returns all std::vectors by-value instead of by-ref. Move
semantic together with in-place filtering of codecs actually end up with
fewer copies, and it's also simpler to not return references.
BUG=webrtc:6337
Review-Url: https://codereview.webrtc.org/2492473002
Cr-Commit-Position: refs/heads/master@{#15007}
Reason for revert:
Breaks perf tests.
Original issue's description:
> Extract bitrate allocation of spatial/temporal layers out of codec impl.
>
> This CL makes a number of intervowen changes:
>
> * Add BitrateAllocation struct, that contains a codec independent view
> of how the target bitrate is distributed over spatial and temporal
> layers.
>
> * Adds the BitrateAllocator interface, which takes a bitrate and frame
> rate and produces a BitrateAllocation.
>
> * A default (non layered) implementation is added, and
> SimulcastRateAllocator is extended to fully handle VP8 allocation.
> This includes capturing TemporalLayer instances created by the
> encoder.
>
> * ViEEncoder now owns both the bitrate allocator and the temporal layer
> factories for VP8. This allows allocation to happen fully outside of
> the encoder implementation.
>
> This refactoring will make it possible for ViEEncoder to signal the
> full picture of target bitrates to the RTCP module.
>
> BUG=webrtc:6301
>
> Committed: https://crrev.com/8f46c679d24a05b3f08e02c6d91ec9637f34e24f
> Cr-Commit-Position: refs/heads/master@{#14998}
TBR=stefan@webrtc.org,perkj@webrtc.org,mflodman@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6301
Review-Url: https://codereview.webrtc.org/2489843002
Cr-Commit-Position: refs/heads/master@{#15001}
This CL makes a number of intervowen changes:
* Add BitrateAllocation struct, that contains a codec independent view
of how the target bitrate is distributed over spatial and temporal
layers.
* Adds the BitrateAllocator interface, which takes a bitrate and frame
rate and produces a BitrateAllocation.
* A default (non layered) implementation is added, and
SimulcastRateAllocator is extended to fully handle VP8 allocation.
This includes capturing TemporalLayer instances created by the
encoder.
* ViEEncoder now owns both the bitrate allocator and the temporal layer
factories for VP8. This allows allocation to happen fully outside of
the encoder implementation.
This refactoring will make it possible for ViEEncoder to signal the
full picture of target bitrates to the RTCP module.
BUG=webrtc:6301
Review-Url: https://codereview.webrtc.org/2434073003
Cr-Commit-Position: refs/heads/master@{#14998}
This CL removes WebRtcVideoReceiveStream::FilterSupportedCodecs and
adds more fine grained code for selecting and verifying codecs. This
also removes unnecessary copying of cricket::VideoCodecs.
BUG=webrtc:6337
Review-Url: https://codereview.webrtc.org/2474433012
Cr-Commit-Position: refs/heads/master@{#14964}
The cricket::Codec class contains std containers like
std::map<std::string, std::string> and is expensive to copy. This CL
adds move constructors and move assignment operators for it and all
subclasses.
This CL also:
* Implement functions with '= default' instead of doing it manually.
* Makes codec::Matches symmetric. We currently don't check if the
payload type of the callee is static, and might incorrectly return
true in these cases.
BUG=None
Review-Url: https://codereview.webrtc.org/2481193002
Cr-Commit-Position: refs/heads/master@{#14956}
The unit was kbps but the one default use of it is in bps. The inconsistency should be fixed.
BUG=webrtc:6670
Review-Url: https://codereview.webrtc.org/2247213005
Cr-Commit-Position: refs/heads/master@{#14955}
Reason for revert:
Reverting because of the reasons given in comment #16:
"This change breaks a scenario that is unfortunately not covered by unit tests,
but can easily happen in a real call.
The scenario that is broken by the change is this:
1. A sends an offer to B, with a set of codecs C_a (which is a subset of C_b,
the codecs supported by B)
2. B responds with an answer, and sets the receive codecs to C_a.
3. At a later time, B generates a new offer which by default includes all codecs
in C_b.
4. B calls SetLocalDescription() with this offer, that adds new receive codecs.
5. Adding the new codecs fails, because of the check at
https://cs.chromium.org/chromium/src/third_party/webrtc/voice_engine/channel.....
This causes SetLocalDescription() itself to fail. The net effect is that B
cannot set a local description it just generated.
Before the CL mentioned above, we'd stop playout before changing the codecs, and
the operation would succeed."
Original issue's description:
> Removed the legacy behavior of stopping playout when setting new receive codecs.
>
> BUG=webrtc:4690
>
> Committed: https://crrev.com/917d4e1e7131f35764cff932a8793151585e8179
> Cr-Commit-Position: refs/heads/master@{#14610}
TBR=solenberg@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:4690
Review-Url: https://codereview.webrtc.org/2478433003
Cr-Commit-Position: refs/heads/master@{#14905}
Suppress WebRtcVideoEncoderFactory overloaded virtual function warning
in WebRtcSimulcastEncoderFactory and FakeWebRtcVideoEncoderFactory.
This warning is triggered by the change in this CL:
https://codereview.webrtc.org/2449993003/.
BUG=webrtc:6402, webrtc:6337
Review-Url: https://codereview.webrtc.org/2468253002
Cr-Commit-Position: refs/heads/master@{#14901}
This removes the VideoSendStream::LoadObserver interface and the implementation in WebrtcVideoSendStream and replace it with VideoSinkWants through the VideoSourceInterface.
To do that that, some stats for CPU adaptation is moved into VideoSendStream. Also handling of the CVO rtp header extension is moved to VideoSendStreamImpl.
BUG=webrtc:5687
TBR=mflodman@webrtc.org
Review-Url: https://codereview.webrtc.org/2304363002
Cr-Commit-Position: refs/heads/master@{#14877}
