Re: GStreamer SDK – Preview release for Android

[Andoni Morales]

2012/10/5 cowwoc <cowwoc at bbs.darktech.org>

>
>     x264 is GPL, no doubt about that. I didn't check the bigger library,
> but we'd definitely need to be able to indicate whether it should be
> included or excluded.
>
>     That brings up a bigger question: do we have fine-grained control
> about which plugins get included or excluded as part of the Android build?
> Do you support building *all* the plugins that are available for Linux?
>

We provide the exact same set of plugins as in the rest of platforms,
except for the system plugins such as audio/video sinks and
decoders/encoders wrappers. There might be some exceptions, but in general
you should be able to use the same plugins as on Linux, Windows or OS X.

The list of plugins that will be included in the final shared library is
set in the GSTREAMER_PLUGINS variable, in jni/Android.mk.
>From this list of plugins, a gstreamer_android.c file is generated, that
defines an initialization function which takes care of registering the
static plugins and redirecting the gstreamer logs to logcat among other
things. This list of plugins is also used to find all the dependencies and
link the final shared DLL. We have also solved all the collisions in
function names, so that shouldn't be a problem.
For the plugins list, you can create it manually or use any of the
categories predefined, such as GSTREAMER_PLUGINS_CODECS or
GST_PLUGINS_PLAYBACK.

Andoni



> Thanks,
> Gili
>
>
> On 05/10/2012 4:50 PM, Dragos D wrote:
>
> My understanding is that ffmpeg is LGPL, but what about x264? By the way,
> is it included in the big GStreamer library?
> On Oct 5, 2012 4:33 PM, "Sebastian Dröge" <
> sebastian.droege at collabora.co.uk> wrote:
>
>> On Fr, 2012-10-05 at 16:10 -0400, cowwoc wrote:
>> > What's the impact of static linking followed by dynamic linking as
>> > you mentioned? I assume from a legal/LGPL point of view, it's as if
>> > we're dynamically linking our application with GStreamer, correct?
>>
>> I'm not a lawyer but general understanding of LGPL and static linking
>> is, that you need to provide all means to be able to relink the
>> application against modified versions of the LGPL'd libraries.
>>
>> If you take a look at the approach we did for static linking here you'll
>> notice that this is absolutely nothing to worry about. All (LGPL'd)
>> GStreamer code is linked into a single shared library from these static
>> libraries and your application code is a) separate from this and b) uses
>> GStreamer and related libraries like a shared library, thus the same
>> rules apply as for using GStreamer as a shared library.
>>
>> E.g. the demo application I linked in the original mail contains one
>> shared library libgstreamer_android.so, which contains all of GStreamer,
>> dependencies, plugins. And another library libtutorial-5.so, which
>> contains the native code of the application.
>>
>>
>> There should be no problem developing closed source, commercial
>> applications with this approach as it's the same situation you have on
>> desktop systems with shared LGPL'd libraries.
>>
>> _______________________________________________
>> gstreamer-android mailing list
>> gstreamer-android at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-android
>>
>>
>
> _______________________________________________
> gstreamer-android mailing listgstreamer-android at lists.freedesktop.orghttp://lists.freedesktop.org/mailman/listinfo/gstreamer-android
>
>
>
> _______________________________________________
> gstreamer-android mailing list
> gstreamer-android at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-android
>
>


-- 
Andoni Morales Alastruey

LongoMatch:The Digital Coach
http://www.longomatch.ylatuya.es
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-android/attachments/20121005/82104d19/attachment.html>