Implemented a new sequence number unwrapper in sequence_number_util.h.

Implemented a new sequence number unwrapper in sequence_number_util.h.

There is already an Unwrapper in webrtc/modules/include/module_common_types.h,
but we reimplemented it in sequence_number_util.h for a few reasons:
 - Such a class belongs in sequence_number_util.h.
 - It is a cleaner implementation since we can use the rest of
   sequence_number_util.h functionality.
 - You can choose at which number the unwrapped sequence should start,
   which is used to avoid the edge case when a backward wrap can happen
   as the first few numbers are unwrapped.
 - This unwrapper can unwrap numbers that does not wrap 8/16/32 bits.



BUG=None

Review-Url: https://codereview.webrtc.org/2977603002
Cr-Commit-Position: refs/heads/master@{#19154}
Committed: https://chromium.googlesource.com/external/webrtc/+/7956c0f2f68e3fbaaab0936aad8b1f2b9437d7fe

[philipel, 2017-07-10 17:31:23]

philipel@webrtc.org changed reviewers:
+ terelius@webrtc.org

[philipel, 2017-07-10 17:41:21]

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

[commit-bot: I haz the power, 2017-07-10 17:41:22]

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-07-10 17:42:52]

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

[commit-bot: I haz the power, 2017-07-10 17:42:53]

Dry run: Try jobs failed on following builders:
  ios32_sim_ios9_dbg on master.tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios32_sim_ios9_dbg/buil...)
  ios64_sim_ios10_dbg on master.tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios64_sim_ios10_dbg/bui...)
  ios_arm64_dbg on master.tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios_arm64_dbg/builds/21867)
  ios_arm64_rel on master.tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/ios_arm64_rel/builds/21652)

[philipel, 2017-07-10 17:49:15]

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

[commit-bot: I haz the power, 2017-07-10 17:49:22]

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-07-10 18:22:34]

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

[commit-bot: I haz the power, 2017-07-10 18:22:35]

Dry run: This issue passed the CQ dry run.

[terelius, 2017-07-10 21:20:23]

https://codereview.webrtc.org/2977603002/diff/20001/webrtc/modules/video_codi...
File webrtc/modules/video_coding/sequence_number_util.h (right):

https://codereview.webrtc.org/2977603002/diff/20001/webrtc/modules/video_codi...
webrtc/modules/video_coding/sequence_number_util.h:84: class SeqNumUnwrapper {
We already have an Unwrapper in webrtc/modules/include/module_common_types.h
Any chance we can use that instead?

https://codereview.webrtc.org/2977603002/diff/20001/webrtc/rtc_base/mod_ops.h
File webrtc/rtc_base/mod_ops.h (right):

https://codereview.webrtc.org/2977603002/diff/20001/webrtc/rtc_base/mod_ops.h...
webrtc/rtc_base/mod_ops.h:72: inline typename std::enable_if<(M == 0), T>::type
ForwardDiff(T a, T b) {
Nice generalization, but are there unit tests for this special case? Same below.

[philipel, 2017-07-11 10:42:33]

Description was changed from

==========
Implemented sequence number unwrapper in sequence_number_util.h.

BUG=None
==========

to

==========
Implemented a new sequence number unwrapper in sequence_number_util.h.

There is already an Unwrapper in webrtc/modules/include/module_common_types.h,
but we reimplemented it in sequence_number_util.h for a few reasons:
 - Such a class belongs in sequence_number_util.h.
 - It is a cleaner implementation since we can use the rest of
   sequence_number_util.h functionality.
 - You can choose at which number the unwrapped sequence should start,
   which is used to avoid the edge case when a backward wrap can happen
   with the first few numbers being unwrapped.



BUG=None
==========

[philipel, 2017-07-11 10:43:15]

Description was changed from

==========
Implemented a new sequence number unwrapper in sequence_number_util.h.

There is already an Unwrapper in webrtc/modules/include/module_common_types.h,
but we reimplemented it in sequence_number_util.h for a few reasons:
 - Such a class belongs in sequence_number_util.h.
 - It is a cleaner implementation since we can use the rest of
   sequence_number_util.h functionality.
 - You can choose at which number the unwrapped sequence should start,
   which is used to avoid the edge case when a backward wrap can happen
   with the first few numbers being unwrapped.



BUG=None
==========

to

==========
Implemented a new sequence number unwrapper in sequence_number_util.h.

There is already an Unwrapper in webrtc/modules/include/module_common_types.h,
but we reimplemented it in sequence_number_util.h for a few reasons:
 - Such a class belongs in sequence_number_util.h.
 - It is a cleaner implementation since we can use the rest of
   sequence_number_util.h functionality.
 - You can choose at which number the unwrapped sequence should start,
   which is used to avoid the edge case when a backward wrap can happen
   with the first few numbers being unwrapped.



BUG=None
==========

[philipel, 2017-07-11 11:08:31]

https://codereview.webrtc.org/2977603002/diff/20001/webrtc/modules/video_codi...
File webrtc/modules/video_coding/sequence_number_util.h (right):

https://codereview.webrtc.org/2977603002/diff/20001/webrtc/modules/video_codi...
webrtc/modules/video_coding/sequence_number_util.h:84: class SeqNumUnwrapper {
On 2017/07/10 21:20:23, terelius wrote:
> We already have an Unwrapper in webrtc/modules/include/module_common_types.h
> Any chance we can use that instead?

I updated the CL description with the motivation as to why we reimplement this
functionality.

https://codereview.webrtc.org/2977603002/diff/20001/webrtc/rtc_base/mod_ops.h
File webrtc/rtc_base/mod_ops.h (right):

https://codereview.webrtc.org/2977603002/diff/20001/webrtc/rtc_base/mod_ops.h...
webrtc/rtc_base/mod_ops.h:72: inline typename std::enable_if<(M == 0), T>::type
ForwardDiff(T a, T b) {
On 2017/07/10 21:20:23, terelius wrote:
> Nice generalization, but are there unit tests for this special case? Same
below.

Yes, there were already unit tests for this case and the one below, and
indirectly for the one above, so I added tests for the case above. Both for
ForwardDiff and ReverseDiff of course.

[philipel, 2017-07-11 12:30:33]

Description was changed from

==========
Implemented a new sequence number unwrapper in sequence_number_util.h.

There is already an Unwrapper in webrtc/modules/include/module_common_types.h,
but we reimplemented it in sequence_number_util.h for a few reasons:
 - Such a class belongs in sequence_number_util.h.
 - It is a cleaner implementation since we can use the rest of
   sequence_number_util.h functionality.
 - You can choose at which number the unwrapped sequence should start,
   which is used to avoid the edge case when a backward wrap can happen
   with the first few numbers being unwrapped.



BUG=None
==========

to

==========
Implemented a new sequence number unwrapper in sequence_number_util.h.

There is already an Unwrapper in webrtc/modules/include/module_common_types.h,
but we reimplemented it in sequence_number_util.h for a few reasons:
 - Such a class belongs in sequence_number_util.h.
 - It is a cleaner implementation since we can use the rest of
   sequence_number_util.h functionality.
 - You can choose at which number the unwrapped sequence should start,
   which is used to avoid the edge case when a backward wrap can happen
   as the first few numbers are unwrapped.



BUG=None
==========

[terelius, 2017-07-11 12:38:18]

https://codereview.webrtc.org/2977603002/diff/20001/webrtc/modules/video_codi...
File webrtc/modules/video_coding/sequence_number_util.h (right):

https://codereview.webrtc.org/2977603002/diff/20001/webrtc/modules/video_codi...
webrtc/modules/video_coding/sequence_number_util.h:84: class SeqNumUnwrapper {
On 2017/07/11 11:08:30, philipel wrote:
> On 2017/07/10 21:20:23, terelius wrote:
> > We already have an Unwrapper in webrtc/modules/include/module_common_types.h
> > Any chance we can use that instead?
> 
> I updated the CL description with the motivation as to why we reimplement this
> functionality.

Not sure I agree with the reasons for reimplementing it. An unwrapper doesn't
seem specific to the video coding module, so to me it actually seems appropriate
to place it in modules_common_types.h
The implementation in that file isn't longer than this, and it already contains
similar helper functions like IsNewer. The initial unwrapping value is a good
point, but maybe this feature could be added to the existing class?

https://codereview.webrtc.org/2977603002/diff/20001/webrtc/rtc_base/mod_ops.h
File webrtc/rtc_base/mod_ops.h (right):

https://codereview.webrtc.org/2977603002/diff/20001/webrtc/rtc_base/mod_ops.h...
webrtc/rtc_base/mod_ops.h:72: inline typename std::enable_if<(M == 0), T>::type
ForwardDiff(T a, T b) {
On 2017/07/11 11:08:30, philipel wrote:
> On 2017/07/10 21:20:23, terelius wrote:
> > Nice generalization, but are there unit tests for this special case? Same
> below.
> 
> Yes, there were already unit tests for this case and the one below, and
> indirectly for the one above, so I added tests for the case above. Both for
> ForwardDiff and ReverseDiff of course.

Acknowledged.

[philipel, 2017-07-11 12:49:06]

https://codereview.webrtc.org/2977603002/diff/20001/webrtc/modules/video_codi...
File webrtc/modules/video_coding/sequence_number_util.h (right):

https://codereview.webrtc.org/2977603002/diff/20001/webrtc/modules/video_codi...
webrtc/modules/video_coding/sequence_number_util.h:84: class SeqNumUnwrapper {
On 2017/07/11 12:38:17, terelius wrote:
> On 2017/07/11 11:08:30, philipel wrote:
> > On 2017/07/10 21:20:23, terelius wrote:
> > > We already have an Unwrapper in
webrtc/modules/include/module_common_types.h
> > > Any chance we can use that instead?
> > 
> > I updated the CL description with the motivation as to why we reimplement
this
> > functionality.
> 
> Not sure I agree with the reasons for reimplementing it. An unwrapper doesn't
> seem specific to the video coding module, so to me it actually seems
appropriate
> to place it in modules_common_types.h

If that is the case then I guess we could move sequence_number_util.h to
modules/include (or maybe even to rtc_base?).

I also think that breaking module_common_types into separate files/classes is a
good thing, instead of being this large file with various functions, definitions
and classes.

> The implementation in that file isn't longer than this, and it already
contains
> similar helper functions like IsNewer. The initial unwrapping value is a good
> point, but maybe this feature could be added to the existing class?

The IsNewer and such functions can only handle numbers that wrap at 8/16/32
bits, but not at some other value. I expect to use this new unwrapper in the
RtpFrameReferenceFinder where for example picture ids can wrap at 15 bits.

[philipel, 2017-07-14 13:12:34]

Description was changed from

==========
Implemented a new sequence number unwrapper in sequence_number_util.h.

There is already an Unwrapper in webrtc/modules/include/module_common_types.h,
but we reimplemented it in sequence_number_util.h for a few reasons:
 - Such a class belongs in sequence_number_util.h.
 - It is a cleaner implementation since we can use the rest of
   sequence_number_util.h functionality.
 - You can choose at which number the unwrapped sequence should start,
   which is used to avoid the edge case when a backward wrap can happen
   as the first few numbers are unwrapped.



BUG=None
==========

to

==========
Implemented a new sequence number unwrapper in sequence_number_util.h.

There is already an Unwrapper in webrtc/modules/include/module_common_types.h,
but we reimplemented it in sequence_number_util.h for a few reasons:
 - Such a class belongs in sequence_number_util.h.
 - It is a cleaner implementation since we can use the rest of
   sequence_number_util.h functionality.
 - You can choose at which number the unwrapped sequence should start,
   which is used to avoid the edge case when a backward wrap can happen
   as the first few numbers are unwrapped.
 - This unwrapper can unwrap numbers that does not wrap 8/16/32 bits.



BUG=None
==========

[terelius, 2017-07-24 13:35:39]

lgtm, but please consider the comments below:

https://codereview.webrtc.org/2977603002/diff/40001/webrtc/modules/video_codi...
File webrtc/modules/video_coding/sequence_number_util.h (right):

https://codereview.webrtc.org/2977603002/diff/40001/webrtc/modules/video_codi...
webrtc/modules/video_coding/sequence_number_util.h:49: inline bool AheadOrAt(T
a, T b) {
As a follow-up, what do you think about making the interface closer to the old
unwrapper so that this can eventually replace it? For example, maybe this could
be renamed to IsNewer?

https://codereview.webrtc.org/2977603002/diff/40001/webrtc/modules/video_codi...
File webrtc/modules/video_coding/sequence_number_util_unittest.cc (right):

https://codereview.webrtc.org/2977603002/diff/40001/webrtc/modules/video_codi...
webrtc/modules/video_coding/sequence_number_util_unittest.cc:218: //
unwrapper.Unwrap(255);
Should this really be commented? Did you intend to make a death test instead?

[philipel, 2017-07-24 14:31:26]

The CQ bit was checked by philipel@webrtc.org

[philipel, 2017-07-24 14:31:27]

The patchset sent to the CQ was uploaded after l-g-t-m from terelius@webrtc.org
Link to the patchset: https://codereview.webrtc.org/2977603002/#ps60001 (title:
"Updated test with ASSERT_DEATH")

[commit-bot: I haz the power, 2017-07-24 14:31:32]

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-07-24 14:34:01]

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

[commit-bot: I haz the power, 2017-07-24 14:34:02]

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

[philipel, 2017-07-24 14:46:43]

https://codereview.webrtc.org/2977603002/diff/40001/webrtc/modules/video_codi...
File webrtc/modules/video_coding/sequence_number_util.h (right):

https://codereview.webrtc.org/2977603002/diff/40001/webrtc/modules/video_codi...
webrtc/modules/video_coding/sequence_number_util.h:49: inline bool AheadOrAt(T
a, T b) {
On 2017/07/24 13:35:39, terelius wrote:
> As a follow-up, what do you think about making the interface closer to the old
> unwrapper so that this can eventually replace it? For example, maybe this
could
> be renamed to IsNewer?

I think it would be good to clean out the old one, but before we can do that we
have to move this to either modules/include or to rtc_base.

https://codereview.webrtc.org/2977603002/diff/40001/webrtc/modules/video_codi...
File webrtc/modules/video_coding/sequence_number_util_unittest.cc (right):

https://codereview.webrtc.org/2977603002/diff/40001/webrtc/modules/video_codi...
webrtc/modules/video_coding/sequence_number_util_unittest.cc:218: //
unwrapper.Unwrap(255);
On 2017/07/24 13:35:39, terelius wrote:
> Should this really be commented? Did you intend to make a death test instead?

TIL, death tests :)

[philipel, 2017-07-24 14:46:54]

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

[commit-bot: I haz the power, 2017-07-24 14:47:01]

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-07-24 15:39:52]

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

[commit-bot: I haz the power, 2017-07-24 15:39:53]

Dry run: This issue passed the CQ dry run.

[philipel, 2017-07-24 15:41:42]

philipel@webrtc.org changed reviewers:
+ perkj@webrtc.org, sprang@webrtc.org

[philipel, 2017-07-24 15:41:43]

Per, PTAL at rtc_base/*.
Erik, PTAL at video_coding/*

Need OWNERS approval :)

[philipel, 2017-07-25 11:29:32]

philipel@webrtc.org changed reviewers:
+ deadbeef@webrtc.org
- perkj@webrtc.org

[philipel, 2017-07-25 11:29:33]

Taylor, PTAL at rtc_base/*

[sprang_webrtc, 2017-07-25 12:46:13]

https://codereview.webrtc.org/2977603002/diff/80001/webrtc/modules/video_codi...
File webrtc/modules/video_coding/sequence_number_util_unittest.cc (right):

https://codereview.webrtc.org/2977603002/diff/80001/webrtc/modules/video_codi...
webrtc/modules/video_coding/sequence_number_util_unittest.cc:219: }
Only from 0? Isn't any backwards wrap past 0 illegal? In that case, also test
largest possible start value where an illegal backwards wrap exists. Plus wrap
from 0 to the lowest value causing illegal wrap.

Additionally, make sure that assumption is made clear in a comment in the
unwrapper class.

https://codereview.webrtc.org/2977603002/diff/80001/webrtc/modules/video_codi...
webrtc/modules/video_coding/sequence_number_util_unittest.cc:306: 
Add a case for uint32_t as well. Or just parameterize these test for all
unsigned integer types.

Would fuzzing this (including M?) be useful?

[philipel, 2017-07-25 13:05:48]

https://codereview.webrtc.org/2977603002/diff/80001/webrtc/modules/video_codi...
File webrtc/modules/video_coding/sequence_number_util_unittest.cc (right):

https://codereview.webrtc.org/2977603002/diff/80001/webrtc/modules/video_codi...
webrtc/modules/video_coding/sequence_number_util_unittest.cc:219: }
On 2017/07/25 12:46:13, sprang_webrtc wrote:
> Only from 0? Isn't any backwards wrap past 0 illegal? In that case, also test
> largest possible start value where an illegal backwards wrap exists. Plus wrap
> from 0 to the lowest value causing illegal wrap.
> 
> Additionally, make sure that assumption is made clear in a comment in the
> unwrapper class.

Updated/added comments.

https://codereview.webrtc.org/2977603002/diff/80001/webrtc/modules/video_codi...
webrtc/modules/video_coding/sequence_number_util_unittest.cc:306: 
On 2017/07/25 12:46:13, sprang_webrtc wrote:
> Add a case for uint32_t as well. Or just parameterize these test for all
> unsigned integer types.
> 
> Would fuzzing this (including M?) be useful?

Added NoForwardWrap which use uint32_t.

I don't think it makes sense to fuzz this class since we CHECK that we the
unwrapped sequence does not wrap.

[philipel, 2017-07-25 13:24:29]

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

[commit-bot: I haz the power, 2017-07-25 13:24:32]

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-07-25 14:14:22]

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

[commit-bot: I haz the power, 2017-07-25 14:14:23]

Dry run: This issue passed the CQ dry run.

[Taylor Brandstetter, 2017-07-25 21:33:05]

rtc_base lgtm, with minor comments.

https://codereview.webrtc.org/2977603002/diff/100001/webrtc/rtc_base/mod_ops.h
File webrtc/rtc_base/mod_ops.h (right):

https://codereview.webrtc.org/2977603002/diff/100001/webrtc/rtc_base/mod_ops....
webrtc/rtc_base/mod_ops.h:61: //
Would be nice to have a comment explaining that M is the value at which wrapping
occurs (aka the divisor), and that "M==0" means it uses the full range of T.

https://codereview.webrtc.org/2977603002/diff/100001/webrtc/rtc_base/mod_ops_...
File webrtc/rtc_base/mod_ops_unittest.cc (right):

https://codereview.webrtc.org/2977603002/diff/100001/webrtc/rtc_base/mod_ops_...
webrtc/rtc_base/mod_ops_unittest.cc:98: }
nit: I don't like how these tests are written; they duplicate logic by the code
under test and it's not immediately obvious that they're correct. I would have
written them to test a few representative values, including corner cases. For
example:

ASSERT_EQ(122, ForwardDiff<uint8_t, 123>(0, 122));
ASSERT_EQ(122, ForwardDiff<uint8_t, 123>(1, 0));
ASSERT_EQ(1, ForwardDiff<uint8_t, 123>(122, 0));

And maybe even split these into separate tests cases.

See:
https://engdoc.corp.google.com/eng/doc/devguide/coding/testing/unit-testing-b...

Though the rest of the existing tests do the same thing as the new tests. So you
can decide whether to go for consistency or "good test design". At a minimum it
would be nice to have a TODO though.

[philipel, 2017-07-26 09:52:15]

https://codereview.webrtc.org/2977603002/diff/100001/webrtc/rtc_base/mod_ops.h
File webrtc/rtc_base/mod_ops.h (right):

https://codereview.webrtc.org/2977603002/diff/100001/webrtc/rtc_base/mod_ops....
webrtc/rtc_base/mod_ops.h:61: //
On 2017/07/25 21:33:04, Taylor Brandstetter wrote:
> Would be nice to have a comment explaining that M is the value at which
wrapping
> occurs (aka the divisor), and that "M==0" means it uses the full range of T.

Added Comment.

https://codereview.webrtc.org/2977603002/diff/100001/webrtc/rtc_base/mod_ops_...
File webrtc/rtc_base/mod_ops_unittest.cc (right):

https://codereview.webrtc.org/2977603002/diff/100001/webrtc/rtc_base/mod_ops_...
webrtc/rtc_base/mod_ops_unittest.cc:98: }
On 2017/07/25 21:33:05, Taylor Brandstetter wrote:
> nit: I don't like how these tests are written; they duplicate logic by the
code
> under test and it's not immediately obvious that they're correct. I would have
> written them to test a few representative values, including corner cases. For
> example:
> 
> ASSERT_EQ(122, ForwardDiff<uint8_t, 123>(0, 122));
> ASSERT_EQ(122, ForwardDiff<uint8_t, 123>(1, 0));
> ASSERT_EQ(1, ForwardDiff<uint8_t, 123>(122, 0));
> 
> And maybe even split these into separate tests cases.
> 
> See:
>
https://engdoc.corp.google.com/eng/doc/devguide/coding/testing/unit-testing-b...
> 
> Though the rest of the existing tests do the same thing as the new tests. So
you
> can decide whether to go for consistency or "good test design". At a minimum
it
> would be nice to have a TODO though.

Better to start using better test design. Updated the tests with simpler logic.

[philipel, 2017-07-26 09:52:31]

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

[commit-bot: I haz the power, 2017-07-26 09:52:42]

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-07-26 10:20:53]

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

[commit-bot: I haz the power, 2017-07-26 10:20:54]

Dry run: This issue passed the CQ dry run.

[sprang_webrtc, 2017-07-26 13:26:01]

lgtm

[philipel, 2017-07-26 14:44:46]

The CQ bit was checked by philipel@webrtc.org

[philipel, 2017-07-26 14:44:46]

The patchset sent to the CQ was uploaded after l-g-t-m from terelius@webrtc.org,
deadbeef@webrtc.org
Link to the patchset: https://codereview.webrtc.org/2977603002/#ps120001 (title:
"Feedback")

[commit-bot: I haz the power, 2017-07-26 14:44:55]

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-07-26 14:48:16]

CQ is committing da patch.

Bot data: {"patchset_id": 120001, "attempt_start_ts": 1501080286210900,
"parent_rev": "8de1826b6d51830aacfcc0944e85584495369c70", "commit_rev":
"7956c0f2f68e3fbaaab0936aad8b1f2b9437d7fe"}

[commit-bot: I haz the power, 2017-07-26 14:48:24]

Description was changed from

==========
Implemented a new sequence number unwrapper in sequence_number_util.h.

There is already an Unwrapper in webrtc/modules/include/module_common_types.h,
but we reimplemented it in sequence_number_util.h for a few reasons:
 - Such a class belongs in sequence_number_util.h.
 - It is a cleaner implementation since we can use the rest of
   sequence_number_util.h functionality.
 - You can choose at which number the unwrapped sequence should start,
   which is used to avoid the edge case when a backward wrap can happen
   as the first few numbers are unwrapped.
 - This unwrapper can unwrap numbers that does not wrap 8/16/32 bits.



BUG=None
==========

to

==========
Implemented a new sequence number unwrapper in sequence_number_util.h.

There is already an Unwrapper in webrtc/modules/include/module_common_types.h,
but we reimplemented it in sequence_number_util.h for a few reasons:
 - Such a class belongs in sequence_number_util.h.
 - It is a cleaner implementation since we can use the rest of
   sequence_number_util.h functionality.
 - You can choose at which number the unwrapped sequence should start,
   which is used to avoid the edge case when a backward wrap can happen
   as the first few numbers are unwrapped.
 - This unwrapper can unwrap numbers that does not wrap 8/16/32 bits.



BUG=None

Review-Url: https://codereview.webrtc.org/2977603002
Cr-Commit-Position: refs/heads/master@{#19154}
Committed:
https://chromium.googlesource.com/external/webrtc/+/7956c0f2f68e3fbaaab0936aa...
==========

[commit-bot: I haz the power, 2017-07-26 14:48:25]

Committed patchset #7 (id:120001) as
https://chromium.googlesource.com/external/webrtc/+/7956c0f2f68e3fbaaab0936aa...