Adds new libcast_media shared library for cast_shell media

Adds new libcast_media shared library for cast_shell media

Starting with just the init/finalize functions.

BUG=

Committed: https://crrev.com/9450166c8a88a866715256ec7e7e0362052be25a
Cr-Commit-Position: refs/heads/master@{#329687}

[halliwell, 2015-05-11 17:44:58]

halliwell@chromium.org changed reviewers:
+ erickung@chromium.org, gunsch@chromium.org, lcwu@chromium.org

[halliwell, 2015-05-12 17:53:27]

halliwell@chromium.org changed reviewers:
+ servolk@chromium.org

[halliwell, 2015-05-13 00:50:41]

On 2015/05/11 17:45:21, halliwell wrote:

bump

[lcwu1, 2015-05-13 01:58:25]

lgtm % nit on gyp variable name.

https://codereview.chromium.org/1140583002/diff/20001/chromecast/media/media.gyp
File chromecast/media/media.gyp (right):

https://codereview.chromium.org/1140583002/diff/20001/chromecast/media/media....
chromecast/media/media.gyp:9: 'enable_default_cast_media%': 1,
nit: I would probably change the gyp var name slightly to
"use_default_libcast_media' because we are talking about the default
implementation of the shared library here, not the default implementation of
cma. (The latter appears to suggest that way.)

[gunsch, 2015-05-13 03:26:04]

https://codereview.chromium.org/1140583002/diff/20001/chromecast/media/media.gyp
File chromecast/media/media.gyp (right):

https://codereview.chromium.org/1140583002/diff/20001/chromecast/media/media....
chromecast/media/media.gyp:10: 'libcast_media_gyp%': '',
I just noticed libcast_graphics does the same thing, but I'm not sure I like
this approach.

For example, I assume we'll have prebuilt .so files that aren't provided via gyp
files. But this assumes there will always be a gyp target pointing to a target
that provides the .so file. Can we find a way to get rid of that assumption?

https://codereview.chromium.org/1140583002/diff/20001/chromecast/public/cast_...
File chromecast/public/cast_media_shlib.h (right):

https://codereview.chromium.org/1140583002/diff/20001/chromecast/public/cast_...
chromecast/public/cast_media_shlib.h:18: // hardware resources. Called at
startup in browser process before main
I think references to "browser process" here are inappropriate; this can also be
called in cases such as unit test startup, no?

[halliwell, 2015-05-13 03:43:33]

https://codereview.chromium.org/1140583002/diff/20001/chromecast/media/media.gyp
File chromecast/media/media.gyp (right):

https://codereview.chromium.org/1140583002/diff/20001/chromecast/media/media....
chromecast/media/media.gyp:9: 'enable_default_cast_media%': 1,
On 2015/05/13 01:58:24, lcwu1 wrote:
> nit: I would probably change the gyp var name slightly to
> "use_default_libcast_media' because we are talking about the default
> implementation of the shared library here, not the default implementation of
> cma. (The latter appears to suggest that way.)

I think I was going for consistency with the graphics variable, but I see your
point.

Maybe the right fix is to change as you suggest, and change graphics to be
consistent with media?  The question never arose for graphics because there was
no cast_graphics target.

https://codereview.chromium.org/1140583002/diff/20001/chromecast/media/media....
chromecast/media/media.gyp:10: 'libcast_media_gyp%': '',
On 2015/05/13 03:26:04, gunsch wrote:
> I just noticed libcast_graphics does the same thing, but I'm not sure I like
> this approach.
> 
> For example, I assume we'll have prebuilt .so files that aren't provided via
gyp
> files. But this assumes there will always be a gyp target pointing to a target
> that provides the .so file. Can we find a way to get rid of that assumption?

We should discuss for sure.  The challenge is with Marvell, where we want to
supply a vendor override shared lib, but we also want to build it all in our
build system, unlike other vendors who might override the shared lib externally.

Last time around with graphics, we discussed having a make file step that copied
the Marvell so to replace the default one.  But we concluded that would be extra
complexity and that just depending on their gyp target makes sense for now.

https://codereview.chromium.org/1140583002/diff/20001/chromecast/public/cast_...
File chromecast/public/cast_media_shlib.h (right):

https://codereview.chromium.org/1140583002/diff/20001/chromecast/public/cast_...
chromecast/public/cast_media_shlib.h:18: // hardware resources. Called at
startup in browser process before main
On 2015/05/13 03:26:04, gunsch wrote:
> I think references to "browser process" here are inappropriate; this can also
be
> called in cases such as unit test startup, no?

True that it can be called in unit tests, but remember these comments are for
vendors, this is our API documentation.  I actually think it's critical that we
document which processes they can expect their APIs to be called in.  For
example, I'm unhappy with the graphics egl platform class, which gets
instantiated both in the browser and the GPU process, and a subset of the
functions get called in each case.  This is something we kind of inherited from
Ozone, not something we designed that way, but still it sucks.  The vendor has
to make sure not to initialise any GL stuff when they're called in the browser
process.  My plan there is to separate that into two APIs, one for each process.

For media, there is going to be stuff happening in the renderer and stuff
happening in the browser, and theoretically one could imagine doing stuff in the
gpu process one day.  I think it's important to be clear about that.

[halliwell, 2015-05-13 16:10:54]

halliwell@chromium.org changed reviewers:
+ yucliu@chromium.org

[erickung1, 2015-05-13 16:48:08]

I'll be better to create a chromium bug attaching to this CL

LGTM % nit and a question

https://codereview.chromium.org/1140583002/diff/40001/chromecast/media/media.gyp
File chromecast/media/media.gyp (right):

https://codereview.chromium.org/1140583002/diff/40001/chromecast/media/media....
chromecast/media/media.gyp:314: 'base/cast_media_default.cc',
are we planning to move *.fake.* files in cma_backend in to this target later
on?

https://codereview.chromium.org/1140583002/diff/40001/chromecast/public/cast_...
File chromecast/public/cast_media_shlib.h (right):

https://codereview.chromium.org/1140583002/diff/40001/chromecast/public/cast_...
chromecast/public/cast_media_shlib.h:14: 
namespace media {

Since most our media code are under ::chromecast::media namespace

[erickung1, 2015-05-13 16:57:53]

After talking to @gunsch we don't need to create a chromium bug for this since
this is for chromecast only

[halliwell, 2015-05-13 17:02:20]

https://codereview.chromium.org/1140583002/diff/40001/chromecast/media/media.gyp
File chromecast/media/media.gyp (right):

https://codereview.chromium.org/1140583002/diff/40001/chromecast/media/media....
chromecast/media/media.gyp:314: 'base/cast_media_default.cc',
On 2015/05/13 16:48:07, erickung1 wrote:
> are we planning to move *.fake.* files in cma_backend in to this target later
> on?

Yeah, I assume they will move to the default shlib when cma generally moves into
the shared lib.

https://codereview.chromium.org/1140583002/diff/40001/chromecast/public/cast_...
File chromecast/public/cast_media_shlib.h (right):

https://codereview.chromium.org/1140583002/diff/40001/chromecast/public/cast_...
chromecast/public/cast_media_shlib.h:14: 
On 2015/05/13 16:48:07, erickung1 wrote:
> namespace media {
> 
> Since most our media code are under ::chromecast::media namespace

I half-remember a discussion about whether to put public APIs directly in
::chromecast ... @lcwu + @gunsch do you remember if we reached a conclusion on
that?

[lcwu1, 2015-05-13 17:08:57]

https://codereview.chromium.org/1140583002/diff/40001/chromecast/public/cast_...
File chromecast/public/cast_media_shlib.h (right):

https://codereview.chromium.org/1140583002/diff/40001/chromecast/public/cast_...
chromecast/public/cast_media_shlib.h:14: 
On 2015/05/13 17:02:20, halliwell wrote:
> On 2015/05/13 16:48:07, erickung1 wrote:
> > namespace media {
> > 
> > Since most our media code are under ::chromecast::media namespace
> 
> I half-remember a discussion about whether to put public APIs directly in
> ::chromecast ... @lcwu + @gunsch do you remember if we reached a conclusion on
> that?

I don't remember a discussion on what namespace(s) to use, but I agree that it
makes sense to use chromecast::media namespace here to further/better segregate
the names.

[halliwell, 2015-05-13 17:44:54]

On 2015/05/13 17:08:57, lcwu1 wrote:
>
https://codereview.chromium.org/1140583002/diff/40001/chromecast/public/cast_...
> File chromecast/public/cast_media_shlib.h (right):
> 
>
https://codereview.chromium.org/1140583002/diff/40001/chromecast/public/cast_...
> chromecast/public/cast_media_shlib.h:14: 
> On 2015/05/13 17:02:20, halliwell wrote:
> > On 2015/05/13 16:48:07, erickung1 wrote:
> > > namespace media {
> > > 
> > > Since most our media code are under ::chromecast::media namespace
> > 
> > I half-remember a discussion about whether to put public APIs directly in
> > ::chromecast ... @lcwu + @gunsch do you remember if we reached a conclusion
on
> > that?
> 
> I don't remember a discussion on what namespace(s) to use, but I agree that it
> makes sense to use chromecast::media namespace here to further/better
segregate
> the names.

Ok, moved to chromecast::media

[halliwell, 2015-05-13 18:42:50]

The CQ bit was checked by halliwell@chromium.org

[halliwell, 2015-05-13 18:42:51]

The patchset sent to the CQ was uploaded after l-g-t-m from lcwu@chromium.org,
erickung@chromium.org
Link to the patchset: https://codereview.chromium.org/1140583002/#ps60001
(title: "Move to media namespace")

[commit-bot: I haz the power, 2015-05-13 18:43:21]

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

[commit-bot: I haz the power, 2015-05-13 18:53:18]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2015-05-13 18:54:01]

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