GStreamer on android [Fwd: Re: GIT repositories]

[Edward Hervey]

I thought I'd also send this mail out for anybody interested in building
GStreamer on android easily with git repositories.

  S60, Android... what next ? :)

    Edward

Hi all,

* GIT repositories

  I have finally taken time to cleanup my repositories and patches.

  All the repositories are located here (the ones starting with
android-) : http://cgit.freedesktop.org/~bilboed/

  These repositories share all the commits from the upstream official
git repositories.
  glib : git://git.gnome.org/preview/glib
  liboil : git://anongit.freedesktop.org/git/liboil
  gst* : git://anongit.freedesktop.org/git/gstreamer/gst*
  build : git://android.git.kernel.org/platform/build.git

  This makes it much easier to 'rebase' the android patches against a
newer release or commit.

  These repositories only contain, so far, the patches that were on the
google groups site. I splitted them up into individual commits, in order
to make it easier to push upstream what can be pushed upstream and leave
alone what can't be pushed upstream.

  I have also modified the makefiles so that you no longer need to put
them in a subdirectory in external, but directly in external (like all
the other external projects).

  To check them out (once you've already checked out the full build
system and done repo sync), do the following:

$ cd external/
$ for i in glib liboil gstreamer gst-plugins-base gst-plugins-good
gst-plugins-bad; do git clone
git://anongit.freedesktop.org/~bilboed/android-$i $i; done

  I have also got a 'build' repository, currently containing the prelink
patch.
  You can check it out as follow:

$ cd build/
$ git remote add fdo
git://anongit.freedesktop.org/~bilboed/android-build
$ git checkout -b gst fdo/master

  From that point on, just build android as you normally would and it
will build/install the libraries/plugins.


* Auto-generated .c/.h files

  Apart from the Android.mk files, the only thing required to compile
several libraries/plugins are files that are generated by the standard
autotools system at build/dist time.

  We have been thinking lately with Zaheer (who ported gstreamer to S60
[1]) that we should have a common location for all the .c/.h files
generated at build/dist time.
  Currently we have some files for the win32 build system in win32/, but
we need to make this more generic. Maybe have a generated/ directory in
GStreamer containing those files.
  This could help solve a big chunk of the non-standard build systems.


* plugins are not libraries

  All the plugins are currently using the build/core/shared_library.mk
makefile ... which results in those libraries ending up in /system/lib
in the target.
  This is painful for many reasons. Plugins aren't 'standard' shared
libraries:
  * They don't need to be prelinked
  * They are not imported at link time
  * When scanning for plugins (with GST_PLUGIN_PATH=/system/lib), we end
up with a *lot* of non-plugins. They should be in a separate directory,
like /system/gst-plugins.

  I'm currently investigating a modification to the build/ system to add
the notion of plugins so that we can just use 'plugin.mk' in every
plugin directory and have the problems above solved. I'll keep you
updated on this progress and will push it to my android-build git
repository.


* android-gst manifest

  The only thing left to bring everything together is to setup a
manifest specifying all the afore-mentionned git repositories/branches.
  I'll look into it.


* It runs on the G1

  Yes, setup the build system as you would for the G1 [2], checkout the
repositories/branches mentionned above, run 'make' from the toplevel
directory and then flash your phone with it... and it works :)


* Comments and feedback...

  ... are most welcome as usual !

    Edward

[1] http://zaheer.merali.org/articles/2009/03/11/gstreamer-port-to-s60/
[2] http://source.android.com/documentation/building-for-dream


On Wed, 2009-03-04 at 23:17 -0800, bilboed wrote:

> Hi all,
>
>   I've been using the various patches to build GStreamer for Android
> on the emulator and also on a dev G1 phone and it works great !
>
>   I've cleaned/splitted up the various patches into smaller commits in
> git repositories I have locally.
>
>   What I can do is push upstream the various commits that can actually
> go upstream (like the parts to make libiconv/gettext optional for
> glib).
>
>   Then ideally, we should create some 'public' git repositories to
> easily integrate all of this in a android build. There are many free
> git hosting places available to host that (github, gitorious, or we
> could even have those repositories at freedesktop alongside the
> official gstreamer repositories !). But in the long run, we should
> make this as easy as 'repo init -u <gstreamer-manifest-file> && make'.
>
>   I'll try to put my repositories online as soon as possible.
>
>   The easier we make it for people to try/use a gstreamer-based
> android, the better it will be for us all (more feedback, more
> contributors, maybe even tempting some companies to switch to
> gstreamer for Android?)
>
>   Comments welcome,
>
>    Edward
>
> P.S. For those wondering, I'm one of the GStreamer developers,
> therefore very interested to push this as hard as possible :)
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "prajnashi" group.
> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to [hidden email]
> For more options, visit this group at http://groups.google.com/group/prajnashi?hl=en
> -~----------~----~----~----~------~----~------~--~---
>

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Farkas Levente]

Edward Hervey wrote:

> I thought I'd also send this mail out for anybody interested in building
> GStreamer on android easily with git repositories.
>
>   S60, Android... what next ? :)
>
>     Edward
>
>
> ------------------------------------------------------------------------
>
> Subject:
> Re: GIT repositories
> From:
> Edward Hervey <[hidden email]>
> Date:
> Fri, 13 Mar 2009 18:56:16 +0100
> To:
> [hidden email]
>
> To:
> [hidden email]
>
>
> Hi all,
>
> * GIT repositories
>
>   I have finally taken time to cleanup my repositories and patches.
>
>   All the repositories are located here (the ones starting with
> android-) : http://cgit.freedesktop.org/~bilboed/
>
>   These repositories share all the commits from the upstream official
> git repositories.
>   glib : git://git.gnome.org/preview/glib
>   liboil : git://anongit.freedesktop.org/git/liboil
>   gst* : git://anongit.freedesktop.org/git/gstreamer/gst*
>   build : git://android.git.kernel.org/platform/build.git
>
>   This makes it much easier to 'rebase' the android patches against a
> newer release or commit.
>
>   These repositories only contain, so far, the patches that were on the
> google groups site. I splitted them up into individual commits, in order
> to make it easier to push upstream what can be pushed upstream and leave
> alone what can't be pushed upstream.

what's the reason why something can't be pushed upstream?

--
  Levente                               "Si vis pacem para bellum!"

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Edward Hervey]

On Fri, 2009-03-13 at 20:57 +0100, Farkas Levente wrote:

> Edward Hervey wrote:
> > I thought I'd also send this mail out for anybody interested in building
> > GStreamer on android easily with git repositories.
> >
> >   These repositories only contain, so far, the patches that were on the
> > google groups site. I splitted them up into individual commits, in order
> > to make it easier to push upstream what can be pushed upstream and leave
> > alone what can't be pushed upstream.
>
> what's the reason why something can't be pushed upstream?
>

* intrusive patches that need cleaner rewrites.
  For example : There's not i18n/libiconv/gettext on Android. Therefore
we need to deactivate that everywhere in the modules we're using
(glib/liboil/gst*).. but currently it uses non-standard #ifdef ANDROID.
We should transform that into a clean way to disable i18n support for
all those modules.

* Android specific defaults.
  For example : We can use fbdevsink on the G1... but the default sink
isn't the same as on unix. We could split that up in one upstream patch
that makes it more modular to compile in a different default, and one
patch (a one-liner non-upstream patch) that defines the default fb
device on android.


* Android-specific Makefiles and auto-generated files
  Android doesn't use the standard autotools build system, but has it's
own build system. That means that we have to store files that are
normally generated at configure time (config.h, *.in) or compile time
(*-enum.[ch], gst parser (uses flex/bison), ...) and have Android.mk
makefiles in all the correct directories.
  This is in fact a similar issue that was Zaheer has with the S60 port,
and very close to what we do for the win32 builds.
  We need to find a clean/unified way to solve this for all
non-autotools build systems/architectures. One could be switching away
from autotools and using CMake (which can create Makefiles for various
systems).

  Edward


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Prajnashi S]

Hi, all
After everything is stable, I think merge everything back to up stream is better.

On Sat, Mar 14, 2009 at 4:53 PM, Edward Hervey <[hidden email]> wrote:

On Fri, 2009-03-13 at 20:57 +0100, Farkas Levente wrote:
> Edward Hervey wrote:
> > I thought I'd also send this mail out for anybody interested in building
> > GStreamer on android easily with git repositories.
> >

> >   These repositories only contain, so far, the patches that were on the
> > google groups site. I splitted them up into individual commits, in order
> > to make it easier to push upstream what can be pushed upstream and leave
> > alone what can't be pushed upstream.
>
> what's the reason why something can't be pushed upstream?
>

* intrusive patches that need cleaner rewrites.
 For example : There's not i18n/libiconv/gettext on Android. Therefore
we need to deactivate that everywhere in the modules we're using
(glib/liboil/gst*).. but currently it uses non-standard #ifdef ANDROID.
We should transform that into a clean way to disable i18n support for
all those modules.

* Android specific defaults.
 For example : We can use fbdevsink on the G1... but the default sink
isn't the same as on unix. We could split that up in one upstream patch
that makes it more modular to compile in a different default, and one
patch (a one-liner non-upstream patch) that defines the default fb
device on android.


* Android-specific Makefiles and auto-generated files
 Android doesn't use the standard autotools build system, but has it's
own build system. That means that we have to store files that are
normally generated at configure time (config.h, *.in) or compile time
(*-enum.[ch], gst parser (uses flex/bison), ...) and have Android.mk
makefiles in all the correct directories.
 This is in fact a similar issue that was Zaheer has with the S60 port,
and very close to what we do for the win32 builds.
 We need to find a clean/unified way to solve this for all
non-autotools build systems/architectures. One could be switching away
from autotools and using CMake (which can create Makefiles for various
systems).

 Edward

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

--
-- Prajnashi S

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel