Adds a test for an one-way media PeerConnection.

Adds a test for an one-way media PeerConnection.

This involves changing a few verification functions for frames
received so that they always accept the result if there's no stream.

BUG=

Committed: https://crrev.com/6b4f839c53090683ef2fb4be60d6b0d8f93818af
Cr-Commit-Position: refs/heads/master@{#11937}

[hta-webrtc, 2016-03-08 12:39:04]

Description was changed from

==========
Adds a test for an one-way media PeerConnection.

This involves changing a few verification functions for frames
received so that they always accept the result if there's no stream.

BUG=
==========

to

==========
Adds a test for an one-way media PeerConnection.

This involves changing a few verification functions for frames
received so that they always accept the result if there's no stream.

BUG=
==========

[hta-webrtc, 2016-03-08 12:39:04]

hta@webrtc.org changed reviewers:
+ phoglund@webrtc.org

[hta-webrtc, 2016-03-08 12:39:16]

Small CL.

[phoglund, 2016-03-08 12:52:18]

lgtm

https://codereview.webrtc.org/1772353002/diff/1/webrtc/api/peerconnection_uni...
File webrtc/api/peerconnection_unittest.cc (right):

https://codereview.webrtc.org/1772353002/diff/1/webrtc/api/peerconnection_uni...
webrtc/api/peerconnection_unittest.cc:429: // If there is no incoming stream,
return true always.
Nit: I can see that from the code, so maybe "Only check if there is a stream in
this test."

[hta-webrtc, 2016-03-08 13:52:45]

The CQ bit was checked by hta@webrtc.org

[hta-webrtc, 2016-03-08 13:52:49]

The patchset sent to the CQ was uploaded after l-g-t-m from phoglund@webrtc.org
Link to the patchset: https://codereview.webrtc.org/1772353002/#ps20001 (title:
"Review comment")

[commit-bot: I haz the power, 2016-03-08 13:52:51]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1772353002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1772353002/20001

[hta-webrtc, 2016-03-08 13:54:06]

Thanks, committing.

https://codereview.webrtc.org/1772353002/diff/1/webrtc/api/peerconnection_uni...
File webrtc/api/peerconnection_unittest.cc (right):

https://codereview.webrtc.org/1772353002/diff/1/webrtc/api/peerconnection_uni...
webrtc/api/peerconnection_unittest.cc:429: // If there is no incoming stream,
return true always.
On 2016/03/08 12:52:18, phoglund wrote:
> Nit: I can see that from the code, so maybe "Only check if there is a stream
in
> this test."

Done.

[commit-bot: I haz the power, 2016-03-08 13:58:21]

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

[commit-bot: I haz the power, 2016-03-08 13:58:22]

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

[hta-webrtc, 2016-03-08 14:05:16]

Need an OWNER approval

[hta-webrtc, 2016-03-08 17:18:37]

hta@webrtc.org changed reviewers:
+ perkj@webrtc.org, tommi@webrtc.org

[perkj_webrtc, 2016-03-08 23:07:50]

https://codereview.webrtc.org/1772353002/diff/20001/webrtc/api/peerconnection...
File webrtc/api/peerconnection_unittest.cc (right):

https://codereview.webrtc.org/1772353002/diff/20001/webrtc/api/peerconnection...
webrtc/api/peerconnection_unittest.cc:430: if (remote_streams()->count() == 0) {
can you please refactor LocalP2PTest instead? There is already a check for
can_receive... to fix this this. But it checks both the sender and the receiver
as one unit instead of separate. ie number_of_frames should be 0 if you dont
expect a frame.

[hta-webrtc, 2016-03-09 04:09:53]

Not wanting to do restructuring at this time....

https://codereview.webrtc.org/1772353002/diff/20001/webrtc/api/peerconnection...
File webrtc/api/peerconnection_unittest.cc (right):

https://codereview.webrtc.org/1772353002/diff/20001/webrtc/api/peerconnection...
webrtc/api/peerconnection_unittest.cc:430: if (remote_streams()->count() == 0) {
On 2016/03/08 23:07:50, perkj_webrtc wrote:
> can you please refactor LocalP2PTest instead? There is already a check for
> can_receive... to fix this this. But it checks both the sender and the
receiver
> as one unit instead of separate. ie number_of_frames should be 0 if you dont
> expect a frame.

I'd like not to, because I've got another CL in flight that significantly
restructures this whole piece of infrastructure (constraint removal). Would a
TODO be sufficient at this time?

The check for can_receive.... was wrong. It did not work for one-way media - in
the one-way media case, we're perfectly happy to receive, there just isn't
anyone sending.

[hta-webrtc, 2016-03-09 09:40:17]

After having meditated upon it for a few hours....

https://codereview.webrtc.org/1772353002/diff/20001/webrtc/api/peerconnection...
File webrtc/api/peerconnection_unittest.cc (right):

https://codereview.webrtc.org/1772353002/diff/20001/webrtc/api/peerconnection...
webrtc/api/peerconnection_unittest.cc:430: if (remote_streams()->count() == 0) {
On 2016/03/09 04:09:53, hta-webrtc wrote:
> On 2016/03/08 23:07:50, perkj_webrtc wrote:
> > can you please refactor LocalP2PTest instead? There is already a check for
> > can_receive... to fix this this. But it checks both the sender and the
> receiver
> > as one unit instead of separate. ie number_of_frames should be 0 if you dont
> > expect a frame.
> 
> I'd like not to, because I've got another CL in flight that significantly
> restructures this whole piece of infrastructure (constraint removal). Would a
> TODO be sufficient at this time?
> 
> The check for can_receive.... was wrong. It did not work for one-way media -
in
> the one-way media case, we're perfectly happy to receive, there just isn't
> anyone sending.
> 

Only took an hour to restructure the counting. Looks better?

[hta-webrtc, 2016-03-09 09:40:26]

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

[commit-bot: I haz the power, 2016-03-09 09:40:35]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1772353002/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1772353002/40001

[commit-bot: I haz the power, 2016-03-09 10:41:16]

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

[commit-bot: I haz the power, 2016-03-09 10:41:17]

Dry run: This issue passed the CQ dry run.

[perkj_webrtc, 2016-03-09 14:17:17]

Yes - thanks much better. Just a question .. You abort if nothing can receive
audio or video. Shouldnt we still test for connection to support data only?

https://codereview.webrtc.org/1772353002/diff/40001/webrtc/api/peerconnection...
File webrtc/api/peerconnection_unittest.cc (right):

https://codereview.webrtc.org/1772353002/diff/40001/webrtc/api/peerconnection...
webrtc/api/peerconnection_unittest.cc:1075: // established. There's nothing more
to check.
Is this really true? What about data channels only?

https://codereview.webrtc.org/1772353002/diff/40001/webrtc/api/peerconnection...
webrtc/api/peerconnection_unittest.cc:1091:
EXPECT_NE(webrtc::PeerConnectionInterface::kIceGatheringNew,
Should you leave the todo here unless you know that this is the correct
behaviour?

[hta-webrtc, 2016-03-09 14:31:28]

More commentary. My build machine is upgrading, so it's a bit tricky to expand
the comments in source just now :-(

https://codereview.webrtc.org/1772353002/diff/40001/webrtc/api/peerconnection...
File webrtc/api/peerconnection_unittest.cc (right):

https://codereview.webrtc.org/1772353002/diff/40001/webrtc/api/peerconnection...
webrtc/api/peerconnection_unittest.cc:1075: // established. There's nothing more
to check.
On 2016/03/09 14:17:17, perkj_webrtc wrote:
> Is this really true? What about data channels only?

Datachannels will cause transports to be established, yes. The old logic ignored
that case, so I reproduced that. Need a way to detect the presence of
datachannels.

This whole logic is not valid under Plan A + non-Bundle anyway (we should be
counting media sections of each type, not whether constraints have been set).

https://codereview.webrtc.org/1772353002/diff/40001/webrtc/api/peerconnection...
webrtc/api/peerconnection_unittest.cc:1091:
EXPECT_NE(webrtc::PeerConnectionInterface::kIceGatheringNew,
On 2016/03/09 14:17:17, perkj_webrtc wrote:
> Should you leave the todo here unless you know that this is the correct
> behaviour? 

I know it's not correct behavior according to current spec (and the bug is
already filed a year ago, I think), but the WG seems about to revise its state
machine so that the kIceGatheringComplete state changes meaning, so it doesn't
make sense to fixate upon changing this now.

The check is correct, and will remain correct after spec revision.

[perkj_webrtc, 2016-03-09 14:44:42]

https://codereview.webrtc.org/1772353002/diff/40001/webrtc/api/peerconnection...
File webrtc/api/peerconnection_unittest.cc (right):

https://codereview.webrtc.org/1772353002/diff/40001/webrtc/api/peerconnection...
webrtc/api/peerconnection_unittest.cc:1061: if
(!initiating_client_->can_receive_audio() ||
these can be removed now?

https://codereview.webrtc.org/1772353002/diff/40001/webrtc/api/peerconnection...
webrtc/api/peerconnection_unittest.cc:1065: if
(!initiating_client_->can_receive_video() ||
dito?

https://codereview.webrtc.org/1772353002/diff/40001/webrtc/api/peerconnection...
webrtc/api/peerconnection_unittest.cc:1075: // established. There's nothing more
to check.
On 2016/03/09 14:31:28, hta-webrtc wrote:
> On 2016/03/09 14:17:17, perkj_webrtc wrote:
> > Is this really true? What about data channels only?
> 
> Datachannels will cause transports to be established, yes. The old logic
ignored
> that case, so I reproduced that. Need a way to detect the presence of
> datachannels.
> 
> This whole logic is not valid under Plan A + non-Bundle anyway (we should be
> counting media sections of each type, not whether constraints have been set).
> 

I mean- should the below checks now work even if you just remove all if cases
here and above?

[hta-webrtc, 2016-03-09 16:37:52]

Looks better?

https://codereview.webrtc.org/1772353002/diff/40001/webrtc/api/peerconnection...
File webrtc/api/peerconnection_unittest.cc (right):

https://codereview.webrtc.org/1772353002/diff/40001/webrtc/api/peerconnection...
webrtc/api/peerconnection_unittest.cc:1061: if
(!initiating_client_->can_receive_audio() ||
On 2016/03/09 14:44:41, perkj_webrtc wrote:
> these can be removed now? 

With one more tweak, yes.

https://codereview.webrtc.org/1772353002/diff/40001/webrtc/api/peerconnection...
webrtc/api/peerconnection_unittest.cc:1065: if
(!initiating_client_->can_receive_video() ||
On 2016/03/09 14:44:41, perkj_webrtc wrote:
> dito?

Done.

https://codereview.webrtc.org/1772353002/diff/40001/webrtc/api/peerconnection...
webrtc/api/peerconnection_unittest.cc:1075: // established. There's nothing more
to check.
On 2016/03/09 14:44:41, perkj_webrtc wrote:
> On 2016/03/09 14:31:28, hta-webrtc wrote:
> > On 2016/03/09 14:17:17, perkj_webrtc wrote:
> > > Is this really true? What about data channels only?
> > 
> > Datachannels will cause transports to be established, yes. The old logic
> ignored
> > that case, so I reproduced that. Need a way to detect the presence of
> > datachannels.
> > 
> > This whole logic is not valid under Plan A + non-Bundle anyway (we should be
> > counting media sections of each type, not whether constraints have been
set).
> > 
> 
> I mean- should the below checks now work even if you just remove all if cases
> here and above?

The checks that wait for ICE to complete won't work if ICE doesn't start, and
ICE won't start if there are no transports, and there won't be any transports
when there is no media or datachannel.
So this IF test is necessary. The rest are gone.

I added a TODO about the data channel case.

https://codereview.webrtc.org/1772353002/diff/40001/webrtc/api/peerconnection...
webrtc/api/peerconnection_unittest.cc:1091:
EXPECT_NE(webrtc::PeerConnectionInterface::kIceGatheringNew,
On 2016/03/09 14:31:28, hta-webrtc wrote:
> On 2016/03/09 14:17:17, perkj_webrtc wrote:
> > Should you leave the todo here unless you know that this is the correct
> > behaviour? 
> 
> I know it's not correct behavior according to current spec (and the bug is
> already filed a year ago, I think), but the WG seems about to revise its state
> machine so that the kIceGatheringComplete state changes meaning, so it doesn't
> make sense to fixate upon changing this now.
> 
> The check is correct, and will remain correct after spec revision.

Added a TODO and explanatory text.

[perkj_webrtc, 2016-03-09 16:56:26]

lgtm with the comments below addressed.

https://codereview.webrtc.org/1772353002/diff/60001/webrtc/api/peerconnection...
File webrtc/api/peerconnection_unittest.cc (right):

https://codereview.webrtc.org/1772353002/diff/60001/webrtc/api/peerconnection...
webrtc/api/peerconnection_unittest.cc:938: audio_frames_to_receive);
video_frames_to_receive

https://codereview.webrtc.org/1772353002/diff/60001/webrtc/api/peerconnection...
webrtc/api/peerconnection_unittest.cc:943:
receiving_client_->can_receive_audio()) {
please change to 
if (receiving_client_->local_streams()->count() > 0) && if
(receiving_client_->local_streams()->at(0)->GetAudioTracks().size() > 0)

instead.

https://codereview.webrtc.org/1772353002/diff/60001/webrtc/api/peerconnection...
webrtc/api/peerconnection_unittest.cc:950: audio_frames_to_receive);
video_frames_to_receive

https://codereview.webrtc.org/1772353002/diff/60001/webrtc/api/peerconnection...
webrtc/api/peerconnection_unittest.cc:1061: // TODO(ronghuawu): Add test to
cover the case of sendonly and recvonly.
please remove this todo

[hta-webrtc, 2016-03-09 17:23:30]

This way?

[hta-webrtc, 2016-03-09 17:50:56]

The other way. (after teleconference)

https://codereview.webrtc.org/1772353002/diff/60001/webrtc/api/peerconnection...
File webrtc/api/peerconnection_unittest.cc (right):

https://codereview.webrtc.org/1772353002/diff/60001/webrtc/api/peerconnection...
webrtc/api/peerconnection_unittest.cc:938: audio_frames_to_receive);
On 2016/03/09 16:56:25, perkj_webrtc wrote:
> video_frames_to_receive

Done.

https://codereview.webrtc.org/1772353002/diff/60001/webrtc/api/peerconnection...
webrtc/api/peerconnection_unittest.cc:943:
receiving_client_->can_receive_audio()) {
On 2016/03/09 16:56:25, perkj_webrtc wrote:
> please change to 
> if (receiving_client_->local_streams()->count() > 0) && if
> (receiving_client_->local_streams()->at(0)->GetAudioTracks().size() > 0)
> 
> instead.
Restructured.

https://codereview.webrtc.org/1772353002/diff/60001/webrtc/api/peerconnection...
webrtc/api/peerconnection_unittest.cc:950: audio_frames_to_receive);
On 2016/03/09 16:56:25, perkj_webrtc wrote:
> video_frames_to_receive

Done.

https://codereview.webrtc.org/1772353002/diff/60001/webrtc/api/peerconnection...
webrtc/api/peerconnection_unittest.cc:1061: // TODO(ronghuawu): Add test to
cover the case of sendonly and recvonly.
On 2016/03/09 16:56:25, perkj_webrtc wrote:
> please remove this todo

Don't think it's right to remove. We still have no tests for sendonly/recvonly
in SDP.

[hta-webrtc, 2016-03-09 17:51:31]

The CQ bit was checked by hta@webrtc.org

[hta-webrtc, 2016-03-09 17:51:32]

The patchset sent to the CQ was uploaded after l-g-t-m from phoglund@webrtc.org,
perkj@webrtc.org
Link to the patchset: https://codereview.webrtc.org/1772353002/#ps120001 (title:
"No more remote track check")

[commit-bot: I haz the power, 2016-03-09 17:51:36]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1772353002/120001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1772353002/120001

[commit-bot: I haz the power, 2016-03-09 17:55:46]

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

[commit-bot: I haz the power, 2016-03-09 17:55:47]

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

[hta-webrtc, 2016-03-09 18:03:03]

The CQ bit was checked by hta@webrtc.org

[hta-webrtc, 2016-03-09 18:03:04]

The patchset sent to the CQ was uploaded after l-g-t-m from phoglund@webrtc.org,
perkj@webrtc.org
Link to the patchset: https://codereview.webrtc.org/1772353002/#ps140001 (title:
"Fix Windows compile error")

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

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1772353002/140001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1772353002/140001

[commit-bot: I haz the power, 2016-03-09 18:38:53]

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

[commit-bot: I haz the power, 2016-03-09 18:38:54]

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

[perkj_webrtc, 2016-03-09 18:58:05]

not lgtm

here is a bug unfortunatly.

https://codereview.webrtc.org/1772353002/diff/140001/webrtc/api/peerconnectio...
File webrtc/api/peerconnection_unittest.cc (right):

https://codereview.webrtc.org/1772353002/diff/140001/webrtc/api/peerconnectio...
webrtc/api/peerconnection_unittest.cc:967:
receiving_client_->AudioFramesReceivedCheck(audio_frames_to_receive);
initializing_client->AudioFramesReceivedCheck(audio_frames_to_receive)

https://codereview.webrtc.org/1772353002/diff/140001/webrtc/api/peerconnectio...
webrtc/api/peerconnection_unittest.cc:972:
receiving_client_->VideoFramesReceivedCheck(video_frames_to_receive);
initializing->VideoFramesReceivedCheck(video_frames_to_receive

[perkj_webrtc, 2016-03-09 18:58:45]

On 2016/03/09 18:58:05, perkj_webrtc wrote:
> not lgtm
> 
> here is a bug unfortunatly.
> 
>
https://codereview.webrtc.org/1772353002/diff/140001/webrtc/api/peerconnectio...
> File webrtc/api/peerconnection_unittest.cc (right):
> 
>
https://codereview.webrtc.org/1772353002/diff/140001/webrtc/api/peerconnectio...
> webrtc/api/peerconnection_unittest.cc:967:
> receiving_client_->AudioFramesReceivedCheck(audio_frames_to_receive);
> initializing_client->AudioFramesReceivedCheck(audio_frames_to_receive)
> 
>
https://codereview.webrtc.org/1772353002/diff/140001/webrtc/api/peerconnectio...
> webrtc/api/peerconnection_unittest.cc:972:
> receiving_client_->VideoFramesReceivedCheck(video_frames_to_receive);
> initializing->VideoFramesReceivedCheck(video_frames_to_receive

just tbr when its fixed.

[hta-webrtc, 2016-03-09 19:33:44]

Sigh. The eyes are where one turns blind first.

https://codereview.webrtc.org/1772353002/diff/140001/webrtc/api/peerconnectio...
File webrtc/api/peerconnection_unittest.cc (right):

https://codereview.webrtc.org/1772353002/diff/140001/webrtc/api/peerconnectio...
webrtc/api/peerconnection_unittest.cc:967:
receiving_client_->AudioFramesReceivedCheck(audio_frames_to_receive);
On 2016/03/09 18:58:05, perkj_webrtc wrote:
> initializing_client->AudioFramesReceivedCheck(audio_frames_to_receive)
> 

Done.

https://codereview.webrtc.org/1772353002/diff/140001/webrtc/api/peerconnectio...
webrtc/api/peerconnection_unittest.cc:972:
receiving_client_->VideoFramesReceivedCheck(video_frames_to_receive);
On 2016/03/09 18:58:05, perkj_webrtc wrote:
> initializing->VideoFramesReceivedCheck(video_frames_to_receive

Done.

[hta-webrtc, 2016-03-09 19:34:10]

Description was changed from

==========
Adds a test for an one-way media PeerConnection.

This involves changing a few verification functions for frames
received so that they always accept the result if there's no stream.

BUG=
==========

to

==========
Adds a test for an one-way media PeerConnection.

This involves changing a few verification functions for frames
received so that they always accept the result if there's no stream.

TBR=perkj

BUG=
==========

[hta-webrtc, 2016-03-09 19:34:19]

The CQ bit was checked by hta@webrtc.org

[hta-webrtc, 2016-03-09 19:34:20]

The patchset sent to the CQ was uploaded after l-g-t-m from phoglund@webrtc.org
Link to the patchset: https://codereview.webrtc.org/1772353002/#ps160001 (title:
"Bug fix")

[commit-bot: I haz the power, 2016-03-09 19:34:31]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1772353002/160001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1772353002/160001

[commit-bot: I haz the power, 2016-03-09 19:34:33]

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

[commit-bot: I haz the power, 2016-03-09 19:34:34]

A disapproval has been posted by following reviewers: perkj@webrtc.org.
Please make sure to get positive review before another CQ attempt.

[hta-webrtc, 2016-03-09 19:40:01]

Description was changed from

==========
Adds a test for an one-way media PeerConnection.

This involves changing a few verification functions for frames
received so that they always accept the result if there's no stream.

TBR=perkj

BUG=
==========

to

==========
Adds a test for an one-way media PeerConnection.

This involves changing a few verification functions for frames
received so that they always accept the result if there's no stream.

TBR=perkj@webrtc.org

BUG=
==========

[hta-webrtc, 2016-03-09 19:40:10]

The CQ bit was checked by hta@webrtc.org

[commit-bot: I haz the power, 2016-03-09 19:40:22]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1772353002/160001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1772353002/160001

[commit-bot: I haz the power, 2016-03-09 19:40:24]

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

[commit-bot: I haz the power, 2016-03-09 19:40:25]

A disapproval has been posted by following reviewers: perkj@webrtc.org.
Please make sure to get positive review before another CQ attempt.

[perkj_webrtc, 2016-03-09 19:46:46]

The CQ bit was checked by perkj@webrtc.org

[perkj_webrtc, 2016-03-09 19:46:47]

lgtm

[commit-bot: I haz the power, 2016-03-09 19:46:51]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1772353002/160001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1772353002/160001

[hta-webrtc, 2016-03-09 19:49:04]

Description was changed from

==========
Adds a test for an one-way media PeerConnection.

This involves changing a few verification functions for frames
received so that they always accept the result if there's no stream.

TBR=perkj@webrtc.org

BUG=
==========

to

==========
Adds a test for an one-way media PeerConnection.

This involves changing a few verification functions for frames
received so that they always accept the result if there's no stream.

BUG=
==========

[commit-bot: I haz the power, 2016-03-09 19:53:43]

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

[commit-bot: I haz the power, 2016-03-09 19:53:44]

Try jobs failed on following builders:
  linux_rel on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/linux_rel/builds/13361)
  linux_ubsan_vptr on tryserver.webrtc (JOB_FAILED,
http://build.chromium.org/p/tryserver.webrtc/builders/linux_ubsan_vptr/builds...)

[hta-webrtc, 2016-03-09 19:57:43]

The CQ bit was checked by hta@webrtc.org

[commit-bot: I haz the power, 2016-03-09 19:57:52]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1772353002/160001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1772353002/160001

[commit-bot: I haz the power, 2016-03-09 20:46:01]

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

[commit-bot: I haz the power, 2016-03-09 20:46:02]

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

[hta-webrtc, 2016-03-09 22:05:29]

The CQ bit was checked by hta@webrtc.org

[commit-bot: I haz the power, 2016-03-09 22:05:36]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1772353002/160001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1772353002/160001

[commit-bot: I haz the power, 2016-03-09 22:56:06]

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

[commit-bot: I haz the power, 2016-03-09 22:56:08]

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

[hta-webrtc, 2016-03-10 07:23:46]

The CQ bit was checked by hta@webrtc.org

[commit-bot: I haz the power, 2016-03-10 07:23:53]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1772353002/160001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1772353002/160001

[commit-bot: I haz the power, 2016-03-10 08:24:36]

Description was changed from

==========
Adds a test for an one-way media PeerConnection.

This involves changing a few verification functions for frames
received so that they always accept the result if there's no stream.

BUG=
==========

to

==========
Adds a test for an one-way media PeerConnection.

This involves changing a few verification functions for frames
received so that they always accept the result if there's no stream.

BUG=
==========

[commit-bot: I haz the power, 2016-03-10 08:24:37]

Committed patchset #9 (id:160001)

[commit-bot: I haz the power, 2016-03-10 08:24:44]

Description was changed from

==========
Adds a test for an one-way media PeerConnection.

This involves changing a few verification functions for frames
received so that they always accept the result if there's no stream.

BUG=
==========

to

==========
Adds a test for an one-way media PeerConnection.

This involves changing a few verification functions for frames
received so that they always accept the result if there's no stream.

BUG=

Committed: https://crrev.com/6b4f839c53090683ef2fb4be60d6b0d8f93818af
Cr-Commit-Position: refs/heads/master@{#11937}
==========

[commit-bot: I haz the power, 2016-03-10 08:24:45]

Patchset 9 (id:??) landed as
https://crrev.com/6b4f839c53090683ef2fb4be60d6b0d8f93818af
Cr-Commit-Position: refs/heads/master@{#11937}