SSRC and RSID may only refer to one sink each in RtpDemuxer

SSRC and RSID may only refer to one sink each in RtpDemuxer

RTP demuxing should only match RTP packets with one sink.

BUG=webrtc:7135
Review-Url: https://codereview.webrtc.org/2968693002
Cr-Commit-Position: refs/heads/master@{#19233}
Committed: https://chromium.googlesource.com/external/webrtc/+/7b7e06fd23ac67d81f378b773bb631abb1d82116

[eladalon, 2017-06-30 12:53:23]

eladalon@webrtc.org changed reviewers:
+ danilchap@webrtc.org, nisse@webrtc.org

[eladalon, 2017-06-30 12:53:24]

PTAL

https://codereview.webrtc.org/2968693002/diff/1/webrtc/call/rtp_stream_receiv...
File webrtc/call/rtp_stream_receiver_controller.cc (right):

https://codereview.webrtc.org/2968693002/diff/1/webrtc/call/rtp_stream_receiv...
webrtc/call/rtp_stream_receiver_controller.cc:49: demuxer_.AddSink(ssrc, sink); 
// TODO(eladalon): Return-value useful here?
Reviewers - input welcome!

[danilchap, 2017-06-30 16:45:31]

https://codereview.webrtc.org/2968693002/diff/1/webrtc/call/rtp_demuxer.cc
File webrtc/call/rtp_demuxer.cc (right):

https://codereview.webrtc.org/2968693002/diff/1/webrtc/call/rtp_demuxer.cc#ne...
webrtc/call/rtp_demuxer.cc:37: if (ssrc_sinks_.find(ssrc) == ssrc_sinks_.cend())
{
can be done with single lookup instead of two:
return ssrc_sinks_.emplace(ssrc, sink).second;

https://codereview.webrtc.org/2968693002/diff/1/webrtc/call/rtp_demuxer.cc#ne...
webrtc/call/rtp_demuxer.cc:40: } else {
fyi (since likely irrelevant due to previous comment)
https://chromium.googlesource.com/chromium/src/+/master/styleguide/c++/c++.md
"Don't use else after return"

https://codereview.webrtc.org/2968693002/diff/1/webrtc/call/rtp_demuxer.h
File webrtc/call/rtp_demuxer.h (right):

https://codereview.webrtc.org/2968693002/diff/1/webrtc/call/rtp_demuxer.h#new...
webrtc/call/rtp_demuxer.h:49: // Hanldes RTP packets. Returns true if at least
one matching sink was found.
Not in this CL, but it might be overall cleaner and more powerfull interface if
demuxer would return the matching sink instead of using it:
// Returns null if no matching sink was found.
RtpPacketSinkInterface* FindSink(const RtpPacketReceived& packet);

it wasn't possible with -to-many mapping but doable with -to-one mapping

https://codereview.webrtc.org/2968693002/diff/1/webrtc/call/rtp_rtcp_demuxer_...
File webrtc/call/rtp_rtcp_demuxer_helper.h (right):

https://codereview.webrtc.org/2968693002/diff/1/webrtc/call/rtp_rtcp_demuxer_...
webrtc/call/rtp_rtcp_demuxer_helper.h:68: // TODO(eladalon): Remove this in the
next CL.
Why next CL? do you mean 'Remove when unused'?
or 'Remove when rtcp_demuxer will not use multimap too'?

https://codereview.webrtc.org/2968693002/diff/1/webrtc/call/rtp_stream_receiv...
File webrtc/call/rtp_stream_receiver_controller.cc (right):

https://codereview.webrtc.org/2968693002/diff/1/webrtc/call/rtp_stream_receiv...
webrtc/call/rtp_stream_receiver_controller.cc:49: demuxer_.AddSink(ssrc, sink); 
// TODO(eladalon): Return-value useful here?
On 2017/06/30 12:53:24, eladalon wrote:
> Reviewers - input welcome!

might be helpful.
either return bool, or RTC_CHECK() sink was added.

Otherwise if AddSink will fail it will be hard to understand what's going on.

https://codereview.webrtc.org/2968693002/diff/80001/webrtc/call/rtp_demuxer.cc
File webrtc/call/rtp_demuxer.cc (right):

https://codereview.webrtc.org/2968693002/diff/80001/webrtc/call/rtp_demuxer.c...
webrtc/call/rtp_demuxer.cc:49: // TODO(eladalon): Discuss with nisse and
danilchap whether we want to
I do not know a use case where adding sink by rsid expect to fail.
i.e. keep DCHECK.
returning bool will push DCHECK to user of the RtpDemuxer. that is an option
too, but for now better change less.

https://codereview.webrtc.org/2968693002/diff/80001/webrtc/call/rtp_demuxer_u...
File webrtc/call/rtp_demuxer_unittest.cc (right):

https://codereview.webrtc.org/2968693002/diff/80001/webrtc/call/rtp_demuxer_u...
webrtc/call/rtp_demuxer_unittest.cc:240: for (size_t i = 0; i <
arraysize(sinks); i++) {
unwind loop probably easier to read:
ASSERT_TRUE(demuxer.AddSink(ssrc, &sinks[0]));
ASSERT_FALSE(demuxer.AddSink(ssrc, &sinks[1]));
ASSERT_FALSE(demuxer.AddSink(ssrc, &sinks[2]));

https://codereview.webrtc.org/2968693002/diff/80001/webrtc/call/rtp_demuxer_u...
webrtc/call/rtp_demuxer_unittest.cc:255: TEST(RtpDemuxerTest,
AddSinkFailsIfCalledTwiceEvenIfBothTimesAreForSameSink) {
may be drop 'EvenIfBothTimesAre'

[eladalon, 2017-07-03 08:23:36]

https://codereview.webrtc.org/2968693002/diff/1/webrtc/call/rtp_demuxer.cc
File webrtc/call/rtp_demuxer.cc (right):

https://codereview.webrtc.org/2968693002/diff/1/webrtc/call/rtp_demuxer.cc#ne...
webrtc/call/rtp_demuxer.cc:37: if (ssrc_sinks_.find(ssrc) == ssrc_sinks_.cend())
{
On 2017/06/30 16:45:30, danilchap OOO until July17 wrote:
> can be done with single lookup instead of two:
> return ssrc_sinks_.emplace(ssrc, sink).second;

That's less readable IMHO, but okay.

https://codereview.webrtc.org/2968693002/diff/1/webrtc/call/rtp_demuxer.cc#ne...
webrtc/call/rtp_demuxer.cc:40: } else {
On 2017/06/30 16:45:30, danilchap OOO until July17 wrote:
> fyi (since likely irrelevant due to previous comment)
> https://chromium.googlesource.com/chromium/src/+/master/styleguide/c++/c++.md
> "Don't use else after return"

Thanks for letting me know. I don't like this particular guideline, but
guidelines are guidelines.

https://codereview.webrtc.org/2968693002/diff/1/webrtc/call/rtp_demuxer.h
File webrtc/call/rtp_demuxer.h (right):

https://codereview.webrtc.org/2968693002/diff/1/webrtc/call/rtp_demuxer.h#new...
webrtc/call/rtp_demuxer.h:49: // Hanldes RTP packets. Returns true if at least
one matching sink was found.
On 2017/06/30 16:45:30, danilchap OOO until July17 wrote:
> Not in this CL, but it might be overall cleaner and more powerfull interface
if
> demuxer would return the matching sink instead of using it:
> // Returns null if no matching sink was found.
> RtpPacketSinkInterface* FindSink(const RtpPacketReceived& packet);
> 
> it wasn't possible with -to-many mapping but doable with -to-one mapping

Agreed, but that would also require removing the broadcast interface from
RtcpDemuxer; I'd not want to have RtpDemuxer and RtcpDemuxer behave more
differently than they must.

https://codereview.webrtc.org/2968693002/diff/1/webrtc/call/rtp_rtcp_demuxer_...
File webrtc/call/rtp_rtcp_demuxer_helper.h (right):

https://codereview.webrtc.org/2968693002/diff/1/webrtc/call/rtp_rtcp_demuxer_...
webrtc/call/rtp_rtcp_demuxer_helper.h:68: // TODO(eladalon): Remove this in the
next CL.
On 2017/06/30 16:45:31, danilchap OOO until July17 wrote:
> Why next CL? do you mean 'Remove when unused'?
> or 'Remove when rtcp_demuxer will not use multimap too'?

The next CL will do something similar for RtcpDemuxer, at which point this will
become dead code, and will be removed. (Seemed like too wordy for a TODO that
will survive for one CL.)

https://codereview.webrtc.org/2968693002/diff/1/webrtc/call/rtp_stream_receiv...
File webrtc/call/rtp_stream_receiver_controller.cc (right):

https://codereview.webrtc.org/2968693002/diff/1/webrtc/call/rtp_stream_receiv...
webrtc/call/rtp_stream_receiver_controller.cc:49: demuxer_.AddSink(ssrc, sink); 
// TODO(eladalon): Return-value useful here?
On 2017/06/30 16:45:31, danilchap OOO until July17 wrote:
> On 2017/06/30 12:53:24, eladalon wrote:
> > Reviewers - input welcome!
> 
> might be helpful.
> either return bool, or RTC_CHECK() sink was added.
> 
> Otherwise if AddSink will fail it will be hard to understand what's going on.

Done.

https://codereview.webrtc.org/2968693002/diff/80001/webrtc/call/rtp_demuxer.cc
File webrtc/call/rtp_demuxer.cc (right):

https://codereview.webrtc.org/2968693002/diff/80001/webrtc/call/rtp_demuxer.c...
webrtc/call/rtp_demuxer.cc:49: // TODO(eladalon): Discuss with nisse and
danilchap whether we want to
On 2017/06/30 16:45:31, danilchap OOO until July17 wrote:
> I do not know a use case where adding sink by rsid expect to fail.
> i.e. keep DCHECK.
> returning bool will push DCHECK to user of the RtpDemuxer. that is an option
> too, but for now better change less.

Acknowledged.

https://codereview.webrtc.org/2968693002/diff/80001/webrtc/call/rtp_demuxer_u...
File webrtc/call/rtp_demuxer_unittest.cc (right):

https://codereview.webrtc.org/2968693002/diff/80001/webrtc/call/rtp_demuxer_u...
webrtc/call/rtp_demuxer_unittest.cc:240: for (size_t i = 0; i <
arraysize(sinks); i++) {
On 2017/06/30 16:45:31, danilchap OOO until July17 wrote:
> unwind loop probably easier to read:
> ASSERT_TRUE(demuxer.AddSink(ssrc, &sinks[0]));
> ASSERT_FALSE(demuxer.AddSink(ssrc, &sinks[1]));
> ASSERT_FALSE(demuxer.AddSink(ssrc, &sinks[2]));

Done. (The downside of this approach is that you can't as easily change the
number of sinks anymore.)

https://codereview.webrtc.org/2968693002/diff/80001/webrtc/call/rtp_demuxer_u...
webrtc/call/rtp_demuxer_unittest.cc:255: TEST(RtpDemuxerTest,
AddSinkFailsIfCalledTwiceEvenIfBothTimesAreForSameSink) {
On 2017/06/30 16:45:31, danilchap OOO until July17 wrote:
> may be drop 'EvenIfBothTimesAre'

Changed to AddSinkFailsIfCalledTwiceEvenIfSameSink; I'd like to keep some focus
on "this adds a twist to a previous test." (The previous test being
OnlyOneSinkPerSsrcGetsOnRtpPacketTriggered, but I don't want to rename that to
get them to look more similar, as I believe that names would be less
illustrative of the test's function.)

[eladalon, 2017-07-03 08:24:24]

eladalon@webrtc.org changed reviewers:
+ perkj@webrtc.org, stefan@webrtc.org

[eladalon, 2017-07-03 08:24:25]

Adding Per and Stefan to accept, as Danil is OOO.

[holmer, 2017-07-03 09:06:13]

holmer@google.com changed reviewers:
+ holmer@google.com

[holmer, 2017-07-03 09:06:15]

https://codereview.webrtc.org/2968693002/diff/100001/webrtc/call/flexfec_rece...
File webrtc/call/flexfec_receive_stream_impl.cc (right):

https://codereview.webrtc.org/2968693002/diff/100001/webrtc/call/flexfec_rece...
webrtc/call/flexfec_receive_stream_impl.cc:161:
RTC_CHECK(receiver_controller->AddSink(ssrc, this));
Is it possible to trigger this by writing a broken SDP? In that case I think we
shouldn't CHECK but instead return an error. Hopefully this is verified earlier
in the stack though?

https://codereview.webrtc.org/2968693002/diff/100001/webrtc/call/rtp_demuxer.cc
File webrtc/call/rtp_demuxer.cc (right):

https://codereview.webrtc.org/2968693002/diff/100001/webrtc/call/rtp_demuxer....
webrtc/call/rtp_demuxer.cc:90: return;
Log a warning?

https://codereview.webrtc.org/2968693002/diff/100001/webrtc/call/rtp_demuxer....
webrtc/call/rtp_demuxer.cc:95: return;
Should we log warnings when this happens?

https://codereview.webrtc.org/2968693002/diff/100001/webrtc/call/rtp_demuxer....
webrtc/call/rtp_demuxer.cc:102: // with a sink, avoid propagating the problem to
the resolution observers.
Warning

https://codereview.webrtc.org/2968693002/diff/100001/webrtc/call/rtp_demuxer.h
File webrtc/call/rtp_demuxer.h (right):

https://codereview.webrtc.org/2968693002/diff/100001/webrtc/call/rtp_demuxer....
webrtc/call/rtp_demuxer.h:49: // Hanldes RTP packets. Returns true if at least
one matching sink was found.
Handles

https://codereview.webrtc.org/2968693002/diff/100001/webrtc/call/rtp_stream_r...
File webrtc/call/rtp_stream_receiver_controller.cc (right):

https://codereview.webrtc.org/2968693002/diff/100001/webrtc/call/rtp_stream_r...
webrtc/call/rtp_stream_receiver_controller.cc:21:
RTC_CHECK(controller_->AddSink(ssrc, sink_));
Is this CHECK good given that this likely comes from SDP?

[eladalon, 2017-07-03 11:25:35]

https://codereview.webrtc.org/2968693002/diff/100001/webrtc/call/flexfec_rece...
File webrtc/call/flexfec_receive_stream_impl.cc (right):

https://codereview.webrtc.org/2968693002/diff/100001/webrtc/call/flexfec_rece...
webrtc/call/flexfec_receive_stream_impl.cc:161:
RTC_CHECK(receiver_controller->AddSink(ssrc, this));
On 2017/07/03 09:06:14, holmer wrote:
> Is it possible to trigger this by writing a broken SDP? In that case I think
we
> shouldn't CHECK but instead return an error. Hopefully this is verified
earlier
> in the stack though?

As per our offline discussion, it would be better to first fix FlexFec to not
require being registered with the demuxer, and rebase this CL on top of it. I'll
do that.

https://codereview.webrtc.org/2968693002/diff/100001/webrtc/call/rtp_demuxer.cc
File webrtc/call/rtp_demuxer.cc (right):

https://codereview.webrtc.org/2968693002/diff/100001/webrtc/call/rtp_demuxer....
webrtc/call/rtp_demuxer.cc:90: return;
On 2017/07/03 09:06:14, holmer wrote:
> Log a warning?
Not an error; this packet simply had no RSID.

https://codereview.webrtc.org/2968693002/diff/100001/webrtc/call/rtp_demuxer....
webrtc/call/rtp_demuxer.cc:95: return;
On 2017/07/03 09:06:14, holmer wrote:
> Should we log warnings when this happens?

Done.

https://codereview.webrtc.org/2968693002/diff/100001/webrtc/call/rtp_demuxer....
webrtc/call/rtp_demuxer.cc:102: // with a sink, avoid propagating the problem to
the resolution observers.
On 2017/07/03 09:06:14, holmer wrote:
> Warning

Done.

https://codereview.webrtc.org/2968693002/diff/100001/webrtc/call/rtp_demuxer.h
File webrtc/call/rtp_demuxer.h (right):

https://codereview.webrtc.org/2968693002/diff/100001/webrtc/call/rtp_demuxer....
webrtc/call/rtp_demuxer.h:49: // Hanldes RTP packets. Returns true if at least
one matching sink was found.
On 2017/07/03 09:06:14, holmer wrote:
> Handles

Thanks

https://codereview.webrtc.org/2968693002/diff/100001/webrtc/call/rtp_stream_r...
File webrtc/call/rtp_stream_receiver_controller.cc (right):

https://codereview.webrtc.org/2968693002/diff/100001/webrtc/call/rtp_stream_r...
webrtc/call/rtp_stream_receiver_controller.cc:21:
RTC_CHECK(controller_->AddSink(ssrc, sink_));
On 2017/07/03 09:06:14, holmer wrote:
> Is this CHECK good given that this likely comes from SDP?

Changed to a log. Do you think we should have a TODO and/or bug filed for making
sure this can't happen, or would we rely on seeing this warning come up if this
is not sufficiently protected against?

[eladalon, 2017-07-06 16:44:33]

https://codereview.webrtc.org/2968693002/diff/140001/webrtc/call/flexfec_rece...
File webrtc/call/flexfec_receive_stream_impl.cc (right):

https://codereview.webrtc.org/2968693002/diff/140001/webrtc/call/flexfec_rece...
webrtc/call/flexfec_receive_stream_impl.cc:161: // TODO(eladalon): Make sure
FlexFec no longer requires this, then rebase
The CL that remove this has been put up for review -
https://codereview.webrtc.org/2974453002/diff/1/webrtc/call/flexfec_receive_s...
I'll rebase this CL after that CL has gone through the review process. For now,
please just ignore this TODO.

[eladalon, 2017-07-13 14:39:22]

eladalon@webrtc.org changed reviewers:
+ deadbeef@webrtc.org

[eladalon, 2017-07-21 09:10:01]

Description was changed from

==========
SSRC and RSID may only refer to one sink each in RtpDemuxer

RTP demuxing should only match RTP packets with one sink.

BUG=webrtc:7135
==========

to

==========
SSRC and RSID may only refer to one sink each in RtpDemuxer

RTP demuxing should only match RTP packets with one sink.

BUG=webrtc:7135
==========

[eladalon, 2017-07-21 09:10:02]

eladalon@webrtc.org changed reviewers:
+ pthatcher@webrtc.org

[danilchap, 2017-07-26 11:25:47]

lgtm

https://codereview.webrtc.org/2968693002/diff/1/webrtc/call/rtp_rtcp_demuxer_...
File webrtc/call/rtp_rtcp_demuxer_helper.h (right):

https://codereview.webrtc.org/2968693002/diff/1/webrtc/call/rtp_rtcp_demuxer_...
webrtc/call/rtp_rtcp_demuxer_helper.h:68: // TODO(eladalon): Remove this in the
next CL.
On 2017/07/03 08:23:35, eladalon wrote:
> On 2017/06/30 16:45:31, danilchap OOO until July17 wrote:
> > Why next CL? do you mean 'Remove when unused'?
> > or 'Remove when rtcp_demuxer will not use multimap too'?
> 
> The next CL will do something similar for RtcpDemuxer, at which point this
will
> become dead code, and will be removed. (Seemed like too wordy for a TODO that
> will survive for one CL.)

Acknowledged.

https://codereview.webrtc.org/2968693002/diff/180001/webrtc/call/rtp_stream_r...
File webrtc/call/rtp_stream_receiver_controller.cc (right):

https://codereview.webrtc.org/2968693002/diff/180001/webrtc/call/rtp_stream_r...
webrtc/call/rtp_stream_receiver_controller.cc:23: const bool sink_added =
controller_->AddSink(ssrc, sink_);
nit: const is probably overkill here

[eladalon, 2017-07-26 11:30:13]

https://codereview.webrtc.org/2968693002/diff/180001/webrtc/call/rtp_stream_r...
File webrtc/call/rtp_stream_receiver_controller.cc (right):

https://codereview.webrtc.org/2968693002/diff/180001/webrtc/call/rtp_stream_r...
webrtc/call/rtp_stream_receiver_controller.cc:23: const bool sink_added =
controller_->AddSink(ssrc, sink_);
On 2017/07/26 11:25:47, danilchap wrote:
> nit: const is probably overkill here

IIRC, this was required by some previous reviewers in other CLs; I think Minyue.
I'll keep until I've asked around and found out what the current style-consensus
is.

[Steve Anton, 2017-08-02 20:34:34]

LGTM, just a couple of minor nits on the tests.

[Steve Anton, 2017-08-02 20:35:24]

https://codereview.webrtc.org/2968693002/diff/240001/webrtc/call/rtp_demuxer_...
File webrtc/call/rtp_demuxer_unittest.cc (right):

https://codereview.webrtc.org/2968693002/diff/240001/webrtc/call/rtp_demuxer_...
webrtc/call/rtp_demuxer_unittest.cc:237: ASSERT_FALSE(demuxer.AddSink(ssrc,
&sinks[2]));
nit: I don't think it's really necessary to check that sinks[2] fails to be
added, since that case should be covered by the previous line.

https://codereview.webrtc.org/2968693002/diff/240001/webrtc/call/rtp_demuxer_...
webrtc/call/rtp_demuxer_unittest.cc:242: EXPECT_CALL(sinks[0],
OnRtpPacket(SamePacketAs(*packet)));
nit: Perhaps also expect that sinks[1], sinks[2] receive no calls to
OnRtpPacket?

[Taylor Brandstetter, 2017-08-02 21:03:32]

lgtm, though there are just some behaviors in this CL that are changed in
Steve's CL (https://chromium-review.googlesource.com/c/578628/12..13), and some
places where "all we guarantee is graceful behavior" has been upgraded to an
explicit guarantee about what will happen. I think we can go ahead and land
this, but if there's disagreement about those changes we should discuss them.

https://codereview.webrtc.org/2968693002/diff/240001/webrtc/call/rtp_demuxer.cc
File webrtc/call/rtp_demuxer.cc (right):

https://codereview.webrtc.org/2968693002/diff/240001/webrtc/call/rtp_demuxer....
webrtc/call/rtp_demuxer.cc:102: << packet.Ssrc() << ").";
In Steve's CL, the RSID takes precedence in this case (which comes at the advice
of Peter, if I understood him correctly, because RSIDs are a more trustworthy
source of information than SSRCs). Though we can land this CL as-is and let
Steve's CL change it, assuming you're ok with that decision.

https://codereview.webrtc.org/2968693002/diff/240001/webrtc/call/rtp_demuxer....
webrtc/call/rtp_demuxer.cc:112: rsid_sinks_.erase(it);
Do we need this restriction? Steve's CL changes it.

[eladalon, 2017-08-03 11:14:25]

Taylor, the differences compared to Steve's CL are not due to disagreement about
the intended direction. This CL was created as a step towards implementing the
BUNDLE algorithm. This particular step is chiefly concerned with removing the
many-to-many behavior. More steps were expected, including steps that might
throw away some of the code from this CL. Overall, I believe this should make
Steve's CL's work easier.

https://codereview.webrtc.org/2968693002/diff/240001/webrtc/call/rtp_demuxer_...
File webrtc/call/rtp_demuxer_unittest.cc (right):

https://codereview.webrtc.org/2968693002/diff/240001/webrtc/call/rtp_demuxer_...
webrtc/call/rtp_demuxer_unittest.cc:237: ASSERT_FALSE(demuxer.AddSink(ssrc,
&sinks[2]));
On 2017/08/02 20:35:24, Steve Anton wrote:
> nit: I don't think it's really necessary to check that sinks[2] fails to be
> added, since that case should be covered by the previous line.

I've used an ASSERT here, which marks that "though this is not the thing being
tested, the test cannot go on if this doesn't hold true." The actual test for
this, using EXPECT, is done at AddSinkFailsIfCalledForTwoSinks. If someone
modifies code so that this breaks, we want AddSinkFailsIfCalledForTwoSinks to
record the failure, and OnlyOneSinkPerSsrcGetsOnRtpPacketTriggered shows an
assertion failure rather than passing.

https://codereview.webrtc.org/2968693002/diff/240001/webrtc/call/rtp_demuxer_...
webrtc/call/rtp_demuxer_unittest.cc:242: EXPECT_CALL(sinks[0],
OnRtpPacket(SamePacketAs(*packet)));
On 2017/08/02 20:35:24, Steve Anton wrote:
> nit: Perhaps also expect that sinks[1], sinks[2] receive no calls to
> OnRtpPacket?

Done.

[stefan-webrtc, 2017-08-03 11:32:07]

rs-lgtm

[eladalon, 2017-08-03 11:34:12]

The CQ bit was checked by eladalon@webrtc.org

[eladalon, 2017-08-03 11:34:13]

The patchset sent to the CQ was uploaded after l-g-t-m from
danilchap@webrtc.org, steveanton@webrtc.org, deadbeef@webrtc.org
Link to the patchset: https://codereview.webrtc.org/2968693002/#ps280001 (title:
"Add expectations to OnlyOneSinkPerSsrcGetsOnRtpPacketTriggered.")

[commit-bot: I haz the power, 2017-08-03 11:34:16]

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-03 12:13:49]

CQ is committing da patch.

Bot data: {"patchset_id": 280001, "attempt_start_ts": 1501760052488550,
"parent_rev": "1d0bdc296be7e47c9812a72451112cb3c9a8dc8b", "commit_rev":
"7b7e06fd23ac67d81f378b773bb631abb1d82116"}

[commit-bot: I haz the power, 2017-08-03 12:13:55]

Description was changed from

==========
SSRC and RSID may only refer to one sink each in RtpDemuxer

RTP demuxing should only match RTP packets with one sink.

BUG=webrtc:7135
==========

to

==========
SSRC and RSID may only refer to one sink each in RtpDemuxer

RTP demuxing should only match RTP packets with one sink.

BUG=webrtc:7135

Review-Url: https://codereview.webrtc.org/2968693002
Cr-Commit-Position: refs/heads/master@{#19233}
Committed:
https://chromium.googlesource.com/external/webrtc/+/7b7e06fd23ac67d81f378b773...
==========

[commit-bot: I haz the power, 2017-08-03 12:13:56]

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

[Zhi Huang, 2017-08-03 17:09:29]

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

The reason for reverting is: Some internal tests keep failing after this change.
Try to fix it by reverting it. Will reland it if this isn't the root cause..

[charujain, 2017-08-03 17:51:22]

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

The reason for reverting is: Break internal projects.