2015-11-04 08:31:52 +01:00
|
|
|
/*
|
|
|
|
|
* 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.
|
|
|
|
|
*/
|
|
|
|
|
|
2017-09-15 06:47:31 +02:00
|
|
|
#ifndef MODULES_RTP_RTCP_INCLUDE_RTP_PAYLOAD_REGISTRY_H_
|
|
|
|
|
#define MODULES_RTP_RTCP_INCLUDE_RTP_PAYLOAD_REGISTRY_H_
|
2015-11-04 08:31:52 +01:00
|
|
|
|
2015-12-10 05:05:27 -08:00
|
|
|
#include <map>
|
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>
|
2015-12-10 05:05:27 -08:00
|
|
|
|
2018-06-14 12:59:38 +02:00
|
|
|
#include "absl/types/optional.h"
|
2017-09-15 06:47:31 +02:00
|
|
|
#include "api/audio_codecs/audio_format.h"
|
2018-06-08 14:03:44 +02:00
|
|
|
#include "api/video_codecs/video_codec.h"
|
2017-09-15 06:47:31 +02:00
|
|
|
#include "modules/rtp_rtcp/source/rtp_utility.h"
|
|
|
|
|
#include "rtc_base/criticalsection.h"
|
2015-11-04 08:31:52 +01:00
|
|
|
|
|
|
|
|
namespace webrtc {
|
|
|
|
|
|
|
|
|
|
class RTPPayloadRegistry {
|
|
|
|
|
public:
|
2016-11-25 06:40:25 -08:00
|
|
|
RTPPayloadRegistry();
|
2015-11-04 08:31:52 +01:00
|
|
|
~RTPPayloadRegistry();
|
|
|
|
|
|
2016-11-24 09:34:46 -08:00
|
|
|
// TODO(magjed): Split RTPPayloadRegistry into separate Audio and Video class
|
2016-11-25 06:40:25 -08:00
|
|
|
// and simplify the code. http://crbug/webrtc/6743.
|
2017-03-27 07:15:49 -07:00
|
|
|
|
|
|
|
|
// Replace all audio receive payload types with the given map.
|
|
|
|
|
void SetAudioReceivePayloads(std::map<int, SdpAudioFormat> codecs);
|
|
|
|
|
|
2017-10-04 12:38:53 +02:00
|
|
|
int32_t RegisterReceivePayload(int payload_type,
|
|
|
|
|
const SdpAudioFormat& audio_format,
|
2016-07-28 15:19:10 -07:00
|
|
|
bool* created_new_payload_type);
|
2016-11-24 09:34:46 -08:00
|
|
|
int32_t RegisterReceivePayload(const VideoCodec& video_codec);
|
2015-11-04 08:31:52 +01:00
|
|
|
|
2016-07-28 15:19:10 -07:00
|
|
|
int32_t DeRegisterReceivePayload(int8_t payload_type);
|
2015-11-04 08:31:52 +01:00
|
|
|
|
|
|
|
|
int GetPayloadTypeFrequency(uint8_t payload_type) const;
|
|
|
|
|
|
2018-06-14 12:59:38 +02:00
|
|
|
absl::optional<RtpUtility::Payload> PayloadTypeToPayload(
|
2017-09-21 15:00:58 +02:00
|
|
|
uint8_t payload_type) const;
|
2015-11-04 08:31:52 +01:00
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
// Prunes the payload type map of the specific payload type, if it exists.
|
|
|
|
|
void DeregisterAudioCodecOrRedTypeRegardlessOfPayloadType(
|
2017-10-04 12:38:53 +02:00
|
|
|
const SdpAudioFormat& audio_format);
|
2015-11-04 08:31:52 +01:00
|
|
|
|
2016-04-14 03:05:31 -07:00
|
|
|
rtc::CriticalSection crit_sect_;
|
2016-11-25 06:40:25 -08:00
|
|
|
std::map<int, RtpUtility::Payload> payload_type_map_;
|
2017-03-23 00:10:09 -07:00
|
|
|
|
|
|
|
|
// 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
|
2017-09-07 07:53:45 -07:00
|
|
|
bool used_for_audio_ RTC_GUARDED_BY(crit_sect_) = false;
|
|
|
|
|
bool used_for_video_ RTC_GUARDED_BY(crit_sect_) = false;
|
2017-03-23 00:10:09 -07:00
|
|
|
#endif
|
2015-11-04 08:31:52 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
} // namespace webrtc
|
|
|
|
|
|
2017-09-15 06:47:31 +02:00
|
|
|
#endif // MODULES_RTP_RTCP_INCLUDE_RTP_PAYLOAD_REGISTRY_H_
|