webrtc_m130/webrtc/modules/rtp_rtcp/include/rtp_payload_registry.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

158 lines
5.5 KiB
C
Raw Normal View History

/*
* Copyright (c) 2013 The WebRTC project authors. All Rights Reserved.
*
* Use of this source code is governed by a BSD-style license
* that can be found in the LICENSE file in the root of the source
* tree. An additional intellectual property rights grant can be found
* in the file PATENTS. All contributing project authors may
* be found in the AUTHORS file in the root of the source tree.
*/
#ifndef WEBRTC_MODULES_RTP_RTCP_INCLUDE_RTP_PAYLOAD_REGISTRY_H_
#define WEBRTC_MODULES_RTP_RTCP_INCLUDE_RTP_PAYLOAD_REGISTRY_H_
#include <map>
#include <memory>
Remove RED/RTX workaround from sender/receiver and VideoEngine2. 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}
2016-11-11 03:28:30 -08:00
#include <set>
#include "webrtc/api/audio_codecs/audio_format.h"
#include "webrtc/base/criticalsection.h"
Remove RED/RTX workaround from sender/receiver and VideoEngine2. 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}
2016-11-11 03:28:30 -08:00
#include "webrtc/base/deprecation.h"
#include "webrtc/modules/rtp_rtcp/source/rtp_receiver_strategy.h"
#include "webrtc/modules/rtp_rtcp/source/rtp_utility.h"
namespace webrtc {
struct CodecInst;
class VideoCodec;
Reland of move RTPPayloadStrategy and simplify RTPPayloadRegistry (patchset #1 id:1 of https://codereview.webrtc.org/2528993002/ ) 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}
2016-11-25 06:40:25 -08:00
// TODO(magjed): Remove once external code is updated.
class RTPPayloadStrategy {
public:
Reland of move RTPPayloadStrategy and simplify RTPPayloadRegistry (patchset #1 id:1 of https://codereview.webrtc.org/2528993002/ ) 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}
2016-11-25 06:40:25 -08:00
static RTPPayloadStrategy* CreateStrategy(bool handling_audio) {
return nullptr;
}
};
class RTPPayloadRegistry {
public:
Reland of move RTPPayloadStrategy and simplify RTPPayloadRegistry (patchset #1 id:1 of https://codereview.webrtc.org/2528993002/ ) 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}
2016-11-25 06:40:25 -08:00
RTPPayloadRegistry();
~RTPPayloadRegistry();
Reland of move RTPPayloadStrategy and simplify RTPPayloadRegistry (patchset #1 id:1 of https://codereview.webrtc.org/2528993002/ ) 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}
2016-11-25 06:40:25 -08:00
// TODO(magjed): Remove once external code is updated.
explicit RTPPayloadRegistry(RTPPayloadStrategy* rtp_payload_strategy)
: RTPPayloadRegistry() {}
// TODO(magjed): Split RTPPayloadRegistry into separate Audio and Video class
Reland of move RTPPayloadStrategy and simplify RTPPayloadRegistry (patchset #1 id:1 of https://codereview.webrtc.org/2528993002/ ) 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}
2016-11-25 06:40:25 -08:00
// and simplify the code. http://crbug/webrtc/6743.
// Replace all audio receive payload types with the given map.
void SetAudioReceivePayloads(std::map<int, SdpAudioFormat> codecs);
int32_t RegisterReceivePayload(const CodecInst& audio_codec,
bool* created_new_payload_type);
int32_t RegisterReceivePayload(const VideoCodec& video_codec);
int32_t DeRegisterReceivePayload(int8_t payload_type);
int32_t ReceivePayloadType(const CodecInst& audio_codec,
int8_t* payload_type) const;
int32_t ReceivePayloadType(const VideoCodec& video_codec,
int8_t* payload_type) const;
bool RtxEnabled() const;
void SetRtxSsrc(uint32_t ssrc);
bool GetRtxSsrc(uint32_t* ssrc) const;
void SetRtxPayloadType(int payload_type, int associated_payload_type);
bool IsRtx(const RTPHeader& header) const;
bool RestoreOriginalPacket(uint8_t* restored_packet,
const uint8_t* packet,
size_t* packet_length,
uint32_t original_ssrc,
Remove RED/RTX workaround from sender/receiver and VideoEngine2. 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}
2016-11-11 03:28:30 -08:00
const RTPHeader& header);
bool IsRed(const RTPHeader& header) const;
// Returns true if the media of this RTP packet is encapsulated within an
// extra header, such as RTX or RED.
bool IsEncapsulated(const RTPHeader& header) const;
bool GetPayloadSpecifics(uint8_t payload_type, PayloadUnion* payload) const;
int GetPayloadTypeFrequency(uint8_t payload_type) const;
const RtpUtility::Payload* PayloadTypeToPayload(uint8_t payload_type) const;
void ResetLastReceivedPayloadTypes() {
rtc::CritScope cs(&crit_sect_);
last_received_payload_type_ = -1;
last_received_media_payload_type_ = -1;
}
// This sets the payload type of the packets being received from the network
// on the media SSRC. For instance if packets are encapsulated with RED, this
// payload type will be the RED payload type.
void SetIncomingPayloadType(const RTPHeader& header);
// Returns true if the new media payload type has not changed.
bool ReportMediaPayloadType(uint8_t media_payload_type);
Reland of move RTPPayloadStrategy and simplify RTPPayloadRegistry (patchset #1 id:1 of https://codereview.webrtc.org/2528993002/ ) 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}
2016-11-25 06:40:25 -08:00
int8_t red_payload_type() const { return GetPayloadTypeWithName("red"); }
int8_t ulpfec_payload_type() const {
Reland of move RTPPayloadStrategy and simplify RTPPayloadRegistry (patchset #1 id:1 of https://codereview.webrtc.org/2528993002/ ) 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}
2016-11-25 06:40:25 -08:00
return GetPayloadTypeWithName("ulpfec");
}
int8_t last_received_payload_type() const {
rtc::CritScope cs(&crit_sect_);
return last_received_payload_type_;
}
void set_last_received_payload_type(int8_t last_received_payload_type) {
rtc::CritScope cs(&crit_sect_);
last_received_payload_type_ = last_received_payload_type;
}
int8_t last_received_media_payload_type() const {
rtc::CritScope cs(&crit_sect_);
return last_received_media_payload_type_;
}
Remove RED/RTX workaround from sender/receiver and VideoEngine2. 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}
2016-11-11 03:28:30 -08:00
RTC_DEPRECATED void set_use_rtx_payload_mapping_on_restore(bool val) {}
private:
// Prunes the payload type map of the specific payload type, if it exists.
void DeregisterAudioCodecOrRedTypeRegardlessOfPayloadType(
Reland of move RTPPayloadStrategy and simplify RTPPayloadRegistry (patchset #1 id:1 of https://codereview.webrtc.org/2528993002/ ) 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}
2016-11-25 06:40:25 -08:00
const CodecInst& audio_codec);
bool IsRtxInternal(const RTPHeader& header) const;
Reland of move RTPPayloadStrategy and simplify RTPPayloadRegistry (patchset #1 id:1 of https://codereview.webrtc.org/2528993002/ ) 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}
2016-11-25 06:40:25 -08:00
// Returns the payload type for the payload with name |payload_name|, or -1 if
// no such payload is registered.
int8_t GetPayloadTypeWithName(const char* payload_name) const;
rtc::CriticalSection crit_sect_;
Reland of move RTPPayloadStrategy and simplify RTPPayloadRegistry (patchset #1 id:1 of https://codereview.webrtc.org/2528993002/ ) 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}
2016-11-25 06:40:25 -08:00
std::map<int, RtpUtility::Payload> payload_type_map_;
int8_t incoming_payload_type_;
int8_t last_received_payload_type_;
int8_t last_received_media_payload_type_;
bool rtx_;
// Mapping rtx_payload_type_map_[rtx] = associated.
std::map<int, int> rtx_payload_type_map_;
uint32_t ssrc_rtx_;
Remove RED/RTX workaround from sender/receiver and VideoEngine2. 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}
2016-11-11 03:28:30 -08:00
// Only warn once per payload type, if an RTX packet is received but
// no associated payload type found in |rtx_payload_type_map_|.
std::set<int> payload_types_with_suppressed_warnings_ GUARDED_BY(crit_sect_);
// As a first step in splitting this class up in separate cases for audio and
// video, DCHECK that no instance is used for both audio and video.
#if RTC_DCHECK_IS_ON
bool used_for_audio_ GUARDED_BY(crit_sect_) = false;
bool used_for_video_ GUARDED_BY(crit_sect_) = false;
#endif
};
} // namespace webrtc
#endif // WEBRTC_MODULES_RTP_RTCP_INCLUDE_RTP_PAYLOAD_REGISTRY_H_