buildroot/package/gstreamer, branch 2015.11.1

gst-plugins-ugly: add legal info

2015-11-26T21:39:26+00:00

Even though COPYING is LGPLv2.1+ many code files state v2+ Signed-off-by: Gustavo Zacarias Acked-by: Arnout Vandecappelle (Essensium/Mind) Signed-off-by: Peter Korsgaard

gst-plugins-bad: add legal info

2015-11-26T21:39:09+00:00

Even though COPYING.LIB is LGPLv2+ many code files state v2.1+ Signed-off-by: Gustavo Zacarias Acked-by: Arnout Vandecappelle (Essensium/Mind) Signed-off-by: Peter Korsgaard

gst-plugins-good: add legal info

2015-11-26T21:39:06+00:00

Signed-off-by: Gustavo Zacarias Acked-by: Arnout Vandecappelle (Essensium/Mind) Signed-off-by: Peter Korsgaard

gst-plugins-base: add legal info

2015-11-26T21:38:34+00:00

Signed-off-by: Gustavo Zacarias Acked-by: Arnout Vandecappelle (Essensium/Mind) Signed-off-by: Peter Korsgaard

gstreamer: add legal info

2015-11-26T21:38:14+00:00

Even though COPYING is LGPLv2+ many code files state v2.1+ Signed-off-by: Gustavo Zacarias Reviewed-by: Arnout Vandecappelle (Essensium/Mind) Acked-by: Arnout Vandecappelle (Essensium/Mind) Signed-off-by: Peter Korsgaard

gstreamer: can optionally use libxml2

2015-11-26T21:36:19+00:00

gstreamer can optionally build against libxml2, so account for it in the dependencies. Functionality seems somewhat reduced without it, an example being misdetecting subtitle (.srt) files as subrip mime type instead of subtitle itself. A failed scenario would be: $ gst-typefind-0.10 some.srt some.srt - application/x-subrip When built with libxml2: $ gst-typefind-0.10 some.srt some.srt - application/x-subtitle This doesn't affect gstreamer 1.x since it dropped any use of libxml2. Signed-off-by: Gustavo Zacarias Signed-off-by: Peter Korsgaard

gstreamer: fix unaligned detection for nios2

2015-11-24T21:46:10+00:00

Fixes: http://autobuild.buildroot.net/results/874/874c4da3ca7d27551f580994e016bcbd3597a107/ http://autobuild.buildroot.net/results/f8b/f8ba30408b5ce15022792e823a0c8fd3a004fb31/ http://autobuild.buildroot.net/results/bf2/bf2f374357ed7a36f072d89ed0687c942eb1ee6d/ http://autobuild.buildroot.net/results/14a/14aaac32b92939957a9f39ac2ba8a949f9ddd22a/ Similar to how we do it for arc/xtensa/microblaze. Signed-off-by: Peter Korsgaard

gst-fsl-plugins: bump version to 4.0.3

2015-09-19T13:39:39+00:00

Also added the package hash file. This patch is based on the Yocto equivalent: https://github.com/Freescale/meta-fsl-arm/commit/0d2f4f8 This package has been tested using the following commands: # gst-launch-0.10 playbin uri=file:///root/tears_of_steel_1080p.webm # gst-launch-0.10 filesrc location=/root/tears_of_steel_1080p.webm ! \ matroskademux ! vpudec ! autovideosink # gst-launch-0.10 filesrc location=/root/tears_of_steel_1080p.webm ! \ matroskademux ! vpudec ! mfw_isink # gst-launch-0.10 imxv4l2src ! autovideosink Signed-off-by: Gary Bisson Signed-off-by: Thomas Petazzoni

gst-plugins-bad: depend on directfb instead of selecting it for directfb plugin

2015-09-14T19:36:51+00:00

As discussed here: http://lists.busybox.net/pipermail/buildroot/2015-September/139213.html It makes more sense to use 'depends on' (and default to y) for a big dependency like directfb. Signed-off-by: Peter Korsgaard

directfb: mark as available only for gcc >= 4.5

2015-09-10T11:47:00+00:00

The new DirectFB version does not build with gcc 4.3 from the Blackfin toolchain. One of the reason is that va_copy has some issues, which were fixed in gcc 4.4.0 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36799). There are also some other issues, which were fixed by a patch proposed by Peter Seiderer at http://lists.busybox.net/pipermail/buildroot/2015-February/120281.html. However, it probably doesn't make a lot of sense to carry patches that are not upstream for such old compilers. Instead, this commit takes the action of making DirectFB available only on toolchains using gcc >= 4.5, which was tested with the Arago toolchain. gcc 4.4 could potentially work, but wasn't tested (it is no longer supported by the internal toolchain backend, and we don't have any toolchain based on gcc 4.4), so we take the safe decision of requiring at least gcc 4.5. [Peter: add comment explaining toolchain dependenc as suggested by Vincente] Signed-off-by: Thomas Petazzoni Reviewed-by: Vicente Olivert Riera Signed-off-by: Peter Korsgaard