Revert of Don't send FEC for H.264 with NACK enabled.

Revert of Don't send FEC for H.264 with NACK enabled. (patchset #5 id:80001 of https://codereview.webrtc.org/1687303002/ )

Reason for revert:
Broke the VerifyHistogramStatsWithRed test on the Windows DrMemory Full bot and Linux Memcheck bot. Please fix the test and reland.

Original issue's description:
> Don't send FEC for H.264 with NACK enabled.
>
> The H.264 does not contain picture IDs and are not sufficient to
> determine that a packet may be skipped. This causes retransmission
> requests for FEC that are currently dropped by the sender (since they
> should be redundant).
>
> The receiver is then unable to continue without having the packet gap
> filled (unlike VP8/VP9 which moves on since it has a consecutive stream
> of picture IDs).
>
> Even if FEC retransmission did work it's a huge waste of bandwidth,
> since it just adds additional overhead that has to be unconditionally
> transmitted. This bandwidth is better used to send higher-quality
> frames.
>
> BUG=webrtc:5264
> R=stefan@webrtc.org
>
> Committed: https://crrev.com/25558ad819b4df41ba51537e26a77480ace1e525
> Cr-Commit-Position: refs/heads/master@{#11601}

TBR=stefan@webrtc.org,pbos@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5264
Committed: https://crrev.com/29ffdc1a15e31bd81e806ff135c2100d811714f0
Cr-Commit-Position: refs/heads/master@{#11607}

[Taylor Brandstetter, 2016-02-12 20:00:23]

Created Revert of Don't send FEC for H.264 with NACK enabled.

[commit-bot: I haz the power, 2016-02-12 20:00:30]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1692783005/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1692783005/1

[commit-bot: I haz the power, 2016-02-12 20:00:46]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-02-12 20:00:53]

Description was changed from

==========
Revert of Don't send FEC for H.264 with NACK enabled. (patchset #5 id:80001 of
https://codereview.webrtc.org/1687303002/ )

Reason for revert:
Broke the VerifyHistogramStatsWithRed test on the Windows DrMemory Full bot and
Linux Memcheck bot. Please fix the test and reland.

Original issue's description:
> Don't send FEC for H.264 with NACK enabled.
> 
> The H.264 does not contain picture IDs and are not sufficient to
> determine that a packet may be skipped. This causes retransmission
> requests for FEC that are currently dropped by the sender (since they
> should be redundant).
> 
> The receiver is then unable to continue without having the packet gap
> filled (unlike VP8/VP9 which moves on since it has a consecutive stream
> of picture IDs).
> 
> Even if FEC retransmission did work it's a huge waste of bandwidth,
> since it just adds additional overhead that has to be unconditionally
> transmitted. This bandwidth is better used to send higher-quality
> frames.
> 
> BUG=webrtc:5264
> R=stefan@webrtc.org
> 
> Committed: https://crrev.com/25558ad819b4df41ba51537e26a77480ace1e525
> Cr-Commit-Position: refs/heads/master@{#11601}

TBR=stefan@webrtc.org,pbos@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5264
==========

to

==========
Revert of Don't send FEC for H.264 with NACK enabled. (patchset #5 id:80001 of
https://codereview.webrtc.org/1687303002/ )

Reason for revert:
Broke the VerifyHistogramStatsWithRed test on the Windows DrMemory Full bot and
Linux Memcheck bot. Please fix the test and reland.

Original issue's description:
> Don't send FEC for H.264 with NACK enabled.
>
> The H.264 does not contain picture IDs and are not sufficient to
> determine that a packet may be skipped. This causes retransmission
> requests for FEC that are currently dropped by the sender (since they
> should be redundant).
>
> The receiver is then unable to continue without having the packet gap
> filled (unlike VP8/VP9 which moves on since it has a consecutive stream
> of picture IDs).
>
> Even if FEC retransmission did work it's a huge waste of bandwidth,
> since it just adds additional overhead that has to be unconditionally
> transmitted. This bandwidth is better used to send higher-quality
> frames.
>
> BUG=webrtc:5264
> R=stefan@webrtc.org
>
> Committed: https://crrev.com/25558ad819b4df41ba51537e26a77480ace1e525
> Cr-Commit-Position: refs/heads/master@{#11601}

TBR=stefan@webrtc.org,pbos@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5264

Committed: https://crrev.com/29ffdc1a15e31bd81e806ff135c2100d811714f0
Cr-Commit-Position: refs/heads/master@{#11607}
==========

[commit-bot: I haz the power, 2016-02-12 20:00:55]

Patchset 1 (id:??) landed as
https://crrev.com/29ffdc1a15e31bd81e806ff135c2100d811714f0
Cr-Commit-Position: refs/heads/master@{#11607}

[pbos-webrtc, 2016-02-15 10:17:07]

A revert of this CL (patchset #1 id:1) has been created in
https://codereview.webrtc.org/1697093002/ by pbos@webrtc.org.

The reason for reverting is: Disabling tests on memcheck that time out due to
using real VP8 encoders..

[pbos-webrtc, 2016-02-15 11:33:35]

On 2016/02/15 10:17:07, pbos-webrtc wrote:
> A revert of this CL (patchset #1 id:1) has been created in
> https://codereview.webrtc.org/1697093002/ by mailto:pbos@webrtc.org.
> 
> The reason for reverting is: Disabling tests on memcheck that time out due to
> using real VP8 encoders..

lgtm but relanded