The purpose with this CL is to be able to send video codec specific
information down to RTPPayloadRegistry. We already do this for audio
with explicit arguments for e.g. number of channels. Instead of
extracting the arguments from webrtc::CodecInst (audio) and
webrtc::VideoCodec, this CL sends the types unmodified all the way down
to RTPPayloadRegistry.
This CL does not contain any functional changes, and is just a
preparation for future CL:s.
In the dependent CL https://codereview.webrtc.org/2524923002/,
RTPPayloadStrategy is removed. RTPPayloadStrategy previously handled
audio/video specific aspects of payload handling. After this CL, we will
know if we get audio or video codecs without any dependency injection,
since we have different functions with different signatures for audio
vs video.
BUG=webrtc:6743
TBR=mflodman
Review-Url: https://codereview.webrtc.org/2523843002
Cr-Commit-Position: refs/heads/master@{#15231}
Reason for revert:
Internal bots failed.
Original issue's description:
> Reland "Move smoothing filter to common audio".
>
> The original CL was this https://codereview.webrtc.org/2484153002/
>
> Due to failure with internal trial servers, it was reverted. This CL tries to reland it.
>
> BUG=webrtc:6443
>
> Committed: https://crrev.com/223641f1b903e41e77d88f03199b4cdb65255ec8
> Cr-Commit-Position: refs/heads/master@{#15227}
TBR=tommi@webrtc.org,solenberg@webrtc.org,terelius@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:6443
Review-Url: https://codereview.webrtc.org/2529943002
Cr-Commit-Position: refs/heads/master@{#15228}
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 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}
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}
PayloadRouter::OnEncodedImage() was casing boolean result from
SendOutgoingData() to int, and then not handling it correctly, which
results in all errors in SendOutgoingData() being ignored. This issue
was introduced in
https://chromium.googlesource.com/external/webrtc/+/ad34dbe934
This bug masked another issue with VP9 codec (see
crbug.com/webrtc/6723 ) and that increased number of dropped frames.
BUG=634816
Review-Url: https://codereview.webrtc.org/2512543002
Cr-Commit-Position: refs/heads/master@{#15143}
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}
This CL adds full stack tests that are used to measure the performance
of H264 with and without FlexFEC. In order to not increase the bot
run time, the CL also reduces the test time to 45 secs. This should
be OK, since the BWE is faster to ramp up nowadays.
Due to the test time change, there may be some performance alerts.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2499273002
Cr-Commit-Position: refs/heads/master@{#15118}
Will be used by full stack tests and video_loopback.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2500373002
Cr-Commit-Position: refs/heads/master@{#15114}
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}
This is initial work to get the stats working for FlexFEC.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2498393002
Cr-Commit-Position: refs/heads/master@{#15089}
This is needed for the following coming tests: VideoSendStream, end-to-end,
full stack, and video_loopback.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2500943002
Cr-Commit-Position: refs/heads/master@{#15087}
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}
FlexfecSender is owned and configured by VideoSendStream.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2501503003
Cr-Commit-Position: refs/heads/master@{#15082}
Right now, the H264 end-to-end tests are not run on the bots.
BUG=None
Review-Url: https://codereview.webrtc.org/2484913007
Cr-Commit-Position: refs/heads/master@{#15062}
After the removal of the RED/RTX workaround, we now need to explicitly
enable RTX for RED. Prior to the removal of the workaround, RED over RTX
was implicitly enabled whenever media over RTX was enabled.
BUG=webrtc:6650
Review-Url: https://codereview.webrtc.org/2493723002
Cr-Commit-Position: refs/heads/master@{#15061}
Reason for revert:
Broke a lot of tests in chromium.webrtc browser_tests. See e.g. https://build.chromium.org/p/chromium.webrtc/builders/Mac%20Tester/builds/62228 and https://build.chromium.org/p/chromium.webrtc/builders/Win8%20Tester/builds/30102.
[ RUN ] WebRtcVideoQualityBrowserTests/WebRtcVideoQualityBrowserTest.MANUAL_TestVideoQualityH264/1
...
#
# Fatal error in e:\b\c\b\win_builder\src\third_party\webrtc\modules\rtp_rtcp\source\rtp_format_h264.cc, line 170
# last system error: 0
# Check failed: packetization_mode_ == kH264PacketizationMode1 (0 vs. 2)
#
Original issue's description:
> Implement H.264 packetization mode 0.
>
> This approach extends the H.264 specific information with
> a packetization mode enum.
>
> Status: Parameter is in code. No way to set it yet.
>
> Rebase of CL 2009213002
>
> BUG=600254
>
> Committed: https://crrev.com/3bba101f36483b8030a693dfbc93af736d1dba68
> Cr-Commit-Position: refs/heads/master@{#15032}
TBR=hbos@webrtc.org,sprang@webrtc.org,mflodman@webrtc.org,hta@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=600254
NOPRESUBMIT=true
Review-Url: https://codereview.webrtc.org/2500743002
Cr-Commit-Position: refs/heads/master@{#15050}
Reason for revert:
Relanding, now that downstream issues have been fixed.
Original issue's description:
> Revert of Declare VideoCodec.codec_specific_info private (patchset #5 id:80001 of https://codereview.webrtc.org/2452963002/ )
>
> Reason for revert:
> Broke a google3 build
>
> Original issue's description:
> > Declare VideoCodec.codec_specific_info private
> >
> > This completes the privatization of the codec specific
> > information in VideoCodec.
> >
> > BUG=webrtc:6603
> >
> > Committed: https://crrev.com/792738640234d81c916ac4458ac72286cb2548a4
> > Cr-Commit-Position: refs/heads/master@{#15013}
>
> TBR=tommi@chromium.org,magjed@chromium.org,tommi@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:6603
>
> Committed: https://crrev.com/7fe6db91d99cf6d43874651bcca56092cf869e2f
> Cr-Commit-Position: refs/heads/master@{#15027}
TBR=tommi@chromium.org,magjed@chromium.org,tommi@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6603
Review-Url: https://codereview.webrtc.org/2494683006
Cr-Commit-Position: refs/heads/master@{#15041}
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}
This approach extends the H.264 specific information with
a packetization mode enum.
Status: Parameter is in code. No way to set it yet.
Rebase of CL 2009213002
BUG=600254
Review-Url: https://codereview.webrtc.org/2337453002
Cr-Commit-Position: refs/heads/master@{#15032}
Reason for revert:
Broke a google3 build
Original issue's description:
> Declare VideoCodec.codec_specific_info private
>
> This completes the privatization of the codec specific
> information in VideoCodec.
>
> BUG=webrtc:6603
>
> Committed: https://crrev.com/792738640234d81c916ac4458ac72286cb2548a4
> Cr-Commit-Position: refs/heads/master@{#15013}
TBR=tommi@chromium.org,magjed@chromium.org,tommi@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6603
Review-Url: https://codereview.webrtc.org/2491933002
Cr-Commit-Position: refs/heads/master@{#15027}
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}
This completes the privatization of the codec specific
information in VideoCodec.
BUG=webrtc:6603
Review-Url: https://codereview.webrtc.org/2452963002
Cr-Commit-Position: refs/heads/master@{#15013}
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}
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}
- Change const ptr to const ref in parameter list.
Using nullptr as argument was invalid, so no need to send
pointer instead of reference.
- Change return type to void or bool, where appropriate
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2455963003
Cr-Commit-Position: refs/heads/master@{#14945}
Prior to this change, we signalled that ULPFEC was disabled
through a bool, but that RED was disabled by setting its
payload type to -1. The latter is consistent with how we
disable RED/ULPFEC in the config, so this CL removes the
ULPFEC bool from the {,Set}UlpfecConfig chain of member
functions.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2460533002
Cr-Commit-Position: refs/heads/master@{#14944}
At the same time, change to using int's instead of uint8_t's for the payload type.
This allows us to signal disabled FEC or RED using the sentinel value -1, which
is commonplace in other parts of the code.
These APIs will be deprecated when ULPFEC is deprecated.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2448463003
Cr-Commit-Position: refs/heads/master@{#14942}
Removed EncodedImageCallback::Encoded() and RtpRtcp::SendOutgoingData().
These methods should no longer be used anywhere and it's safe to remove
them.
BUG=chromium:621691
Committed: https://crrev.com/c681250aaa2025836db7669694e323898e5c2ca7
Review-Url: https://codereview.webrtc.org/2405173006
Cr-Original-Commit-Position: refs/heads/master@{#14923}
Cr-Commit-Position: refs/heads/master@{#14935}
Reason for revert:
Still breaks internal downstream project.
Sergey: Please update internal project before relanding this.
Original issue's description:
> Remove deprected functions from EncodedImageCallback and RtpRtcp
>
> Removed EncodedImageCallback::Encoded() and RtpRtcp::SendOutgoingData().
> These methods should no longer be used anywhere and it's safe to remove
> them.
>
> BUG=chromium:621691
>
> Committed: https://crrev.com/c681250aaa2025836db7669694e323898e5c2ca7
> Cr-Commit-Position: refs/heads/master@{#14923}
TBR=mflodman@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=chromium:621691
Review-Url: https://codereview.webrtc.org/2479643002
Cr-Commit-Position: refs/heads/master@{#14925}
Removed EncodedImageCallback::Encoded() and RtpRtcp::SendOutgoingData().
These methods should no longer be used anywhere and it's safe to remove
them.
BUG=chromium:621691
Review-Url: https://codereview.webrtc.org/2405173006
Cr-Commit-Position: refs/heads/master@{#14923}
