Remove RED/RTX workaround from sender/receiver and VideoEngine2.

webrtc/modules/rtp_rtcp/source/rtp_sender.cc

Index: webrtc/modules/rtp_rtcp/source/rtp_sender.cc
diff --git a/webrtc/modules/rtp_rtcp/source/rtp_sender.cc b/webrtc/modules/rtp_rtcp/source/rtp_sender.cc
index a3593c604e1217682fec0f819933042ce9764e52..f9e5db15dd864e8cdb7d1039c5489ba361c84e44 100644
--- a/webrtc/modules/rtp_rtcp/source/rtp_sender.cc
+++ b/webrtc/modules/rtp_rtcp/source/rtp_sender.cc
@@ -1158,14 +1158,9 @@ std::unique_ptr<RtpPacketToSend> RTPSender::BuildRtxPacket(
     rtc::CritScope lock(&send_critsect_);
     if (!sending_media_)
       return nullptr;
-    // Replace payload type, if a specific type is set for RTX.
-    auto kv = rtx_payload_type_map_.find(packet.PayloadType());
 
-    // Use rtx mapping associated with media codec if we can't find one,
-    // assume it's red.
-    // TODO(holmer): Remove once old Chrome versions don't rely on this.
-    if (kv == rtx_payload_type_map_.end())
-      kv = rtx_payload_type_map_.find(payload_type_);
+    // Replace payload type.
+    auto kv = rtx_payload_type_map_.find(packet.PayloadType());
     if (kv != rtx_payload_type_map_.end())

[danilchap, 2016/11/02 13:56:52]

this look like hack 'If no payload type mapping existed, the payload type of the
underlying media would be used.'
Is it still needed, or is it safe to reject sending rtx packet:
if (kv == rtx_map_.end())
  return nullptr;

[brandtr, 2016/11/03 12:02:48]

It should be safe to reject sending it, because all associated payload types are
set here:
https://cs.chromium.org/chromium/src/third_party/webrtc/video/video_send_stre...

+holmer: can you verify this?

       rtx_packet->SetPayloadType(kv->second);