[OE-core] GStreamer 0.10's future


Paul Eggleton
 

On Thursday 08 May 2014 15:48:40 Burton, Ross wrote:
Hi all,

Sorry for the cross-post but I want this to have a wide audience.

For the 1.7 release I want to move GStreamer 0.10 from oe-core into
meta-multimedia, and ensure everything in oe-core has ported to
GStreamer 1.x. GStreamer 0.10 is considered dead upstream and is
unmaintained so we don't need to be shipping both versions anymore.

Everyone in agreement? Should I expect any hate mail over this?
+1

The next question is does that mean for the "old" libav (which gst-ffmpeg
depends upon), do we move that as well or drop it?

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre


Burton, Ross <ross.burton@...>
 

On 8 May 2014 16:07, Paul Eggleton <paul.eggleton@...> wrote:
The next question is does that mean for the "old" libav (which gst-ffmpeg
depends upon), do we move that as well or drop it?
If gst-ffmpeg is the sole consumer, then certainly yes.

Ross


Tim Orling
 

On May 8, 2014, at 8:07 AM, Paul Eggleton <paul.eggleton@...> wrote:

On Thursday 08 May 2014 15:48:40 Burton, Ross wrote:
Hi all,

Sorry for the cross-post but I want this to have a wide audience.

For the 1.7 release I want to move GStreamer 0.10 from oe-core into
meta-multimedia, and ensure everything in oe-core has ported to
GStreamer 1.x. GStreamer 0.10 is considered dead upstream and is
unmaintained so we don't need to be shipping both versions anymore.

Everyone in agreement? Should I expect any hate mail over this?
+1
+1 as well
The next question is does that mean for the "old" libav (which gst-ffmpeg
depends upon), do we move that as well or drop it?
If xbmc is ever going to work, it will need to be updated to build ffmpeg internally. Unless we can get upstream to improve things.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@...
http://lists.openembedded.org/mailman/listinfo/openembedded-core


Martin Jansa
 

On Thu, May 08, 2014 at 04:07:19PM +0100, Paul Eggleton wrote:
On Thursday 08 May 2014 15:48:40 Burton, Ross wrote:
Hi all,

Sorry for the cross-post but I want this to have a wide audience.

For the 1.7 release I want to move GStreamer 0.10 from oe-core into
meta-multimedia, and ensure everything in oe-core has ported to
GStreamer 1.x. GStreamer 0.10 is considered dead upstream and is
unmaintained so we don't need to be shipping both versions anymore.

Everyone in agreement? Should I expect any hate mail over this?
+1

The next question is does that mean for the "old" libav (which gst-ffmpeg
depends upon), do we move that as well or drop it?
libav was migrated to oe-core quite recently and there is couple of
recipes in meta-oe, meta-webserver depending on it/ffmpeg so moving to
meta-multimedia wouldn't be very easy.

meta-multimedia/recipes-multimedia/sox/sox_14.4.0.bb:DEPENDS = "libpng libav libsndfile1"
meta-multimedia/recipes-mediacentre/xbmc/xbmc_git.bb:DEPENDS = "libusb1 libcec libplist expat yajl gperf-native libxmu fribidi mpeg2dec ffmpeg samba fontconfig curl python libass libmodplug libmicrohttpd wavpack libmms cmake-native libsdl-image libsdl-mixer virtual/egl mysql5 sqlite3 libmms faad2 libcdio libpcre boost lzo enca avahi libsamplerate0 libxinerama libxrandr libxtst bzip2 virtual/libsdl jasper zip-native zlib libtinyxml libmad"
meta-multimedia/recipes-multimedia/musicpd/mpd_0.18.9.bb:DEPENDS = "alsa-lib libsamplerate0 libsndfile1 libvorbis libogg faad2 ffmpeg curl sqlite bzip2 pulseaudio"
meta-multimedia/recipes-multimedia/vlc/vlc.inc: faad2 ffmpeg flac libxpm libxinerama fluidsynth alsa-lib libdvdcss \

meta-oe/recipes-multimedia/nonworking/minidlna/minidlna_1.0.25.bb:DEPENDS = "flac libav jpeg sqlite3 libexif libogg libid3tag"
meta-oe/recipes-support/opencv/opencv_2.4.bb:PACKAGECONFIG ??= "eigen gtk jpeg libav png tiff v4l"
meta-oe/recipes-graphics/gegl/gegl_0.2.0.bb:PACKAGECONFIG[avformat] = "--with-libavformat,--without-libavformat,libav"
meta-oe/recipes-multimedia/libpostproc/libpostproc_git.bb:DEPENDS = "libav"
meta-oe/recipes-multimedia/mplayer/mplayer2_git.bb:DEPENDS = "libvpx libdvdread libtheora virtual/libsdl ffmpeg xsp zlib \

meta-webserver/recipes-httpd/cherokee/cherokee_1.2.98.bb:PACKAGECONFIG[ffmpeg] = "--with-ffmpeg,--without-ffmpeg,libav"

But I would like to see migration to libav-9 which currently has negative D_P
(mplayer2 already depends on 9*, but there are few recipes which fails with
libav-9 too - see earlier world builds for list).

Regards,

--
Martin 'JaMa' Jansa jabber: Martin.Jansa@...


Paul Eggleton
 

On Thursday 08 May 2014 18:19:08 Martin Jansa wrote:
On Thu, May 08, 2014 at 04:07:19PM +0100, Paul Eggleton wrote:
On Thursday 08 May 2014 15:48:40 Burton, Ross wrote:
Hi all,

Sorry for the cross-post but I want this to have a wide audience.

For the 1.7 release I want to move GStreamer 0.10 from oe-core into
meta-multimedia, and ensure everything in oe-core has ported to
GStreamer 1.x. GStreamer 0.10 is considered dead upstream and is
unmaintained so we don't need to be shipping both versions anymore.

Everyone in agreement? Should I expect any hate mail over this?
+1

The next question is does that mean for the "old" libav (which gst-ffmpeg
depends upon), do we move that as well or drop it?
libav was migrated to oe-core quite recently and there is couple of
recipes in meta-oe, meta-webserver depending on it/ffmpeg so moving to
meta-multimedia wouldn't be very easy.

meta-multimedia/recipes-multimedia/sox/sox_14.4.0.bb:DEPENDS = "libpng libav
libsndfile1" meta-multimedia/recipes-mediacentre/xbmc/xbmc_git.bb:DEPENDS =
"libusb1 libcec libplist expat yajl gperf-native libxmu fribidi mpeg2dec
ffmpeg samba fontconfig curl python libass libmodplug libmicrohttpd wavpack
libmms cmake-native libsdl-image libsdl-mixer virtual/egl mysql5 sqlite3
libmms faad2 libcdio libpcre boost lzo enca avahi libsamplerate0
libxinerama libxrandr libxtst bzip2 virtual/libsdl jasper zip-native zlib
libtinyxml libmad"
meta-multimedia/recipes-multimedia/musicpd/mpd_0.18.9.bb:DEPENDS =
"alsa-lib libsamplerate0 libsndfile1 libvorbis libogg faad2 ffmpeg curl
sqlite bzip2 pulseaudio" meta-multimedia/recipes-multimedia/vlc/vlc.inc:
faad2 ffmpeg flac libxpm libxinerama fluidsynth alsa-lib libdvdcss \

meta-oe/recipes-multimedia/nonworking/minidlna/minidlna_1.0.25.bb:DEPENDS =
"flac libav jpeg sqlite3 libexif libogg libid3tag"
meta-oe/recipes-support/opencv/opencv_2.4.bb:PACKAGECONFIG ??= "eigen gtk
jpeg libav png tiff v4l"
meta-oe/recipes-graphics/gegl/gegl_0.2.0.bb:PACKAGECONFIG[avformat] =
"--with-libavformat,--without-libavformat,libav"
meta-oe/recipes-multimedia/libpostproc/libpostproc_git.bb:DEPENDS = "libav"
meta-oe/recipes-multimedia/mplayer/mplayer2_git.bb:DEPENDS = "libvpx
libdvdread libtheora virtual/libsdl ffmpeg xsp zlib \

meta-webserver/recipes-httpd/cherokee/cherokee_1.2.98.bb:PACKAGECONFIG[ffmpe
g] = "--with-ffmpeg,--without-ffmpeg,libav"

But I would like to see migration to libav-9 which currently has negative
D_P (mplayer2 already depends on 9*, but there are few recipes which fails
with libav-9 too - see earlier world builds for list).
Yes, I'm just talking about libav 0.8 here - libav 9 would remain where it is.
That might still be problematic though given that their PN is the same. I'm
open to better suggestions, but I think we have to do *something* here.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre


Martin Jansa
 

On Thu, May 08, 2014 at 05:57:54PM +0100, Paul Eggleton wrote:
On Thursday 08 May 2014 18:19:08 Martin Jansa wrote:
On Thu, May 08, 2014 at 04:07:19PM +0100, Paul Eggleton wrote:
On Thursday 08 May 2014 15:48:40 Burton, Ross wrote:
Hi all,

Sorry for the cross-post but I want this to have a wide audience.

For the 1.7 release I want to move GStreamer 0.10 from oe-core into
meta-multimedia, and ensure everything in oe-core has ported to
GStreamer 1.x. GStreamer 0.10 is considered dead upstream and is
unmaintained so we don't need to be shipping both versions anymore.

Everyone in agreement? Should I expect any hate mail over this?
+1

The next question is does that mean for the "old" libav (which gst-ffmpeg
depends upon), do we move that as well or drop it?
libav was migrated to oe-core quite recently and there is couple of
recipes in meta-oe, meta-webserver depending on it/ffmpeg so moving to
meta-multimedia wouldn't be very easy.

meta-multimedia/recipes-multimedia/sox/sox_14.4.0.bb:DEPENDS = "libpng libav
libsndfile1" meta-multimedia/recipes-mediacentre/xbmc/xbmc_git.bb:DEPENDS =
"libusb1 libcec libplist expat yajl gperf-native libxmu fribidi mpeg2dec
ffmpeg samba fontconfig curl python libass libmodplug libmicrohttpd wavpack
libmms cmake-native libsdl-image libsdl-mixer virtual/egl mysql5 sqlite3
libmms faad2 libcdio libpcre boost lzo enca avahi libsamplerate0
libxinerama libxrandr libxtst bzip2 virtual/libsdl jasper zip-native zlib
libtinyxml libmad"
meta-multimedia/recipes-multimedia/musicpd/mpd_0.18.9.bb:DEPENDS =
"alsa-lib libsamplerate0 libsndfile1 libvorbis libogg faad2 ffmpeg curl
sqlite bzip2 pulseaudio" meta-multimedia/recipes-multimedia/vlc/vlc.inc:
faad2 ffmpeg flac libxpm libxinerama fluidsynth alsa-lib libdvdcss \

meta-oe/recipes-multimedia/nonworking/minidlna/minidlna_1.0.25.bb:DEPENDS =
"flac libav jpeg sqlite3 libexif libogg libid3tag"
meta-oe/recipes-support/opencv/opencv_2.4.bb:PACKAGECONFIG ??= "eigen gtk
jpeg libav png tiff v4l"
meta-oe/recipes-graphics/gegl/gegl_0.2.0.bb:PACKAGECONFIG[avformat] =
"--with-libavformat,--without-libavformat,libav"
meta-oe/recipes-multimedia/libpostproc/libpostproc_git.bb:DEPENDS = "libav"
meta-oe/recipes-multimedia/mplayer/mplayer2_git.bb:DEPENDS = "libvpx
libdvdread libtheora virtual/libsdl ffmpeg xsp zlib \

meta-webserver/recipes-httpd/cherokee/cherokee_1.2.98.bb:PACKAGECONFIG[ffmpe
g] = "--with-ffmpeg,--without-ffmpeg,libav"

But I would like to see migration to libav-9 which currently has negative
D_P (mplayer2 already depends on 9*, but there are few recipes which fails
with libav-9 too - see earlier world builds for list).
Yes, I'm just talking about libav 0.8 here - libav 9 would remain where it is.
That might still be problematic though given that their PN is the same. I'm
open to better suggestions, but I think we have to do *something* here.
Ah ok, I though you meant both versions.

Then I would rather drop 0.8 completely, otherwise it will be preferred
even with negative D_P from meta-multimedia (YOCTO #2964) and we cannot
expect people which happen to have meta-multimedia layer to know that
they are expected to update P_V everytime libav is updated in oe-core.

--
Martin 'JaMa' Jansa jabber: Martin.Jansa@...


Paul Eggleton
 

On Thursday 08 May 2014 19:21:44 Martin Jansa wrote:
On Thu, May 08, 2014 at 05:57:54PM +0100, Paul Eggleton wrote:
On Thursday 08 May 2014 18:19:08 Martin Jansa wrote:
On Thu, May 08, 2014 at 04:07:19PM +0100, Paul Eggleton wrote:
On Thursday 08 May 2014 15:48:40 Burton, Ross wrote:
Hi all,

Sorry for the cross-post but I want this to have a wide audience.

For the 1.7 release I want to move GStreamer 0.10 from oe-core into
meta-multimedia, and ensure everything in oe-core has ported to
GStreamer 1.x. GStreamer 0.10 is considered dead upstream and is
unmaintained so we don't need to be shipping both versions anymore.

Everyone in agreement? Should I expect any hate mail over this?
+1

The next question is does that mean for the "old" libav (which
gst-ffmpeg
depends upon), do we move that as well or drop it?
libav was migrated to oe-core quite recently and there is couple of
recipes in meta-oe, meta-webserver depending on it/ffmpeg so moving to
meta-multimedia wouldn't be very easy.

meta-multimedia/recipes-multimedia/sox/sox_14.4.0.bb:DEPENDS = "libpng
libav libsndfile1"
meta-multimedia/recipes-mediacentre/xbmc/xbmc_git.bb:DEPENDS = "libusb1
libcec libplist expat yajl gperf-native libxmu fribidi mpeg2dec ffmpeg
samba fontconfig curl python libass libmodplug libmicrohttpd wavpack
libmms cmake-native libsdl-image libsdl-mixer virtual/egl mysql5
sqlite3 libmms faad2 libcdio libpcre boost lzo enca avahi
libsamplerate0
libxinerama libxrandr libxtst bzip2 virtual/libsdl jasper zip-native
zlib
libtinyxml libmad"
meta-multimedia/recipes-multimedia/musicpd/mpd_0.18.9.bb:DEPENDS =
"alsa-lib libsamplerate0 libsndfile1 libvorbis libogg faad2 ffmpeg curl
sqlite bzip2 pulseaudio" meta-multimedia/recipes-multimedia/vlc/vlc.inc:
faad2 ffmpeg flac libxpm libxinerama fluidsynth alsa-lib libdvdcss \

meta-oe/recipes-multimedia/nonworking/minidlna/minidlna_1.0.25.bb:DEPEND
S =
"flac libav jpeg sqlite3 libexif libogg libid3tag"
meta-oe/recipes-support/opencv/opencv_2.4.bb:PACKAGECONFIG ??= "eigen
gtk
jpeg libav png tiff v4l"
meta-oe/recipes-graphics/gegl/gegl_0.2.0.bb:PACKAGECONFIG[avformat] =
"--with-libavformat,--without-libavformat,libav"
meta-oe/recipes-multimedia/libpostproc/libpostproc_git.bb:DEPENDS =
"libav"
meta-oe/recipes-multimedia/mplayer/mplayer2_git.bb:DEPENDS = "libvpx
libdvdread libtheora virtual/libsdl ffmpeg xsp zlib \

meta-webserver/recipes-httpd/cherokee/cherokee_1.2.98.bb:PACKAGECONFIG[f
fmpe g] = "--with-ffmpeg,--without-ffmpeg,libav"

But I would like to see migration to libav-9 which currently has
negative
D_P (mplayer2 already depends on 9*, but there are few recipes which
fails
with libav-9 too - see earlier world builds for list).
Yes, I'm just talking about libav 0.8 here - libav 9 would remain where it
is. That might still be problematic though given that their PN is the
same. I'm open to better suggestions, but I think we have to do
*something* here.
Ah ok, I though you meant both versions.

Then I would rather drop 0.8 completely, otherwise it will be preferred
even with negative D_P from meta-multimedia (YOCTO #2964) and we cannot
expect people which happen to have meta-multimedia layer to know that
they are expected to update P_V everytime libav is updated in oe-core.
Hmm. Perhaps a less intrusive solution then would be to create a completely
separate meta-gstreamer0.10 layer for those that still really need it rather
than putting it in meta-multimedia?

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre


Richard Purdie
 

On Thu, 2014-05-08 at 17:57 +0100, Paul Eggleton wrote:
Yes, I'm just talking about libav 0.8 here - libav 9 would remain where it is.
That might still be problematic though given that their PN is the same. I'm
open to better suggestions, but I think we have to do *something* here.
We could put a PROVIDES += "xxx" into one of the libavs and then DEPENDS
on that in the corresponding recipes...

Cheers,

Richard