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}
Before this change, the configuration logic in FlexfecReceiveStream
tried to make unsupported configurations work, e.g., by dropping the
protection of some media streams when multiple media streams were
protected by a single FlexFEC stream. This CL makes the configuration logic
return more errors on such unsupported configurations.
This harmonizes the logic with the new configuration logic in
VideoSendStream, for the FlexfecSender.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2499963002
Cr-Commit-Position: refs/heads/master@{#15083}
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}
Also extract all iOS sources into a static library configuration
so it's easier to include them in the test target as well.
Also, fix a wrong test that was undiscovered because the
tests were not running
BUG=webrtc:6707
Review-Url: https://codereview.webrtc.org/2502623002
Cr-Commit-Position: refs/heads/master@{#15076}
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}
- 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}
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}
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}
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}
DataChannel.SignalOpened and unittests added.
PeerConnection.SignalDataChannelCreated added and wired up to
RTCStatsCollector.OnDataChannelCreated on RTCStatsCollector
construction.
RTCStatsCollector.OnSignalOpened/Closed added and wired up on
OnDataChannelCreated.
rtcstatscollector_unittest.cc updated, faking that channels are opened
and closed.
I did not want to use DataChannelObserver because it is used for more
than state changes and there can only be one observer (unless code is
updated). Since DataChannel already had a SignalClosed it made sense to
add a SignalOpened.
Having OnSignalBlah in RTCStatsCollector is new in this CL but will
likely be needed to correctly handle RTPMediaStreamTracks being added
and detached independently of getStats. This CL establishes this
pattern.
(An integration test will be needed for this and all the other stats to
make sure everything is wired up correctly and test outside of a
mock/fake environment, but this is not news.)
BUG=chromium:636818, chromium:627816
Review-Url: https://codereview.webrtc.org/2472113002
Cr-Commit-Position: refs/heads/master@{#15059}
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}
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}
We want to keep these warnings on. They were switched off temporarily
to unblock chromium roll.
BUG=webrtc:6520
Review-Url: https://codereview.webrtc.org/2493873005
Cr-Commit-Position: refs/heads/master@{#15043}
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}
These functions currently copy cricket::Codec classes by value which is
expensive since they contain e.g. std::map<std::string, std::string>
containers with parameters. This CL avoids copying them altogether.
BUG=webrtc:6337
Review-Url: https://codereview.webrtc.org/2493733003
Cr-Commit-Position: refs/heads/master@{#15040}
Reason for revert:
Relanding after known downstream breakages have been fixed.
Original issue's description:
> Revert of Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame. (patchset #7 id:120001 of https://codereview.webrtc.org/2383093002/ )
>
> Reason for revert:
> Breaks chrome, see https://build.chromium.org/p/chromium.webrtc.fyi/builders/Mac%20Builder/builds/19019/steps/compile/logs/stdio
>
> Analysis: Chrome uses cricket::VideoFrame, without explicitly including webrtc/media/base/videoframe.h, and breaks when that file is no longer included by any other webrtc headers. Will reland after updating Chrome.
>
> Original issue's description:
> > Delete all use of cricket::VideoFrame and cricket::WebRtcVideoFrame.
> >
> > Replaced with webrtc::VideoFrame.
> >
> > TBR=mflodman@webrtc.org
> > BUG=webrtc:5682
> >
> > Committed: https://crrev.com/45c8b8940042bd2574c39920804ade8343cefdba
> > Cr-Commit-Position: refs/heads/master@{#14885}
>
> TBR=perkj@webrtc.org,pthatcher@webrtc.org,tkchin@webrtc.org,mflodman@webrtc.org,stefan@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:5682
>
> Committed: https://crrev.com/7341ab8e2505c9763d208e069bda269018357e7d
> Cr-Commit-Position: refs/heads/master@{#14886}
TBR=perkj@webrtc.org,pthatcher@webrtc.org,tkchin@webrtc.org,mflodman@webrtc.org,stefan@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:5682
Review-Url: https://codereview.webrtc.org/2487633002
Cr-Commit-Position: refs/heads/master@{#15039}
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:
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}
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}
