This moves some GN check configurations out of .gn to individual
targets.
This commit also removes the source file 'mocks/mock_rtp_rtcp.h' from
the static_library 'rtp_rtcp' because it depends on a 'testonly = true'
target. After a check this seems only included in the unitest code:
$ grep -Rn "mocks/mock_rtp_rtcp.h" webrtc/modules/rtp_rtcp/
webrtc/modules/rtp_rtcp/source/ulpfec_receiver_unittest.cc:18:#include "webrtc/modules/rtp_rtcp/mocks/mock_rtp_rtcp.h"
webrtc/modules/rtp_rtcp/source/rtp_format_h264_unittest.cc:17:#include "webrtc/modules/rtp_rtcp/mocks/mock_rtp_rtcp.h"
This commit also removes the dependency on
'//webrt/modules/video_coding' because it seems that the following
include can be removed:
#include "webrtc/modules/video_coding/include/video_coding_defines.h"
The now checked target is:
"//webrtc/modules/rtp_rtcp/*"
BUG=webrtc:6828
NOTRY=True
Review-Url: https://codereview.webrtc.org/2598963002
Cr-Commit-Position: refs/heads/master@{#15760}
Problem fixed: RTP header extensions were not properly set in tests.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2593963003
Cr-Commit-Position: refs/heads/master@{#15741}
The packetization parts of this class are accessed from the
encoder thread, which might change under different occasions.
The use of a sequenced task checker here is thus incorrect, since
that requires the access to always be on the same thread, whenever
a task queue is not used.
The access to the instantiated object of this class, at least when
it comes to the RTP packetization parts, is however synchronized
using the lock in PayloadRouter::OnEncodedImage. We can therefore
safely remove the sequenced task checker.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2562983002
Cr-Commit-Position: refs/heads/master@{#15549}
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}
Reason for revert:
Include fix; set profile information in CreatePayloadType for video.
Original issue's description:
> Revert of Add H264 profile to webrtc::VideoCodecH264 and webrtc::VideoPayload (patchset #1 id:40001 of https://codereview.webrtc.org/2525693003/ )
>
> Reason for revert:
> The CL doesn't actually set profile information in VideoPayload.
>
> Original issue's description:
> > Add H264 profile to webrtc::VideoCodecH264 and webrtc::VideoPayload
> >
> > It's necessary to check H264 profile information as well as payload name
> > in PayloadIsCompatible in RTPPayloadRegistry.
> >
> > BUG=webrtc:6743
> >
> > Committed: https://crrev.com/bdbc4b7ef578ba1d61ceec351bc47c33da115329
> > Cr-Commit-Position: refs/heads/master@{#15248}
>
> TBR=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/d7e6ccbc53fc24acdcc7507a6f3a155626473d54
> Cr-Commit-Position: refs/heads/master@{#15251}
TBR=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/2529153002
Cr-Commit-Position: refs/heads/master@{#15252}
Reason for revert:
The CL doesn't actually set profile information in VideoPayload.
Original issue's description:
> Add H264 profile to webrtc::VideoCodecH264 and webrtc::VideoPayload
>
> It's necessary to check H264 profile information as well as payload name
> in PayloadIsCompatible in RTPPayloadRegistry.
>
> BUG=webrtc:6743
>
> Committed: https://crrev.com/bdbc4b7ef578ba1d61ceec351bc47c33da115329
> Cr-Commit-Position: refs/heads/master@{#15248}
TBR=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/2529143002
Cr-Commit-Position: refs/heads/master@{#15251}
It's necessary to check H264 profile information as well as payload name
in PayloadIsCompatible in RTPPayloadRegistry.
BUG=webrtc:6743
Review-Url: https://codereview.webrtc.org/2525693003
Cr-Commit-Position: refs/heads/master@{#15248}
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}
Turns out this function is needed by external code.
BUG=webrtc:6743
Review-Url: https://codereview.webrtc.org/2532663002
Cr-Commit-Position: refs/heads/master@{#15237}
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}
They just decay to pointers anyway, so it's more honest to declare
them as pointers.
BUG=webrtc:5805
Review-Url: https://codereview.webrtc.org/2515163002
Cr-Commit-Position: refs/heads/master@{#15165}
FlexfecSender is owned and configured by VideoSendStream.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2501503003
Cr-Commit-Position: refs/heads/master@{#15082}
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}
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 CL adds the ability for RTPSenderVideo to generate and send
FlexFEC packets.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2490523002
Cr-Commit-Position: refs/heads/master@{#15016}
- Change const ptr to const ref in parameter list.
Using nullptr as argument was invalid, so no need to send
pointer instead of reference.
- Change return type to void or bool, where appropriate
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2455963003
Cr-Commit-Position: refs/heads/master@{#14945}
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}
Removed EncodedImageCallback::Encoded() and RtpRtcp::SendOutgoingData().
These methods should no longer be used anywhere and it's safe to remove
them.
BUG=chromium:621691
Committed: https://crrev.com/c681250aaa2025836db7669694e323898e5c2ca7
Review-Url: https://codereview.webrtc.org/2405173006
Cr-Original-Commit-Position: refs/heads/master@{#14923}
Cr-Commit-Position: refs/heads/master@{#14935}
Reason for revert:
Still breaks internal downstream project.
Sergey: Please update internal project before relanding this.
Original issue's description:
> Remove deprected functions from EncodedImageCallback and RtpRtcp
>
> Removed EncodedImageCallback::Encoded() and RtpRtcp::SendOutgoingData().
> These methods should no longer be used anywhere and it's safe to remove
> them.
>
> BUG=chromium:621691
>
> Committed: https://crrev.com/c681250aaa2025836db7669694e323898e5c2ca7
> Cr-Commit-Position: refs/heads/master@{#14923}
TBR=mflodman@webrtc.org,stefan@webrtc.org,sergeyu@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:621691
Review-Url: https://codereview.webrtc.org/2479643002
Cr-Commit-Position: refs/heads/master@{#14925}
Removed EncodedImageCallback::Encoded() and RtpRtcp::SendOutgoingData().
These methods should no longer be used anywhere and it's safe to remove
them.
BUG=chromium:621691
Review-Url: https://codereview.webrtc.org/2405173006
Cr-Commit-Position: refs/heads/master@{#14923}
This class will interface RTPSenderVideo with the underlying
erasure code. It is functionally similar to ProducerFec
(to be renamed UlpfecGenerator). In fact, the FlexfecSender is a
friend of ProducerFec, and reuses most of its implementation.
Besides the fact that FlexfecSender outputs FlexFEC packets,
the main difference with ProducerFec is that FlexfecSender
allocates RTP sequence numbers, whereas ProducerFec does not
do this for the RED-encapsulated ULPFEC packets.
This class is split as interface/implementation, since it will
be owned by VideoSendStream initially. Further along, it may be
owned by PacedSender.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2441613002
Cr-Commit-Position: refs/heads/master@{#14922}
There is no need for it to be an interface.
In this CL, I also took the opportunity to make two small fixes:
- remove the 'flexfec_' prefix from some member variables
- remove unnecessary use of a stringstream object
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2471073003
Cr-Commit-Position: refs/heads/master@{#14919}
Reason for revert:
Breaks everything
Original issue's description:
> Revert of Remove deprected functions from EncodedImageCallback and RtpRtcp (patchset #4 id:100001 of https://codereview.webrtc.org/2405173006/ )
>
> Reason for revert:
> This might be breaking projects downstream.
>
> Original issue's description:
> > Remove deprected functions from EncodedImageCallback and RtpRtcp
> >
> > Removed EncodedImageCallback::Encoded() and RtpRtcp::SendOutgoingData().
> > These methods should no longer be used anywhere and it's safe to remove
> > them.
> >
> > BUG=chromium:621691
> >
> > Committed: https://crrev.com/fa565842718ad178a7562721b25d916fbabc2b92
> > Cr-Commit-Position: refs/heads/master@{#14902}
>
> TBR=mflodman@webrtc.org,stefan@webrtc.org,sergeyu@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=chromium:621691
>
> Committed: https://crrev.com/6c78307a21252c2dbd704f6d5e92a220fb722ed4
> Cr-Commit-Position: refs/heads/master@{#14914}
TBR=mflodman@webrtc.org,stefan@webrtc.org,sergeyu@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:621691
Review-Url: https://codereview.webrtc.org/2467373003
Cr-Commit-Position: refs/heads/master@{#14915}
Reason for revert:
This might be breaking projects downstream.
Original issue's description:
> Remove deprected functions from EncodedImageCallback and RtpRtcp
>
> Removed EncodedImageCallback::Encoded() and RtpRtcp::SendOutgoingData().
> These methods should no longer be used anywhere and it's safe to remove
> them.
>
> BUG=chromium:621691
>
> Committed: https://crrev.com/fa565842718ad178a7562721b25d916fbabc2b92
> Cr-Commit-Position: refs/heads/master@{#14902}
TBR=mflodman@webrtc.org,stefan@webrtc.org,sergeyu@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:621691
Review-Url: https://codereview.webrtc.org/2474433008
Cr-Commit-Position: refs/heads/master@{#14914}
Removed EncodedImageCallback::Encoded() and RtpRtcp::SendOutgoingData().
These methods should no longer be used anywhere and it's safe to remove
them.
BUG=chromium:621691
Review-Url: https://codereview.webrtc.org/2405173006
Cr-Commit-Position: refs/heads/master@{#14902}
- Add histogram: "WebRTC.Video.RtpToNtpFreqOffsetInKhz"
The absolute value of the difference between the estimated frequency during RTP timestamp to NTP time conversion and the actual value (i.e. 90 kHz) is measured per received video frame. The max offset during 40 second intervals is stored. The average of these stored offsets per received video stream is recorded when a stream is removed.
Updated rtp_to_ntp.cc:
- Add validation for only inserting newer RTCP sender reports to the rtcp list.
- Move calculation of frequency/offset (from RTP/NTP timestamp pairs) to UpdateRtcpList. Calculated when a new RTCP SR in inserted (and not in RtpToNtpMs per packet).
BUG=webrtc:6579
Review-Url: https://codereview.webrtc.org/2385763002
Cr-Commit-Position: refs/heads/master@{#14891}
Separate the null implementation from rtp_rtcp_defines.h, and follow chromium style guide for virtual functions.
BUG=webrtc:163
Review-Url: https://codereview.webrtc.org/2400993002
Cr-Commit-Position: refs/heads/master@{#14738}
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}
This class is split in interface/implementation classes, since it
will be referenced from the Call level. Its purpose is to interface
the erasure code decoder with a new class FlexfecReceiveStream
(for received packets), as well as with the main RTP pipeline (for
recovered packets).
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2392663006
Cr-Commit-Position: refs/heads/master@{#14594}
The renaming is to reflect this class is only used for RTCP interaction
and not for other transports.
This Cl will be followed by multiple CLs moving all send-side RTP
functionality to a separate class, rtp module ownership away from
VideoSendStream and use TaskQueue instead of ProcessThread for RTP.
BUG=webrtc:6456
Review-Url: https://codereview.webrtc.org/2390463002
Cr-Commit-Position: refs/heads/master@{#14556}
