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}
Prior to this change, we signalled that ULPFEC was disabled
through a bool, but that RED was disabled by setting its
payload type to -1. The latter is consistent with how we
disable RED/ULPFEC in the config, so this CL removes the
ULPFEC bool from the {,Set}UlpfecConfig chain of member
functions.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2460533002
Cr-Commit-Position: refs/heads/master@{#14944}
At the same time, change to using int's instead of uint8_t's for the payload type.
This allows us to signal disabled FEC or RED using the sentinel value -1, which
is commonplace in other parts of the code.
These APIs will be deprecated when ULPFEC is deprecated.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2448463003
Cr-Commit-Position: refs/heads/master@{#14942}
Also rename some related minor methods. No functional changes
are intended/expected.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2391963002
Cr-Commit-Position: refs/heads/master@{#14513}
Reason for revert:
Downstream build is fixed.
Original issue's description:
> Revert of Ignore Camera and Flip bits in CVO when parsing video rotation (patchset #3 id:80001 of https://codereview.webrtc.org/2280703002/ )
>
> Reason for revert:
> Breaks downstream build.
>
> Original issue's description:
> > Ignore Camera and Flip bits in CVO when parsing video rotation
> >
> > Currently, if WebRTC receives a CVO byte where the Camera or Flip bit is
> > set, then rotation is incorrectly parsed as 0. This CL fixes that issue.
> > The Camera and Flip bit is still unimplemented and will just be ignored
> > though.
> >
> > BUG=webrtc:6120
> > R=danilchap@webrtc.org, pthatcher@webrtc.org, tommi@webrtc.org
> >
> > Committed: f9e1b922ef
>
> TBR=pthatcher@webrtc.org,danilchap@webrtc.org,tommi@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:6120
>
> Committed: https://crrev.com/97667c7746282704acccd896e26175decee349c0
> Cr-Commit-Position: refs/heads/master@{#14035}
TBR=pthatcher@webrtc.org,danilchap@webrtc.org,tommi@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:6120
Review-Url: https://codereview.webrtc.org/2320913003
Cr-Commit-Position: refs/heads/master@{#14124}
Reason for revert:
Breaks downstream build.
Original issue's description:
> Ignore Camera and Flip bits in CVO when parsing video rotation
>
> Currently, if WebRTC receives a CVO byte where the Camera or Flip bit is
> set, then rotation is incorrectly parsed as 0. This CL fixes that issue.
> The Camera and Flip bit is still unimplemented and will just be ignored
> though.
>
> BUG=webrtc:6120
> R=danilchap@webrtc.org, pthatcher@webrtc.org, tommi@webrtc.org
>
> Committed: f9e1b922efTBR=pthatcher@webrtc.org,danilchap@webrtc.org,tommi@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6120
Review-Url: https://codereview.webrtc.org/2300323002
Cr-Commit-Position: refs/heads/master@{#14035}
Currently, if WebRTC receives a CVO byte where the Camera or Flip bit is
set, then rotation is incorrectly parsed as 0. This CL fixes that issue.
The Camera and Flip bit is still unimplemented and will just be ignored
though.
BUG=webrtc:6120
R=danilchap@webrtc.org, pthatcher@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/2280703002 .
Cr-Commit-Position: refs/heads/master@{#14027}
This CL removes (almost) the last RTP references in VideoReceiveStream.
There are still references to RTPFragmentationHeader and SSRCs, which
will be dealt with later.
There are also new GUARDED_BY and thred checker added to the
synchronization class.
When there are othre transports than RTP, there will instead be an
interface + inheritance for RtpStreamReceiver and
RtpStreamSynchronizattion in VideoReceiveStream. This work will be done
when we actually know how we want to make thee transport interface.
BUG=webrtc:5838
Review-Url: https://codereview.webrtc.org/2216533002
Cr-Commit-Position: refs/heads/master@{#13655}
Reason for revert:
Upstream fixes in place, should be OK now.
Original issue's description:
> Revert of Refactor NACK bitrate allocation (patchset #16 id:300001 of https://codereview.webrtc.org/2061423003/ )
>
> Reason for revert:
> Breaks upstream code.
>
> Original issue's description:
> > Refactor NACK bitrate allocation
> >
> > Nack bitrate allocation should not be done on a per-rtp-module basis,
> > but rather shared bitrate pool per call. This CL moves allocation to the
> > pacer and cleans up a bunch if bitrate stats handling.
> >
> > BUG=
> > R=danilchap@webrtc.org, stefan@webrtc.org, tommi@webrtc.org
> >
> > Committed: 5fc59e810b
>
> TBR=tommi@webrtc.org,danilchap@webrtc.org,stefan@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=
>
> Committed: https://crrev.com/e5dd44101eca485f5ad12e5f7ce6f6b0d204116b
> Cr-Commit-Position: refs/heads/master@{#13417}
TBR=tommi@webrtc.org,danilchap@webrtc.org,stefan@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=
Review-Url: https://codereview.webrtc.org/2146013002
Cr-Commit-Position: refs/heads/master@{#13465}
Reason for revert:
It keeps breaking upstream.
Original issue's description:
> Reland Issue 2061423003: Refactor NACK bitrate allocation
>
> This is a reland of https://codereview.webrtc.org/2061423003/
> Which was reverted in https://codereview.webrtc.org/2131913003/
>
> The reason for the revert was that some upstream code used
> RtpSender::SetTargetBitrate(). I've added that back as a no-op until we
> it's been brought up to date.
>
> TBR=tommi@webrtc.org
>
> Committed: 05ce4ae31fTBR=tommi@webrtc.org,sprang@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.webrtc.org/2130423002
Cr-Commit-Position: refs/heads/master@{#13419}
Reason for revert:
Breaks upstream code.
Original issue's description:
> Refactor NACK bitrate allocation
>
> Nack bitrate allocation should not be done on a per-rtp-module basis,
> but rather shared bitrate pool per call. This CL moves allocation to the
> pacer and cleans up a bunch if bitrate stats handling.
>
> BUG=
> R=danilchap@webrtc.org, stefan@webrtc.org, tommi@webrtc.org
>
> Committed: 5fc59e810bTBR=tommi@webrtc.org,danilchap@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/2131913003
Cr-Commit-Position: refs/heads/master@{#13417}
Allows detecting large-enough audio packets as part of a probe,
speculative fix for a rampup-time regression in M50. These packets are
accounted on the send side when probing.
BUG=webrtc:5985
R=mflodman@webrtc.org, philipel@webrtc.org
Review URL: https://codereview.webrtc.org/2061193002 .
Cr-Commit-Position: refs/heads/master@{#13210}
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 adds support for an extension on RTP frames to allow the sender
to specify the minimum and maximum playout delay limits.
The receiver makes a best-effort attempt to keep the capture-to-render delay
within this range. This allows different types of application to specify
different end-to-end delay goals. For example gaming can support rendering
of frames as soon as received on receiver to minimize delay. A movie playback
application can specify a minimum playout delay to allow fixed buffering
in presence of network jitter.
There are no tests at this time and most of testing is done with chromium
webrtc prototype.
On chromoting performance tests, this extension helps bring down end-to-end
delay by about 150 ms on small frames.
BUG=webrtc:5895
Review-Url: https://codereview.webrtc.org/2007743003
Cr-Commit-Position: refs/heads/master@{#13059}
Currently there are two structs that are identical and track extension details:
webrtc::RtpExtension
cricket::RtpHeaderExtension
The use of the structs is mixed in the code to track the extensions being
supported. This results in duplicate definition of
the URI constants and there is code to convert between the two structs.
Clean up to use a single RtpHeader throughout the codebase. The actual location
of RtpHeader may change in future (perhaps to be located in api/). Additionally,
this CL renames some of the constants to clarify Uri and Id use.
BUG= webrtc:5895
Review-Url: https://codereview.webrtc.org/1984983002
Cr-Commit-Position: refs/heads/master@{#12924}
There are still a few places in VideoReceiveStream where the RTP module
is explicitly used, e.g. setting up a/v sync, but it's a bigger task to
change and that will be done in a follow up instead of in this CL.
BUG=webrtc:5838
Review-Url: https://codereview.webrtc.org/1947913002
Cr-Commit-Position: refs/heads/master@{#12642}
ViEChannel is now called VideoStreamReceiver.
There will be a follow up CL removing all rtp references from VideoReceiveStream, but that made this CL to big and it will be done separately.
BUG=webrtc:5079
Review-Url: https://codereview.webrtc.org/1929313002
Cr-Commit-Position: refs/heads/master@{#12619}
- "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}
This CL will be followed up with another CL removing everything related
to RTP from ViEChannel to RtpStreamReceiver, i.e. remove ViEChannel::rtp_stream_receiver_.
BUG=5838
Review-Url: https://codereview.webrtc.org/1917363005
Cr-Commit-Position: refs/heads/master@{#12553}
