This makes a few things a lot clearer when looking at perf trace data:
* What module instances (where they were created) are called
* On what thread
* How frequently
* For how long
ProcessThread will be replaced by TaskQueue moving forward and this is a step towards understanding the behavior of the affected code.
BUG=webrtc:7219
Review-Url: https://codereview.webrtc.org/2729053002
Cr-Commit-Position: refs/heads/master@{#16998}
|transport_overhead_per_packet_| and |rtp_overhead_per_packet_| could
be read from and written to on different threads concurrently. This CL
introduces a lock to GUARD these variables.
NOTRY because master.tryserver.webrtc.linux_ubsan_vptr is broken, all
other tests pass.
BUG=webrtc:7231
NOTRY=True
Review-Url: https://codereview.webrtc.org/2710363003
Cr-Commit-Position: refs/heads/master@{#16900}
In this CL:
- Add message BweProbeCluster and BweProbeResult to rtc_event_log.proto.
- Add corresponding log functions to RtcEventLog.
- Add optional field |probe_cluster_id| to RtpPacket message and added
an overload function to log with this information.
- Propagate the probe_cluster_id to where RTP packets are logged.
BUG=webrtc:6984
Review-Url: https://codereview.webrtc.org/2666533002
Cr-Commit-Position: refs/heads/master@{#16857}
In order to not make this CL too large I have broken it down into at least two
steps. Previous CL: https://codereview.chromium.org/2628563003/
webrtc::PacedSender::Process <--- previous CL start here
webrtc::PacedSender::SendPacket
webrtc::PacketRouter::TimeToSendPacket
webrtc::ModuleRtpRtcpImpl::TimeToSendPacket <--- previous CL end here, this Cl start here
webrtc::RTPSender::TimeToSendPacket
webrtc::RTPSender::PrepareAndSendPacket
webrtc::RTPSender::AddPacketToTransportFeedback
webrtc::TransportFeedbackAdapter::AddPacket
webrtc::SendTimeHistory::AddAndRemoveOld <--- this CL end here
BUG=webrtc:6822
Review-Url: https://codereview.webrtc.org/2708873003
Cr-Commit-Position: refs/heads/master@{#16796}
Rename loss based and delay based bwe updates in proto (and correspondingly in the C++ code).
BUG=webrtc:6423
Review-Url: https://codereview.webrtc.org/2705613002
Cr-Commit-Position: refs/heads/master@{#16719}
and the method RTPSender::GenerateNewSSRC.
It's now mandatory for higher layers to call SetSSRC, RTPSender
no longer allocates any ssrc by default.
BUG=webrtc:4306,webrtc:6887
Review-Url: https://codereview.webrtc.org/2644303002
Cr-Commit-Position: refs/heads/master@{#16670}
The removed tests are covered by cases in call_perf_tests.
BUG=webrtc:4690
Review-Url: https://codereview.webrtc.org/2672583002
Cr-Commit-Position: refs/heads/master@{#16621}
This lets the RTP code be unaware of lower layers, and the
SetTransportOverhead method is deleted from RTPSender and RtpRtcp.
Instead, that method is added to CongestionController and
TransportFeedbackAdapter, where it is more appropriate.
BUG=wertc:6847
Review-Url: https://codereview.webrtc.org/2589743002
Cr-Commit-Position: refs/heads/master@{#15995}
This CL is in preparation to move the AudioFrame into webrtc/api. The
AudioFrame is a POD type used for representing 10ms of audio. It
appears as a parameter and return value of interfaces being migrated
to webrtc/api, in particular AudioMixer.
Here, methods operator+=, operator>>=, Mute are
moved into a new target webrtc/audio/utility/audio_frame_operations,
and dependencies are changed to use
the new versions. The old AudioFrame methods are marked deprecated.
The audio frame utilities in webrtc/modules/utility:audio_frame_operations
are also moved to the new location.
TBR=kjellander@webrtc.org
BUG=webrtc:6548
NOPRESUBMIT=True
Review-Url: https://codereview.webrtc.org/2424173003
Cr-Commit-Position: refs/heads/master@{#15413}
The packet size was only used to control how often to output DTMF
packets. However, it likely did not work as intended, since that
interval was only set during initialization. No changes to the packet
size, like what AudioEncoder::Num10MsFramesInNextPacket could
indicate, were picked up. The value was instead taken from an entry in
ACMCodecDB.
Since it was not-fully-functional, its exact value didn't seem to
matter and it was getting in the way of making it possible to supply
an external audio encoder factory, I've decided to remove it
altogether. The DTMF code now uses an interval of 50 ms regardless,
which is a value recommended by the RFC.
BUG=webrtc:5806
Review-Url: https://codereview.webrtc.org/2545753002
Cr-Commit-Position: refs/heads/master@{#15380}
This change rewrites RMSLevel, making it accept an ArrayView as input,
and modify the implementation somewhat. It also makes the class keep
track of the peak RMS in addition to the average RMS over the
measurement period.
New tests are added to cover the new functionality.
BUG=webrtc:6622
Review-Url: https://codereview.webrtc.org/2535523002
Cr-Commit-Position: refs/heads/master@{#15294}
Reason for revert:
Unfortunately, this change breaks internal projects. Specifically the change to the CongestionController interface means anything implementing it will be forced to change in lock-step.
Original issue's description:
> Pass time constanct to bwe smoothing filter.
>
> BUG=webrtc:6443, webrtc:6303
>
> Committed: https://crrev.com/9abbf5ae4ec7d688a9b4aa03a405f3faadb74b90
> Cr-Commit-Position: refs/heads/master@{#15266}
TBR=minyue@webrtc.org,stefan@webrtc.org,solenberg@webrtc.org,michaelt@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6443, webrtc:6303
Review-Url: https://codereview.webrtc.org/2532993002
Cr-Commit-Position: refs/heads/master@{#15272}
Reason for revert:
Downstream code has been updated.
Original issue's description:
> Revert of Remove RTPPayloadStrategy and simplify RTPPayloadRegistry (patchset #7 id:240001 of https://codereview.webrtc.org/2524923002/ )
>
> Reason for revert:
> Breaks downstream projects.
>
> Original issue's description:
> > Remove RTPPayloadStrategy and simplify RTPPayloadRegistry
> >
> > This CL removes RTPPayloadStrategy that is currently used to handle
> > audio/video specific aspects of payload handling. Instead, the audio and
> > video specific aspects will now have different functions, with linear
> > code flow.
> >
> > This CL does not contain any functional changes, and is just a
> > preparation for future CL:s.
> >
> > The main purpose with this CL is to add this function:
> > bool PayloadIsCompatible(const RtpUtility::Payload& payload,
> > const webrtc::VideoCodec& video_codec);
> > that can easily be extended in a future CL to look at video codec
> > specific information.
> >
> > BUG=webrtc:6743
> >
> > Committed: https://crrev.com/b881254dc86d2cc80a52e08155433458be002166
> > Cr-Commit-Position: refs/heads/master@{#15232}
>
> TBR=danilchap@webrtc.org,solenberg@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:6743
>
> Committed: https://crrev.com/33c81d05613f45f65ee17224ed381c6cdd1c6c6f
> Cr-Commit-Position: refs/heads/master@{#15234}
TBR=danilchap@webrtc.org,solenberg@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:6743
Review-Url: https://codereview.webrtc.org/2531043002
Cr-Commit-Position: refs/heads/master@{#15245}
Reason for revert:
Breaks downstream projects.
Original issue's description:
> Remove RTPPayloadStrategy and simplify RTPPayloadRegistry
>
> This CL removes RTPPayloadStrategy that is currently used to handle
> audio/video specific aspects of payload handling. Instead, the audio and
> video specific aspects will now have different functions, with linear
> code flow.
>
> This CL does not contain any functional changes, and is just a
> preparation for future CL:s.
>
> The main purpose with this CL is to add this function:
> bool PayloadIsCompatible(const RtpUtility::Payload& payload,
> const webrtc::VideoCodec& video_codec);
> that can easily be extended in a future CL to look at video codec
> specific information.
>
> BUG=webrtc:6743
>
> Committed: https://crrev.com/b881254dc86d2cc80a52e08155433458be002166
> Cr-Commit-Position: refs/heads/master@{#15232}
TBR=danilchap@webrtc.org,solenberg@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:6743
Review-Url: https://codereview.webrtc.org/2528993002
Cr-Commit-Position: refs/heads/master@{#15234}
This CL removes RTPPayloadStrategy that is currently used to handle
audio/video specific aspects of payload handling. Instead, the audio and
video specific aspects will now have different functions, with linear
code flow.
This CL does not contain any functional changes, and is just a
preparation for future CL:s.
The main purpose with this CL is to add this function:
bool PayloadIsCompatible(const RtpUtility::Payload& payload,
const webrtc::VideoCodec& video_codec);
that can easily be extended in a future CL to look at video codec
specific information.
BUG=webrtc:6743
Review-Url: https://codereview.webrtc.org/2524923002
Cr-Commit-Position: refs/heads/master@{#15232}
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}
We support multiple payload types, and one which matches the audio codec the closest, is picked (or the one with lowest clock rate, if no perfect match is found).
The exact clock rate is then ignored and DTMF packets are time stamped with the rate of the current audio codec. This is exactly the way the code has worked up to this point, but until now we have been under the impression that we were in fact sending 8k DTMF.
In other words, this is an improvement over the current situation, since we will most likely find a payload type which matches the codec clock rate.
This CL also does a little cleaning of the DTMFQueue and RTPSenderAudio classes.
BUG=webrtc:2795
Review-Url: https://codereview.webrtc.org/2392883002
Cr-Commit-Position: refs/heads/master@{#15129}
- 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}
- The legacy API is not used in WVoE/MC.
- Removed use of the API (along with StartReceive()) from unit tests.
BUG=webrtc:4690
Review-Url: https://codereview.webrtc.org/2453243003
Cr-Commit-Position: refs/heads/master@{#14858}
Simplify the AudioMixer::Source interface and update the mixer
implementation to the new interface.
Instead of asking a mixer source to provide a pointer to an AudioFrame
during each mixing iteration, a mixer should supply a pointer to its
own AudioFrame.
This simplifies lifetime issues as sources do not give away an
internal pointer.
Implementation: when an audio source is added, the mixer allocates a
new AudioFrame. The audio frame is kept together in the internal class
SourceStatus together with the audio source pointer until the source
is removed.
NOTRY=True
BUG=webrtc:6346
Review-Url: https://codereview.webrtc.org/2420913002
Cr-Commit-Position: refs/heads/master@{#14713}
Methods to facilitate this are added to ChannelProxy and voe::Channel.
BUG=webrtc:6346
Review-Url: https://codereview.webrtc.org/2378143004
Cr-Commit-Position: refs/heads/master@{#14707}
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 gets rid of a bit of codec-specific code in VoE.
BUG=webrtc:5805
Review-Url: https://codereview.webrtc.org/2355483003
Cr-Commit-Position: refs/heads/master@{#14614}
