Use system timestamp as capture timestamp

Use system timestamp as capture timestamp

For rendering smoothness, we used camera timestamp as capture timestamp,
but if the clockrate of the camera is different from the system clock,
it will make audio-video out of sync. So we change it back so far.

This CL is essentially a revert of
https://codereview.chromium.org/1324683004/
https://codereview.chromium.org/1421583007/

P.S. An ideal solution is that we should take in camera
timestamp, but smoothly aligned with system clock. But at
this point, we should make a quick CL to resolve this issue.

BUG=584015
Committed: https://crrev.com/8e0974d2b27ab55a8df948b86804bf0f11c036e2
Cr-Commit-Position: refs/heads/master@{#373966}

[qiangchen, 2016-02-05 23:51:22]

Description was changed from

==========
Use system timestamp as capture timestamp

For rendering smoothness, we used camera timestamp as capture timestamp, but
it may lead to audio-video sync issue. So we change it back so far.

BUG=584015
==========

to

==========
Use system timestamp as capture timestamp

For rendering smoothness, we used camera timestamp as capture timestamp, but
if the clockrate of the camera is different from the system clock, 
it will make audio-video out of sync. So we change it back so far.

P.S. An ideal solution is that we should take in camera
timestamp, but smoothly aligned with system clock. But at
this point, we should make a quick CL to resolve this issue.

BUG=584015
==========

[qiangchen, 2016-02-05 23:52:09]

Description was changed from

==========
Use system timestamp as capture timestamp

For rendering smoothness, we used camera timestamp as capture timestamp, but
if the clockrate of the camera is different from the system clock, 
it will make audio-video out of sync. So we change it back so far.

P.S. An ideal solution is that we should take in camera
timestamp, but smoothly aligned with system clock. But at
this point, we should make a quick CL to resolve this issue.

BUG=584015
==========

to

==========
Use system timestamp as capture timestamp

For rendering smoothness, we used camera timestamp as capture timestamp, 
but if the clockrate of the camera is different from the system clock, 
it will make audio-video out of sync. So we change it back so far.

P.S. An ideal solution is that we should take in camera
timestamp, but smoothly aligned with system clock. But at
this point, we should make a quick CL to resolve this issue.

BUG=584015
==========

[qiangchen, 2016-02-05 23:52:09]

qiangchen@chromium.org changed reviewers:
+ dalecurtis@chromium.org

[qiangchen, 2016-02-05 23:52:23]

qiangchen@chromium.org changed reviewers:
+ pbos@chromium.org

[qiangchen, 2016-02-05 23:59:08]

Description was changed from

==========
Use system timestamp as capture timestamp

For rendering smoothness, we used camera timestamp as capture timestamp, 
but if the clockrate of the camera is different from the system clock, 
it will make audio-video out of sync. So we change it back so far.

P.S. An ideal solution is that we should take in camera
timestamp, but smoothly aligned with system clock. But at
this point, we should make a quick CL to resolve this issue.

BUG=584015
==========

to

==========
Use system timestamp as capture timestamp

For rendering smoothness, we used camera timestamp as capture timestamp, 
but if the clockrate of the camera is different from the system clock, 
it will make audio-video out of sync. So we change it back so far.

This CL is essentially a revert of 
https://codereview.chromium.org/1324683004/
https://codereview.chromium.org/1421583007/

P.S. An ideal solution is that we should take in camera
timestamp, but smoothly aligned with system clock. But at
this point, we should make a quick CL to resolve this issue.

BUG=584015
==========

[qiangchen, 2016-02-05 23:59:42]

PTAL.

It should be fixed asap.

[DaleCurtis, 2016-02-06 00:07:22]

lgtm

[qiangchen, 2016-02-06 00:17:07]

The CQ bit was checked by qiangchen@chromium.org

[commit-bot: I haz the power, 2016-02-06 00:17:51]

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

[commit-bot: I haz the power, 2016-02-06 00:25:53]

Description was changed from

==========
Use system timestamp as capture timestamp

For rendering smoothness, we used camera timestamp as capture timestamp, 
but if the clockrate of the camera is different from the system clock, 
it will make audio-video out of sync. So we change it back so far.

This CL is essentially a revert of 
https://codereview.chromium.org/1324683004/
https://codereview.chromium.org/1421583007/

P.S. An ideal solution is that we should take in camera
timestamp, but smoothly aligned with system clock. But at
this point, we should make a quick CL to resolve this issue.

BUG=584015
==========

to

==========
Use system timestamp as capture timestamp

For rendering smoothness, we used camera timestamp as capture timestamp, 
but if the clockrate of the camera is different from the system clock, 
it will make audio-video out of sync. So we change it back so far.

This CL is essentially a revert of 
https://codereview.chromium.org/1324683004/
https://codereview.chromium.org/1421583007/

P.S. An ideal solution is that we should take in camera
timestamp, but smoothly aligned with system clock. But at
this point, we should make a quick CL to resolve this issue.

BUG=584015
==========

[commit-bot: I haz the power, 2016-02-06 00:25:53]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-02-06 00:28:32]

Description was changed from

==========
Use system timestamp as capture timestamp

For rendering smoothness, we used camera timestamp as capture timestamp, 
but if the clockrate of the camera is different from the system clock, 
it will make audio-video out of sync. So we change it back so far.

This CL is essentially a revert of 
https://codereview.chromium.org/1324683004/
https://codereview.chromium.org/1421583007/

P.S. An ideal solution is that we should take in camera
timestamp, but smoothly aligned with system clock. But at
this point, we should make a quick CL to resolve this issue.

BUG=584015
==========

to

==========
Use system timestamp as capture timestamp

For rendering smoothness, we used camera timestamp as capture timestamp,
but if the clockrate of the camera is different from the system clock,
it will make audio-video out of sync. So we change it back so far.

This CL is essentially a revert of
https://codereview.chromium.org/1324683004/
https://codereview.chromium.org/1421583007/

P.S. An ideal solution is that we should take in camera
timestamp, but smoothly aligned with system clock. But at
this point, we should make a quick CL to resolve this issue.

BUG=584015

Committed: https://crrev.com/8e0974d2b27ab55a8df948b86804bf0f11c036e2
Cr-Commit-Position: refs/heads/master@{#373966}
==========

[commit-bot: I haz the power, 2016-02-06 00:28:33]

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

[pbos, 2016-02-06 13:15:28]

lgtm

[qiangchen, 2016-03-10 20:54:02]

A revert of this CL (patchset #1 id:1) has been created in
https://codereview.chromium.org/1783603004/ by qiangchen@chromium.org.

The reason for reverting is: WebRTC part of the issue has been fixed.
Thus we can reland the camera timestamp CL..