Remove faulty DCHECK in rtcp::TransportFeedback::ParseFrom

Remove faulty DCHECK in rtcp::TransportFeedback::ParseFrom

BUG=chromium:632585
R=sprang@webrtc.org

Committed: https://chromium.googlesource.com/external/webrtc/+/837a1707ae5aed19306f2bd9b4b0927901247b68

[danilchap, 2016-07-29 11:53:21]

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

[danilchap, 2016-07-29 11:53:21]

Parse shouldn't assume transport feedback packet arrived from network use
maximum 3 bytes of padding.

[stefan-webrtc, 2016-07-29 13:25:12]

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

[stefan-webrtc, 2016-07-29 13:25:12]

sprang wrote this code, so I think he's a better reviewer.

[danilchap, 2016-08-03 08:47:45]

Description was changed from

==========
Remove faulty DCHECK in rtcp::TransportFeedback::ParseFrom

BUG=chromium:632585
==========

to

==========
Remove faulty DCHECK in rtcp::TransportFeedback::ParseFrom

BUG=chromium:632585
==========

[danilchap, 2016-08-03 08:47:45]

danilchap@webrtc.org changed reviewers:
- stefan@webrtc.org

[danilchap, 2016-08-03 09:30:13]

ptal

[sprang_webrtc, 2016-08-03 10:27:35]

Pad up to nearest 32bit boundary was my intention for the message, but maybe
this wasn't explicitly stated in the spec?
In that case you are technically correct, and this lgtm

[danilchap, 2016-08-03 10:36:32]

On 2016/08/03 10:27:35, språng wrote:
> Pad up to nearest 32bit boundary was my intention for the message, but maybe
> this wasn't explicitly stated in the spec?
> In that case you are technically correct, and this lgtm

Either way it shouldn't be a DCHECK because incoming data might
understand/ignore spec any way it wants.
We can fail parse if it is not padded up to nearest 32bit, do you think we
should?

[sprang_webrtc, 2016-08-03 11:36:10]

On 2016/08/03 10:36:32, danilchap wrote:
> On 2016/08/03 10:27:35, språng wrote:
> > Pad up to nearest 32bit boundary was my intention for the message, but maybe
> > this wasn't explicitly stated in the spec?
> > In that case you are technically correct, and this lgtm
> 
> Either way it shouldn't be a DCHECK because incoming data might
> understand/ignore spec any way it wants.
> We can fail parse if it is not padded up to nearest 32bit, do you think we
> should?

No. It's just a weird wasteful behavior, but if the parsing worked otherwise,
then I don't think it's a problem.
I suspect I added that to catch problems when writing our own packetization. :)
Be lenient when reading but strict when writing and all that. I think just
removing the DCHECK is OK.

[commit-bot: I haz the power, 2016-08-03 11:40:18]

Description was changed from

==========
Remove faulty DCHECK in rtcp::TransportFeedback::ParseFrom

BUG=chromium:632585
==========

to

==========
Remove faulty DCHECK in rtcp::TransportFeedback::ParseFrom

BUG=chromium:632585
R=sprang@webrtc.org

Committed: https://crrev.com/837a1707ae5aed19306f2bd9b4b0927901247b68
Cr-Commit-Position: refs/heads/master@{#13622}
==========

[commit-bot: I haz the power, 2016-08-03 11:40:19]

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

[danilchap, 2016-08-03 11:40:20]

Description was changed from

==========
Remove faulty DCHECK in rtcp::TransportFeedback::ParseFrom

BUG=chromium:632585
R=sprang@webrtc.org

Committed: https://crrev.com/837a1707ae5aed19306f2bd9b4b0927901247b68
Cr-Commit-Position: refs/heads/master@{#13622}
==========

to

==========
Remove faulty DCHECK in rtcp::TransportFeedback::ParseFrom

BUG=chromium:632585
R=sprang@webrtc.org

Committed:
https://chromium.googlesource.com/external/webrtc/+/837a1707ae5aed19306f2bd9b...
==========

[danilchap, 2016-08-03 11:40:21]

Committed patchset #1 (id:1) manually as
837a1707ae5aed19306f2bd9b4b0927901247b68 (presubmit successful).