Split webrtc/video into webrtc/{audio,call,video}.

Split webrtc/video into webrtc/{audio,call,video}.

Moves audio_receive_stream.{h,cc} into webrtc/audio, and common parts
into webrtc/call, splitting out audio/shared components with separate
OWNERS files.

BUG=webrtc:4690
R=solenberg@webrtc.org, tina.legrand@webrtc.org
TBR=mflodman@webrtc.org

Committed: https://crrev.com/5c389d3e09646c0e2ed76d5ccb37a3419a09eb6a
Cr-Commit-Position: refs/heads/master@{#10073}

[pbos-webrtc, 2015-07-13 12:24:17]

PTAL, not expecting to submit any of this before you guys get back from
vacation. So no rush, just thought it'd make sense to get a directory up so you
can have OWNERS. :)

[the sun, 2015-07-15 07:46:59]

On 2015/07/13 12:24:17, pbos-webrtc wrote:
> PTAL, not expecting to submit any of this before you guys get back from
> vacation. So no rush, just thought it'd make sense to get a directory up so
you
> can have OWNERS. :)

Thanks for doing this Peter, having ownership will certainly be useful!

It isn't super logical to me that call.cc lives under webrtc/video/. I'd expect
there to be more things, such as tests and utils, that can be shared. How about
a structure like this:

webrtc/call/ [common stuff, call.cc, possible stream impl base classes, tests,
utils]
webrtc/call/audio/
webrtc/call/video/

WDYT?

[pbos-webrtc, 2015-07-15 08:00:51]

On 2015/07/15 07:46:59, the sun wrote:
> On 2015/07/13 12:24:17, pbos-webrtc wrote:
> > PTAL, not expecting to submit any of this before you guys get back from
> > vacation. So no rush, just thought it'd make sense to get a directory up so
> you
> > can have OWNERS. :)
> 
> Thanks for doing this Peter, having ownership will certainly be useful!
> 
> It isn't super logical to me that call.cc lives under webrtc/video/. I'd
expect
> there to be more things, such as tests and utils, that can be shared. How
about
> a structure like this:
> 
> webrtc/call/ [common stuff, call.cc, possible stream impl base classes, tests,
> utils]
> webrtc/call/audio/
> webrtc/call/video/
> 
> WDYT?

We're talking about not calling call call anymore because it might be split up
for ORTC in the future (I'd like to not commit to having "call" as a central
piece in future structure). I like video/ and audio/ being generic subcategory
names and not "API project names", there will be both audio and video in the
future no matter what we call the APIs to them. Also I like flatter hierarchies.

I'd like to find a more generic name for a place where things for both lives. It
might also not matter too much if the common stuff is a very slim part of the
whole thing? I think shared tests/utils can go under webrtc/test/. So that just
leaves where to put call-common things. I'm voting for keeping them under video/
until we find a better name for "common stuff", or forever, if there's not too
much common stuff.

Does that make sense?

[the sun, 2015-07-15 09:43:02]

On 2015/07/15 08:00:51, pbos-webrtc wrote:
> On 2015/07/15 07:46:59, the sun wrote:
> > On 2015/07/13 12:24:17, pbos-webrtc wrote:
> > > PTAL, not expecting to submit any of this before you guys get back from
> > > vacation. So no rush, just thought it'd make sense to get a directory up
so
> > you
> > > can have OWNERS. :)
> > 
> > Thanks for doing this Peter, having ownership will certainly be useful!
> > 
> > It isn't super logical to me that call.cc lives under webrtc/video/. I'd
> expect
> > there to be more things, such as tests and utils, that can be shared. How
> about
> > a structure like this:
> > 
> > webrtc/call/ [common stuff, call.cc, possible stream impl base classes,
tests,
> > utils]
> > webrtc/call/audio/
> > webrtc/call/video/
> > 
> > WDYT?
> 
> We're talking about not calling call call anymore because it might be split up
> for ORTC in the future (I'd like to not commit to having "call" as a central
> piece in future structure). I like video/ and audio/ being generic subcategory
> names and not "API project names", there will be both audio and video in the
> future no matter what we call the APIs to them. Also I like flatter
hierarchies.
> 
> I'd like to find a more generic name for a place where things for both lives.
It
> might also not matter too much if the common stuff is a very slim part of the
> whole thing? I think shared tests/utils can go under webrtc/test/. So that
just
> leaves where to put call-common things. I'm voting for keeping them under
video/
> until we find a better name for "common stuff", or forever, if there's not too
> much common stuff.
> 
> Does that make sense?

The reasoning makes sense, but I think it is confusing to keep the common stuff
under video/.

Is it so hard to rename folders again once we get to the point of splitting up
or renaming call? If the split is on the table in the near term, maybe we should
just leave the audio stuff under webrtc/video/?

[pbos-webrtc, 2015-07-15 10:57:10]

On 2015/07/15 09:43:02, the sun wrote:
> On 2015/07/15 08:00:51, pbos-webrtc wrote:
> > On 2015/07/15 07:46:59, the sun wrote:
> > > On 2015/07/13 12:24:17, pbos-webrtc wrote:
> > > > PTAL, not expecting to submit any of this before you guys get back from
> > > > vacation. So no rush, just thought it'd make sense to get a directory up
> so
> > > you
> > > > can have OWNERS. :)
> > > 
> > > Thanks for doing this Peter, having ownership will certainly be useful!
> > > 
> > > It isn't super logical to me that call.cc lives under webrtc/video/. I'd
> > expect
> > > there to be more things, such as tests and utils, that can be shared. How
> > about
> > > a structure like this:
> > > 
> > > webrtc/call/ [common stuff, call.cc, possible stream impl base classes,
> tests,
> > > utils]
> > > webrtc/call/audio/
> > > webrtc/call/video/
> > > 
> > > WDYT?
> > 
> > We're talking about not calling call call anymore because it might be split
up
> > for ORTC in the future (I'd like to not commit to having "call" as a central
> > piece in future structure). I like video/ and audio/ being generic
subcategory
> > names and not "API project names", there will be both audio and video in the
> > future no matter what we call the APIs to them. Also I like flatter
> hierarchies.
> > 
> > I'd like to find a more generic name for a place where things for both
lives.
> It
> > might also not matter too much if the common stuff is a very slim part of
the
> > whole thing? I think shared tests/utils can go under webrtc/test/. So that
> just
> > leaves where to put call-common things. I'm voting for keeping them under
> video/
> > until we find a better name for "common stuff", or forever, if there's not
too
> > much common stuff.
> > 
> > Does that make sense?
> 
> The reasoning makes sense, but I think it is confusing to keep the common
stuff
> under video/.
> 
> Is it so hard to rename folders again once we get to the point of splitting up
> or renaming call? If the split is on the table in the near term, maybe we
should
> just leave the audio stuff under webrtc/video/?

I think we'll definitely want webrtc/audio/ regardless of how we split it right?
I'm not sure we want call/ and I don't think it should be named after the call.h
header but rather be something more generic (but not common/ because that's used
by modules and lower-level). Can you think of a better name for the call/
folder?

[the sun, 2015-07-15 13:48:36]

On 2015/07/15 10:57:10, pbos-webrtc wrote:
> On 2015/07/15 09:43:02, the sun wrote:
> > On 2015/07/15 08:00:51, pbos-webrtc wrote:
> > > On 2015/07/15 07:46:59, the sun wrote:
> > > > On 2015/07/13 12:24:17, pbos-webrtc wrote:
> > > > > PTAL, not expecting to submit any of this before you guys get back
from
> > > > > vacation. So no rush, just thought it'd make sense to get a directory
up
> > so
> > > > you
> > > > > can have OWNERS. :)
> > > > 
> > > > Thanks for doing this Peter, having ownership will certainly be useful!
> > > > 
> > > > It isn't super logical to me that call.cc lives under webrtc/video/. I'd
> > > expect
> > > > there to be more things, such as tests and utils, that can be shared.
How
> > > about
> > > > a structure like this:
> > > > 
> > > > webrtc/call/ [common stuff, call.cc, possible stream impl base classes,
> > tests,
> > > > utils]
> > > > webrtc/call/audio/
> > > > webrtc/call/video/
> > > > 
> > > > WDYT?
> > > 
> > > We're talking about not calling call call anymore because it might be
split
> up
> > > for ORTC in the future (I'd like to not commit to having "call" as a
central
> > > piece in future structure). I like video/ and audio/ being generic
> subcategory
> > > names and not "API project names", there will be both audio and video in
the
> > > future no matter what we call the APIs to them. Also I like flatter
> > hierarchies.
> > > 
> > > I'd like to find a more generic name for a place where things for both
> lives.
> > It
> > > might also not matter too much if the common stuff is a very slim part of
> the
> > > whole thing? I think shared tests/utils can go under webrtc/test/. So that
> > just
> > > leaves where to put call-common things. I'm voting for keeping them under
> > video/
> > > until we find a better name for "common stuff", or forever, if there's not
> too
> > > much common stuff.
> > > 
> > > Does that make sense?
> > 
> > The reasoning makes sense, but I think it is confusing to keep the common
> stuff
> > under video/.
> > 
> > Is it so hard to rename folders again once we get to the point of splitting
up
> > or renaming call? If the split is on the table in the near term, maybe we
> should
> > just leave the audio stuff under webrtc/video/?
> 
> I think we'll definitely want webrtc/audio/ regardless of how we split it
right?
> I'm not sure we want call/ and I don't think it should be named after the
call.h
> header but rather be something more generic (but not common/ because that's
used
> by modules and lower-level). Can you think of a better name for the call/
> folder?

uhm... "api"? nah.

I guess what's missing here are good names for the lower level parts (former
ViE/VoE) and the upper layer parts (former libjingle). Perhaps "media layer" for
the low level and "transport layer" for the upper layer, though that can be
confusing for other reasons. Then we'd have media_api and transport_api.
Perhaps. Maybe. Tentatively. And so on.

[pbos-webrtc, 2015-07-15 13:53:29]

On 2015/07/15 13:48:36, the sun wrote:
> On 2015/07/15 10:57:10, pbos-webrtc wrote:
> > On 2015/07/15 09:43:02, the sun wrote:
> > > On 2015/07/15 08:00:51, pbos-webrtc wrote:
> > > > On 2015/07/15 07:46:59, the sun wrote:
> > > > > On 2015/07/13 12:24:17, pbos-webrtc wrote:
> > > > > > PTAL, not expecting to submit any of this before you guys get back
> from
> > > > > > vacation. So no rush, just thought it'd make sense to get a
directory
> up
> > > so
> > > > > you
> > > > > > can have OWNERS. :)
> > > > > 
> > > > > Thanks for doing this Peter, having ownership will certainly be
useful!
> > > > > 
> > > > > It isn't super logical to me that call.cc lives under webrtc/video/.
I'd
> > > > expect
> > > > > there to be more things, such as tests and utils, that can be shared.
> How
> > > > about
> > > > > a structure like this:
> > > > > 
> > > > > webrtc/call/ [common stuff, call.cc, possible stream impl base
classes,
> > > tests,
> > > > > utils]
> > > > > webrtc/call/audio/
> > > > > webrtc/call/video/
> > > > > 
> > > > > WDYT?
> > > > 
> > > > We're talking about not calling call call anymore because it might be
> split
> > up
> > > > for ORTC in the future (I'd like to not commit to having "call" as a
> central
> > > > piece in future structure). I like video/ and audio/ being generic
> > subcategory
> > > > names and not "API project names", there will be both audio and video in
> the
> > > > future no matter what we call the APIs to them. Also I like flatter
> > > hierarchies.
> > > > 
> > > > I'd like to find a more generic name for a place where things for both
> > lives.
> > > It
> > > > might also not matter too much if the common stuff is a very slim part
of
> > the
> > > > whole thing? I think shared tests/utils can go under webrtc/test/. So
that
> > > just
> > > > leaves where to put call-common things. I'm voting for keeping them
under
> > > video/
> > > > until we find a better name for "common stuff", or forever, if there's
not
> > too
> > > > much common stuff.
> > > > 
> > > > Does that make sense?
> > > 
> > > The reasoning makes sense, but I think it is confusing to keep the common
> > stuff
> > > under video/.
> > > 
> > > Is it so hard to rename folders again once we get to the point of
splitting
> up
> > > or renaming call? If the split is on the table in the near term, maybe we
> > should
> > > just leave the audio stuff under webrtc/video/?
> > 
> > I think we'll definitely want webrtc/audio/ regardless of how we split it
> right?
> > I'm not sure we want call/ and I don't think it should be named after the
> call.h
> > header but rather be something more generic (but not common/ because that's
> used
> > by modules and lower-level). Can you think of a better name for the call/
> > folder?
> 
> uhm... "api"? nah.
> 
> I guess what's missing here are good names for the lower level parts (former
> ViE/VoE) and the upper layer parts (former libjingle). Perhaps "media layer"
for
> the low level and "transport layer" for the upper layer, though that can be
> confusing for other reasons. Then we'd have media_api and transport_api.
> Perhaps. Maybe. Tentatively. And so on.

Yeah, I think we should extend this part of the discussion with Kirkland. We
shouldn't be having this split between talk/ and webrtc/.

[pbos-webrtc, 2015-07-15 13:53:55]

On 2015/07/15 13:53:29, pbos-webrtc wrote:
> On 2015/07/15 13:48:36, the sun wrote:
> > On 2015/07/15 10:57:10, pbos-webrtc wrote:
> > > On 2015/07/15 09:43:02, the sun wrote:
> > > > On 2015/07/15 08:00:51, pbos-webrtc wrote:
> > > > > On 2015/07/15 07:46:59, the sun wrote:
> > > > > > On 2015/07/13 12:24:17, pbos-webrtc wrote:
> > > > > > > PTAL, not expecting to submit any of this before you guys get back
> > from
> > > > > > > vacation. So no rush, just thought it'd make sense to get a
> directory
> > up
> > > > so
> > > > > > you
> > > > > > > can have OWNERS. :)
> > > > > > 
> > > > > > Thanks for doing this Peter, having ownership will certainly be
> useful!
> > > > > > 
> > > > > > It isn't super logical to me that call.cc lives under webrtc/video/.
> I'd
> > > > > expect
> > > > > > there to be more things, such as tests and utils, that can be
shared.
> > How
> > > > > about
> > > > > > a structure like this:
> > > > > > 
> > > > > > webrtc/call/ [common stuff, call.cc, possible stream impl base
> classes,
> > > > tests,
> > > > > > utils]
> > > > > > webrtc/call/audio/
> > > > > > webrtc/call/video/
> > > > > > 
> > > > > > WDYT?
> > > > > 
> > > > > We're talking about not calling call call anymore because it might be
> > split
> > > up
> > > > > for ORTC in the future (I'd like to not commit to having "call" as a
> > central
> > > > > piece in future structure). I like video/ and audio/ being generic
> > > subcategory
> > > > > names and not "API project names", there will be both audio and video
in
> > the
> > > > > future no matter what we call the APIs to them. Also I like flatter
> > > > hierarchies.
> > > > > 
> > > > > I'd like to find a more generic name for a place where things for both
> > > lives.
> > > > It
> > > > > might also not matter too much if the common stuff is a very slim part
> of
> > > the
> > > > > whole thing? I think shared tests/utils can go under webrtc/test/. So
> that
> > > > just
> > > > > leaves where to put call-common things. I'm voting for keeping them
> under
> > > > video/
> > > > > until we find a better name for "common stuff", or forever, if there's
> not
> > > too
> > > > > much common stuff.
> > > > > 
> > > > > Does that make sense?
> > > > 
> > > > The reasoning makes sense, but I think it is confusing to keep the
common
> > > stuff
> > > > under video/.
> > > > 
> > > > Is it so hard to rename folders again once we get to the point of
> splitting
> > up
> > > > or renaming call? If the split is on the table in the near term, maybe
we
> > > should
> > > > just leave the audio stuff under webrtc/video/?
> > > 
> > > I think we'll definitely want webrtc/audio/ regardless of how we split it
> > right?
> > > I'm not sure we want call/ and I don't think it should be named after the
> > call.h
> > > header but rather be something more generic (but not common/ because
that's
> > used
> > > by modules and lower-level). Can you think of a better name for the call/
> > > folder?
> > 
> > uhm... "api"? nah.
> > 
> > I guess what's missing here are good names for the lower level parts (former
> > ViE/VoE) and the upper layer parts (former libjingle). Perhaps "media layer"
> for
> > the low level and "transport layer" for the upper layer, though that can be
> > confusing for other reasons. Then we'd have media_api and transport_api.
> > Perhaps. Maybe. Tentatively. And so on.
> 
> Yeah, I think we should extend this part of the discussion with Kirkland. We
> shouldn't be having this split between talk/ and webrtc/.

But since we know that we want audio/ (right?) should we go with that part
first?

[the sun, 2015-07-16 10:16:42]

On 2015/07/15 13:53:55, pbos-webrtc wrote:
> On 2015/07/15 13:53:29, pbos-webrtc wrote:
> > On 2015/07/15 13:48:36, the sun wrote:
> > > On 2015/07/15 10:57:10, pbos-webrtc wrote:
> > > > On 2015/07/15 09:43:02, the sun wrote:
> > > > > On 2015/07/15 08:00:51, pbos-webrtc wrote:
> > > > > > On 2015/07/15 07:46:59, the sun wrote:
> > > > > > > On 2015/07/13 12:24:17, pbos-webrtc wrote:
> > > > > > > > PTAL, not expecting to submit any of this before you guys get
back
> > > from
> > > > > > > > vacation. So no rush, just thought it'd make sense to get a
> > directory
> > > up
> > > > > so
> > > > > > > you
> > > > > > > > can have OWNERS. :)
> > > > > > > 
> > > > > > > Thanks for doing this Peter, having ownership will certainly be
> > useful!
> > > > > > > 
> > > > > > > It isn't super logical to me that call.cc lives under
webrtc/video/.
> > I'd
> > > > > > expect
> > > > > > > there to be more things, such as tests and utils, that can be
> shared.
> > > How
> > > > > > about
> > > > > > > a structure like this:
> > > > > > > 
> > > > > > > webrtc/call/ [common stuff, call.cc, possible stream impl base
> > classes,
> > > > > tests,
> > > > > > > utils]
> > > > > > > webrtc/call/audio/
> > > > > > > webrtc/call/video/
> > > > > > > 
> > > > > > > WDYT?
> > > > > > 
> > > > > > We're talking about not calling call call anymore because it might
be
> > > split
> > > > up
> > > > > > for ORTC in the future (I'd like to not commit to having "call" as a
> > > central
> > > > > > piece in future structure). I like video/ and audio/ being generic
> > > > subcategory
> > > > > > names and not "API project names", there will be both audio and
video
> in
> > > the
> > > > > > future no matter what we call the APIs to them. Also I like flatter
> > > > > hierarchies.
> > > > > > 
> > > > > > I'd like to find a more generic name for a place where things for
both
> > > > lives.
> > > > > It
> > > > > > might also not matter too much if the common stuff is a very slim
part
> > of
> > > > the
> > > > > > whole thing? I think shared tests/utils can go under webrtc/test/.
So
> > that
> > > > > just
> > > > > > leaves where to put call-common things. I'm voting for keeping them
> > under
> > > > > video/
> > > > > > until we find a better name for "common stuff", or forever, if
there's
> > not
> > > > too
> > > > > > much common stuff.
> > > > > > 
> > > > > > Does that make sense?
> > > > > 
> > > > > The reasoning makes sense, but I think it is confusing to keep the
> common
> > > > stuff
> > > > > under video/.
> > > > > 
> > > > > Is it so hard to rename folders again once we get to the point of
> > splitting
> > > up
> > > > > or renaming call? If the split is on the table in the near term, maybe
> we
> > > > should
> > > > > just leave the audio stuff under webrtc/video/?
> > > > 
> > > > I think we'll definitely want webrtc/audio/ regardless of how we split
it
> > > right?
> > > > I'm not sure we want call/ and I don't think it should be named after
the
> > > call.h
> > > > header but rather be something more generic (but not common/ because
> that's
> > > used
> > > > by modules and lower-level). Can you think of a better name for the
call/
> > > > folder?
> > > 
> > > uhm... "api"? nah.
> > > 
> > > I guess what's missing here are good names for the lower level parts
(former
> > > ViE/VoE) and the upper layer parts (former libjingle). Perhaps "media
layer"
> > for
> > > the low level and "transport layer" for the upper layer, though that can
be
> > > confusing for other reasons. Then we'd have media_api and transport_api.
> > > Perhaps. Maybe. Tentatively. And so on.
> > 
> > Yeah, I think we should extend this part of the discussion with Kirkland. We
> > shouldn't be having this split between talk/ and webrtc/.
> 
> But since we know that we want audio/ (right?) should we go with that part
> first?

My vote is on either of:

1. Leave as is, until above discussion is resolved.
2. Use call/, call/audio, call/video since that is what we have at the moment. 
3. Just add a call/audio folder and move some bits in there so we can have a
separate OWNERS file.

[the sun, 2015-09-24 12:32:33]

On 2015/07/16 10:16:42, the sun wrote:
> On 2015/07/15 13:53:55, pbos-webrtc wrote:
> > On 2015/07/15 13:53:29, pbos-webrtc wrote:
> > > On 2015/07/15 13:48:36, the sun wrote:
> > > > On 2015/07/15 10:57:10, pbos-webrtc wrote:
> > > > > On 2015/07/15 09:43:02, the sun wrote:
> > > > > > On 2015/07/15 08:00:51, pbos-webrtc wrote:
> > > > > > > On 2015/07/15 07:46:59, the sun wrote:
> > > > > > > > On 2015/07/13 12:24:17, pbos-webrtc wrote:
> > > > > > > > > PTAL, not expecting to submit any of this before you guys get
> back
> > > > from
> > > > > > > > > vacation. So no rush, just thought it'd make sense to get a
> > > directory
> > > > up
> > > > > > so
> > > > > > > > you
> > > > > > > > > can have OWNERS. :)
> > > > > > > > 
> > > > > > > > Thanks for doing this Peter, having ownership will certainly be
> > > useful!
> > > > > > > > 
> > > > > > > > It isn't super logical to me that call.cc lives under
> webrtc/video/.
> > > I'd
> > > > > > > expect
> > > > > > > > there to be more things, such as tests and utils, that can be
> > shared.
> > > > How
> > > > > > > about
> > > > > > > > a structure like this:
> > > > > > > > 
> > > > > > > > webrtc/call/ [common stuff, call.cc, possible stream impl base
> > > classes,
> > > > > > tests,
> > > > > > > > utils]
> > > > > > > > webrtc/call/audio/
> > > > > > > > webrtc/call/video/
> > > > > > > > 
> > > > > > > > WDYT?
> > > > > > > 
> > > > > > > We're talking about not calling call call anymore because it might
> be
> > > > split
> > > > > up
> > > > > > > for ORTC in the future (I'd like to not commit to having "call" as
a
> > > > central
> > > > > > > piece in future structure). I like video/ and audio/ being generic
> > > > > subcategory
> > > > > > > names and not "API project names", there will be both audio and
> video
> > in
> > > > the
> > > > > > > future no matter what we call the APIs to them. Also I like
flatter
> > > > > > hierarchies.
> > > > > > > 
> > > > > > > I'd like to find a more generic name for a place where things for
> both
> > > > > lives.
> > > > > > It
> > > > > > > might also not matter too much if the common stuff is a very slim
> part
> > > of
> > > > > the
> > > > > > > whole thing? I think shared tests/utils can go under webrtc/test/.
> So
> > > that
> > > > > > just
> > > > > > > leaves where to put call-common things. I'm voting for keeping
them
> > > under
> > > > > > video/
> > > > > > > until we find a better name for "common stuff", or forever, if
> there's
> > > not
> > > > > too
> > > > > > > much common stuff.
> > > > > > > 
> > > > > > > Does that make sense?
> > > > > > 
> > > > > > The reasoning makes sense, but I think it is confusing to keep the
> > common
> > > > > stuff
> > > > > > under video/.
> > > > > > 
> > > > > > Is it so hard to rename folders again once we get to the point of
> > > splitting
> > > > up
> > > > > > or renaming call? If the split is on the table in the near term,
maybe
> > we
> > > > > should
> > > > > > just leave the audio stuff under webrtc/video/?
> > > > > 
> > > > > I think we'll definitely want webrtc/audio/ regardless of how we split
> it
> > > > right?
> > > > > I'm not sure we want call/ and I don't think it should be named after
> the
> > > > call.h
> > > > > header but rather be something more generic (but not common/ because
> > that's
> > > > used
> > > > > by modules and lower-level). Can you think of a better name for the
> call/
> > > > > folder?
> > > > 
> > > > uhm... "api"? nah.
> > > > 
> > > > I guess what's missing here are good names for the lower level parts
> (former
> > > > ViE/VoE) and the upper layer parts (former libjingle). Perhaps "media
> layer"
> > > for
> > > > the low level and "transport layer" for the upper layer, though that can
> be
> > > > confusing for other reasons. Then we'd have media_api and transport_api.
> > > > Perhaps. Maybe. Tentatively. And so on.
> > > 
> > > Yeah, I think we should extend this part of the discussion with Kirkland.
We
> > > shouldn't be having this split between talk/ and webrtc/.
> > 
> > But since we know that we want audio/ (right?) should we go with that part
> > first?
> 
> My vote is on either of:
> 
> 1. Leave as is, until above discussion is resolved.
> 2. Use call/, call/audio, call/video since that is what we have at the moment.

> 3. Just add a call/audio folder and move some bits in there so we can have a
> separate OWNERS file.

Can we resolve this soonish?

[pbos-webrtc, 2015-09-24 14:01:22]

new proposal

[pbos-webrtc, 2015-09-24 14:05:02]

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

[pbos-webrtc, 2015-09-24 14:05:23]

There, PTAL. This is split up into audio, call (shared) and video as we
discussed.

[The Sun (google.com), 2015-09-24 14:20:24]

On 2015/09/24 14:05:23, pbos-webrtc wrote:
> There, PTAL. This is split up into audio, call (shared) and video as we
> discussed.

I think you should move any of the tests that aren't specifically video tests to
call/:

bitrate_estimator_tests.cc
packet_injection_tests.cc

others?

[the sun, 2015-09-24 14:27:41]

lgtm

[pbos-webrtc, 2015-09-24 14:33:40]

move tests

[pbos-webrtc, 2015-09-24 14:34:42]

Tests moved, + call_perf_tests.cc which contains AV sync (I consider this
shared)

[tlegrand-webrtc, 2015-09-25 11:36:21]

On 2015/09/24 14:34:42, pbos-webrtc wrote:
> Tests moved, + call_perf_tests.cc which contains AV sync (I consider this
> shared)

LGTM

[pbos-webrtc, 2015-09-25 11:42:58]

rebase

[pbos-webrtc, 2015-09-25 11:43:26]

Thanks, TBR=mflodman@ so that I don't have to do a weird rebase of this. We've
discussed the overall structure offline.

[pbos-webrtc, 2015-09-25 11:43:32]

The CQ bit was checked by pbos@webrtc.org

[pbos-webrtc, 2015-09-25 11:43:32]

The patchset sent to the CQ was uploaded after l-g-t-m from
solenberg@webrtc.org, tina.legrand@webrtc.org
Link to the patchset: https://codereview.webrtc.org/1227923005/#ps60001 (title:
"rebase")

[commit-bot: I haz the power, 2015-09-25 11:43:47]

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

[commit-bot: I haz the power, 2015-09-25 11:46:29]

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

[commit-bot: I haz the power, 2015-09-25 11:46:30]

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

[pbos-webrtc, 2015-09-25 11:58:45]

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

[commit-bot: I haz the power, 2015-09-25 11:58:45]

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