This is in preparation for merging the ViERemb logic in packet_router,
to send REMB feedback as sender reports if possible, otherwise as
receiver reports.
BUG=webrtc:7135
Review-Url: https://codereview.webrtc.org/2774623006
Cr-Commit-Position: refs/heads/master@{#17489}
Deletes left-over includes of trace.h and critical_section_wrapper.h.
BUG=webrtc:7035
Review-Url: https://codereview.webrtc.org/2784873002
Cr-Commit-Position: refs/heads/master@{#17460}
This is one step towards separation of send-side and receive-side
processing.
BUG=webrtc:7135
Review-Url: https://codereview.webrtc.org/2740163002
Cr-Commit-Position: refs/heads/master@{#17306}
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}
Also reducing locking in NackModule (and by extension RtpStreamReceiver)
BUG=webrtc:7246
Review-Url: https://codereview.webrtc.org/2720603002
Cr-Commit-Position: refs/heads/master@{#16856}
This avoids redoing RTP header parsing already done in Call, for video.
The next step is to convert other types of receive streams, i.e.,
audio and flexfec, to use a compatible OnRtpPacket method. We can then
introduce a shared base interface, and simplify media-independent
receive processing in Call.
BUG=webrtc:7135
Review-Url: https://codereview.webrtc.org/2681673004
Cr-Commit-Position: refs/heads/master@{#16583}
We can then drop the CongestionController and RemoteBitrateEstimator
completely from the receive streams.
BUG=webrtc:6847
Review-Url: https://codereview.webrtc.org/2669463006
Cr-Commit-Position: refs/heads/master@{#16459}
Delete the calls from RtpStreamReceiver (for video) and
AudioReceiveStream.
BUG=webrtc:6847
Review-Url: https://codereview.webrtc.org/2659563002
Cr-Commit-Position: refs/heads/master@{#16393}
Reason for revert:
Downstream project relied on changed struct.
Transition made possible by https://codereview.webrtc.org/2655243006/.
Original issue's description:
> Revert of Make RTX pt/apt reconfigurable by calling WebRtcVideoChannel2::SetRecvParameters. (patchset #7 id:160001 of https://codereview.webrtc.org/2646073004/ )
>
> Reason for revert:
> Breaks internal downstream project.
>
> Original issue's description:
> > Make RTX pt/apt reconfigurable by calling WebRtcVideoChannel2::SetRecvParameters.
> >
> > Prior to this CL, received RTX (associated) payload types were only configured
> > when WebRtcVideoChannel2::AddRecvStream was called. In the same method, the RTX
> > SSRC was set up.
> >
> > After this CL, the RTX (associated) payload types are set in
> > WebRtcVideoChannel2::SetRecvParameters, which is the appropriate place to set
> > them. The RTX SSRC is still set in WebRtcVideoChannel2::AddRecvStream, since
> > that is the code path that sets other SSRCs.
> >
> > As part of this fix, the VideoReceiveStream::Config::Rtp struct is changed.
> > We remove the possibility for each video payload type to have an associated
> > specific RTX SSRC. Although the config previously allowed for this, all payload
> > types always had the same RTX SSRC set, and the underlying RtpPayloadRegistry
> > did not support multiple SSRCs. This change to the config struct should thus not
> > have any functional impact. The change does however affect the RtcEventLog, since
> > that is used for storing the VideoReceiveStream::Configs. For simplicity,
> > this CL does not change the event log proto definitions, instead duplicating
> > the serialized RTX SSRCs such that they fit in the existing proto definition.
> >
> > BUG=webrtc:7011
> >
> > Review-Url: https://codereview.webrtc.org/2646073004
> > Cr-Commit-Position: refs/heads/master@{#16302}
> > Committed: fe2bef39cd
>
> TBR=stefan@webrtc.org,magjed@webrtc.org,terelius@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:7011
>
> Review-Url: https://codereview.webrtc.org/2649323010
> Cr-Commit-Position: refs/heads/master@{#16307}
> Committed: e4974953ceTBR=stefan@webrtc.org,magjed@webrtc.org,terelius@webrtc.org,kjellander@webrtc.org,kjellander@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
# NOTREECHECKS=true
# NOTRY=true
BUG=webrtc:7011
Review-Url: https://codereview.webrtc.org/2654163006
Cr-Commit-Position: refs/heads/master@{#16322}
Reason for revert:
Breaks internal downstream project.
Original issue's description:
> Make RTX pt/apt reconfigurable by calling WebRtcVideoChannel2::SetRecvParameters.
>
> Prior to this CL, received RTX (associated) payload types were only configured
> when WebRtcVideoChannel2::AddRecvStream was called. In the same method, the RTX
> SSRC was set up.
>
> After this CL, the RTX (associated) payload types are set in
> WebRtcVideoChannel2::SetRecvParameters, which is the appropriate place to set
> them. The RTX SSRC is still set in WebRtcVideoChannel2::AddRecvStream, since
> that is the code path that sets other SSRCs.
>
> As part of this fix, the VideoReceiveStream::Config::Rtp struct is changed.
> We remove the possibility for each video payload type to have an associated
> specific RTX SSRC. Although the config previously allowed for this, all payload
> types always had the same RTX SSRC set, and the underlying RtpPayloadRegistry
> did not support multiple SSRCs. This change to the config struct should thus not
> have any functional impact. The change does however affect the RtcEventLog, since
> that is used for storing the VideoReceiveStream::Configs. For simplicity,
> this CL does not change the event log proto definitions, instead duplicating
> the serialized RTX SSRCs such that they fit in the existing proto definition.
>
> BUG=webrtc:7011
>
> Review-Url: https://codereview.webrtc.org/2646073004
> Cr-Commit-Position: refs/heads/master@{#16302}
> Committed: fe2bef39cdTBR=stefan@webrtc.org,magjed@webrtc.org,terelius@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:7011
Review-Url: https://codereview.webrtc.org/2649323010
Cr-Commit-Position: refs/heads/master@{#16307}
Prior to this CL, received RTX (associated) payload types were only configured
when WebRtcVideoChannel2::AddRecvStream was called. In the same method, the RTX
SSRC was set up.
After this CL, the RTX (associated) payload types are set in
WebRtcVideoChannel2::SetRecvParameters, which is the appropriate place to set
them. The RTX SSRC is still set in WebRtcVideoChannel2::AddRecvStream, since
that is the code path that sets other SSRCs.
As part of this fix, the VideoReceiveStream::Config::Rtp struct is changed.
We remove the possibility for each video payload type to have an associated
specific RTX SSRC. Although the config previously allowed for this, all payload
types always had the same RTX SSRC set, and the underlying RtpPayloadRegistry
did not support multiple SSRCs. This change to the config struct should thus not
have any functional impact. The change does however affect the RtcEventLog, since
that is used for storing the VideoReceiveStream::Configs. For simplicity,
this CL does not change the event log proto definitions, instead duplicating
the serialized RTX SSRCs such that they fit in the existing proto definition.
BUG=webrtc:7011
Review-Url: https://codereview.webrtc.org/2646073004
Cr-Commit-Position: refs/heads/master@{#16302}
Reason for revert:
Bugfixes related to the new jitter buffer has landed.
Original issue's description:
> Revert of Make the new jitter buffer the default jitter buffer. (patchset #2 id:230001 of https://codereview.webrtc.org/2642753002/ )
>
> Reason for revert:
> Breaks tests downstream.
>
> Original issue's description:
> > Reland of Make the new jitter buffer the default jitter buffer. (patchset #1 id:1 of https://codereview.chromium.org/2632123005/ )
> >
> > Reason for revert:
> > Fix in this CL: https://codereview.chromium.org/2640793003/
> >
> > Original issue's description:
> > > Revert of Make the new jitter buffer the default jitter buffer. (patchset #7 id:120001 of https://codereview.chromium.org/2627463004/ )
> > >
> > > Reason for revert:
> > > Breaks android bots.
> > >
> > > Original issue's description:
> > > > Make the new jitter buffer the default jitter buffer.
> > > >
> > > > This CL contains only the changes necessary to make the switch to the new jitter
> > > > buffer, clean up will be done in follow up CLs.
> > > >
> > > > In this CL:
> > > > - Removed the WebRTC-NewVideoJitterBuffer experiment and made the
> > > > new video jitter buffer the default one.
> > > > - Moved WebRTC.Video.KeyFramesReceivedInPermille and
> > > > WebRTC.Video.JitterBufferDelayInMs to the ReceiveStatisticsProxy.
> > > >
> > > > BUG=webrtc:5514
> > > >
> > > > Review-Url: https://codereview.webrtc.org/2627463004
> > > > Cr-Commit-Position: refs/heads/master@{#16114}
> > > > Committed: 0f0763d86d
> > >
> > > TBR=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:5514
> > >
> > > Review-Url: https://codereview.webrtc.org/2632123005
> > > Cr-Commit-Position: refs/heads/master@{#16117}
> > > Committed: c08c191f7d
> >
> > TBR=stefan@webrtc.org,terelius@webrtc.org
> > # Not skipping CQ checks because original CL landed more than 1 days ago.
> > BUG=webrtc:5514
> >
> > Review-Url: https://codereview.webrtc.org/2642753002
> > Cr-Commit-Position: refs/heads/master@{#16149}
> > Committed: f20dd0014d
>
> TBR=stefan@webrtc.org,terelius@webrtc.org,philipel@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:5514
>
> Review-Url: https://codereview.webrtc.org/2638423003
> Cr-Commit-Position: refs/heads/master@{#16159}
> Committed: 04926b8264TBR=stefan@webrtc.org,terelius@webrtc.org,kjellander@webrtc.org,kjellander@google.com
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:5514
Review-Url: https://codereview.webrtc.org/2652043005
Cr-Commit-Position: refs/heads/master@{#16293}
This CL introduces a dedicated unit test for webrtc::RtpStreamReceiver.
Focus of this CL is testing RtpStreamReciver::OnReceivedPayloadData().
Dependencies with virtual interfaces are (g)mocked, non-virtual
dependencies are instantiated.
This CL is chained to https://codereview.webrtc.org/2638933002/ .
BUG=webrtc:5948
Review-Url: https://codereview.webrtc.org/2641463002
Cr-Commit-Position: refs/heads/master@{#16240}
They were passed on via RtpRtcp::Configuration, but unused for a
receive only RtpRtcp module.
BUG=webrtc:6847
Review-Url: https://codereview.webrtc.org/2639423007
Cr-Commit-Position: refs/heads/master@{#16234}
Reason for revert:
Triggers leak on Linux memcheck (non-default trybot):
### BEGIN MEMORY TOOL REPORT (error hash=#0112A395AF2326BC#)
Command: ../Release/./modules_unittests --isolated-script-test-output=/b/s/w/ioUlJCnu/output.json --isolated-script-test-chartjson-output=/b/s/w/ioUlJCnu/chartjson-output.json --gtest_filter=-CommonFormats/AudioProcessingTest*
Leak_DefinitelyLost
45 bytes in 1 blocks are definitely lost in loss record 118 of 277
operator new[](unsigned long) (m_replacemalloc/vg_replace_malloc.c:363)
webrtc::video_coding::H264SpsPpsTracker::CopyAndFixBitstream(webrtc::VCMPacket*) (/b/s/w/irJgAGsR/out/Release/modules_unittests)
webrtc::video_coding::TestH264SpsPpsTracker_SpsPpsOutOfBand_Test::TestBody() (/b/s/w/irJgAGsR/out/Release/modules_unittests)
Suppression (error hash=#0112A395AF2326BC#):
For more info on using suppressions see http://dev.chromium.org/developers/tree-sheriffs/sheriff-details-chromium/memory-sheriff#TOC-Suppressing-memory-reports
{
<insert_a_suppression_name_here>
Memcheck:Leak
fun:_Zna*
fun:_ZN6webrtc12video_coding17H264SpsPpsTracker19CopyAndFixBitstreamEPNS_9VCMPacketE
fun:_ZN6webrtc12video_coding42TestH264SpsPpsTracker_SpsPpsOutOfBand_Test8TestBodyEv
}
### END MEMORY TOOL REPORT (error hash=#0112A395AF2326BC#)
Original issue's description:
> H264SpsPpsTracker.InsertSpsPpsNalus() should accept Nalus with header.
>
> - Changed method name to clarify that entire Nalus are expected.
> - Added unit test code.
> - Adjusted InsetSpsPpsNalus() implementation to above requirement.
>
> BUG=webrtc:5948
>
> Review-Url: https://codereview.webrtc.org/2638933002
> Cr-Commit-Position: refs/heads/master@{#16221}
> Committed: f53d7374cfTBR=philipel@webrtc.org,sprang@webrtc.org,johan@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5948
Review-Url: https://codereview.webrtc.org/2649113003
Cr-Commit-Position: refs/heads/master@{#16225}
- Changed method name to clarify that entire Nalus are expected.
- Added unit test code.
- Adjusted InsetSpsPpsNalus() implementation to above requirement.
BUG=webrtc:5948
Review-Url: https://codereview.webrtc.org/2638933002
Cr-Commit-Position: refs/heads/master@{#16221}
Reason for revert:
Breaks tests downstream.
Original issue's description:
> Reland of Make the new jitter buffer the default jitter buffer. (patchset #1 id:1 of https://codereview.chromium.org/2632123005/ )
>
> Reason for revert:
> Fix in this CL: https://codereview.chromium.org/2640793003/
>
> Original issue's description:
> > Revert of Make the new jitter buffer the default jitter buffer. (patchset #7 id:120001 of https://codereview.chromium.org/2627463004/ )
> >
> > Reason for revert:
> > Breaks android bots.
> >
> > Original issue's description:
> > > Make the new jitter buffer the default jitter buffer.
> > >
> > > This CL contains only the changes necessary to make the switch to the new jitter
> > > buffer, clean up will be done in follow up CLs.
> > >
> > > In this CL:
> > > - Removed the WebRTC-NewVideoJitterBuffer experiment and made the
> > > new video jitter buffer the default one.
> > > - Moved WebRTC.Video.KeyFramesReceivedInPermille and
> > > WebRTC.Video.JitterBufferDelayInMs to the ReceiveStatisticsProxy.
> > >
> > > BUG=webrtc:5514
> > >
> > > Review-Url: https://codereview.webrtc.org/2627463004
> > > Cr-Commit-Position: refs/heads/master@{#16114}
> > > Committed: 0f0763d86d
> >
> > TBR=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:5514
> >
> > Review-Url: https://codereview.webrtc.org/2632123005
> > Cr-Commit-Position: refs/heads/master@{#16117}
> > Committed: c08c191f7d
>
> TBR=stefan@webrtc.org,terelius@webrtc.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=webrtc:5514
>
> Review-Url: https://codereview.webrtc.org/2642753002
> Cr-Commit-Position: refs/heads/master@{#16149}
> Committed: f20dd0014dTBR=stefan@webrtc.org,terelius@webrtc.org,philipel@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5514
Review-Url: https://codereview.webrtc.org/2638423003
Cr-Commit-Position: refs/heads/master@{#16159}
Reason for revert:
Fix in this CL: https://codereview.chromium.org/2640793003/
Original issue's description:
> Revert of Make the new jitter buffer the default jitter buffer. (patchset #7 id:120001 of https://codereview.chromium.org/2627463004/ )
>
> Reason for revert:
> Breaks android bots.
>
> Original issue's description:
> > Make the new jitter buffer the default jitter buffer.
> >
> > This CL contains only the changes necessary to make the switch to the new jitter
> > buffer, clean up will be done in follow up CLs.
> >
> > In this CL:
> > - Removed the WebRTC-NewVideoJitterBuffer experiment and made the
> > new video jitter buffer the default one.
> > - Moved WebRTC.Video.KeyFramesReceivedInPermille and
> > WebRTC.Video.JitterBufferDelayInMs to the ReceiveStatisticsProxy.
> >
> > BUG=webrtc:5514
> >
> > Review-Url: https://codereview.webrtc.org/2627463004
> > Cr-Commit-Position: refs/heads/master@{#16114}
> > Committed: 0f0763d86d
>
> TBR=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:5514
>
> Review-Url: https://codereview.webrtc.org/2632123005
> Cr-Commit-Position: refs/heads/master@{#16117}
> Committed: c08c191f7dTBR=stefan@webrtc.org,terelius@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:5514
Review-Url: https://codereview.webrtc.org/2642753002
Cr-Commit-Position: refs/heads/master@{#16149}
Reason for revert:
Breaks android bots.
Original issue's description:
> Make the new jitter buffer the default jitter buffer.
>
> This CL contains only the changes necessary to make the switch to the new jitter
> buffer, clean up will be done in follow up CLs.
>
> In this CL:
> - Removed the WebRTC-NewVideoJitterBuffer experiment and made the
> new video jitter buffer the default one.
> - Moved WebRTC.Video.KeyFramesReceivedInPermille and
> WebRTC.Video.JitterBufferDelayInMs to the ReceiveStatisticsProxy.
>
> BUG=webrtc:5514
>
> Review-Url: https://codereview.webrtc.org/2627463004
> Cr-Commit-Position: refs/heads/master@{#16114}
> Committed: 0f0763d86dTBR=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:5514
Review-Url: https://codereview.webrtc.org/2632123005
Cr-Commit-Position: refs/heads/master@{#16117}
This CL contains only the changes necessary to make the switch to the new jitter
buffer, clean up will be done in follow up CLs.
In this CL:
- Removed the WebRTC-NewVideoJitterBuffer experiment and made the
new video jitter buffer the default one.
- Moved WebRTC.Video.KeyFramesReceivedInPermille and
WebRTC.Video.JitterBufferDelayInMs to the ReceiveStatisticsProxy.
BUG=webrtc:5514
Review-Url: https://codereview.webrtc.org/2627463004
Cr-Commit-Position: refs/heads/master@{#16114}
AddCodec represents better what this function actually does.
BUG=None
Review-Url: https://codereview.webrtc.org/2573593003
Cr-Commit-Position: refs/heads/master@{#15565}
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}
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}
