FlexfecSender is owned and configured by VideoSendStream.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2501503003
Cr-Commit-Position: refs/heads/master@{#15082}
This is undefined behavior, according to specification.
BUG=chromium:661133
Review-Url: https://codereview.webrtc.org/2500953003
Cr-Commit-Position: refs/heads/master@{#15078}
In DxgiOutputDuplicator, we need to convert between a monitor based coordinate
and a entire screen based coordinate. i.e. Copying an updated area from a
monitor (an output in DirectX API) to the entire screen frame (DesktopFrame).
But DxgiOutputDuplicator always assumes the coordinate is based on screen frame.
So we only need to convert a rectange in updated_region to monitor based
coordinate when copying data from texture_. But in last_frame_, the data are
always based on screen coordinate.
So fixes are both required in line 167 and line 180. In the previous one, we do
not need to convert the DesktopRect, which is already screen based, into screen
based coordinate. In the late one, we do not need to convert the DesktopRect at
all. So after these two changes, DxgiOutputDuplicator::TargetRect() function can
be removed.
Flickers of DirectX capturer can happen on any devices, but a virtual machine
can easily reproduce it. While on a regular high performance machine, it's
harder, but not totally impossible, to reproduce the issue.
BUG=314516
Review-Url: https://codereview.webrtc.org/2495143002
Cr-Commit-Position: refs/heads/master@{#15075}
Previously when BitrateControllerImpl::OnDelayBasedBweResult() is
called as result of a probe it was calling
bandwidth_estimation_.SetSendBitrate(), but not
UpdateDelayBasedEstimate(). As result SendSideBandwidthEstimation was
effectively ignoring probe results as it kept the old
delay_based_bitrate_bps_ value, which caps the resulting bitrate.
BUG=webrtc:6332,webrtc:6710
Review-Url: https://codereview.webrtc.org/2481383002
Cr-Commit-Position: refs/heads/master@{#15071}
This can happen in rare and strange cases.
Also taking the opportunity to replace all asserts with DCHECKs in
that file.
BUG=chromium:659225
Review-Url: https://codereview.webrtc.org/2499013002
Cr-Commit-Position: refs/heads/master@{#15070}
This adds two command-line flags to audioproc_f: -red and -red_graph, which can be used to enable/disable the RED, and to set the output path for the graph. The graph is generated as a python script that depends on matplotlib and numpy to display the graph.
BUG=webrtc:6525
Review-Url: https://codereview.webrtc.org/2486763002
Cr-Commit-Position: refs/heads/master@{#15069}
Prior to this change, FlexFEC packets that were paced would be lost in
the RTPSender, since they were not stored in a packet history. This CL
introduces such a packet history, as well as the needed wireup for
higher layers to be aware that the particular RTPSender is able to
send FlexFEC packets with a particular SSRC.
Updated RTPSender unit test to reflect the fact that paced packets
are now actually sent.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2491293002
Cr-Commit-Position: refs/heads/master@{#15066}
Updates GetStats() function in AudioSendStream to use the new GetStatistics function in APM instead of the corresponding VoE functions.
BUG=webrtc:6525
Review-Url: https://codereview.webrtc.org/2463813002
Cr-Commit-Position: refs/heads/master@{#15065}
The only difference is that the F and R bits have changed place.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2495253002
Cr-Commit-Position: refs/heads/master@{#15064}
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}
This is a trivial change to remove MockScreenCapturerCallback, and use
MockDesktopCapturerCallback to replace it.
BUG=webrtc:6513
Review-Url: https://codereview.webrtc.org/2494013003
Cr-Commit-Position: refs/heads/master@{#15047}
A tiny but critical change to avoid a crash failure in DirectX capturer.
A good news is this failure is caught by ScreenCapturer integration tests.
BUG=314516
Review-Url: https://codereview.webrtc.org/2494893002
Cr-Commit-Position: refs/heads/master@{#15046}
The old CroppingWindowCapturer::Create() function returns a raw pointer, which
cannot explain the ownership.
So this change adds a CreateCapturer() function to return a unique_ptr.
BUG=webrtc:6513
Review-Url: https://codereview.webrtc.org/2496993003
Cr-Commit-Position: refs/heads/master@{#15045}
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 change removes ScreenCapturer and WindowCapturer from WebRTC.
BUG=webrtc:6513
Review-Url: https://codereview.webrtc.org/2490063002
Cr-Commit-Position: refs/heads/master@{#15033}
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}
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:
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}
The likelihood is logged as a percentage, with 100 bins in the histogram.
BUG=webrtc:6525
Review-Url: https://codereview.webrtc.org/2487243002
Cr-Commit-Position: refs/heads/master@{#15025}
Due to bugs.webrtc.org/216 code that includes
//webrtc/modules/audio_device:mock_audio_device fails to compile on
Windows unless a warning flag is switched off. It seems that
googlemock changes types of overridden virtual method parameters from
'const int' to 'int', which causes the VS compiler to report an error.
The problem was not solved by suppressing the flag wd4373 in
//webrtc/modules/audio_device:mock_audio_device, because targets that
include the headers are compiled separately.
This CL adds the flag suppression to the GN variable
|all_dependent_configs|. Then GN will apply the configuration to all
reachable dependencies. This is needed to reduce clutter and extra
conditions in dependency build targets.
The reason for |all_dependent_configs| before |public_configs| is
for a situation in which a targets headers include the headers from
this target. Then dependencies of dependencies will have a copy of
this targets' code after preprocessing, and compilation will fail.
This will happen if we e.g. change mock_voice_engine to return a
MockAudioTransport or MockAudioDevice.
This change has been tested by compiling a dependent CL
(https://codereview.webrtc.org/2454373002/) which uses these mocks
on Windows without suppressing the flag.
There is no GYP change, because test code has been removed from GYP.
NOTRY=True
BUG=webrtc:216
Review-Url: https://codereview.webrtc.org/2492713003
Cr-Commit-Position: refs/heads/master@{#15024}
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 is not the right place for a SequencedTaskChecker, as we can
not make any guarantees about the thread this method runs on.
We were hitting this check on Android and iOS whenever the encoder
would be reconfigured. Access to these ivars should be guarded
by a lock.
As a bonus, an unused method declaration was removed.
BUG=webrtc:6686
Review-Url: https://codereview.webrtc.org/2495483002
Cr-Commit-Position: refs/heads/master@{#15019}
This CL adds the ability for RTPSenderVideo to generate and send
FlexFEC packets.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2490523002
Cr-Commit-Position: refs/heads/master@{#15016}
There are currently two nearly identical classes called
MockAudioTransport defined in two unit tests:
android/audio_transport_unittest.cc and
/ios/audio_transport_unittest_ios.cc
This change defines a common mocked AudioTransport. The two current
mocks are rewritten to use the common one. A GN target is created for
this mock and MockAudioDevice.
This change will allow to provide a mocked AudioTransport to
AudioState in a dependent CL https://codereview.webrtc.org/2454373002/
BUG=webrtc:6346
NOPRESUBMIT=True
Review-Url: https://codereview.webrtc.org/2493483002
Cr-Commit-Position: refs/heads/master@{#15010}
This change removes references of ScreenCapturer and WindowCapturer from WebRTC.
So after this change, ScreenCapturer and WindowCapturer classes can be entirely
removed.
BUG=webrtc:6513
Review-Url: https://codereview.webrtc.org/2489943004
Cr-Commit-Position: refs/heads/master@{#15006}
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}
Reason for revert:
Fix gyp build
Original issue's description:
> Revert of Add a webrtc{en,de}coderfactory implementation for VideoToolbox (patchset #2 id:20001 of https://codereview.webrtc.org/2463313002/ )
>
> Reason for revert:
> Broke dependent project because the .gn changes weren't accompanied by corresponding .gyp changes.
>
> Original issue's description:
> > Add a webrtc{en,de}coderfactory implementation for VideoToolbox
> >
> > This CL removes the coupling of the VideoToolbox h264 implementation
> > to the generic h264 code. The files have been moved into sdb/obj/Framework
> > and all dependency on them has been removed from the rest of WebRTC.
> > We now add it as an external encoder via a factory supplied to the
> > CreatePeerConnectionFactory call. This also brings the iOS implementation
> > closer to what we do on Android for MediaCodec.
> >
> > BUG=webrtc:6619
> >
> > Committed: https://crrev.com/6a5047dad31f14f53dd9f8bc1ecde19e1dede2e4
> > Cr-Commit-Position: refs/heads/master@{#14953}
>
> TBR=magjed@webrtc.org,stefan@webrtc.org,kthelgason@webrtc.org
> BUG=webrtc:6619
>
> Committed: https://crrev.com/d69ad84420d9c0e1c11450c352f6c92e7c9583f1
> Cr-Commit-Position: refs/heads/master@{#14985}
R=magjed@webrtc.orgTBR=kwiberg@webrtc.org, magjed@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:6619
Review URL: https://codereview.webrtc.org/2487723004 .
Cr-Commit-Position: refs/heads/master@{#14992}
This is a trivial but dangerous change to remove X11/Xlib.h out of
shared_x_display.h. Since we do not have a strict and automatically
Include-What-You-Use rule, I cannot quite tell whether any Chromium source files
wrongly assume X11/Xlib.h will be included through shared_x_display.h. We can
fix the breaks in Chromium after this change has been failed to integrate to
Chromium.
BUG=webrtc:6513
Review-Url: https://codereview.webrtc.org/2482963003
Cr-Commit-Position: refs/heads/master@{#14987}
Reason for revert:
Broke dependent project because the .gn changes weren't accompanied by corresponding .gyp changes.
Original issue's description:
> Add a webrtc{en,de}coderfactory implementation for VideoToolbox
>
> This CL removes the coupling of the VideoToolbox h264 implementation
> to the generic h264 code. The files have been moved into sdb/obj/Framework
> and all dependency on them has been removed from the rest of WebRTC.
> We now add it as an external encoder via a factory supplied to the
> CreatePeerConnectionFactory call. This also brings the iOS implementation
> closer to what we do on Android for MediaCodec.
>
> BUG=webrtc:6619
>
> Committed: https://crrev.com/6a5047dad31f14f53dd9f8bc1ecde19e1dede2e4
> Cr-Commit-Position: refs/heads/master@{#14953}
TBR=magjed@webrtc.org,stefan@webrtc.org,kthelgason@webrtc.org
BUG=webrtc:6619
Review-Url: https://codereview.webrtc.org/2483273002
Cr-Commit-Position: refs/heads/master@{#14985}
The new format for plot lines is PLOT <plot_no> <var_name>:<ssrc>@<alg_name> <time> <value>. The var_name is no longer prefixed by the context/tag (which most of the time was just the same as the test name.)
Update plot_dynamics.py script (which didn't work) to visualize the new BWE_TEST_LOGGING_PLOT lines.
BUG=webrtc:6621
Review-Url: https://codereview.webrtc.org/2456373002
Cr-Commit-Position: refs/heads/master@{#14983}
This change changes mixing to be done at the lowest possible
APM-native rate that does not lead to quality loss. An Audio
Processing-native rate is one of 8, 16, 32, or 48 kHz. Mixing at a
lower sampling rate and avoiding resampling can in many cases lead to
big efficiency improvements, as reported by experiments.
This CL also fixes a design issue with the AudioMixer: audio at
non-native rates is no longer fed to the APM instance which is the
limiter.
NOTRY=True
BUG=webrtc:6346
Review-Url: https://codereview.webrtc.org/2458703002
Cr-Commit-Position: refs/heads/master@{#14980}
I have no idea how bad it is that we're hitting this limit; I'm just
doing this to stop the tests from flaking.
BUG=webrtc:6484
Review-Url: https://codereview.webrtc.org/2477663002
Cr-Commit-Position: refs/heads/master@{#14974}
D3D_FEATURE_LEVEL_11_0 is not offically documented on MSDN to be a requirement
of DXGI duplicator APIs. So instead of using D3D_FEATURE_LEVEL_11_0 as a
requirement in D3dDevice::Initialize(), this change adds a
ScreenCapturerWinDirectx::SupportedFeatureLevel() function to retrieves minimum
and maximium for further reference (in HostTraits to control the experiment).
BUG=314516
Review-Url: https://codereview.webrtc.org/2468083002
Cr-Commit-Position: refs/heads/master@{#14962}
