<br><br><div class="gmail_quote">2012/10/5 cowwoc <span dir="ltr"><<a href="mailto:cowwoc@bbs.darktech.org" target="_blank">cowwoc@bbs.darktech.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div><br>
          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.<br>
      <br>
          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?<br></div></div></blockquote><div><br>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.<br>

<br>The list of plugins that will be included in the final shared library is set in the GSTREAMER_PLUGINS variable, in jni/Android.mk.<br>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.<br>

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.<br><br>Andoni<br><br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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

<br>_______________________________________________<br>
gstreamer-android mailing list<br>
<a href="mailto:gstreamer-android@lists.freedesktop.org">gstreamer-android@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-android" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-android</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Andoni Morales Alastruey<br><br>LongoMatch:The Digital Coach<br><a href="http://www.longomatch.ylatuya.es">http://www.longomatch.ylatuya.es</a><br>