GStreamer 0.10's future

GStreamer 0.10's future

[Burton, Ross]

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?

Ross

Re: GStreamer 0.10's future

[Koen Kooi]

Op 8 mei 2014, om 16:48 heeft Burton, Ross <ross.burton@intel.com> het volgende geschreven:

> 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?  

A plus one from me.

> Should I expect any hate mail over this?

This is the internet, of course you'll get hate mail :/

Re: 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

Re: GStreamer 0.10's future

[Burton, Ross]

On 8 May 2014 16:07, Paul Eggleton <paul.eggleton@linux.intel.com> 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

Re: GStreamer 0.10's future

[Tim Orling]

> On May 8, 2014, at 8:07 AM, Paul Eggleton <paul.eggleton@linux.intel.com> 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@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [yocto] GStreamer 0.10's future

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2687 bytes --]

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@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [yocto] GStreamer 0.10's future

[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

Re: [yocto] GStreamer 0.10's future

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 3589 bytes --]

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@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [yocto] GStreamer 0.10's future

[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

Re: [yocto] GStreamer 0.10's future

[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

Re: GStreamer 0.10's future

[Carlos Rafael Giani]

On 2014-05-08 16:48, 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?
>
> Ross

I suppose it wouldn't be possible to rename the recipes as well? It 
would be cleaner to have them adopt the GStreamer 1.0 recipe naming 
convention. So, for example, no more gst-plugins-bad_1.0.23.bb , but 
gstreamer0.10-plugins-bad_1.0.23.bb for example.

I guess that this would break compatibility with some existing layers 
that still use 0.10.

Re: GStreamer 0.10's future

[Burton, Ross]

On 8 May 2014 16:11, Carlos Rafael Giani <dv@pseudoterminal.org> wrote:
> I suppose it wouldn't be possible to rename the recipes as well? It would be
> cleaner to have them adopt the GStreamer 1.0 recipe naming convention. So,
> for example, no more gst-plugins-bad_1.0.23.bb , but
> gstreamer0.10-plugins-bad_1.0.23.bb for example.
>
> I guess that this would break compatibility with some existing layers that
> still use 0.10.

If the 0.10 recipes had a future that would be sensible, but I
wouldn't be surprised to see them deleted from meta-multimedia's
master branch in a year's time so this would be needless change.

Ross

Re: GStreamer 0.10's future

[Burton, Ross]

On 8 May 2014 15:48, Burton, Ross <ross.burton@intel.com> wrote:
> 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.

So the catch here is that Qt4 currently depends on GStreamer 0.10.

Can someone who doesn't come out in a rash when looking at C++ code
spend two minutes to tell if me Qt4 supports GStreamer 1.0 (unlikely)
and whether we can make GStreamer 0.10 support a build-time
configuration and simply disable it in oe-core.

Ross

Re: [yocto] [oe] GStreamer 0.10's future

[Burton, Ross]

On 9 May 2014 16:19, Neuer User <auslands-kv@gmx.de> wrote:
>> So the catch here is that Qt4 currently depends on GStreamer 0.10.
>>
> Yes, it does, as long as you need QtMultimedia. Same applies to Qt5.
> There was a discussion on the Qt mailing list about moving to
> gstreamer1.0, but this seems to be rather some time in the future was my
> impression.

Oh, even Qt5 needs 0.10?  That's disappointing.

Ross

Re: [yocto] [oe] GStreamer 0.10's future

[Burton, Ross]

On 9 May 2014 16:19, Neuer User <auslands-kv@gmx.de> wrote:
> Yes, it does, as long as you need QtMultimedia. Same applies to Qt5.
> There was a discussion on the Qt mailing list about moving to
> gstreamer1.0, but this seems to be rather some time in the future was my
> impression.

So Qt 5.3 won't have GStreamer 1.0 support.  The port is being done in
a branch so it's possible that it will land in Qt 5.4, which is due to
be released in the September/October timeframe.

One option would be to move GStreamer 0.10 into another layer, give
Qt4/Qt5 disabled-by-default GStreamer 0.10 options and hope that by
the time Yocto 1.7 is released, Qt5.4 with GStreamer 1.0 is also
released.  Even as someone who's rather keen on removing cruft from
oe-core that's a bit too eager for my liking.

Revised plan unless anyone has a better idea: in 1.7 we'll move
everything possible away from GStreamer 0.10 but keep 0.10 around
until the 1.8 cycle, and then revisit the Qt situation.

Ross

Re: GStreamer 0.10's future

[Khem Raj]

On Thu, May 8, 2014 at 7:48 AM, Burton, Ross <ross.burton@intel.com> wrote:
> 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?

I think we still have QT versions which has not yet removed the
support. but as long as its in
some layer I am good with it.