Fix bandwidth estimation on remoting webrtc

Fix bandwidth estimation on remoting webrtc

The socket factory implementation on remoting was incorrectly
providing millisecond timestamps for updating the absolute time
RTP extension and this was the cause of the broken bandwidth
estimation on both the tests and the implementation.

On the test, I see significant improvements in the overall latency
numbers. The test itself is still not entirely correct due to
the way the frame ids are handled.

BUG=601713
TEST results:

Previously:

Average latency for big frames: 1562.03
Average latency for small frames: 1245.65

Bandwidth fix (with local test fix for unique frame id):

Average latency (ms): 73.851 average loss (%): 0
Average latency for big frames: 277.975
Average latency for small frames: 76.221

Committed: https://crrev.com/3943d65cbc744467a489b7013cd736025851ef24
Cr-Commit-Position: refs/heads/master@{#386108}

[Irfan, 2016-04-08 06:56:05]

Description was changed from

==========
Fix bandwidth estimation on remoting webrtc

The socket factory implementation on remoting was incorrectly
providing millisecond timestamps for updating the absolute time
RTP extension and this was the cause of the broken bandwidth
estimation on both the tests and the implementation.

On the test, I see significant improvements in the overall latency
numbers. The test itself is still not entirely correct due to
the way the frame ids are handled.

BUG=601713
==========

to

==========
Fix bandwidth estimation on remoting webrtc

The socket factory implementation on remoting was incorrectly
providing millisecond timestamps for updating the absolute time
RTP extension and this was the cause of the broken bandwidth
estimation on both the tests and the implementation.

On the test, I see significant improvements in the overall latency
numbers. The test itself is still not entirely correct due to
the way the frame ids are handled.

BUG=601713
==========

[Irfan, 2016-04-08 06:56:05]

isheriff@chromium.org changed reviewers:
+ sergeyu@chromium.org

[Irfan, 2016-04-08 06:57:20]

PTAL. I am yet to evaluate the benefit on real sockets, but it helps a lot on
the tests.

[Irfan, 2016-04-08 07:58:11]

Patchset #1 (id:1) has been deleted

[Irfan, 2016-04-08 08:26:44]

Description was changed from

==========
Fix bandwidth estimation on remoting webrtc

The socket factory implementation on remoting was incorrectly
providing millisecond timestamps for updating the absolute time
RTP extension and this was the cause of the broken bandwidth
estimation on both the tests and the implementation.

On the test, I see significant improvements in the overall latency
numbers. The test itself is still not entirely correct due to
the way the frame ids are handled.

BUG=601713
==========

to

==========
Fix bandwidth estimation on remoting webrtc

The socket factory implementation on remoting was incorrectly
providing millisecond timestamps for updating the absolute time
RTP extension and this was the cause of the broken bandwidth
estimation on both the tests and the implementation.

On the test, I see significant improvements in the overall latency
numbers. The test itself is still not entirely correct due to
the way the frame ids are handled.

BUG=601713

TEST results:

Previously:

Average latency for big frames: 1562.03
Average latency for small frames: 1245.65


Bandwidth fix (with local test fix for unique frame id):

Average latency (ms): 73.851 average loss (%): 0
Average latency for big frames: 277.975
Average latency for small frames: 76.221
==========

[Irfan, 2016-04-08 08:27:19]

Test results on remoting_perftests:

Previously:

Average latency for big frames: 1562.03
Average latency for small frames: 1245.65


Bandwidth fix (with local test fix for unique frame id):

Average latency (ms): 73.851 average loss (%): 0
Average latency for big frames: 277.975
Average latency for small frames: 76.221

[Sergey Ulanov, 2016-04-08 17:13:27]

LGTM. Thanks for tracking this down!
I wish WebRTC used TimeDelta type, then it would be impossible to make mistake
like this.

[Sergey Ulanov, 2016-04-08 17:13:52]

The CQ bit was checked by sergeyu@chromium.org

[commit-bot: I haz the power, 2016-04-08 17:14:17]

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

[commit-bot: I haz the power, 2016-04-08 17:20:07]

Description was changed from

==========
Fix bandwidth estimation on remoting webrtc

The socket factory implementation on remoting was incorrectly
providing millisecond timestamps for updating the absolute time
RTP extension and this was the cause of the broken bandwidth
estimation on both the tests and the implementation.

On the test, I see significant improvements in the overall latency
numbers. The test itself is still not entirely correct due to
the way the frame ids are handled.

BUG=601713

TEST results:

Previously:

Average latency for big frames: 1562.03
Average latency for small frames: 1245.65


Bandwidth fix (with local test fix for unique frame id):

Average latency (ms): 73.851 average loss (%): 0
Average latency for big frames: 277.975
Average latency for small frames: 76.221
==========

to

==========
Fix bandwidth estimation on remoting webrtc

The socket factory implementation on remoting was incorrectly
providing millisecond timestamps for updating the absolute time
RTP extension and this was the cause of the broken bandwidth
estimation on both the tests and the implementation.

On the test, I see significant improvements in the overall latency
numbers. The test itself is still not entirely correct due to
the way the frame ids are handled.

BUG=601713

TEST results:

Previously:

Average latency for big frames: 1562.03
Average latency for small frames: 1245.65


Bandwidth fix (with local test fix for unique frame id):

Average latency (ms): 73.851 average loss (%): 0
Average latency for big frames: 277.975
Average latency for small frames: 76.221
==========

[commit-bot: I haz the power, 2016-04-08 17:20:08]

Committed patchset #1 (id:20001)

[commit-bot: I haz the power, 2016-04-08 17:21:35]

Description was changed from

==========
Fix bandwidth estimation on remoting webrtc

The socket factory implementation on remoting was incorrectly
providing millisecond timestamps for updating the absolute time
RTP extension and this was the cause of the broken bandwidth
estimation on both the tests and the implementation.

On the test, I see significant improvements in the overall latency
numbers. The test itself is still not entirely correct due to
the way the frame ids are handled.

BUG=601713

TEST results:

Previously:

Average latency for big frames: 1562.03
Average latency for small frames: 1245.65


Bandwidth fix (with local test fix for unique frame id):

Average latency (ms): 73.851 average loss (%): 0
Average latency for big frames: 277.975
Average latency for small frames: 76.221
==========

to

==========
Fix bandwidth estimation on remoting webrtc

The socket factory implementation on remoting was incorrectly
providing millisecond timestamps for updating the absolute time
RTP extension and this was the cause of the broken bandwidth
estimation on both the tests and the implementation.

On the test, I see significant improvements in the overall latency
numbers. The test itself is still not entirely correct due to
the way the frame ids are handled.

BUG=601713

TEST results:

Previously:

Average latency for big frames: 1562.03
Average latency for small frames: 1245.65

Bandwidth fix (with local test fix for unique frame id):

Average latency (ms): 73.851 average loss (%): 0
Average latency for big frames: 277.975
Average latency for small frames: 76.221

Committed: https://crrev.com/3943d65cbc744467a489b7013cd736025851ef24
Cr-Commit-Position: refs/heads/master@{#386108}
==========

[commit-bot: I haz the power, 2016-04-08 17:21:36]

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