Some frames are already marked as 'timing frames' via video-timing RTP header extension. Timestamps along full WebRTC pipeline are gathered for these frames. This CL implements reporting of these timestamps for a single
timing frame since the last GetStats(). The frame with the longest end-to-end delay between two consecutive GetStats calls is reported.
The purpose of this timing information is not to provide a realtime statistics but to provide debugging information as it will help identify problematic places in video pipeline for outliers (frames which took longest to process).
BUG=webrtc:7594
Review-Url: https://codereview.webrtc.org/2946413002
Cr-Commit-Position: refs/heads/master@{#18909}
I used a command like this to update the paths:
perl -pi -e "s/webrtc\/base/webrtc\/rtc_base/g" `find webrtc/rtc_base -name "*.cc" -o -name "*.h"`
BUG=webrtc:7634
NOPRESUBMIT=True # cpplint errors that aren't caused by this CL.
Review-Url: https://codereview.webrtc.org/2969623003
Cr-Commit-Position: refs/heads/master@{#18870}
This CL makes the WebRTC more modular and allows the users to build
WebRTC without audio and video(DataChannel only).
The BUILD files in call/, logging/, media/ and pc/ are modified to
support modular WebRTC.
The dependencies on Call and RtcEventLog are removed from the
PeerConnection. Instead of being created internally, they would be
passed in by the PeerConnectionFactory.
Add the CreateModularPeerConnectionFactory function which allow the
users to create a PeerConnectionFactory with the modules they need.
If the users want to build WebRTC without audio and video, they can
pass in null pointers for modules they don't need. (MediaEngine,
VideoEncoderFactory etc.)
BUG=webrtc:7613
Review-Url: https://codereview.webrtc.org/2854123003
Cr-Commit-Position: refs/heads/master@{#18617}
WebRtcVideoChannel and and WebRtcVideoEngine seem to have been removed, and only WebRtcVideoChannel2 and WebRtcVideoEngine2 remain, which removes the need for the "2" postfix.
BUG=None
Review-Url: https://codereview.webrtc.org/2932073002
Cr-Commit-Position: refs/heads/master@{#18531}
Reason for revert:
Broken downstream projects
Original issue's description:
> Wire up BWE stats through WebrtcSession so that they are filled in both for audio and video calls.
>
> Prior to this CL Call::Stats were collected via WebRtcVideoEngine2, but not via WebRtcVoiceEngine, causing these stats to be missing for audio-only calls. Call lives on the peerconnection/session level and should only be collected once independent on how many streams we have.
>
> BUG=webrtc:5079
> R=deadbeef@webrtc.org, hbos@webrtc.org
>
> Review-Url: https://codereview.webrtc.org/2863123002 .
> Cr-Commit-Position: refs/heads/master@{#18384}
> Committed: e80f4c91d0TBR=hbos@webrtc.org,deadbeef@webrtc.org,holmer@google.com,stefan@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5079
Review-Url: https://codereview.webrtc.org/2916793003
Cr-Commit-Position: refs/heads/master@{#18386}
Prior to this CL Call::Stats were collected via WebRtcVideoEngine2, but not via WebRtcVoiceEngine, causing these stats to be missing for audio-only calls. Call lives on the peerconnection/session level and should only be collected once independent on how many streams we have.
BUG=webrtc:5079
R=deadbeef@webrtc.org, hbos@webrtc.org
Review-Url: https://codereview.webrtc.org/2863123002 .
Cr-Commit-Position: refs/heads/master@{#18384}
When SSRCs aren't signaled, an SSRC of 0 is used internally to mean
"the default receive stream". But this wasn't working with the
implementation of GetRtpReceiveParameters in the audio/video
engines. This was breaking RtpReceiver.GetParameters in this situation,
as well as the new getStats implementation (which relies on
GetParameters).
The new implementation will fail if *no* default receive stream is
configured (meaning no default sink is set), and otherwise will return
a default RtpEncodingParameters (later it will be filled with relevant
SDP parameters as they're implemented).
BUG=webrtc:6971
Review-Url: https://codereview.webrtc.org/2806173002
Cr-Commit-Position: refs/heads/master@{#17803}
These methods relate to typing detection but are not used anymore. Typing detection is enabled through the VoiceDetection module on the APM.
BUG=webrtc:4690
Review-Url: https://codereview.webrtc.org/2684933008
Cr-Commit-Position: refs/heads/master@{#16527}
This is not implemented yet in any of the decoders.
BUG=webrtc:6541
Review-Url: https://codereview.webrtc.org/2649133005
Cr-Commit-Position: refs/heads/master@{#16475}
Most notably, will return "INVALID_MODIFICATION" if a field in the
configuration was modified and modification of that field isn't supported.
Also changing RTCError to a class that wraps an enum type, because it will
eventually need to hold other information (like SDP line number), to match
the RTCError that was recently added to the spec:
https://github.com/w3c/webrtc-pc/pull/850
BUG=webrtc:6916
Review-Url: https://codereview.webrtc.org/2587133004
Cr-Original-Commit-Position: refs/heads/master@{#15777}
Committed: 7a5fa6cd61
Review-Url: https://codereview.webrtc.org/2587133004
Cr-Commit-Position: refs/heads/master@{#16016}
The BaseChannel code is geared around RTP; the presence of media engines,
send and receive streams, SRTP, SDP directional attribute negotiation, etc.
It doesn't make sense to use it for SCTP as well. This separation should make
future work both on BaseChannel and the SCTP code paths easier.
SctpDataEngine now becomes SctpTransport, and is used by WebRtcSession
directly. cricket::DataChannel is also renamed, to RtpDataChannel, so it
doesn't get confused with webrtc::DataChannel any more.
Beyond just moving code around, some consequences of this CL:
- We'll now stop using the worker thread for SCTP. Packets will be
processed right on the network thread instead.
- The SDP directional attribute is ignored, as it's supposed to be.
BUG=None
Review-Url: https://codereview.webrtc.org/2564333002
Cr-Original-Commit-Position: refs/heads/master@{#15906}
Committed: 67b3bbe639
Review-Url: https://codereview.webrtc.org/2564333002
Cr-Commit-Position: refs/heads/master@{#15973}
Reason for revert:
Hitting DCHECK in chromium's WebrtcTransportTest.TerminateDataChannel and WebrtcTransportTest.DataStreamLate. Will investigate and reland.
Original issue's description:
> Separating SCTP code from BaseChannel/MediaChannel.
>
> The BaseChannel code is geared around RTP; the presence of media engines,
> send and receive streams, SRTP, SDP directional attribute negotiation, etc.
> It doesn't make sense to use it for SCTP as well. This separation should make
> future work both on BaseChannel and the SCTP code paths easier.
>
> SctpDataEngine now becomes SctpTransport, and is used by WebRtcSession
> directly. cricket::DataChannel is also renamed, to RtpDataChannel, so it
> doesn't get confused with webrtc::DataChannel any more.
>
> Beyond just moving code around, some consequences of this CL:
> - We'll now stop using the worker thread for SCTP. Packets will be
> processed right on the network thread instead.
> - The SDP directional attribute is ignored, as it's supposed to be.
>
> BUG=None
>
> Review-Url: https://codereview.webrtc.org/2564333002
> Cr-Commit-Position: refs/heads/master@{#15906}
> Committed: 67b3bbe639TBR=pthatcher@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=None
Review-Url: https://codereview.webrtc.org/2614813003
Cr-Commit-Position: refs/heads/master@{#15908}
The BaseChannel code is geared around RTP; the presence of media engines,
send and receive streams, SRTP, SDP directional attribute negotiation, etc.
It doesn't make sense to use it for SCTP as well. This separation should make
future work both on BaseChannel and the SCTP code paths easier.
SctpDataEngine now becomes SctpTransport, and is used by WebRtcSession
directly. cricket::DataChannel is also renamed, to RtpDataChannel, so it
doesn't get confused with webrtc::DataChannel any more.
Beyond just moving code around, some consequences of this CL:
- We'll now stop using the worker thread for SCTP. Packets will be
processed right on the network thread instead.
- The SDP directional attribute is ignored, as it's supposed to be.
BUG=None
Review-Url: https://codereview.webrtc.org/2564333002
Cr-Commit-Position: refs/heads/master@{#15906}
Reason for revert:
Broke chromium FYI bot because the chromium mock PC overrides the method whose signature is changing.
Also broke a downstream internal test, which I need to investigate further.
Original issue's description:
> Adding error output param to SetConfiguration, using new RTCError type.
>
> Most notably, will return "INVALID_MODIFICATION" if a field in the
> configuration was modified and modification of that field isn't supported.
>
> Also changing RTCError to a class that wraps an enum type, because it will
> eventually need to hold other information (like SDP line number), to match
> the RTCError that was recently added to the spec:
> https://github.com/w3c/webrtc-pc/pull/850
>
> BUG=webrtc:6916
>
> Review-Url: https://codereview.webrtc.org/2587133004
> Cr-Commit-Position: refs/heads/master@{#15777}
> Committed: 7a5fa6cd61TBR=pthatcher@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6916
Review-Url: https://codereview.webrtc.org/2600813002
Cr-Commit-Position: refs/heads/master@{#15778}
Most notably, will return "INVALID_MODIFICATION" if a field in the
configuration was modified and modification of that field isn't supported.
Also changing RTCError to a class that wraps an enum type, because it will
eventually need to hold other information (like SDP line number), to match
the RTCError that was recently added to the spec:
https://github.com/w3c/webrtc-pc/pull/850
BUG=webrtc:6916
Review-Url: https://codereview.webrtc.org/2587133004
Cr-Commit-Position: refs/heads/master@{#15777}
Now ProbeController can send periodic bandwidth probes when in
application-limited region. This will allow to maintain correct
bottleneck bandwidth estimate, even not all bandwidth is being used.
The feature is not enabled by default, but can be enabled with a flag.
Interval between probes is currently set to 5 seconds.
BUG=webrtc:6332
Review-Url: https://codereview.webrtc.org/2504023002
Cr-Commit-Position: refs/heads/master@{#15279}
Payload type -> RtpCodecParameters maps added for sender and receiver.
This is a follow-up to https://codereview.webrtc.org/2484193002/ which
did the same thing for VideoMediaInfo. This information will be used to
produce RTCCodecStats[1].
Voice[Sender/Receiver]Info is updated with current codec payload type
for every stream which can be used to look up the codec in
VoiceMediaInfo.
[1] https://w3c.github.io/webrtc-stats/#codec-dict*
BUG=chromium:659117
Review-Url: https://codereview.webrtc.org/2503383002
Cr-Commit-Position: refs/heads/master@{#15144}
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}
This removes the VideoSendStream::LoadObserver interface and the implementation in WebrtcVideoSendStream and replace it with VideoSinkWants through the VideoSourceInterface.
To do that that, some stats for CPU adaptation is moved into VideoSendStream. Also handling of the CVO rtp header extension is moved to VideoSendStreamImpl.
BUG=webrtc:5687
TBR=mflodman@webrtc.org
Review-Url: https://codereview.webrtc.org/2304363002
Cr-Commit-Position: refs/heads/master@{#14877}
The stat is currently always set to zero until the residual echo detector has landed.
BUG=webrtc:6525
Review-Url: https://codereview.webrtc.org/2431443003
Cr-Commit-Position: refs/heads/master@{#14721}
An audio track with a level controller with the correct initialization
value can be created by a combination of
PeerConnectionFactory::CreateAudioTrack(..., audio_source) and
either
audio_source = PeerConnectionFactory::CreateAudioSource(constraints) or
audio_source = PeerConnectionFactory::CreateAudioSource(audio_options).
NOTRY=True
BUG=webrtc:6386
Review-Url: https://codereview.webrtc.org/2408143003
Cr-Commit-Position: refs/heads/master@{#14693}
This change adds a new statistic for logging how many calls to
NetEq::GetAudio resulted in a "muted output". A muted output happens
if the packet stream has been dead for some time (and the last decoded
packet was not comfort noise).
BUG=webrtc:5606
BUG=b/31256483
Review-Url: https://codereview.webrtc.org/2341293002
Cr-Commit-Position: refs/heads/master@{#14302}
This is part of rewriting the ConferenceMixer and OutputMixer.
Calls are instead routed through AudioReceiveStream::Start/Stop.
NOTRY=True
Review-Url: https://codereview.webrtc.org/2206223002
Cr-Commit-Position: refs/heads/master@{#13636}
functionality and exposes the functionality using the
MediaConstraints.
The exposing of the feature through the MediaConstraints
was done similarly to what was done for the intelligibility
enhancer in the CL
https://codereview.webrtc.org/1952123003
This CL is dependent on the CL https://codereview.webrtc.org/2090583002/ which contains
the level control functionality.
NOTRY=true
BUG=webrtc:5920
Review-Url: https://codereview.webrtc.org/2095563002
Cr-Commit-Position: refs/heads/master@{#13336}
This means there's only one thread hop to the worker thread.
At the video engine level, SetOptions and SetSource
are combined into one method (all within the same critical section)
which ensures that no frame will be encoded while SetVideoSend
is only partially finished.
BUG=webrtc:5691
Review-Url: https://codereview.webrtc.org/1838413002
Cr-Commit-Position: refs/heads/master@{#13022}
