Add a flags field to video timing extension.

Add a flags field to video timing extension.

The rtp header extension for video timing shuold have an additional
field for signaling metadata, such as what triggered the extension for
this particular frame. This will allow separating frames select because
of outlier sizes from regular frames, for more accurate stats.

This implementation is backwards compatible in that it can read video
timing extensions without the new flag field, but it always sends with
it included.

BUG=webrtc:7594
Review-Url: https://codereview.webrtc.org/3000753002
Cr-Commit-Position: refs/heads/master@{#19353}
Committed: https://chromium.googlesource.com/external/webrtc/+/cf5d485e147f7d7b3081692f101e496ce9e1d257

[sprang_webrtc, 2017-08-11 11:07:54]

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

[danilchap, 2017-08-11 12:22:36]

https://codereview.webrtc.org/3000753002/diff/1/webrtc/api/video/video_timing.h
File webrtc/api/video/video_timing.h (right):

https://codereview.webrtc.org/3000753002/diff/1/webrtc/api/video/video_timing...
webrtc/api/video/video_timing.h:36: static constexpr uint8_t
kEncodeStartDeltaIdx = 0;
may be rename them from Idx to Offset

https://codereview.webrtc.org/3000753002/diff/1/webrtc/api/video/video_timing...
webrtc/api/video/video_timing.h:50: printf("Wat\n");
may be add to next line:
RTC_DCHECK_GE(time_ms, base_ms) << "Time goes backwards sometimes...";

https://codereview.webrtc.org/3000753002/diff/1/webrtc/api/video/video_timing...
webrtc/api/video/video_timing.h:61: uint8_t flags;
may be TimingFrameFlags instead of uint8_t

https://codereview.webrtc.org/3000753002/diff/1/webrtc/api/video/video_timing...
webrtc/api/video/video_timing.h:109: uint8_t flags;  // Flags indicating
validity and/or why tracing was triggered.
ditto

https://codereview.webrtc.org/3000753002/diff/1/webrtc/modules/rtp_rtcp/sourc...
File webrtc/modules/rtp_rtcp/source/rtp_header_extensions.cc (right):

https://codereview.webrtc.org/3000753002/diff/1/webrtc/modules/rtp_rtcp/sourc...
webrtc/modules/rtp_rtcp/source/rtp_header_extensions.cc:255: // 2 = Frame marked
as timing frame due to size being bein an outlier.
bein?

https://codereview.webrtc.org/3000753002/diff/1/webrtc/modules/rtp_rtcp/sourc...
webrtc/modules/rtp_rtcp/source/rtp_header_extensions.cc:256: // 255 = Invalid.
The whole timing frame extension should be ignored.
what is a usecase to use this value on the wire?
if only used in code, may be change type to be wider (e.g. int instead of
uint8_t) and use value -1 as invalid.

Similar question for special value 0

https://codereview.webrtc.org/3000753002/diff/1/webrtc/modules/rtp_rtcp/sourc...
webrtc/modules/rtp_rtcp/source/rtp_header_extensions.cc:261: //   |  ID   |
len=11|  encode start ms delta          | encode finish |
len=12

https://codereview.webrtc.org/3000753002/diff/1/webrtc/modules/rtp_rtcp/sourc...
webrtc/modules/rtp_rtcp/source/rtp_header_extensions.cc:277: const bool
is_old_protocol = data.size() == (kValueSizeBytes - 1);
may be add TODO to remove support for old protocol in X months.

https://codereview.webrtc.org/3000753002/diff/1/webrtc/modules/rtp_rtcp/sourc...
webrtc/modules/rtp_rtcp/source/rtp_header_extensions.cc:323: uint8_t idx) {
may be rename index to offset

https://codereview.webrtc.org/3000753002/diff/1/webrtc/modules/rtp_rtcp/sourc...
webrtc/modules/rtp_rtcp/source/rtp_header_extensions.cc:324: RTC_DCHECK_LT(idx,
kValueSizeBytes);
may be LE(offset, kValueSizeBytes - 2)
since you write 2 bytes.

https://codereview.webrtc.org/3000753002/diff/1/webrtc/modules/rtp_rtcp/sourc...
File webrtc/modules/rtp_rtcp/source/rtp_packet_unittest.cc (right):

https://codereview.webrtc.org/3000753002/diff/1/webrtc/modules/rtp_rtcp/sourc...
webrtc/modules/rtp_rtcp/source/rtp_packet_unittest.cc:502: TEST(RtpPacketTest,
TimingFrameExtension) {
Prefer to split this test into 2-3 smaller tests:
Create and Parse, ParseOldFormat

[sprang_webrtc, 2017-08-11 13:19:06]

https://codereview.webrtc.org/3000753002/diff/1/webrtc/api/video/video_timing.h
File webrtc/api/video/video_timing.h (right):

https://codereview.webrtc.org/3000753002/diff/1/webrtc/api/video/video_timing...
webrtc/api/video/video_timing.h:36: static constexpr uint8_t
kEncodeStartDeltaIdx = 0;
On 2017/08/11 12:22:35, danilchap wrote:
> may be rename them from Idx to Offset

Done.

https://codereview.webrtc.org/3000753002/diff/1/webrtc/api/video/video_timing...
webrtc/api/video/video_timing.h:50: printf("Wat\n");
On 2017/08/11 12:22:35, danilchap wrote:
> may be add to next line:
> RTC_DCHECK_GE(time_ms, base_ms) << "Time goes backwards sometimes...";


Oops, this was debug code I forgot to remove.

https://codereview.webrtc.org/3000753002/diff/1/webrtc/api/video/video_timing...
webrtc/api/video/video_timing.h:61: uint8_t flags;
On 2017/08/11 12:22:35, danilchap wrote:
> may be TimingFrameFlags instead of uint8_t

No, this is intended a bit-field. kTriggeredByTimer and kTriggeredBySize allowed
to be set at the same time.

https://codereview.webrtc.org/3000753002/diff/1/webrtc/api/video/video_timing...
webrtc/api/video/video_timing.h:109: uint8_t flags;  // Flags indicating
validity and/or why tracing was triggered.
On 2017/08/11 12:22:35, danilchap wrote:
> ditto

ditto :)

https://codereview.webrtc.org/3000753002/diff/1/webrtc/modules/rtp_rtcp/sourc...
File webrtc/modules/rtp_rtcp/source/rtp_header_extensions.cc (right):

https://codereview.webrtc.org/3000753002/diff/1/webrtc/modules/rtp_rtcp/sourc...
webrtc/modules/rtp_rtcp/source/rtp_header_extensions.cc:255: // 2 = Frame marked
as timing frame due to size being bein an outlier.
On 2017/08/11 12:22:35, danilchap wrote:
> bein?

typo, slightly rephrased.

https://codereview.webrtc.org/3000753002/diff/1/webrtc/modules/rtp_rtcp/sourc...
webrtc/modules/rtp_rtcp/source/rtp_header_extensions.cc:256: // 255 = Invalid.
The whole timing frame extension should be ignored.
On 2017/08/11 12:22:36, danilchap wrote:
> what is a usecase to use this value on the wire?
> if only used in code, may be change type to be wider (e.g. int instead of
> uint8_t) and use value -1 as invalid.
> 
> Similar question for special value 0

This value (255) should not normally be used on the wire, but can be so for
instance if a logging tool or content protection scheme etc assumes that the
headers for a set of packets have exactly the same layout. 

The 0 value is just intended to make it easy to have the same behavior as the
"old" wire format where there is no flag-field.

https://codereview.webrtc.org/3000753002/diff/1/webrtc/modules/rtp_rtcp/sourc...
webrtc/modules/rtp_rtcp/source/rtp_header_extensions.cc:261: //   |  ID   |
len=11|  encode start ms delta          | encode finish |
On 2017/08/11 12:22:35, danilchap wrote:
> len=12

Nice catch.

https://codereview.webrtc.org/3000753002/diff/1/webrtc/modules/rtp_rtcp/sourc...
webrtc/modules/rtp_rtcp/source/rtp_header_extensions.cc:277: const bool
is_old_protocol = data.size() == (kValueSizeBytes - 1);
On 2017/08/11 12:22:35, danilchap wrote:
> may be add TODO to remove support for old protocol in X months.

Done.

https://codereview.webrtc.org/3000753002/diff/1/webrtc/modules/rtp_rtcp/sourc...
webrtc/modules/rtp_rtcp/source/rtp_header_extensions.cc:323: uint8_t idx) {
On 2017/08/11 12:22:35, danilchap wrote:
> may be rename index to offset

Done.

https://codereview.webrtc.org/3000753002/diff/1/webrtc/modules/rtp_rtcp/sourc...
webrtc/modules/rtp_rtcp/source/rtp_header_extensions.cc:324: RTC_DCHECK_LT(idx,
kValueSizeBytes);
On 2017/08/11 12:22:36, danilchap wrote:
> may be LE(offset, kValueSizeBytes - 2)
> since you write 2 bytes.

Good idea. using kValueSizeBytes - sizeof(uint16_t) to make it even more clear.

https://codereview.webrtc.org/3000753002/diff/1/webrtc/modules/rtp_rtcp/sourc...
File webrtc/modules/rtp_rtcp/source/rtp_packet_unittest.cc (right):

https://codereview.webrtc.org/3000753002/diff/1/webrtc/modules/rtp_rtcp/sourc...
webrtc/modules/rtp_rtcp/source/rtp_packet_unittest.cc:502: TEST(RtpPacketTest,
TimingFrameExtension) {
On 2017/08/11 12:22:36, danilchap wrote:
> Prefer to split this test into 2-3 smaller tests:
> Create and Parse, ParseOldFormat

Done.

[danilchap, 2017-08-11 13:51:17]

spotted few more typos

https://codereview.webrtc.org/3000753002/diff/20001/webrtc/api/video/video_ti...
File webrtc/api/video/video_timing.cc (right):

https://codereview.webrtc.org/3000753002/diff/20001/webrtc/api/video/video_ti...
webrtc/api/video/video_timing.cc:43: return flags &
TimingFrameFlags::kTriggeredBySize;
are Invalid frames outliers?

https://codereview.webrtc.org/3000753002/diff/20001/webrtc/api/video/video_ti...
webrtc/api/video/video_timing.cc:47: return flags ==
TimingFrameFlags::kTriggeredBySize;
== ::kInvalid ?

https://codereview.webrtc.org/3000753002/diff/20001/webrtc/api/video/video_ti...
webrtc/api/video/video_timing.cc:61: << IsOutlier();
can it be usefull to trace also if frame trigger by time?

https://codereview.webrtc.org/3000753002/diff/20001/webrtc/api/video/video_ti...
File webrtc/api/video/video_timing.h (right):

https://codereview.webrtc.org/3000753002/diff/20001/webrtc/api/video/video_ti...
webrtc/api/video/video_timing.h:34: // Indices of the fields in the RTP header
extension, counting from the first
Offsets of the...

https://codereview.webrtc.org/3000753002/diff/20001/webrtc/api/video/video_ti...
webrtc/api/video/video_timing.h:42: static constexpr uint8_t kFLagsOffset = 12;
lowercase l

https://codereview.webrtc.org/3000753002/diff/20001/webrtc/modules/rtp_rtcp/s...
File webrtc/modules/rtp_rtcp/source/rtp_header_extensions.cc (right):

https://codereview.webrtc.org/3000753002/diff/20001/webrtc/modules/rtp_rtcp/s...
webrtc/modules/rtp_rtcp/source/rtp_header_extensions.cc:267: //   | stamp ms
delta|     flags     |
did you consider putting flags first?
it would make this full comment nicer (times will be better aligned), will make
more logical adding more kind of timestamps later.

On minus side - will slightly complicate Parsing previous version.
(though that can be mitigated with an extra local variable:
const uint8* timestamps = data.data();
if (is_old_protocol) --timestamps;

old client will discard extension size != 11 anyway.

https://codereview.webrtc.org/3000753002/diff/20001/webrtc/modules/rtp_rtcp/s...
File webrtc/modules/rtp_rtcp/source/rtp_packet_unittest.cc (right):

https://codereview.webrtc.org/3000753002/diff/20001/webrtc/modules/rtp_rtcp/s...
webrtc/modules/rtp_rtcp/source/rtp_packet_unittest.cc:556: // Modify the sent
packet so that the old VideoTimingExtension format is used.
May be it is simpler and more robust to assemble such packet manually (specially
if you find it is better to put flags first)

[sprang_webrtc, 2017-08-11 15:06:34]

https://codereview.webrtc.org/3000753002/diff/20001/webrtc/api/video/video_ti...
File webrtc/api/video/video_timing.cc (right):

https://codereview.webrtc.org/3000753002/diff/20001/webrtc/api/video/video_ti...
webrtc/api/video/video_timing.cc:43: return flags &
TimingFrameFlags::kTriggeredBySize;
On 2017/08/11 13:51:16, danilchap wrote:
> are Invalid frames outliers?

No, this is a bug.

https://codereview.webrtc.org/3000753002/diff/20001/webrtc/api/video/video_ti...
webrtc/api/video/video_timing.cc:47: return flags ==
TimingFrameFlags::kTriggeredBySize;
On 2017/08/11 13:51:16, danilchap wrote:
> == ::kInvalid ?

Yes. What a brain fart...

https://codereview.webrtc.org/3000753002/diff/20001/webrtc/api/video/video_ti...
webrtc/api/video/video_timing.cc:61: << IsOutlier();
On 2017/08/11 13:51:16, danilchap wrote:
> can it be usefull to trace also if frame trigger by time?

Done.

https://codereview.webrtc.org/3000753002/diff/20001/webrtc/api/video/video_ti...
File webrtc/api/video/video_timing.h (right):

https://codereview.webrtc.org/3000753002/diff/20001/webrtc/api/video/video_ti...
webrtc/api/video/video_timing.h:34: // Indices of the fields in the RTP header
extension, counting from the first
On 2017/08/11 13:51:16, danilchap wrote:
> Offsets of the...

Done.

https://codereview.webrtc.org/3000753002/diff/20001/webrtc/api/video/video_ti...
webrtc/api/video/video_timing.h:42: static constexpr uint8_t kFLagsOffset = 12;
On 2017/08/11 13:51:16, danilchap wrote:
> lowercase l

Done.

https://codereview.webrtc.org/3000753002/diff/20001/webrtc/modules/rtp_rtcp/s...
File webrtc/modules/rtp_rtcp/source/rtp_header_extensions.cc (right):

https://codereview.webrtc.org/3000753002/diff/20001/webrtc/modules/rtp_rtcp/s...
webrtc/modules/rtp_rtcp/source/rtp_header_extensions.cc:267: //   | stamp ms
delta|     flags     |
On 2017/08/11 13:51:16, danilchap wrote:
> did you consider putting flags first?
> it would make this full comment nicer (times will be better aligned), will
make
> more logical adding more kind of timestamps later.
> 
> On minus side - will slightly complicate Parsing previous version.
> (though that can be mitigated with an extra local variable:
> const uint8* timestamps = data.data();
> if (is_old_protocol) --timestamps;
> 
> old client will discard extension size != 11 anyway.

I did, mainly abstained because of the Write method that takes a single field
and offset. But since we're always sending with the new format, let's go ahead
and change it.

Also, I think it's technically undefined behavior to move pointer outside your
memory area and then move it back again. But maybe we're ok since we actually
own the memory for the whole rtp header. Still, doing offset subtraction
instead.

https://codereview.webrtc.org/3000753002/diff/20001/webrtc/modules/rtp_rtcp/s...
File webrtc/modules/rtp_rtcp/source/rtp_packet_unittest.cc (right):

https://codereview.webrtc.org/3000753002/diff/20001/webrtc/modules/rtp_rtcp/s...
webrtc/modules/rtp_rtcp/source/rtp_packet_unittest.cc:556: // Modify the sent
packet so that the old VideoTimingExtension format is used.
On 2017/08/11 13:51:16, danilchap wrote:
> May be it is simpler and more robust to assemble such packet manually
(specially
> if you find it is better to put flags first)

Done.

[danilchap, 2017-08-11 15:18:47]

lgtm

https://codereview.webrtc.org/3000753002/diff/40001/webrtc/modules/rtp_rtcp/s...
File webrtc/modules/rtp_rtcp/source/rtp_header_extensions.cc (right):

https://codereview.webrtc.org/3000753002/diff/40001/webrtc/modules/rtp_rtcp/s...
webrtc/modules/rtp_rtcp/source/rtp_header_extensions.cc:279: if (data.size() ==
(kValueSizeBytes - 1)) {
rather than if else if may be use simpler switch:
switch (data.size()) {
  case kValueSizeBytes:
    timing->flags = 
    break;
  case kValueSizeBytes - 1:
    // old format
    off = 1;
    break;
  default:
    // Unknown (future?) format.
    return false;
}

[sprang_webrtc, 2017-08-11 15:44:07]

The CQ bit was checked by sprang@webrtc.org

[sprang_webrtc, 2017-08-11 15:44:07]

The patchset sent to the CQ was uploaded after l-g-t-m from danilchap@webrtc.org
Link to the patchset: https://codereview.webrtc.org/3000753002/#ps60001 (title:
"switch")

[commit-bot: I haz the power, 2017-08-11 15:44:12]

CQ is trying da patch.

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

[sprang_webrtc, 2017-08-11 15:44:32]

https://codereview.webrtc.org/3000753002/diff/40001/webrtc/modules/rtp_rtcp/s...
File webrtc/modules/rtp_rtcp/source/rtp_header_extensions.cc (right):

https://codereview.webrtc.org/3000753002/diff/40001/webrtc/modules/rtp_rtcp/s...
webrtc/modules/rtp_rtcp/source/rtp_header_extensions.cc:279: if (data.size() ==
(kValueSizeBytes - 1)) {
On 2017/08/11 15:18:47, danilchap wrote:
> rather than if else if may be use simpler switch:
> switch (data.size()) {
>   case kValueSizeBytes:
>     timing->flags = 
>     break;
>   case kValueSizeBytes - 1:
>     // old format
>     off = 1;
>     break;
>   default:
>     // Unknown (future?) format.
>     return false;
> }

Done.

[commit-bot: I haz the power, 2017-08-11 15:46:23]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-08-11 15:46:24]

Try jobs failed on following builders:
  ios64_sim_ios10_dbg on master.tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios64_sim_ios10_dbg/bui...)
  linux_rel on master.tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/linux_rel/builds/28422)
  mac_baremetal on master.tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/mac_baremetal/builds/23770)

[sprang_webrtc, 2017-08-11 15:50:35]

The CQ bit was checked by sprang@webrtc.org

[sprang_webrtc, 2017-08-11 15:50:36]

The patchset sent to the CQ was uploaded after l-g-t-m from danilchap@webrtc.org
Link to the patchset: https://codereview.webrtc.org/3000753002/#ps80001 (title:
"Rebase")

[commit-bot: I haz the power, 2017-08-11 15:50:43]

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-08-11 15:56:32]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-08-11 15:56:34]

Try jobs failed on following builders:
  presubmit on master.tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/presubmit/builds/20060)

[sprang_webrtc, 2017-08-14 08:17:27]

The CQ bit was checked by sprang@webrtc.org to run a CQ dry run

[commit-bot: I haz the power, 2017-08-14 08:17:35]

Dry run: 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-08-14 08:23:46]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-08-14 08:23:48]

Dry run: Try jobs failed on following builders:
  mac_compile_dbg on master.tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/mac_compile_dbg/builds/...)

[sprang_webrtc, 2017-08-14 11:19:49]

The CQ bit was checked by sprang@webrtc.org to run a CQ dry run

[commit-bot: I haz the power, 2017-08-14 11:19:59]

Dry run: CQ is trying da patch.

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

[sprang_webrtc, 2017-08-14 11:21:53]

sprang@webrtc.org changed reviewers:
+ kthelgason@webrtc.org, stefan@webrtc.org

[sprang_webrtc, 2017-08-14 11:21:54]

+kthelgason as owner for objc
+stefan as owner for common_video and api/video

[kthelgason, 2017-08-14 11:32:36]

https://codereview.webrtc.org/3000753002/diff/180001/webrtc/sdk/objc/Framewor...
File webrtc/sdk/objc/Framework/Classes/VideoToolbox/RTCVideoEncoderH264.mm
(right):

https://codereview.webrtc.org/3000753002/diff/180001/webrtc/sdk/objc/Framewor...
webrtc/sdk/objc/Framework/Classes/VideoToolbox/RTCVideoEncoderH264.mm:660:
frame.flags = 0;
why is this not webrtc::TimingFrameFlags::kInvalid like on the android side?

[commit-bot: I haz the power, 2017-08-14 11:52:30]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-08-14 11:52:31]

Dry run: This issue passed the CQ dry run.

[sprang_webrtc, 2017-08-14 11:56:44]

https://codereview.webrtc.org/3000753002/diff/180001/webrtc/sdk/objc/Framewor...
File webrtc/sdk/objc/Framework/Classes/VideoToolbox/RTCVideoEncoderH264.mm
(right):

https://codereview.webrtc.org/3000753002/diff/180001/webrtc/sdk/objc/Framewor...
webrtc/sdk/objc/Framework/Classes/VideoToolbox/RTCVideoEncoderH264.mm:660:
frame.flags = 0;
On 2017/08/14 11:32:36, kthelgason wrote:
> why is this not webrtc::TimingFrameFlags::kInvalid like on the android side?

You're right, it should be kInvalid.

[stefan-webrtc, 2017-08-14 12:08:07]

lgtm

[kthelgason, 2017-08-14 12:18:03]

lgtm for objc

[sprang_webrtc, 2017-08-14 12:19:48]

The CQ bit was checked by sprang@webrtc.org

[sprang_webrtc, 2017-08-14 12:19:49]

The patchset sent to the CQ was uploaded after l-g-t-m from danilchap@webrtc.org
Link to the patchset: https://codereview.webrtc.org/3000753002/#ps200001 (title:
"RTCVideoEncoderH264 use kInvalid instead of 0 as flags")

[commit-bot: I haz the power, 2017-08-14 12:20:00]

CQ is trying da patch.

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

[sprang_webrtc, 2017-08-14 12:32:55]

The CQ bit was checked by sprang@webrtc.org

[sprang_webrtc, 2017-08-14 12:32:56]

The patchset sent to the CQ was uploaded after l-g-t-m from
kthelgason@webrtc.org, danilchap@webrtc.org, stefan@webrtc.org
Link to the patchset: https://codereview.webrtc.org/3000753002/#ps220001 (title:
"Rebase")

[commit-bot: I haz the power, 2017-08-14 12:33:07]

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-08-14 13:25:14]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-08-14 13:25:15]

Try jobs failed on following builders:
  ios_api_framework on master.tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios_api_framework/build...)

[sprang_webrtc, 2017-08-15 11:54:37]

The CQ bit was checked by sprang@webrtc.org

[sprang_webrtc, 2017-08-15 11:54:38]

The patchset sent to the CQ was uploaded after l-g-t-m from
kthelgason@webrtc.org, danilchap@webrtc.org, stefan@webrtc.org
Link to the patchset: https://codereview.webrtc.org/3000753002/#ps280001 (title:
"Final rebase try")

[commit-bot: I haz the power, 2017-08-15 11:54:40]

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-08-15 12:33:27]

CQ is committing da patch.

Bot data: {"patchset_id": 280001, "attempt_start_ts": 1502798077331730,
"parent_rev": "892dab52b6436ce00f508726729eded75a25503d", "commit_rev":
"cf5d485e147f7d7b3081692f101e496ce9e1d257"}

[commit-bot: I haz the power, 2017-08-15 12:33:34]

Description was changed from

==========
Add a flags field to video timing extension.

The rtp header extension for video timing shuold have an additional
field for signaling metadata, such as what triggered the extension for
this particular frame. This will allow separating frames select because
of outlier sizes from regular frames, for more accurate stats.

This implementation is backwards compatible in that it can read video
timing extensions without the new flag field, but it always sends with
it included.

BUG=webrtc:7594
==========

to

==========
Add a flags field to video timing extension.

The rtp header extension for video timing shuold have an additional
field for signaling metadata, such as what triggered the extension for
this particular frame. This will allow separating frames select because
of outlier sizes from regular frames, for more accurate stats.

This implementation is backwards compatible in that it can read video
timing extensions without the new flag field, but it always sends with
it included.

BUG=webrtc:7594

Review-Url: https://codereview.webrtc.org/3000753002
Cr-Commit-Position: refs/heads/master@{#19353}
Committed:
https://chromium.googlesource.com/external/webrtc/+/cf5d485e147f7d7b3081692f1...
==========

[commit-bot: I haz the power, 2017-08-15 12:33:36]

Committed patchset #15 (id:280001) as
https://chromium.googlesource.com/external/webrtc/+/cf5d485e147f7d7b3081692f1...

[emircan1, 2017-08-15 19:31:04]

A revert of this CL (patchset #15 id:280001) has been created in
https://codereview.webrtc.org/2995953002/ by emircan@google.com.

The reason for reverting is: Speculative revet for breaking remoting_unittests
in fyi bots.
https://build.chromium.org/p/chromium.webrtc.fyi/waterfall?builder=Win7%20Tester.