Remove now unused code in RtpHeaderExtensionMap

webrtc/modules/rtp_rtcp/source/rtp_sender_video.cc

 /*
  *  Copyright (c) 2012 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.
  */
 
@@ skipping 229 matching lines @@
   // http://www.etsi.org/deliver/etsi_ts/126100_126199/126114/12.07.00_60/
   // ts_126114v120700p.pdf Section 7.4.5:
   // The MTSI client shall add the payload bytes as defined in this clause
   // onto the last RTP packet in each group of packets which make up a key
   // frame (I-frame or IDR frame in H.264 (AVC), or an IRAP picture in H.265
   // (HEVC)). The MTSI client may also add the payload bytes onto the last RTP
   // packet in each group of packets which make up another type of frame
   // (e.g. a P-Frame) only if the current value is different from the previous
   // value sent.
   // Here we are adding it to every packet of every frame at this point.
-  if (video_header && video_header->rotation != kVideoRotation_0) {
-    // TODO(danilchap): Remove next call together with concept
-    // of inactive extension. Now it helps to calulate total maximum size
-    // or rtp header extensions that is used in FECPacketOverhead() function.
-    rtp_sender_->ActivateCVORtpHeaderExtension();
+  if (video_header && video_header->rotation != kVideoRotation_0)

[sprang_webrtc, 2016/10/24 13:48:10]

Just to be clear, how exactly is this rotation extension supposed to work...
The "rotation != kVideoRotation_0" makes me worried we can get into a situation,
where we toggle to 90 rotation and then back to 0, but 0 won't be sent so we're
stuck a 90? Or do we always interpret lack of rotation extension as implicit 0
rotation?

[danilchap, 2016/10/24 14:27:25]

No rotation extension means it is 0.
Before my refactorings this extension was also skipped when rotation was 0, even
if previous was 90:
bool video_rotation_active = false;
if (video_header && video_header->rotation != kVideoRotation_0) {
  video_rotation_active = rtp_sender_->ActivateCVORtpHeaderExtension();
}

But before, even if extension was skipped, place for it was reserved as soon as
there was non-zero rotation at least once. Now the space is used only when
extension is actually set.
Before place in fec was reserved only after non-zero value was observed. Now
[with this CL] it is always reserved. (sure only if it is registered and fec is
enabled). 

[sprang_webrtc, 2016/10/25 07:47:00]

Acknowledged.

I interpreted the previous "rtp_sender_->ActivateCVORtpHeaderExtension()" call
to be sticky, so that the extension was first introduced when rotation != 0, but
was then kept for the rest of the call even when rotation returned to 0.

I'll trust you though. :)

     rtp_header->SetExtension<VideoOrientation>(video_header->rotation);
-  }
 
   size_t packet_capacity = rtp_sender_->MaxPayloadLength() -
                            FecPacketOverhead() -
                            (rtp_sender_->RtxStatus() ? kRtxHeaderSize : 0);
   RTC_DCHECK_LE(packet_capacity, rtp_header->capacity());
   RTC_DCHECK_GT(packet_capacity, rtp_header->headers_size());
   size_t max_data_payload_length = packet_capacity - rtp_header->headers_size();
 
   std::unique_ptr<RtpPacketizer> packetizer(RtpPacketizer::Create(
       video_type, max_data_payload_length,
@@ skipping 74 matching lines @@
   rtc::CritScope cs(&crit_);
   return retransmission_settings_;
 }
 
 void RTPSenderVideo::SetSelectiveRetransmissions(uint8_t settings) {
   rtc::CritScope cs(&crit_);
   retransmission_settings_ = settings;
 }
 
 }  // namespace webrtc