Use VoiceChannel/VideoChannel directly from RtpSender/RtpReceiver.

Reland 2 of: Use VoiceChannel/VideoChannel directly from RtpSender/RtpReceiver.

Relanding again after fixing issue with RTC_DCHECKs.

This CL eliminates the need for the extra layer of indirection provided by
mediastreamprovider.h. It will thus make it easier to implement new
functionality in RtpSender/RtpReceiver.

It also brings us one step closer to the end goal of combining "senders"
and "send streams". Currently the sender still needs to go through the
BaseChannel and MediaChannel, using an SSRC as a key.

R=pthatcher@webrtc.org

Committed: https://crrev.com/ba29c6aac7fd351eb76db2444ccacfb5355ff037
Cr-Commit-Position: refs/heads/master@{#13305}

[Taylor Brandstetter, 2016-06-07 22:44:43]

https://codereview.webrtc.org/2046173002/diff/1/webrtc/api/peerconnection.cc
File webrtc/api/peerconnection.cc (right):

https://codereview.webrtc.org/2046173002/diff/1/webrtc/api/peerconnection.cc#...
webrtc/api/peerconnection.cc:420: receiver->internal()->Stop();
This replaces the need for "StopReceivers".

https://codereview.webrtc.org/2046173002/diff/1/webrtc/api/rtpreceiver.cc
File webrtc/api/rtpreceiver.cc (right):

https://codereview.webrtc.org/2046173002/diff/1/webrtc/api/rtpreceiver.cc#new...
webrtc/api/rtpreceiver.cc:103: channel_->SetOutputVolume(ssrc_,
track_->enabled() ? cached_volume_ : 0));
Previously, SetAudioPlayout would always set the volume to 1. That means if you
set the track's volume to 0.5, then disable and enable it, you would get a
volume of 1. That seems like a bug.

https://codereview.webrtc.org/2046173002/diff/1/webrtc/api/rtpsenderreceiver_...
File webrtc/api/rtpsenderreceiver_unittest.cc (right):

https://codereview.webrtc.org/2046173002/diff/1/webrtc/api/rtpsenderreceiver_...
webrtc/api/rtpsenderreceiver_unittest.cc:539: TEST_F(RtpSenderReceiverTest,
SetAudioMaxSendBitrate) {
Moved from WebRtcSession tests.

[Taylor Brandstetter, 2016-06-08 18:33:43]

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

[pthatcher1, 2016-06-21 07:45:41]

https://codereview.webrtc.org/2046173002/diff/20001/webrtc/api/remoteaudiosou...
File webrtc/api/remoteaudiosource.cc (right):

https://codereview.webrtc.org/2046173002/diff/20001/webrtc/api/remoteaudiosou...
webrtc/api/remoteaudiosource.cc:84: ssrc,
std::unique_ptr<AudioSinkInterface>(new Sink(this)));
SetRawAudioSink could be part of RtpReceiverInternal instead.  And the fewer
things would need to know about channels.

https://codereview.webrtc.org/2046173002/diff/20001/webrtc/api/remoteaudiosou...
File webrtc/api/remoteaudiosource.h (right):

https://codereview.webrtc.org/2046173002/diff/20001/webrtc/api/remoteaudiosou...
webrtc/api/remoteaudiosource.h:30: class RemoteAudioSource : public
Notifier<AudioSourceInterface> {
It sounds like this should be in pc/, not api/.

https://codereview.webrtc.org/2046173002/diff/20001/webrtc/api/remoteaudiosou...
webrtc/api/remoteaudiosource.h:35: cricket::VoiceChannel* channel);
Could this take an RtpReceiver instead?

https://codereview.webrtc.org/2046173002/diff/20001/webrtc/api/rtpreceiver.cc
File webrtc/api/rtpreceiver.cc (right):

https://codereview.webrtc.org/2046173002/diff/20001/webrtc/api/rtpreceiver.cc...
webrtc/api/rtpreceiver.cc:93: stopped_ = true;
Would it make sense to make channel_ = nullptr?

[Taylor Brandstetter, 2016-06-22 00:50:18]

https://codereview.webrtc.org/2046173002/diff/20001/webrtc/api/remoteaudiosou...
File webrtc/api/remoteaudiosource.cc (right):

https://codereview.webrtc.org/2046173002/diff/20001/webrtc/api/remoteaudiosou...
webrtc/api/remoteaudiosource.cc:84: ssrc,
std::unique_ptr<AudioSinkInterface>(new Sink(this)));
On 2016/06/21 07:45:41, pthatcher1 wrote:
> SetRawAudioSink could be part of RtpReceiverInternal instead.  And the fewer
> things would need to know about channels.

That sounds like a good idea but I think it can happen in a separate CL.

https://codereview.webrtc.org/2046173002/diff/20001/webrtc/api/remoteaudiosou...
File webrtc/api/remoteaudiosource.h (right):

https://codereview.webrtc.org/2046173002/diff/20001/webrtc/api/remoteaudiosou...
webrtc/api/remoteaudiosource.h:30: class RemoteAudioSource : public
Notifier<AudioSourceInterface> {
On 2016/06/21 07:45:41, pthatcher1 wrote:
> It sounds like this should be in pc/, not api/.

Yep. Same with most things currently in /api/.

https://codereview.webrtc.org/2046173002/diff/20001/webrtc/api/remoteaudiosou...
webrtc/api/remoteaudiosource.h:35: cricket::VoiceChannel* channel);
On 2016/06/21 07:45:41, pthatcher1 wrote:
> Could this take an RtpReceiver instead?

I agree some refactoring is in order here, but I don't know if that's the best
solution. We would then have a circular dependency between RemoteAudioSource and
AudioRtpSender. I think it would be preferable if RemoteAudioSource just had a
method that returned a Sink object and RtpReceiverInternal could hook up the
wires.

But again, this is orthogonal to this CL.

https://codereview.webrtc.org/2046173002/diff/20001/webrtc/api/rtpreceiver.cc
File webrtc/api/rtpreceiver.cc (right):

https://codereview.webrtc.org/2046173002/diff/20001/webrtc/api/rtpreceiver.cc...
webrtc/api/rtpreceiver.cc:93: stopped_ = true;
On 2016/06/21 07:45:41, pthatcher1 wrote:
> Would it make sense to make channel_ = nullptr?

I don't see why. As long as the channel is available, it doesn't hurt to have a
pointer to it. Previously, "provider_ == nullptr" was used as a substitute for
"stopped_", but that's not very clear to someone reading the code so I changed
it.

[pthatcher1, 2016-06-22 05:12:58]

lgtm

[Taylor Brandstetter, 2016-06-24 19:15:38]

The CQ bit was checked by deadbeef@webrtc.org

[Taylor Brandstetter, 2016-06-24 19:15:38]

The patchset sent to the CQ was uploaded after l-g-t-m from pthatcher@webrtc.org
Link to the patchset: https://codereview.webrtc.org/2046173002/#ps40001 (title:
"Merging with master. Mainly resolving conflicts with "first packet received"
CL.")

[commit-bot: I haz the power, 2016-06-24 19:15:49]

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, 2016-06-24 19:22:44]

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

[commit-bot: I haz the power, 2016-06-24 19:22:45]

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

[Taylor Brandstetter, 2016-06-24 20:12:34]

The CQ bit was checked by deadbeef@webrtc.org

[commit-bot: I haz the power, 2016-06-24 20:12:38]

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, 2016-06-24 20:22:47]

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

[commit-bot: I haz the power, 2016-06-24 20:22:49]

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

[commit-bot: I haz the power, 2016-06-24 21:06:46]

Description was changed from

==========
Use VoiceChannel/VideoChannel directly from RtpSender/RtpReceiver.

This eliminates the need for the extra layer of indirection provided by
mediastreamprovider.h. It will thus make it easier to implement new
functionality in RtpSender/RtpReceiver.

It also brings us one step closer to the end goal of combining "senders"
and "send streams". Currently the sender still needs to go through the
BaseChannel and MediaChannel, using an SSRC as a key.
==========

to

==========
Use VoiceChannel/VideoChannel directly from RtpSender/RtpReceiver.

This eliminates the need for the extra layer of indirection provided by
mediastreamprovider.h. It will thus make it easier to implement new
functionality in RtpSender/RtpReceiver.

It also brings us one step closer to the end goal of combining "senders"
and "send streams". Currently the sender still needs to go through the
BaseChannel and MediaChannel, using an SSRC as a key.

R=pthatcher@webrtc.org

Committed: https://crrev.com/bc5831999d3354509d75357b659b4bb8e39f8a6c
Cr-Commit-Position: refs/heads/master@{#13285}
==========

[Taylor Brandstetter, 2016-06-24 21:06:47]

Description was changed from

==========
Use VoiceChannel/VideoChannel directly from RtpSender/RtpReceiver.

This eliminates the need for the extra layer of indirection provided by
mediastreamprovider.h. It will thus make it easier to implement new
functionality in RtpSender/RtpReceiver.

It also brings us one step closer to the end goal of combining "senders"
and "send streams". Currently the sender still needs to go through the
BaseChannel and MediaChannel, using an SSRC as a key.

R=pthatcher@webrtc.org

Committed: https://crrev.com/bc5831999d3354509d75357b659b4bb8e39f8a6c
Cr-Commit-Position: refs/heads/master@{#13285}
==========

to

==========
Use VoiceChannel/VideoChannel directly from RtpSender/RtpReceiver.

This eliminates the need for the extra layer of indirection provided by
mediastreamprovider.h. It will thus make it easier to implement new
functionality in RtpSender/RtpReceiver.

It also brings us one step closer to the end goal of combining "senders"
and "send streams". Currently the sender still needs to go through the
BaseChannel and MediaChannel, using an SSRC as a key.

R=pthatcher@webrtc.org

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

[commit-bot: I haz the power, 2016-06-24 21:06:47]

Patchset 3 (id:??) landed as
https://crrev.com/bc5831999d3354509d75357b659b4bb8e39f8a6c
Cr-Commit-Position: refs/heads/master@{#13285}

[Taylor Brandstetter, 2016-06-24 21:06:48]

Committed patchset #3 (id:40001) manually as
bc5831999d3354509d75357b659b4bb8e39f8a6c (presubmit successful).

[Taylor Brandstetter, 2016-06-24 21:12:46]

A revert of this CL (patchset #3 id:40001) has been created in
https://codereview.webrtc.org/2099843003/ by deadbeef@webrtc.org.

The reason for reverting is: Broke peerconnection_unittest somehow, due to
introduction of thread check. Will fix and reland..

[Taylor Brandstetter, 2016-06-24 21:13:06]

Description was changed from

==========
Use VoiceChannel/VideoChannel directly from RtpSender/RtpReceiver.

This eliminates the need for the extra layer of indirection provided by
mediastreamprovider.h. It will thus make it easier to implement new
functionality in RtpSender/RtpReceiver.

It also brings us one step closer to the end goal of combining "senders"
and "send streams". Currently the sender still needs to go through the
BaseChannel and MediaChannel, using an SSRC as a key.

R=pthatcher@webrtc.org

Committed: https://crrev.com/bc5831999d3354509d75357b659b4bb8e39f8a6c
Cr-Commit-Position: refs/heads/master@{#13285}
==========

to

==========
Reland of: Use VoiceChannel/VideoChannel directly from RtpSender/RtpReceiver.

This eliminates the need for the extra layer of indirection provided by
mediastreamprovider.h. It will thus make it easier to implement new
functionality in RtpSender/RtpReceiver.

It also brings us one step closer to the end goal of combining "senders"
and "send streams". Currently the sender still needs to go through the
BaseChannel and MediaChannel, using an SSRC as a key.

R=pthatcher@webrtc.org

Committed: https://crrev.com/bc5831999d3354509d75357b659b4bb8e39f8a6c
Cr-Commit-Position: refs/heads/master@{#13285}
==========

[Taylor Brandstetter, 2016-06-24 21:16:16]

Description was changed from

==========
Reland of: Use VoiceChannel/VideoChannel directly from RtpSender/RtpReceiver.

This eliminates the need for the extra layer of indirection provided by
mediastreamprovider.h. It will thus make it easier to implement new
functionality in RtpSender/RtpReceiver.

It also brings us one step closer to the end goal of combining "senders"
and "send streams". Currently the sender still needs to go through the
BaseChannel and MediaChannel, using an SSRC as a key.

R=pthatcher@webrtc.org

Committed: https://crrev.com/bc5831999d3354509d75357b659b4bb8e39f8a6c
Cr-Commit-Position: refs/heads/master@{#13285}
==========

to

==========
Reland of: Use VoiceChannel/VideoChannel directly from RtpSender/RtpReceiver.

This eliminates the need for the extra layer of indirection provided by
mediastreamprovider.h. It will thus make it easier to implement new
functionality in RtpSender/RtpReceiver.

It also brings us one step closer to the end goal of combining "senders"
and "send streams". Currently the sender still needs to go through the
BaseChannel and MediaChannel, using an SSRC as a key.

R=pthatcher@webrtc.org
==========

[Taylor Brandstetter, 2016-06-24 21:16:45]

It turns out this wasn't the CL that broke the bot. Relanding.

[commit-bot: I haz the power, 2016-06-24 21:18:35]

Description was changed from

==========
Reland of: Use VoiceChannel/VideoChannel directly from RtpSender/RtpReceiver.

This eliminates the need for the extra layer of indirection provided by
mediastreamprovider.h. It will thus make it easier to implement new
functionality in RtpSender/RtpReceiver.

It also brings us one step closer to the end goal of combining "senders"
and "send streams". Currently the sender still needs to go through the
BaseChannel and MediaChannel, using an SSRC as a key.

R=pthatcher@webrtc.org
==========

to

==========
Reland of: Use VoiceChannel/VideoChannel directly from RtpSender/RtpReceiver.

This eliminates the need for the extra layer of indirection provided by
mediastreamprovider.h. It will thus make it easier to implement new
functionality in RtpSender/RtpReceiver.

It also brings us one step closer to the end goal of combining "senders"
and "send streams". Currently the sender still needs to go through the
BaseChannel and MediaChannel, using an SSRC as a key.

R=pthatcher@webrtc.org

Committed: https://crrev.com/2d5491783a264c6e57614f87f1a69dc61bf44609
Cr-Commit-Position: refs/heads/master@{#13287}
==========

[Taylor Brandstetter, 2016-06-24 21:18:35]

Description was changed from

==========
Reland of: Use VoiceChannel/VideoChannel directly from RtpSender/RtpReceiver.

This eliminates the need for the extra layer of indirection provided by
mediastreamprovider.h. It will thus make it easier to implement new
functionality in RtpSender/RtpReceiver.

It also brings us one step closer to the end goal of combining "senders"
and "send streams". Currently the sender still needs to go through the
BaseChannel and MediaChannel, using an SSRC as a key.

R=pthatcher@webrtc.org

Committed: https://crrev.com/2d5491783a264c6e57614f87f1a69dc61bf44609
Cr-Commit-Position: refs/heads/master@{#13287}
==========

to

==========
Reland of: Use VoiceChannel/VideoChannel directly from RtpSender/RtpReceiver.

This eliminates the need for the extra layer of indirection provided by
mediastreamprovider.h. It will thus make it easier to implement new
functionality in RtpSender/RtpReceiver.

It also brings us one step closer to the end goal of combining "senders"
and "send streams". Currently the sender still needs to go through the
BaseChannel and MediaChannel, using an SSRC as a key.

R=pthatcher@webrtc.org

Committed:
https://chromium.googlesource.com/external/webrtc/+/2d5491783a264c6e57614f87f...
==========

[commit-bot: I haz the power, 2016-06-24 21:18:36]

Patchset 3 (id:??) landed as
https://crrev.com/2d5491783a264c6e57614f87f1a69dc61bf44609
Cr-Commit-Position: refs/heads/master@{#13287}

[Taylor Brandstetter, 2016-06-24 21:18:37]

Committed patchset #3 (id:40001) manually as
2d5491783a264c6e57614f87f1a69dc61bf44609 (presubmit successful).

[tkchin_webrtc, 2016-06-25 02:05:04]

tkchin@webrtc.org changed reviewers:
+ tkchin@webrtc.org

[tkchin_webrtc, 2016-06-25 02:05:05]

This broke AppRTCDemo - no more video. Is that an AppRTCDemo bug related to
RtpSender/Receiver, or a bug introduced in this CL?

[tkchin_webrtc, 2016-06-25 02:31:17]

A revert of this CL (patchset #3 id:40001) has been created in
https://codereview.webrtc.org/2092273003/ by tkchin@webrtc.org.

The reason for reverting is: Broke video sending for iOS AppRTCDemo. To repro,
run iOS AppRTCDemo in Release in loopback mode. The revision prior to this
change worked..

[Taylor Brandstetter, 2016-06-27 20:15:25]

Description was changed from

==========
Reland of: Use VoiceChannel/VideoChannel directly from RtpSender/RtpReceiver.

This eliminates the need for the extra layer of indirection provided by
mediastreamprovider.h. It will thus make it easier to implement new
functionality in RtpSender/RtpReceiver.

It also brings us one step closer to the end goal of combining "senders"
and "send streams". Currently the sender still needs to go through the
BaseChannel and MediaChannel, using an SSRC as a key.

R=pthatcher@webrtc.org

Committed:
https://chromium.googlesource.com/external/webrtc/+/2d5491783a264c6e57614f87f...
==========

to

==========
Reland of: Use VoiceChannel/VideoChannel directly from RtpSender/RtpReceiver.

This eliminates the need for the extra layer of indirection provided by
mediastreamprovider.h. It will thus make it easier to implement new
functionality in RtpSender/RtpReceiver.

It also brings us one step closer to the end goal of combining "senders"
and "send streams". Currently the sender still needs to go through the
BaseChannel and MediaChannel, using an SSRC as a key.

R=pthatcher@webrtc.org

Committed:
https://chromium.googlesource.com/external/webrtc/+/2d5491783a264c6e57614f87f...
==========

[Taylor Brandstetter, 2016-06-27 21:07:02]

On 2016/06/25 02:31:17, tkchin_webrtc wrote:
> A revert of this CL (patchset #3 id:40001) has been created in
> https://codereview.webrtc.org/2092273003/ by mailto:tkchin@webrtc.org.
> 
> The reason for reverting is: Broke video sending for iOS AppRTCDemo. To repro,
> run iOS AppRTCDemo in Release in loopback mode. The revision prior to this
> change worked..

Thanks for reverting, Zeke. It was a silly mistake; I was RTC_DCHECKING the
result of some functions, but in a way that meant the functions weren't executed
if asserts are disabled. I guess all of the trybots must enable asserts which is
why this wasn't caught earlier.

[Taylor Brandstetter, 2016-06-27 21:07:13]

The CQ bit was checked by deadbeef@webrtc.org

[Taylor Brandstetter, 2016-06-27 21:07:13]

The patchset sent to the CQ was uploaded after l-g-t-m from pthatcher@webrtc.org
Link to the patchset: https://codereview.webrtc.org/2046173002/#ps60001 (title:
"Moving code that needs to execute out of RTC_DCHECKs.")

[commit-bot: I haz the power, 2016-06-27 21:07:19]

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, 2016-06-27 21:14:50]

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

[commit-bot: I haz the power, 2016-06-27 21:14:51]

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

[Taylor Brandstetter, 2016-06-27 23:30:16]

Description was changed from

==========
Reland of: Use VoiceChannel/VideoChannel directly from RtpSender/RtpReceiver.

This eliminates the need for the extra layer of indirection provided by
mediastreamprovider.h. It will thus make it easier to implement new
functionality in RtpSender/RtpReceiver.

It also brings us one step closer to the end goal of combining "senders"
and "send streams". Currently the sender still needs to go through the
BaseChannel and MediaChannel, using an SSRC as a key.

R=pthatcher@webrtc.org

Committed:
https://chromium.googlesource.com/external/webrtc/+/2d5491783a264c6e57614f87f...
==========

to

==========
Reland 2 of: Use VoiceChannel/VideoChannel directly from RtpSender/RtpReceiver.

Relanding again after fixing issue with RTC_DCHECKs.

This CL eliminates the need for the extra layer of indirection provided by
mediastreamprovider.h. It will thus make it easier to implement new
functionality in RtpSender/RtpReceiver.

It also brings us one step closer to the end goal of combining "senders"
and "send streams". Currently the sender still needs to go through the
BaseChannel and MediaChannel, using an SSRC as a key.
==========

[Taylor Brandstetter, 2016-06-27 23:30:51]

Description was changed from

==========
Reland 2 of: Use VoiceChannel/VideoChannel directly from RtpSender/RtpReceiver.

Relanding again after fixing issue with RTC_DCHECKs.

This CL eliminates the need for the extra layer of indirection provided by
mediastreamprovider.h. It will thus make it easier to implement new
functionality in RtpSender/RtpReceiver.

It also brings us one step closer to the end goal of combining "senders"
and "send streams". Currently the sender still needs to go through the
BaseChannel and MediaChannel, using an SSRC as a key.
==========

to

==========
Reland 2 of: Use VoiceChannel/VideoChannel directly from RtpSender/RtpReceiver.

Relanding again after fixing issue with RTC_DCHECKs.

This CL eliminates the need for the extra layer of indirection provided by
mediastreamprovider.h. It will thus make it easier to implement new
functionality in RtpSender/RtpReceiver.

It also brings us one step closer to the end goal of combining "senders"
and "send streams". Currently the sender still needs to go through the
BaseChannel and MediaChannel, using an SSRC as a key.

R=pthatcher@webrtc.org

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

[commit-bot: I haz the power, 2016-06-27 23:30:52]

Description was changed from

==========
Reland 2 of: Use VoiceChannel/VideoChannel directly from RtpSender/RtpReceiver.

Relanding again after fixing issue with RTC_DCHECKs.

This CL eliminates the need for the extra layer of indirection provided by
mediastreamprovider.h. It will thus make it easier to implement new
functionality in RtpSender/RtpReceiver.

It also brings us one step closer to the end goal of combining "senders"
and "send streams". Currently the sender still needs to go through the
BaseChannel and MediaChannel, using an SSRC as a key.
==========

to

==========
Reland 2 of: Use VoiceChannel/VideoChannel directly from RtpSender/RtpReceiver.

Relanding again after fixing issue with RTC_DCHECKs.

This CL eliminates the need for the extra layer of indirection provided by
mediastreamprovider.h. It will thus make it easier to implement new
functionality in RtpSender/RtpReceiver.

It also brings us one step closer to the end goal of combining "senders"
and "send streams". Currently the sender still needs to go through the
BaseChannel and MediaChannel, using an SSRC as a key.

R=pthatcher@webrtc.org

Committed: https://crrev.com/ba29c6aac7fd351eb76db2444ccacfb5355ff037
Cr-Commit-Position: refs/heads/master@{#13305}
==========

[Taylor Brandstetter, 2016-06-27 23:30:52]

Committed patchset #4 (id:60001) manually as
ba29c6aac7fd351eb76db2444ccacfb5355ff037 (presubmit successful).

[commit-bot: I haz the power, 2016-06-27 23:30:53]

Patchset 4 (id:??) landed as
https://crrev.com/ba29c6aac7fd351eb76db2444ccacfb5355ff037
Cr-Commit-Position: refs/heads/master@{#13305}