Patchwork [v3,1/7] gstreamer1: Add gstreamer version 1.0.7 package

login
register
mail settings
Submitter Spenser Gilliland
Date May 10, 2013, 4:02 a.m.
Message ID <1368158558-6069-2-git-send-email-spenser@gillilanding.com>
Download mbox | patch
Permalink /patch/242897/
State Superseded
Headers show

Comments

Spenser Gilliland - May 10, 2013, 4:02 a.m.
This patch adds the gstreamer version 1.x series to buildroot.

Signed-off-by: Spenser Gilliland <spenser@gillilanding.com>
---
 package/multimedia/Config.in                |    1 +
 package/multimedia/gstreamer1/Config.in     |   37 +++++++++++++++++++++++++++
 package/multimedia/gstreamer1/gstreamer1.mk |   36 ++++++++++++++++++++++++++
 3 files changed, 74 insertions(+)
 create mode 100644 package/multimedia/gstreamer1/Config.in
 create mode 100644 package/multimedia/gstreamer1/gstreamer1.mk
Arnout Vandecappelle - May 10, 2013, 11:38 p.m.
Hi Spenser,

  Very quick first review...

  First of all, a comment that is not so much directed at you but at the 
rest of the BR developers: the naming issue.

  We have a tendency to make a copy of a package when there is a major 
version change, cfr. python3 and qt5. However, in this case, I don't 
think it's a good idea. At this time, many (most?) gstreamer downstreams 
have already moved to 1.x. Also, no more patches will be made the the 
0.10 series (though distro's may still make patches). So we can expect 
the old gstreamer stuff to die out relatively quickly. But if we call the 
new thing gstreamer1 now, we're essentially stuck with that name for all 
eternity.

  So instead I'd try to make 0.10 or 1.0 a choice in the gstreamer 
package itself.  For me it's fine if inside the Config.in and the .mk 
files we basically have the two versions in a big ifeq() construct, but 
at least we can keep on using the BR2_PACKAGE_GST* symbols.

  Obviously, there will be some packages that break down when gstreamer 
1.0 is used, but we'll have to discover that at some point anyway.


On 10/05/13 06:02, Spenser Gilliland wrote:
> This patch adds the gstreamer version 1.x series to buildroot.
>
> Signed-off-by: Spenser Gilliland <spenser@gillilanding.com>
> ---
>   package/multimedia/Config.in                |    1 +
>   package/multimedia/gstreamer1/Config.in     |   37 +++++++++++++++++++++++++++
>   package/multimedia/gstreamer1/gstreamer1.mk |   36 ++++++++++++++++++++++++++
>   3 files changed, 74 insertions(+)
>   create mode 100644 package/multimedia/gstreamer1/Config.in
>   create mode 100644 package/multimedia/gstreamer1/gstreamer1.mk
>
> diff --git a/package/multimedia/Config.in b/package/multimedia/Config.in
> index 931e6d3..f6a5fd7 100644
> --- a/package/multimedia/Config.in
> +++ b/package/multimedia/Config.in
> @@ -6,6 +6,7 @@ source "package/multimedia/faad2/Config.in"
>   source "package/multimedia/flac/Config.in"
>   source "package/multimedia/ffmpeg/Config.in"
>   source "package/multimedia/gstreamer/Config.in"
> +source "package/multimedia/gstreamer1/Config.in"
>   source "package/multimedia/gst-ffmpeg/Config.in"
>   source "package/multimedia/gst-dsp/Config.in"
>   source "package/multimedia/gst-fsl-plugins/Config.in"
> diff --git a/package/multimedia/gstreamer1/Config.in b/package/multimedia/gstreamer1/Config.in
> new file mode 100644
> index 0000000..b1fd8b1
> --- /dev/null
> +++ b/package/multimedia/gstreamer1/Config.in
> @@ -0,0 +1,37 @@
> +config BR2_PACKAGE_GSTREAMER1
> +	bool "gstreamer1"
> +	depends on BR2_USE_WCHAR # glib2
> +	depends on BR2_TOOLCHAIN_HAS_THREADS
> +	select BR2_PACKAGE_LIBGLIB2
> +	help
> +	  GStreamer is an open source multimedia framework.
> +
> +	  http://gstreamer.freedesktop.org/
> +
> +config BR2_PACKAGE_GSTREAMER1_GST_DEBUG
> +	bool "enable gst-debug trace support"
> +	default y
> +	depends on BR2_PACKAGE_GSTREAMER1

  We nowadays prefer to put sub-options inside an if...endif construct 
instead of with 'depends on'.


  Regards,
  Arnout

> +	help
> +	  Enable support for the gst-debug tracing functionality in gstreamer.
> +	  This has limited CPU overhead, but does increase the rootfs size
> +	  somewhat.
> +
> +config BR2_PACKAGE_GSTREAMER1_PLUGIN_REGISTRY
> +	bool "enable plugin registry"
> +	default y
> +	depends on BR2_PACKAGE_GSTREAMER1
> +	help
> +	  Enable support for the GStreamer plugin registry. This may increase
> +	  the launch-time for a GStreamer application.
> +
> +config BR2_PACKAGE_GSTREAMER1_INSTALL_TOOLS
> +	bool "install gst-launch gst-inspect"
> +	default y
> +	depends on BR2_PACKAGE_GSTREAMER1
> +	help
> +	  Install the gst-launch and gst-inspect tools. This will take up
> +	  additional space on the target
> +
> +comment "gstreamer requires a toolchain with WCHAR and threads support"
> +	depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS
[snip]
Peter Korsgaard - May 11, 2013, 9:31 p.m.
>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

 Arnout>  Hi Spenser,
 Arnout>  Very quick first review...

 Arnout>  First of all, a comment that is not so much directed at you but at
 Arnout> the rest of the BR developers: the naming issue.

 Arnout>  We have a tendency to make a copy of a package when there is a major
 Arnout> version change, cfr. python3 and qt5. However, in this case, I don't
 Arnout> think it's a good idea. At this time, many (most?) gstreamer
 Arnout> downstreams have already moved to 1.x. Also, no more patches will be
 Arnout> made the the 0.10 series (though distro's may still make patches). So
 Arnout> we can expect the old gstreamer stuff to die out relatively
 Arnout> quickly. But if we call the new thing gstreamer1 now, we're
 Arnout> essentially stuck with that name for all eternity.

I'm not so sure. If you look at the other recent major version upgrades
(python/qt/gtk), it seems to me like people aren't jumping on the new
version right away. I had several people asking me if qt4 would still be
available once qt5 got added.

I think the nicest thing we can do for our users is just to add the new
package next to the existing when these incompatible major version
upgrades happen, so they can chose themselves when/if they want to
upgrade. I agree that gstreamer1 perhaps isn't the nicest name, but it
isn't too bad either, and for python/qt/gtk the names are commonly used.


 Arnout>  So instead I'd try to make 0.10 or 1.0 a choice in the gstreamer
 Arnout> package itself.  For me it's fine if inside the Config.in and the .mk
 Arnout> files we basically have the two versions in a big ifeq() construct,
 Arnout> but at least we can keep on using the BR2_PACKAGE_GST* symbols.

What would the advantage be? Just that people could move from gstreamer
0.10 to 1.0 without adjusting their config?


 Arnout>  Obviously, there will be some packages that break down when
 Arnout> gstreamer 1.0 is used, but we'll have to discover that at some
 Arnout> point anyway.

Like the closed source imx stuff.
Thomas Petazzoni - May 12, 2013, 9:23 a.m.
Dear Peter Korsgaard,

On Sat, 11 May 2013 23:31:12 +0200, Peter Korsgaard wrote:

>  Arnout>  We have a tendency to make a copy of a package when there is a major
>  Arnout> version change, cfr. python3 and qt5. However, in this case, I don't
>  Arnout> think it's a good idea. At this time, many (most?) gstreamer
>  Arnout> downstreams have already moved to 1.x. Also, no more patches will be
>  Arnout> made the the 0.10 series (though distro's may still make patches). So
>  Arnout> we can expect the old gstreamer stuff to die out relatively
>  Arnout> quickly. But if we call the new thing gstreamer1 now, we're
>  Arnout> essentially stuck with that name for all eternity.
> 
> I'm not so sure. If you look at the other recent major version upgrades
> (python/qt/gtk), it seems to me like people aren't jumping on the new
> version right away. I had several people asking me if qt4 would still be
> available once qt5 got added.

I agree. I recently had a customer using Buildroot, with a fairly
important stack of custom/proprietary software written on top of
gstreamer 0.10. Having the possibility to continue to use gstreamer
0.10 is very important to allow such users to migrate to newer
Buildroot versions. The migration to gstreamer 1.x will not happen
overnight for such users who have a large body of software written
against gstreamer 0.10.

Similarly for Qt4 vs. Qt5, as Peter mentioned.

> I think the nicest thing we can do for our users is just to add the new
> package next to the existing when these incompatible major version
> upgrades happen, so they can chose themselves when/if they want to
> upgrade. I agree that gstreamer1 perhaps isn't the nicest name, but it
> isn't too bad either, and for python/qt/gtk the names are commonly used.

Right. Ideally, we would have preferred to have 'gstreamer' be the
latest available version, and 'gstreamer0.10' be the name for the old
packages. But that doesn't work, because we can't predict the future.

We had the same for Gtk. In the past we had package/libgtk and
package/libgtk2, and now package/libgtk is gone. And presumably, we'll
gain package/libgtk3 in the future.

>  Arnout>  Obviously, there will be some packages that break down when
>  Arnout> gstreamer 1.0 is used, but we'll have to discover that at some
>  Arnout> point anyway.
> 
> Like the closed source imx stuff.

Hum, not sure to get your point here, though.

Best regards,

Thomas
Peter Korsgaard - May 12, 2013, 11:13 a.m.
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 Arnout> Obviously, there will be some packages that break down when
 Arnout> gstreamer 1.0 is used, but we'll have to discover that at some
 Arnout> point anyway.

 >> Like the closed source imx stuff.

 Thomas> Hum, not sure to get your point here, though.

Well, it was late when I wrote this ;) I just meant packages like
gst-fsl-plugins probably won't work with gstreamer 1.x
Thomas Petazzoni - May 12, 2013, 11:36 a.m.
Dear Peter Korsgaard,

On Sun, 12 May 2013 13:13:22 +0200, Peter Korsgaard wrote:

>  Arnout> Obviously, there will be some packages that break down when
>  Arnout> gstreamer 1.0 is used, but we'll have to discover that at some
>  Arnout> point anyway.
> 
>  >> Like the closed source imx stuff.
> 
>  Thomas> Hum, not sure to get your point here, though.
> 
> Well, it was late when I wrote this ;) I just meant packages like
> gst-fsl-plugins probably won't work with gstreamer 1.x

Ah, yes, indeed. Makes sense now :)

Thomas
Arnout Vandecappelle - May 12, 2013, 5:16 p.m.
On 12/05/13 11:23, Thomas Petazzoni wrote:
> On Sat, 11 May 2013 23:31:12 +0200, Peter Korsgaard wrote:
>
>> >  Arnout>  We have a tendency to make a copy of a package when there is a major
>> >  Arnout> version change, cfr. python3 and qt5. However, in this case, I don't
>> >  Arnout> think it's a good idea. At this time, many (most?) gstreamer
>> >  Arnout> downstreams have already moved to 1.x. Also, no more patches will be
>> >  Arnout> made the the 0.10 series (though distro's may still make patches). So
>> >  Arnout> we can expect the old gstreamer stuff to die out relatively
>> >  Arnout> quickly. But if we call the new thing gstreamer1 now, we're
>> >  Arnout> essentially stuck with that name for all eternity.
>> >
>> >I'm not so sure. If you look at the other recent major version upgrades
>> >(python/qt/gtk), it seems to me like people aren't jumping on the new
>> >version right away. I had several people asking me if qt4 would still be
>> >available once qt5 got added.
> I agree. I recently had a customer using Buildroot, with a fairly
> important stack of custom/proprietary software written on top of
> gstreamer 0.10. Having the possibility to continue to use gstreamer
> 0.10 is very important to allow such users to migrate to newer
> Buildroot versions. The migration to gstreamer 1.x will not happen
> overnight for such users who have a large body of software written
> against gstreamer 0.10.
>
> Similarly for Qt4 vs. Qt5, as Peter mentioned.

  Fair enough. I guess Peter's right, having the 1 in the name doesn't hurt.

  Regards,
  Arnout
Spenser Gilliland - May 13, 2013, 5:43 p.m.
On Fri, May 10, 2013 at 6:38 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
>  Hi Spenser,
>
>  Very quick first review...
>
>  First of all, a comment that is not so much directed at you but at the rest
> of the BR developers: the naming issue.
>
>  We have a tendency to make a copy of a package when there is a major
> version change, cfr. python3 and qt5. However, in this case, I don't think
> it's a good idea. At this time, many (most?) gstreamer downstreams have
> already moved to 1.x. Also, no more patches will be made the the 0.10 series
> (though distro's may still make patches). So we can expect the old gstreamer
> stuff to die out relatively quickly. But if we call the new thing gstreamer1
> now, we're essentially stuck with that name for all eternity.
>
>  So instead I'd try to make 0.10 or 1.0 a choice in the gstreamer package
> itself.  For me it's fine if inside the Config.in and the .mk files we
> basically have the two versions in a big ifeq() construct, but at least we
> can keep on using the BR2_PACKAGE_GST* symbols.
>
>  Obviously, there will be some packages that break down when gstreamer 1.0
> is used, but we'll have to discover that at some point anyway.
>

Per discussion will leave as gstreamer1.

>  We nowadays prefer to put sub-options inside an if...endif construct
> instead of with 'depends on'.

Will fix.

Please continue to review these patches and let me know of any
additional issues.

Regards,
Spenser

--
Spenser Gilliland
Computer Engineer
Doctoral Candidate

Patch

diff --git a/package/multimedia/Config.in b/package/multimedia/Config.in
index 931e6d3..f6a5fd7 100644
--- a/package/multimedia/Config.in
+++ b/package/multimedia/Config.in
@@ -6,6 +6,7 @@  source "package/multimedia/faad2/Config.in"
 source "package/multimedia/flac/Config.in"
 source "package/multimedia/ffmpeg/Config.in"
 source "package/multimedia/gstreamer/Config.in"
+source "package/multimedia/gstreamer1/Config.in"
 source "package/multimedia/gst-ffmpeg/Config.in"
 source "package/multimedia/gst-dsp/Config.in"
 source "package/multimedia/gst-fsl-plugins/Config.in"
diff --git a/package/multimedia/gstreamer1/Config.in b/package/multimedia/gstreamer1/Config.in
new file mode 100644
index 0000000..b1fd8b1
--- /dev/null
+++ b/package/multimedia/gstreamer1/Config.in
@@ -0,0 +1,37 @@ 
+config BR2_PACKAGE_GSTREAMER1
+	bool "gstreamer1"
+	depends on BR2_USE_WCHAR # glib2
+	depends on BR2_TOOLCHAIN_HAS_THREADS
+	select BR2_PACKAGE_LIBGLIB2
+	help
+	  GStreamer is an open source multimedia framework.
+
+	  http://gstreamer.freedesktop.org/
+
+config BR2_PACKAGE_GSTREAMER1_GST_DEBUG
+	bool "enable gst-debug trace support"
+	default y
+	depends on BR2_PACKAGE_GSTREAMER1
+	help
+	  Enable support for the gst-debug tracing functionality in gstreamer.
+	  This has limited CPU overhead, but does increase the rootfs size
+	  somewhat.
+
+config BR2_PACKAGE_GSTREAMER1_PLUGIN_REGISTRY
+	bool "enable plugin registry"
+	default y
+	depends on BR2_PACKAGE_GSTREAMER1
+	help
+	  Enable support for the GStreamer plugin registry. This may increase
+	  the launch-time for a GStreamer application.
+
+config BR2_PACKAGE_GSTREAMER1_INSTALL_TOOLS
+	bool "install gst-launch gst-inspect"
+	default y
+	depends on BR2_PACKAGE_GSTREAMER1
+	help
+	  Install the gst-launch and gst-inspect tools. This will take up
+	  additional space on the target
+
+comment "gstreamer requires a toolchain with WCHAR and threads support"
+	depends on !BR2_USE_WCHAR || !BR2_TOOLCHAIN_HAS_THREADS
diff --git a/package/multimedia/gstreamer1/gstreamer1.mk b/package/multimedia/gstreamer1/gstreamer1.mk
new file mode 100644
index 0000000..7abdc09
--- /dev/null
+++ b/package/multimedia/gstreamer1/gstreamer1.mk
@@ -0,0 +1,36 @@ 
+#############################################################
+#
+# gstreamer1
+#
+#############################################################
+
+GSTREAMER1_VERSION = 1.0.7
+GSTREAMER1_SOURCE = gstreamer-$(GSTREAMER1_VERSION).tar.xz
+GSTREAMER1_SITE = http://gstreamer.freedesktop.org/src/gstreamer
+GSTREAMER1_INSTALL_STAGING = YES
+
+# Checking if unaligned memory access works correctly cannot be done when cross
+# compiling. For the following architectures there is no information available
+# in the configure script.
+ifeq ($(BR2_avr32),y)
+GSTREAMER1_CONF_ENV = as_cv_unaligned_access=no
+endif
+ifeq ($(BR2_aarch64),y)
+GSTREAMER1_CONF_ENV = as_cv_unaligned_access=yes
+endif
+
+GSTREAMER1_CONF_OPT = \
+		--disable-examples \
+		--disable-tests \
+		--disable-failing-tests \
+		--disable-debug \
+		--disable-valgrind \
+		--disable-benchmarks \
+		--disable-check \
+		$(if $(BR2_PACKAGE_GSTREAMER1_GST_DEBUG),,--disable-gst-debug) \
+		$(if $(BR2_PACKAGE_GSTREAMER1_PLUGIN_REGISTRY),,--disable-registry) \
+		$(if $(BR2_PACKAGE_GSTREAMER1_INSTALL_TOOLS),,--disable-tools) \
+
+GSTREAMER1_DEPENDENCIES = libglib2 host-pkgconf host-bison host-flex
+
+$(eval $(autotools-package))