Chromium Code Reviews| Index: webrtc/video/video_send_stream.cc | 
| diff --git a/webrtc/video/video_send_stream.cc b/webrtc/video/video_send_stream.cc | 
| index 10d3cfd3ed59658eb783d19785a853a3e00d76cf..2ab78ce77de6815d9e096ed08e96a634e8656656 100644 | 
| --- a/webrtc/video/video_send_stream.cc | 
| +++ b/webrtc/video/video_send_stream.cc | 
| @@ -922,7 +922,8 @@ void VideoSendStreamImpl::ConfigureProtection() { | 
| RTC_DCHECK_RUN_ON(worker_queue_); | 
| 
 
brandtr
2016/10/27 11:06:24
This function will see further changes in future C
 
 | 
| // Enable NACK, FEC or both. | 
| const bool enable_protection_nack = config_->rtp.nack.rtp_history_ms > 0; | 
| - bool enable_protection_fec = config_->rtp.ulpfec.ulpfec_payload_type != -1; | 
| + const int red_payload_type = config_->rtp.ulpfec.red_payload_type; | 
| + int ulpfec_payload_type = config_->rtp.ulpfec.ulpfec_payload_type; | 
| // Payload types without picture ID cannot determine that a stream is complete | 
| // without retransmitting FEC, so using FEC + NACK for H.264 (for instance) is | 
| // a waste of bandwidth since FEC packets still have to be transmitted. Note | 
| @@ -933,24 +934,24 @@ void VideoSendStreamImpl::ConfigureProtection() { | 
| LOG(LS_WARNING) << "Transmitting payload type without picture ID using" | 
| "NACK+FEC is a waste of bandwidth since FEC packets " | 
| "also have to be retransmitted. Disabling FEC."; | 
| - enable_protection_fec = false; | 
| + ulpfec_payload_type = -1; | 
| } | 
| // TODO(changbin): Should set RTX for RED mapping in RTP sender in future. | 
| // Validate payload types. If either RED or FEC payload types are set then | 
| // both should be. If FEC is enabled then they both have to be set. | 
| - if (config_->rtp.ulpfec.red_payload_type != -1) { | 
| - RTC_DCHECK_GE(config_->rtp.ulpfec.red_payload_type, 0); | 
| - RTC_DCHECK_LE(config_->rtp.ulpfec.red_payload_type, 127); | 
| + if (red_payload_type != -1) { | 
| + RTC_DCHECK_GE(red_payload_type, 0); | 
| + RTC_DCHECK_LE(red_payload_type, 127); | 
| // TODO(holmer): We should only enable red if ulpfec is also enabled, but | 
| // but due to an incompatibility issue with previous versions the receiver | 
| // assumes rtx packets are containing red if it has been configured to | 
| // receive red. Remove this in a few versions once the incompatibility | 
| // issue is resolved (M53 timeframe). | 
| } | 
| - if (config_->rtp.ulpfec.ulpfec_payload_type != -1) { | 
| - RTC_DCHECK_GE(config_->rtp.ulpfec.ulpfec_payload_type, 0); | 
| - RTC_DCHECK_LE(config_->rtp.ulpfec.ulpfec_payload_type, 127); | 
| + if (ulpfec_payload_type != -1) { | 
| + RTC_DCHECK_GE(ulpfec_payload_type, 0); | 
| + RTC_DCHECK_LE(ulpfec_payload_type, 127); | 
| } | 
| for (RtpRtcp* rtp_rtcp : rtp_rtcp_modules_) { | 
| @@ -960,12 +961,11 @@ void VideoSendStreamImpl::ConfigureProtection() { | 
| kMinSendSidePacketHistorySize); | 
| // Set FEC. | 
| for (RtpRtcp* rtp_rtcp : rtp_rtcp_modules_) { | 
| - rtp_rtcp->SetUlpfecConfig(enable_protection_fec, | 
| - config_->rtp.ulpfec.red_payload_type, | 
| - config_->rtp.ulpfec.ulpfec_payload_type); | 
| + rtp_rtcp->SetUlpfecConfig(red_payload_type, ulpfec_payload_type); | 
| } | 
| } | 
| + const bool enable_protection_fec = (ulpfec_payload_type != -1); | 
| protection_bitrate_calculator_.SetProtectionMethod(enable_protection_fec, | 
| enable_protection_nack); | 
| } |