- 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}
Call demultiplexes received RTP packets and delivers these to the
appropriate {Video,Flexfec}ReceiveStreams. A single video stream
could conceivably be protected by multiple FlexFEC streams.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2388303009
Cr-Commit-Position: refs/heads/master@{#14727}
Reason for revert:
Flaky test has been fixed.
Original issue's description:
> Revert of Add path for recovered packets from internal::Call to RtpStreamReceiver. (patchset #2 id:60001 of https://codereview.webrtc.org/2390823009/ )
>
> Reason for revert:
> Speculative revert as it may be the cause of the DrMemory test failure:
> https://build.chromium.org/p/client.webrtc/builders/Win%20DrMemory%20Full/builds/5115
>
> Original issue's description:
> > Add path for recovered packets from internal::Call to RtpStreamReceiver.
> >
> > When the FlexfecReceiver recovers media packets, it inserts these into
> > internal::Call, which then distributes them to the appropriate
> > VideoReceiveStream/RtpStreamReceiver.
> >
> > BUG=webrtc:5654
> >
> > Committed: https://crrev.com/9c4b4b47f4325b48e1856566a30983f9e4e30dd0
> > Cr-Commit-Position: refs/heads/master@{#14642}
>
> TBR=stefan@webrtc.org,brandtr@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:5654
>
> Committed: https://crrev.com/862d74d0176fa762b3c96cf20bd36f27e7001a47
> Cr-Commit-Position: refs/heads/master@{#14652}
TBR=stefan@webrtc.org,honghaiz@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2428303004
Cr-Commit-Position: refs/heads/master@{#14677}
Reason for revert:
Speculative revert as it may be the cause of the DrMemory test failure:
https://build.chromium.org/p/client.webrtc/builders/Win%20DrMemory%20Full/builds/5115
Original issue's description:
> Add path for recovered packets from internal::Call to RtpStreamReceiver.
>
> When the FlexfecReceiver recovers media packets, it inserts these into
> internal::Call, which then distributes them to the appropriate
> VideoReceiveStream/RtpStreamReceiver.
>
> BUG=webrtc:5654
>
> Committed: https://crrev.com/9c4b4b47f4325b48e1856566a30983f9e4e30dd0
> Cr-Commit-Position: refs/heads/master@{#14642}
TBR=stefan@webrtc.org,brandtr@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2427733002
Cr-Commit-Position: refs/heads/master@{#14652}
When the FlexfecReceiver recovers media packets, it inserts these into
internal::Call, which then distributes them to the appropriate
VideoReceiveStream/RtpStreamReceiver.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2390823009
Cr-Commit-Position: refs/heads/master@{#14642}
Reason for revert:
Speculative revert.
Intermittent memory access errors suspected to be caused by this cl.
See for instance https://build.chromium.org/p/client.webrtc/builders/Win%20DrMemory%20Light/builds/8018
UNADDRESSABLE ACCESS of freed memory: reading 0x0331d330-0x0331d334 4 byte(s)
# 0 webrtc::voe::RtcpRttStatsProxy::LastProcessedRtt
# 1 webrtc::ModuleRtpRtcpImpl::Process
Original issue's description:
> Add RtcpRttStats to AudioStream
>
> BUG=webrtc:6508
>
> Committed: https://crrev.com/e0729c56d35acfaf9738fdb32c6508cd78eaf089
> Cr-Commit-Position: refs/heads/master@{#14595}
TBR=stefan@webrtc.org,minyue@webrtc.org,solenberg@webrtc.org,michaelt@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:6508
Review-Url: https://codereview.webrtc.org/2415943002
Cr-Commit-Position: refs/heads/master@{#14631}
This CL is a pure refactoring which should not result in any functinal
changes. It moves ownership of the RtcEventLog from webrtc::Call to the
webrtc::PeerConnection object.
This is done so that we can add RtcEventLog support for ICE events -
which will require the TransportController to have a pointer to the
RtcEventLog. PeerConnection is the closest common owner of both Call and
TransportController (through WebRtcSession).
BUG=webrtc:6393
Review-Url: https://codereview.webrtc.org/2353033005
Cr-Commit-Position: refs/heads/master@{#14578}
The RtcEventLog headers need to be accessible from any place which needs
logging, and the implementation needs access to data structures that are
logged.
After a discussion in the code review, we all agreed to move the RtcEventLog implementation into its own top level directory - which I called "logging/" in expectation that other types of logging may have similar requirements. The directory contains two main build targets - "rtc_event_log_api", which is just rtc_event_log.h, that has no external dependencies and can be used from anywhere, and "rtc_event_log_impl" which contains the rest of the implementation and has many dependencies (more in the future).
The "api" target can be referenced from anywhere, while the "impl" target is only needed at the place of instantiation (currently Call, soon to be moved to PeerConnection by https://codereview.webrtc.org/2353033005/).
This change allows using RtcEventLog in the p2p/ directory, so that we
can log STUN pings and ICE state transitions.
BUG=webrtc:6393
R=kjellander@webrtc.org, kwiberg@webrtc.org, solenberg@webrtc.org, stefan@webrtc.org, terelius@webrtc.org
Review URL: https://codereview.webrtc.org/2380683005 .
Cr-Commit-Position: refs/heads/master@{#14485}
This includes if RTCP is received, but the number of packets received by the
other end hasn't increased.
Further, if no RTCP is received for more than 3 feedback intervals (3 seconds)
we start reducing the estimate by 20%. This is put under an experiment.
BUG=webrtc:6238
R=terelius@webrtc.org
Review URL: https://codereview.webrtc.org/2262213002 .
Cr-Commit-Position: refs/heads/master@{#14306}
Integrate AvgCounter to be used for BWE stats in call.
Fixes for stats regression in:
WebRTC.Call.EstimatedSendBitrateInKbps
WebRTC.Call.PacerBitrateInKbps
Example:
BWE for a 15 seconds long call (with intervals of 1 sec):
|300|400|500|600|600|600|600| 0 | 0 | 0 | 0 | 0 |800|800|800| // 0 - network state down
Reported via OnNetworkChanged:
|300|400|500|600| x | x | x | 0 | x | x | x | x |800| x | x | // x - empty interval, 0 -> pauses stats
Stats:
|300|400|500|600|600|600|600| - | - | - | - | - |800|800|800| // x -> last value used (intervals during pause ignored)
AvgCounter uses the average of samples within an interval (interval length is 2 sec).
BUG=webrtc:6244
Review-Url: https://codereview.webrtc.org/2307913002
Cr-Commit-Position: refs/heads/master@{#14147}
"WebRTC.Call.BitrateReceivedInKbps"
"WebRTC.Call.VideoBitrateReceivedInKbps"
"WebRTC.Call.AudioBitrateReceivedInKbps"
"WebRTC.Call.RtcpBitrateReceivedInBps"
Reports the average of periodically computed bitrates over a call (2 sec interval). Adds possibility to later modify the stats and use/report the periodic bitrates.
BUG=webrtc:5283
Review-Url: https://codereview.webrtc.org/2303763002
Cr-Commit-Position: refs/heads/master@{#14119}
cl was originally reviewed here:
https://codereview.webrtc.org/2060403002/
- Add task queue to Call with the intent of replacing the use of one of the process threads.
- Split VideoSendStream in two. VideoSendStreamInternal is created and used on the new task queue.
- BitrateAllocator is now created on libjingle's worker thread but always used on the new task queue instead of both encoder threads and the process thread.
- VideoEncoderConfig and VideoSendStream::Config support move semantics.
- The encoder thread is moved from VideoSendStream to ViEEncoder. Frames are forwarded directly to ViEEncoder which is responsible for timestamping ? and encoding the frames.
TBR=mflodman@webrtc.org
BUG=webrtc:5687
Review-Url: https://codereview.webrtc.org/2250123002
Cr-Commit-Position: refs/heads/master@{#14014}
Reason for revert:
Failed on Win 10 Chrome FYI.
https://build.chromium.org/p/chromium.webrtc.fyi/builders/Win10%20Tester/builds/3847/steps/content_browsertests/logs/stdio
#
# Fatal error in e:\b\c\b\win_builder\src\third_party\webrtc\base\task_queue_win.cc, line 138
# last system error: 87
# Check failed: ((DWORD)0xFFFFFFFF) != result (4294967295 vs. 4294967295)
#
WebRtcBrowserTest
#
Original issue's description:
> - Add task queue to Call with the intent of replacing the use of one of the process threads.
>
> - Split VideoSendStream in two. VideoSendStreamInternal is created and used on the new task queue.
>
> - BitrateAllocator is now created on libjingle's worker thread but always used on the new task queue instead of both encoder threads and the process thread.
>
> - VideoEncoderConfig and VideoSendStream::Config support move semantics.
>
> - The encoder thread is moved from VideoSendStream to ViEEncoder. Frames are forwarded directly to ViEEncoder which is responsible for timestamping ? and encoding the frames.
>
> BUG=webrtc:5687
>
> Committed: https://crrev.com/cc168360f41322332860cb075edeb1cde21aa473
> Cr-Commit-Position: refs/heads/master@{#13767}
TBR=tommi@webrtc.org,mflodman@webrtc.org,stefan@webrtc.org,sprang@webrtc.org,pbos@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5687
Review-Url: https://codereview.webrtc.org/2248713003
Cr-Commit-Position: refs/heads/master@{#13774}
- Split VideoSendStream in two. VideoSendStreamInternal is created and used on the new task queue.
- BitrateAllocator is now created on libjingle's worker thread but always used on the new task queue instead of both encoder threads and the process thread.
- VideoEncoderConfig and VideoSendStream::Config support move semantics.
- The encoder thread is moved from VideoSendStream to ViEEncoder. Frames are forwarded directly to ViEEncoder which is responsible for timestamping ? and encoding the frames.
BUG=webrtc:5687
Review-Url: https://codereview.webrtc.org/2060403002
Cr-Commit-Position: refs/heads/master@{#13767}
This is a first CL wiring up AudioSendStream to BitrateAllocator. This
is still experimental and there is a test added for the audio only case,
combined audio video variable bitrate test cases will be added as a
follow up.
BUG=5079
Review-Url: https://codereview.webrtc.org/2165743003
Cr-Commit-Position: refs/heads/master@{#13527}
Don't update histograms until we're sure process threads won't call into
the instance being destructed, trying to update stats.
BUG=webrtc:6103
Review-Url: https://codereview.webrtc.org/2151433002
Cr-Commit-Position: refs/heads/master@{#13461}
A recent refactoring (r13192) introduced a bug where the min transmit
config wasn't being respected. Specifically, if a VideoSendStream was
created without it and the reconfigured, the min transmit bitrate would
not take effect. Probably the other way around as well.
BUG=webrtc::5687
Review-Url: https://codereview.webrtc.org/2106183002
Cr-Commit-Position: refs/heads/master@{#13390}
Reason for revert:
Reverting all CLs related to moving the eventlog, as they break Chromium tests.
Original issue's description:
> Move RtcEventLog object from inside VoiceEngine to Call.
>
> In addition to moving the logging object itself, this also moves the interface from PeerConnectionFactory to PeerConnection, which makes more sense for this functionality. An API parameter to set an upper limit to the size of the logfile is introduced.
> The old interface on PeerConnectionFactory is not removed in this CL, because it is called from Chrome, it will be removed after Chrome is updated to use the PeerConnection interface.
>
> BUG=webrtc:4741,webrtc:5603,chromium:609749
> R=solenberg@webrtc.org, stefan@webrtc.org, terelius@webrtc.org, tommi@webrtc.org
>
> Committed: https://crrev.com/1895526c6130e3d0e9b154f95079b8eda7567016
> Cr-Commit-Position: refs/heads/master@{#13321}
TBR=solenberg@webrtc.org,tommi@webrtc.org,stefan@webrtc.org,terelius@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:4741,webrtc:5603,chromium:609749
Review-Url: https://codereview.webrtc.org/2111813002
Cr-Commit-Position: refs/heads/master@{#13340}
In addition to moving the logging object itself, this also moves the interface from PeerConnectionFactory to PeerConnection, which makes more sense for this functionality. An API parameter to set an upper limit to the size of the logfile is introduced.
The old interface on PeerConnectionFactory is not removed in this CL, because it is called from Chrome, it will be removed after Chrome is updated to use the PeerConnection interface.
BUG=webrtc:4741,webrtc:5603,chromium:609749
R=solenberg@webrtc.org, stefan@webrtc.org, terelius@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1748403002 .
Cr-Commit-Position: refs/heads/master@{#13321}
Reason for revert:
It turns out this revert was not necessary because the connection-state mapping for turn-turn connections was not done in connection.
Original issue's description:
> Revert of Revert "Revert of Update the BWE when the network route changes. (patchset #5 id:180001 of https://… (patchset #5 id:120001 of https://codereview.webrtc.org/2041593002/ )
>
> Reason for revert:
> ReadyToSendMedia did not consider the new presumed_writable state.
>
> Original issue's description:
> > Revert "Revert of Update the BWE when the network route changes. (patchset #5 id:180001 of https://codereview.webrtc.org/2000063003/ )"
> >
> > This reverts commit 72d41aa6da94dacb8a8464d1abd4ca7d1afffc65.
> >
> > New change made:
> > Do not reset the BWE when the new network route is not ready to send media.
> >
> > BUG=
> > R=pthatcher@webrtc.org, stefan@webrtc.org
> >
TBR=pthatcher@webrtc.org,stefan@webrtc.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review-Url: https://codereview.webrtc.org/2094863003
Cr-Commit-Position: refs/heads/master@{#13282}
Reason for revert:
ReadyToSendMedia did not consider the new presumed_writable state.
Original issue's description:
> Revert "Revert of Update the BWE when the network route changes. (patchset #5 id:180001 of https://codereview.webrtc.org/2000063003/ )"
>
> This reverts commit 72d41aa6da94dacb8a8464d1abd4ca7d1afffc65.
>
> New change made:
> Do not reset the BWE when the new network route is not ready to send media.
>
> BUG=
> R=pthatcher@webrtc.org, stefan@webrtc.org
>
> Committed: https://crrev.com/5b5d2cdad7018993272525a723ef34f7da5c45f2
> Cr-Commit-Position: refs/heads/master@{#13280}
TBR=pthatcher@webrtc.org,stefan@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review-Url: https://codereview.webrtc.org/2098703004
Cr-Commit-Position: refs/heads/master@{#13281}
1. It moves calculation of the needed padding to VideoSendStream instead of ViEEncoder and only does it once per send Stream instead of every time the network estimate changes.
2. The maximum amount of padding sent was prior to this cl calculated and updated based on network estimate changes. However, it can only change based on encoder configuration changes and if send streams are added or removed. This cl change the VideoSendStream/VieEncoder to notify the BitrateAllocator of changes to the needed padding bitrate and for BitrateAllocator to notify Call of these changes.
3. Fixed an issue in the SendPacer where it could send a padding packet before sending a real packet. This caused the test EndToEndTest.RestartingSendStreamPreservesRtpStatesWithRtx to fail with these refactorings since the pacer suddenly could send a padding packet before the encoder had produced its first frame.
BUG=webrtc:5687
Review-Url: https://codereview.webrtc.org/1993113003
Cr-Commit-Position: refs/heads/master@{#13149}
Instead of the default copy constructor, the Copy() method has to be used. In this CL, the number of copies has been reduced significantly in production code. One case in the video engine remains, where we need to restart a video stream. Even in that case, I'm sure we could avoid it, but for this particular CL, I decided against it to keep things simple (and it's also an edge case). Most importantly, creating copies is made harder and the interface encourages ownership transfers.
R=mflodman@webrtc.org, pbos@webrtc.org
Review URL: https://codereview.webrtc.org/2042603002 .
Cr-Commit-Position: refs/heads/master@{#13102}
This CL implements auto pausing video streams per stream with logic to
avoid toggling state too often.
Also re-enabling tests disabled for Mac, with the assumption the new
logic removes flakiness.
BUG=webrtc:5868,webrtc:5407
R=pbos@webrtc.org, stefan@webrtc.org
Review URL: https://codereview.webrtc.org/2035383002 .
Cr-Commit-Position: refs/heads/master@{#13092}
Also set the Configuration parameters in CreateRtpRtcpModules in the same order as the members are declared.
BUG=webrtc:5917
Review-Url: https://codereview.webrtc.org/2011433002
Cr-Commit-Position: refs/heads/master@{#12905}
This reverts commit e30c27205148b34ba421184efe65f6a0780b436d (https://codereview.webrtc.org/1958053002/)
Original reverted cl is in patch set #1.
Changes in following patch sets.
The cl now also make sure SendPacer starts with the configured bitrate provided in a call to CongestionController::SetBweBitrates)()
It turns out that the failing tests in 609816 is due to a bug in the current code that runs the proper at 300kbit regardless of configured start bitrate.
Original cl description:
Remove SendPacer from ViEEncoder
This CL moves the logic where the ViEEncoder pause if the pacer is full to the BitrateController. If the queue is full, the controller reports a bitrate of zero to Call (and BitrateAllocator)
BUG=chromium:609816, webrtc:5687
TBR=mflodman@webrtc.org
NOTRY=True // Due to bug in android_x86 cq builder....
Review-Url: https://codereview.webrtc.org/1958113003
Cr-Commit-Position: refs/heads/master@{#12688}
This reverts commit 825eb58d59940a4c3c9837595c4b3b07059c93ca.
This Relands the cl reviewed in https://codereview.webrtc.org/1917793002/
patchset #1 is a pure reland.
patchset #2 fix an overflow in BitrateProber that caused WebRtcVideoChannel2BaseTest.TwoStreamsSendAndReceive to fail.
Original cl description:
Remove SendPacer from ViEEncoder
This CL moves the logic where the ViEEncoder pause if the pacer is full to the BitrateController. If the queue is full, the controller reports a bitrate of zero to Call (and BitrateAllocator)
R=stefan@webrtc.orgTBR=mflodman@webrtc.org
BUG=webrtc:5687
Review URL: https://codereview.webrtc.org/1947873002 .
Cr-Commit-Position: refs/heads/master@{#12630}
This CL moves the logic where the ViEEncoder pause if the pacer is full to the BitrateController. If the queue is full, the controller reports a bitrate of zero to Call (and BitrateAllocator)
BUG=webrtc:5687
Review-Url: https://codereview.webrtc.org/1917793002
Cr-Commit-Position: refs/heads/master@{#12620}
- "WebRTC.Video.SendDelayInMs"
Change so that PacketOption packet id is always set in RtpSender (if having a TransportSequenceNumberAllocator).
Add SendDelayStats class for computing delays.
Add SendPacketObserver to RtpRtcp config and register SendDelayStats as observer.
Wire up OnSentPacket to SendDelayStats.
BUG=webrtc:5215
Review-Url: https://codereview.webrtc.org/1478253002
Cr-Commit-Position: refs/heads/master@{#12600}
VoENetwork is kept for now, but is not really used anylonger.
webrtcvoiceengine is changed to have the same behavior for unsignaled
ssrc as video has, which is reflected by disabling one test case and
this will be discussed and followed up.
BUG=webrtc:5079
TBR=tommi
Review-Url: https://codereview.webrtc.org/1909333002
Cr-Commit-Position: refs/heads/master@{#12555}
They're just no-ops now, and will soon go away.
BUG=webrtc:5520
Review URL: https://codereview.webrtc.org/1914153002
Cr-Commit-Position: refs/heads/master@{#12510}
Any file that uses the RTC_DISALLOW_* macros should #include
"webrtc/base/constructormagic.h", but a shocking number of them don't.
This causes trouble when we try to wean files off of #including
scoped_ptr.h, since a bunch of files get their constructormagic macros
only from there.
Rather than fixing these errors one by one as they turn up, this CL
simply ensures that every file in the WebRTC tree that uses the
RTC_DISALLOW_* macros #includes "webrtc/base/constructormagic.h".
BUG=webrtc:5520
Review URL: https://codereview.webrtc.org/1917043005
Cr-Commit-Position: refs/heads/master@{#12509}
