Remove channel ids from various interfaces.

Remove channel ids from various interfaces.

Starts by removing channel/engine id from ViEChannel which propagates
down to the RTP/RTCP module as well as the transport class.

IncomingVideoStream::RenderFrame() is untouched for now but receives a
fake id instead of the previous channel id. Added a TODO to remove it
later but the RenderFrame call is implemented in a lot of
platform-dependent files and should probably remove the "manager" aspect
of renderers, so preferring to do it separately

BUG=webrtc:1695
R=henrika@webrtc.org, mflodman@webrtc.org

Committed: https://chromium.googlesource.com/external/webrtc/+/ac547a653862744d0aae560713f8418ad2852085

[pbos-webrtc, 2015-09-15 15:10:30]

LoopBackTransport SSRC demuxing.

[pbos-webrtc, 2015-09-15 15:12:06]

pbos@webrtc.org changed reviewers:
+ henrika@webrtc.org

[pbos-webrtc, 2015-09-15 15:12:06]

PTAL:

henrika@ for voice_engine things.
stefan@ for rtp_rtcp, video, video_engine, test and talk/.
mflodman@ for root approval things.

[pbos-webrtc, 2015-09-15 15:14:55]

On 2015/09/15 15:12:06, pbos-webrtc wrote:
> PTAL:
> 
> henrika@ for voice_engine things.
> stefan@ for rtp_rtcp, video, video_engine, test and talk/.
> mflodman@ for root approval things.

The only place where these IDs were really used were
webrtc/voice_engine/test/auto_test/fixtures/after_initialization_fixture.h,
which contains a loopback test class. libjingle and any internet-style
application still has to demux based on SSRCs, so passing around these IDs isn't
super useful.

[henrika_webrtc, 2015-09-16 11:34:50]

LGTM

FYI; it is not obvious how this issue is linked to the attached bug (~2 years
old).
Please create more isolated issues if/when possible. Thanks.

[pbos-webrtc, 2015-09-16 11:37:14]

On 2015/09/16 11:34:50, henrika_webrtc wrote:
> LGTM
> 
> FYI; it is not obvious how this issue is linked to the attached bug (~2 years
> old).
> Please create more isolated issues if/when possible. Thanks.

Thanks. Yeah, I'm attaching general cleanup that's made available through
refactoring there just to BUG= them against something so I can keep track of
cleanup efforts. :)

[mflodman, 2015-09-17 05:36:54]

It would be good with an updated description, saying what you are modifying,
what is left and/or what the next step is. This CL is very big and seems quite
random for which IDs are removed at this time and what you're leaving.

I would also prefer to delete the two classes in another CL instead of throwing
that into a refactoring CL like this, especially when touching this many files.
A potential revert of this CL can get hard.

https://codereview.webrtc.org/1335353005/diff/20001/webrtc/video_engine/vie_c...
File webrtc/video_engine/vie_channel.cc (right):

https://codereview.webrtc.org/1335353005/diff/20001/webrtc/video_engine/vie_c...
webrtc/video_engine/vie_channel.cc:1025: incoming_video_stream_->RenderFrame(0,
video_frame);
Why did you leave this one? Given the CL description it's hard to know what the
real intention is.

And maybe 0xffffffff is better to show it's not a valid id?

[mflodman, 2015-09-17 05:37:48]

On 2015/09/17 05:36:54, mflodman wrote:
> It would be good with an updated description, saying what you are modifying,
> what is left and/or what the next step is. This CL is very big and seems quite
> random for which IDs are removed at this time and what you're leaving.
> 
> I would also prefer to delete the two classes in another CL instead of
throwing
> that into a refactoring CL like this, especially when touching this many
files.
> A potential revert of this CL can get hard.
> 
>
https://codereview.webrtc.org/1335353005/diff/20001/webrtc/video_engine/vie_c...
> File webrtc/video_engine/vie_channel.cc (right):
> 
>
https://codereview.webrtc.org/1335353005/diff/20001/webrtc/video_engine/vie_c...
> webrtc/video_engine/vie_channel.cc:1025:
incoming_video_stream_->RenderFrame(0,
> video_frame);
> Why did you leave this one? Given the CL description it's hard to know what
the
> real intention is.
> 
> And maybe 0xffffffff is better to show it's not a valid id?

And I did not look at the voice_engine folder, since Henrik did that.

[pbos-webrtc, 2015-09-17 06:18:07]

0xFF.. id and adding back deleted files

[pbos-webrtc, 2015-09-17 06:26:01]

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

[pbos-webrtc, 2015-09-17 06:26:02]

PTAL, split off file removal into https://codereview.webrtc.org/1343393003/

Removing stefan@ as reviewer since you're covering this mflodman@. :)

[pbos-webrtc, 2015-09-17 06:27:24]

video_frame typo

[mflodman, 2015-09-17 07:18:00]

LGTM, when it builds again :)

https://codereview.webrtc.org/1335353005/diff/40001/webrtc/video_engine/vie_c...
File webrtc/video_engine/vie_channel.cc (right):

https://codereview.webrtc.org/1335353005/diff/40001/webrtc/video_engine/vie_c...
webrtc/video_engine/vie_channel.cc:1025:
incoming_video_stream_->RenderFrame(0xFFFFFFFF, video_Frame);
This won't build.

[mflodman, 2015-09-17 07:18:35]

On 2015/09/17 07:18:00, mflodman wrote:
> LGTM, when it builds again :)
> 
>
https://codereview.webrtc.org/1335353005/diff/40001/webrtc/video_engine/vie_c...
> File webrtc/video_engine/vie_channel.cc (right):
> 
>
https://codereview.webrtc.org/1335353005/diff/40001/webrtc/video_engine/vie_c...
> webrtc/video_engine/vie_channel.cc:1025:
> incoming_video_stream_->RenderFrame(0xFFFFFFFF, video_Frame);
> This won't build.

Ah, saw now it was fixed after I loaded the code review site.

[pbos-webrtc, 2015-09-17 11:55:28]

rebase

[pbos-webrtc, 2015-09-17 11:56:09]

The CQ bit was checked by pbos@webrtc.org

[pbos-webrtc, 2015-09-17 11:56:09]

The patchset sent to the CQ was uploaded after l-g-t-m from henrika@webrtc.org,
mflodman@webrtc.org
Link to the patchset: https://codereview.webrtc.org/1335353005/#ps80001 (title:
"rebase")

[commit-bot: I haz the power, 2015-09-17 11:56:23]

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

[commit-bot: I haz the power, 2015-09-17 13:56:44]

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

[commit-bot: I haz the power, 2015-09-17 13:56:45]

Try jobs failed on following builders:
  android on tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  android_arm64_rel on tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  android_rel on tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  win_drmemory_light on tryserver.webrtc (JOB_TIMED_OUT, no build URL)

[pbos-webrtc, 2015-09-17 21:06:11]

Committed patchset #5 (id:80001) manually as
ac547a653862744d0aae560713f8418ad2852085 (presubmit successful).

[commit-bot: I haz the power, 2015-09-17 21:06:12]

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