Treat negative ntp time as unset.

Treat negative ntp time as unset.

The video send pipeline uses the magic value 0 for an unset ntp time.
However, the receive pipeline uses the magic value -1 for unset
(unclear where, it seems it behaved differently a few months ago).

This makes cl https://codereview.webrtc.org/2469993003/ fail the
P2PTestConductor.ForwardVideoOnlyStream, because that cl removes code
which always clears the ntp time, and enables propagation of ntp time
from the receive pipeline to the send pipeline.

Treating ntp time <= 0 as unset is a small improvement. Ultimately, a
VideoFrame shouldn't carry an ntp time at all.

BUG=webrtc:5740, webrtc:6977
Review-Url: https://codereview.webrtc.org/2620383005
Cr-Commit-Position: refs/heads/master@{#16035}
Committed: https://chromium.googlesource.com/external/webrtc/+/891419f8e8a1b0fa2d53c887a033693652ff7d28

[nisse-webrtc, 2017-01-12 13:48:28]

nisse@webrtc.org changed reviewers:
+ sprang@webrtc.org

[nisse-webrtc, 2017-01-12 13:48:28]

PTAL. Per's refactoring cl depends on this fix.

[sprang_webrtc, 2017-01-12 14:18:43]

Looks good, but could you add a unit test for this as well?

[nisse-webrtc, 2017-01-12 14:27:08]

On 2017/01/12 14:18:43, språng wrote:
> Looks good, but could you add a unit test for this as well?

What should it test? I'd prefer not to spend too much time on it, since (i) what
it fixes is tested by the ForwardVideoOnlyStream, and (ii) the ntp time logic
ought to be deleted.

[sprang_webrtc, 2017-01-12 15:00:44]

I'm not familiar with ForwardVideoOnlyStream, but I'll trust you if you say
there's coverage already.
lgtm

[nisse-webrtc, 2017-01-12 15:31:06]

The CQ bit was checked by nisse@webrtc.org

[commit-bot: I haz the power, 2017-01-12 15:31:18]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[commit-bot: I haz the power, 2017-01-12 18:02:23]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1484235066015480, "parent_rev":
"b66129a27efd44198e4a73a27268ae17032bb617", "commit_rev":
"891419f8e8a1b0fa2d53c887a033693652ff7d28"}

[commit-bot: I haz the power, 2017-01-12 18:02:26]

Description was changed from

==========
Treat negative ntp time as unset.

The video send pipeline uses the magic value 0 for an unset ntp time.
However, the receive pipeline uses the magic value -1 for unset
(unclear where, it seems it behaved differently a few months ago).

This makes cl https://codereview.webrtc.org/2469993003/ fail the
P2PTestConductor.ForwardVideoOnlyStream, because that cl removes code
which always clears the ntp time, and enables propagation of ntp time
from the receive pipeline to the send pipeline.

Treating ntp time <= 0 as unset is a small improvement. Ultimately, a
VideoFrame shouldn't carry an ntp time at all.

BUG=webrtc:5740,webrtc:6977
==========

to

==========
Treat negative ntp time as unset.

The video send pipeline uses the magic value 0 for an unset ntp time.
However, the receive pipeline uses the magic value -1 for unset
(unclear where, it seems it behaved differently a few months ago).

This makes cl https://codereview.webrtc.org/2469993003/ fail the
P2PTestConductor.ForwardVideoOnlyStream, because that cl removes code
which always clears the ntp time, and enables propagation of ntp time
from the receive pipeline to the send pipeline.

Treating ntp time <= 0 as unset is a small improvement. Ultimately, a
VideoFrame shouldn't carry an ntp time at all.

BUG=webrtc:5740,webrtc:6977

Review-Url: https://codereview.webrtc.org/2620383005
Cr-Commit-Position: refs/heads/master@{#16035}
Committed:
https://chromium.googlesource.com/external/webrtc/+/891419f8e8a1b0fa2d53c887a...
==========

[commit-bot: I haz the power, 2017-01-12 18:02:28]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/external/webrtc/+/891419f8e8a1b0fa2d53c887a...