Change reporting of timing frames conditions in GetStats on receive side

Change reporting of timing frames conditions in GetStats on receive side

Instead of the longest frame since the last GetStats call, the longest
frame received during last 10 seconds should be returned in GetStats().

Previous way is not a good idea because there are maybe several
consumers of GetStats calls. If not all of them parse timing frame
reports, some of them may be lost.

Also, streamline reporting of TimingFrames via GetStats (remove separate
methods and use VideoReceiveStream::Stats struct instead).

Merge into M62. Original reviewed here: https://codereview.webrtc.org/3008983002

BUG=webrtc:7594, chromium:762872
NOTRY=true
NOPRESUBMIT=true
TBR=sprang@webrtc.org

Review-Url: https://codereview.webrtc.org/3012073002
Cr-Commit-Position: refs/branch-heads/62@{#6}
Cr-Branched-From: 85e6a4ba1372f21b8648ffaad2fd19a76a8bb316-refs/heads/master@{#19592}
Committed: https://chromium.googlesource.com/external/webrtc/+/625b4cccdb02c07405106ed7b312956dae9d003e

[ilnik, 2017-09-08 10:23:14]

ilnik@webrtc.org changed reviewers:
+ tommi@webrtc.org

[ilnik, 2017-09-08 10:27:30]

Description was changed from

==========
Change reporting of timing frames conditions in GetStats on receive side

Instead of the longest frame since the last GetStats call, the longest
frame received during last 10 seconds should be returned in GetStats().

Previous way is not a good idea because there are maybe several
consumers of GetStats calls. If not all of them parse timing frame
reports, some of them may be lost.

Also, streamline reporting of TimingFrames via GetStats (remove separate
methods and use VideoReceiveStream::Stats struct instead).

Merge into M62. Original reviewed here: https://codereview.webrtc.org/3008983002

BUG=webrtc:7594,chromium:762872
NOTRY=true
NOPRESUBMIT=true

Review-Url: https://codereview.webrtc.org/3008983002
Cr-Commit-Position: refs/heads/master@{#19650}
(cherry picked from commit 75204c5ccdda561ccffbfa3a8fa94feac8e19e30)
==========

to

==========
Change reporting of timing frames conditions in GetStats on receive side

Instead of the longest frame since the last GetStats call, the longest
frame received during last 10 seconds should be returned in GetStats().

Previous way is not a good idea because there are maybe several
consumers of GetStats calls. If not all of them parse timing frame
reports, some of them may be lost.

Also, streamline reporting of TimingFrames via GetStats (remove separate
methods and use VideoReceiveStream::Stats struct instead).

Merge into M62. Original reviewed here: https://codereview.webrtc.org/3008983002

BUG=webrtc:7594,chromium:762872
NOTRY=true
NOPRESUBMIT=true
==========

[tommi, 2017-09-08 11:42:40]

Description was changed from

==========
Change reporting of timing frames conditions in GetStats on receive side

Instead of the longest frame since the last GetStats call, the longest
frame received during last 10 seconds should be returned in GetStats().

Previous way is not a good idea because there are maybe several
consumers of GetStats calls. If not all of them parse timing frame
reports, some of them may be lost.

Also, streamline reporting of TimingFrames via GetStats (remove separate
methods and use VideoReceiveStream::Stats struct instead).

Merge into M62. Original reviewed here: https://codereview.webrtc.org/3008983002

BUG=webrtc:7594,chromium:762872
NOTRY=true
NOPRESUBMIT=true
==========

to

==========
Change reporting of timing frames conditions in GetStats on receive side

Instead of the longest frame since the last GetStats call, the longest
frame received during last 10 seconds should be returned in GetStats().

Previous way is not a good idea because there are maybe several
consumers of GetStats calls. If not all of them parse timing frame
reports, some of them may be lost.

Also, streamline reporting of TimingFrames via GetStats (remove separate
methods and use VideoReceiveStream::Stats struct instead).

Merge into M62. Original reviewed here: https://codereview.webrtc.org/3008983002

BUG=webrtc:7594,chromium:762872
NOTRY=true
NOPRESUBMIT=true
TBR=sprang@webrtc.org
==========

[tommi, 2017-09-08 11:42:40]

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

[tommi, 2017-09-08 11:42:46]

lgtm

[ilnik, 2017-09-08 12:27:08]

The CQ bit was checked by ilnik@webrtc.org

[commit-bot: I haz the power, 2017-09-08 12:27:11]

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-09-08 12:27:44]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1504873628498340, "parent_rev":
"7e46bc497c8b231585fdcc764605d0996b5909fa", "commit_rev":
"625b4cccdb02c07405106ed7b312956dae9d003e"}

[commit-bot: I haz the power, 2017-09-08 12:27:47]

Description was changed from

==========
Change reporting of timing frames conditions in GetStats on receive side

Instead of the longest frame since the last GetStats call, the longest
frame received during last 10 seconds should be returned in GetStats().

Previous way is not a good idea because there are maybe several
consumers of GetStats calls. If not all of them parse timing frame
reports, some of them may be lost.

Also, streamline reporting of TimingFrames via GetStats (remove separate
methods and use VideoReceiveStream::Stats struct instead).

Merge into M62. Original reviewed here: https://codereview.webrtc.org/3008983002

BUG=webrtc:7594,chromium:762872
NOTRY=true
NOPRESUBMIT=true
TBR=sprang@webrtc.org
==========

to

==========
Change reporting of timing frames conditions in GetStats on receive side

Instead of the longest frame since the last GetStats call, the longest
frame received during last 10 seconds should be returned in GetStats().

Previous way is not a good idea because there are maybe several
consumers of GetStats calls. If not all of them parse timing frame
reports, some of them may be lost.

Also, streamline reporting of TimingFrames via GetStats (remove separate
methods and use VideoReceiveStream::Stats struct instead).

Merge into M62. Original reviewed here: https://codereview.webrtc.org/3008983002

BUG=webrtc:7594,chromium:762872
NOTRY=true
NOPRESUBMIT=true
TBR=sprang@webrtc.org

Review-Url: https://codereview.webrtc.org/3012073002
Cr-Commit-Position: refs/branch-heads/62@{#6}
Cr-Branched-From:
85e6a4ba1372f21b8648ffaad2fd19a76a8bb316-refs/heads/master@{#19592}
Committed:
https://chromium.googlesource.com/external/webrtc/+/625b4cccdb02c07405106ed7b...
==========

[commit-bot: I haz the power, 2017-09-08 12:27:49]

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