Nuke buffered latency mode. It's not actually working, and it's not used. It's just dead code com…

Nuke buffered latency mode.  It's not actually working, and it's not used.  It's just dead code complexity.

R=pbos@webrtc.org

Committed: https://chromium.googlesource.com/external/webrtc/+/a9b4c32052fd55df7e1d02e846fbea3178bebf71

[pthatcher1, 2015-07-10 22:18:09]

pthatcher@webrtc.org changed reviewers:
+ deadbeef@webrtc.org, guoweis@webrtc.org, pbos@webrtc.org

[pthatcher1, 2015-07-11 00:43:12]

On 2015/07/10 22:18:10, pthatcher1 wrote:

By the way, this found a bug in WebRtcVideoEngine2 where we were not applying
options from SetOptions (such as DSCP) if everything was the default.  I have
fixed that.  Pbos, take a look and see if you can think of a cleaner way to fix
it.

[pbos-webrtc, 2015-07-11 08:41:46]

On 2015/07/11 00:43:12, pthatcher1 wrote:
> On 2015/07/10 22:18:10, pthatcher1 wrote:
> 
> By the way, this found a bug in WebRtcVideoEngine2 where we were not applying
> options from SetOptions (such as DSCP) if everything was the default.  I have
> fixed that.  Pbos, take a look and see if you can think of a cleaner way to
fix
> it.

Setting options with default options should be a no-op. Hence ignoring them is
not a bug.

rtc::DSCP_DEFAULT should have been default (why is that not the default?), make
that happen instead.

[pthatcher1, 2015-07-13 22:23:01]

Alright, I reverted the parts in webrtcvideoengine2.cc and 
webrtcvideoengine2_unittest.cc.

[pbos-webrtc, 2015-07-14 03:58:33]

https://codereview.webrtc.org/1226093010/diff/10005/talk/media/webrtc/webrtcv...
File talk/media/webrtc/webrtcvideoengine2_unittest.cc (right):

https://codereview.webrtc.org/1226093010/diff/10005/talk/media/webrtc/webrtcv...
talk/media/webrtc/webrtcvideoengine2_unittest.cc:2186:
EXPECT_EQ(rtc::DSCP_DEFAULT, network_interface->dscp());
Keep this line, we should be doing DSCP_DEFAULT by default, right?

If this doesn't work straight off the bat, I think ::SetInterface should set
DSCP_DEFAULT (or another value) based on current options.

https://codereview.webrtc.org/1226093010/diff/50001/talk/media/webrtc/webrtcv...
File talk/media/webrtc/webrtcvideoengine2.h (right):

https://codereview.webrtc.org/1226093010/diff/50001/talk/media/webrtc/webrtcv...
talk/media/webrtc/webrtcvideoengine2.h:533: bool options_set_ = false;
Undo this one as well.

[pthatcher1, 2015-07-16 07:41:35]

https://codereview.webrtc.org/1226093010/diff/10005/talk/media/webrtc/webrtcv...
File talk/media/webrtc/webrtcvideoengine2_unittest.cc (right):

https://codereview.webrtc.org/1226093010/diff/10005/talk/media/webrtc/webrtcv...
talk/media/webrtc/webrtcvideoengine2_unittest.cc:2186:
EXPECT_EQ(rtc::DSCP_DEFAULT, network_interface->dscp());
On 2015/07/14 03:58:33, pbos-webrtc wrote:
> Keep this line, we should be doing DSCP_DEFAULT by default, right?
> 
> If this doesn't work straight off the bat, I think ::SetInterface should set
> DSCP_DEFAULT (or another value) based on current options.

Arguably, DSCP_NO_CHANGE is correct.  It means the value for DSCP wasn't changed
on the socket.  And if DSCP_DEFAULT really is the default, then the behavior is
the change.  So, I've change the test to DSCP_NO_CHANGE, which matches what the
FakeNetworkInterface is when nothing is changed.

[pthatcher1, 2015-07-16 07:42:33]

pbos, can I get an LGTM to submit the nuking of the buffered latency mode?  If
you have lingering doubts about DSCP stuff, we can do that in a separate CL.

[pbos-webrtc, 2015-07-16 08:21:27]

yeah sure, lgtm

[pthatcher1, 2015-07-16 10:47:44]

Committed patchset #5 (id:70001) manually as
a9b4c32052fd55df7e1d02e846fbea3178bebf71 (presubmit successful).