Remove ViEChannel calls for VideoReceiveStream.

Remove ViEChannel calls for VideoReceiveStream.

Remove hops into ViEChannel for calls directly into RtpRtcp and
ViEReceiver from VideoReceiveStream.

Some calls are more complex and will be removed later.

BUG=webrtc:5494
R=stefan@webrtc.org

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

[pbos-webrtc, 2016-02-05 13:20:37]

PTAL wooo

[pbos-webrtc, 2016-02-05 13:28:22]

Remove ViEChannel::SetRemoteSSRCType

[pbos-webrtc, 2016-02-05 13:33:18]

remove extra include + forward declare ProcessThread

[pbos-webrtc, 2016-02-05 13:34:49]

Description was changed from

==========
Remove ViEChannel calls for VideoReceiveStream.

Remove hops into ViEChannel for calls directly into RtpRtcp and
ViEReceiver from VideoReceiveStream.

BUG=webrtc:5494
R=stefan@webrtc.org
==========

to

==========
Remove ViEChannel calls for VideoReceiveStream.

Remove hops into ViEChannel for calls directly into RtpRtcp and
ViEReceiver from VideoReceiveStream.

Some calls are more complex and will be removed later.

BUG=webrtc:5494
R=stefan@webrtc.org
==========

[stefan-webrtc, 2016-02-05 14:35:57]

https://codereview.webrtc.org/1671893002/diff/40001/webrtc/video/vie_channel.cc
File webrtc/video/vie_channel.cc (right):

https://codereview.webrtc.org/1671893002/diff/40001/webrtc/video/vie_channel....
webrtc/video/vie_channel.cc:100: vie_receiver_(vcm_, remote_bitrate_estimator,
this),
I wonder if it would make sense to instantiate the receiver in video receive
stream instead, and have it be the owner? VideoReceiveStream outlives ViEChannel
which is nice, so we don't have problems where vie_receiver_ will become null.

https://codereview.webrtc.org/1671893002/diff/40001/webrtc/video/vie_channel....
webrtc/video/vie_channel.cc:420: if
(!vie_receiver_.SetReceiveCodec(video_codec)) {
Should be able to move this out too

https://codereview.webrtc.org/1671893002/diff/40001/webrtc/video/vie_channel....
webrtc/video/vie_channel.cc:655: vie_receiver_.SetRtxPayloadType(payload_type,
associated_payload_type);
Move this out instead?

https://codereview.webrtc.org/1671893002/diff/40001/webrtc/video/vie_channel....
webrtc/video/vie_channel.cc:659:
vie_receiver_.SetUseRtxPayloadMappingOnRestore(val);
Same here

https://codereview.webrtc.org/1671893002/diff/40001/webrtc/video/vie_channel....
webrtc/video/vie_channel.cc:797:
vie_receiver_.GetReceiveStatistics()->RegisterRtpStatisticsCallback(callback);
Maybe move out too?

https://codereview.webrtc.org/1671893002/diff/40001/webrtc/video/vie_channel....
webrtc/video/vie_channel.cc:876: vie_receiver_.StopReceive();
Should we call these from outside?

[pbos-webrtc, 2016-02-05 15:15:44]

stefan@ feedback, move out additional receiver calls

[pbos-webrtc, 2016-02-05 15:15:51]

PTAL

https://codereview.webrtc.org/1671893002/diff/40001/webrtc/video/vie_channel.cc
File webrtc/video/vie_channel.cc (right):

https://codereview.webrtc.org/1671893002/diff/40001/webrtc/video/vie_channel....
webrtc/video/vie_channel.cc:100: vie_receiver_(vcm_, remote_bitrate_estimator,
this),
On 2016/02/05 14:35:57, stefan-webrtc (holmer) wrote:
> I wonder if it would make sense to instantiate the receiver in video receive
> stream instead, and have it be the owner? VideoReceiveStream outlives
ViEChannel
> which is nice, so we don't have problems where vie_receiver_ will become null.

I think that makes sense in a follow-up, right now the vie_receiver_ pointer
doesn't outlive vie_channel_ (declared after), so any use of vie_receiver_ where
vie_channel_ is dead is an use-after-free regardless. In the future I want to
move this out, but as a part of removing ViEChannel.

https://codereview.webrtc.org/1671893002/diff/40001/webrtc/video/vie_channel....
webrtc/video/vie_channel.cc:420: if
(!vie_receiver_.SetReceiveCodec(video_codec)) {
On 2016/02/05 14:35:56, stefan-webrtc (holmer) wrote:
> Should be able to move this out too

Done.

https://codereview.webrtc.org/1671893002/diff/40001/webrtc/video/vie_channel....
webrtc/video/vie_channel.cc:655: vie_receiver_.SetRtxPayloadType(payload_type,
associated_payload_type);
On 2016/02/05 14:35:57, stefan-webrtc (holmer) wrote:
> Move this out instead?

Done.

https://codereview.webrtc.org/1671893002/diff/40001/webrtc/video/vie_channel....
webrtc/video/vie_channel.cc:659:
vie_receiver_.SetUseRtxPayloadMappingOnRestore(val);
On 2016/02/05 14:35:56, stefan-webrtc (holmer) wrote:
> Same here

Done.

https://codereview.webrtc.org/1671893002/diff/40001/webrtc/video/vie_channel....
webrtc/video/vie_channel.cc:797:
vie_receiver_.GetReceiveStatistics()->RegisterRtpStatisticsCallback(callback);
On 2016/02/05 14:35:57, stefan-webrtc (holmer) wrote:
> Maybe move out too?

Done.

https://codereview.webrtc.org/1671893002/diff/40001/webrtc/video/vie_channel....
webrtc/video/vie_channel.cc:876: vie_receiver_.StopReceive();
On 2016/02/05 14:35:56, stefan-webrtc (holmer) wrote:
> Should we call these from outside?

Not until we've moved out the decoder thread (follow-up).

[pbos-webrtc, 2016-02-05 15:40:56]

remove number_of_cores_

[stefan-webrtc, 2016-02-08 12:59:23]

lg

https://codereview.webrtc.org/1671893002/diff/80001/webrtc/video/video_receiv...
File webrtc/video/video_receive_stream.cc (right):

https://codereview.webrtc.org/1671893002/diff/80001/webrtc/video/video_receiv...
webrtc/video/video_receive_stream.cc:266:
rtp_rtcp_->RegisterRtcpStatisticsCallback(&stats_proxy_);
Is this part of the sender and therefore shouldn't be included in the receive
stream?

[pbos-webrtc, 2016-02-08 13:05:27]

ptal

https://codereview.webrtc.org/1671893002/diff/80001/webrtc/video/video_receiv...
File webrtc/video/video_receive_stream.cc (right):

https://codereview.webrtc.org/1671893002/diff/80001/webrtc/video/video_receiv...
webrtc/video/video_receive_stream.cc:266:
rtp_rtcp_->RegisterRtcpStatisticsCallback(&stats_proxy_);
On 2016/02/08 12:59:23, stefan-webrtc (holmer) wrote:
> Is this part of the sender and therefore shouldn't be included in the receive
> stream?

Added comment, needed.

[pbos-webrtc, 2016-02-08 13:05:39]

comment

[stefan-webrtc, 2016-02-08 13:06:49]

lgtm

[pbos-webrtc, 2016-02-08 13:07:27]

Description was changed from

==========
Remove ViEChannel calls for VideoReceiveStream.

Remove hops into ViEChannel for calls directly into RtpRtcp and
ViEReceiver from VideoReceiveStream.

Some calls are more complex and will be removed later.

BUG=webrtc:5494
R=stefan@webrtc.org
==========

to

==========
Remove ViEChannel calls for VideoReceiveStream.

Remove hops into ViEChannel for calls directly into RtpRtcp and
ViEReceiver from VideoReceiveStream.

Some calls are more complex and will be removed later.

BUG=webrtc:5494
R=stefan@webrtc.org

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

[pbos-webrtc, 2016-02-08 13:07:28]

Committed patchset #6 (id:100001) manually as
d1d66bab3d257e989f17d05824456767010be356 (presubmit successful).

[commit-bot: I haz the power, 2016-02-08 13:07:29]

Description was changed from

==========
Remove ViEChannel calls for VideoReceiveStream.

Remove hops into ViEChannel for calls directly into RtpRtcp and
ViEReceiver from VideoReceiveStream.

Some calls are more complex and will be removed later.

BUG=webrtc:5494
R=stefan@webrtc.org

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

to

==========
Remove ViEChannel calls for VideoReceiveStream.

Remove hops into ViEChannel for calls directly into RtpRtcp and
ViEReceiver from VideoReceiveStream.

Some calls are more complex and will be removed later.

BUG=webrtc:5494
R=stefan@webrtc.org

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

[commit-bot: I haz the power, 2016-02-08 13:07:30]

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