gst-ffmpeg & decodebin

Hi,

Background: I am trying to get the new Qt/KDE Phonon library working on Qtopia
Core (Qt/Embedded). Linux/Qtopia Core uses the GStreamer backend for Phonon -
specifically the decodebin element.

I'm having problems getting decodebin (& playbin) to detect & use the ffmpeg
elements. E.g.

The following works fine:
gst-launch filesrc location=01_Neighborhood_1_Tunnels_.mp3  ! ffdemux_mp3 !
ffdec_mp3 ! alsasink

However, using decodebin I get:

$ gst-launch-0.10 filesrc location=01_Neighborhood_1_Tunnels_.mp3 !
decodebin ! audioconvert ! alsasink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /pipeline0/decodebin0: A ID3 tag demuxer plugin is
required to play this stream, but not installed.
Additional debug info:
gstdecodebin.c(792): close_pad_link (): /pipeline0/decodebin0:
No decoder to handle media type 'application/x-id3'
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
FREEING pipeline ...

I also have gst-plugin-ogg & gst-plugin-vorbis installed. When I use decodebin
with an ogg/vorbis file, it works fine:

$ gst-launch-0.10 filesrc location=Hydrate-Kenny_Beltrey.ogg ! decodebin !
audioconvert ! alsasink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstAudioSinkClock


I've checked my ~/.gstreamer-0.10/registry.x86_64.xml and found the following:
--snip--
 <feature typename="GstElementFactory">
  <name>ffdemux_mp3</name>
  <longname>FFMPEG MPEG audio demuxer</longname>
  <class>Codec/Demuxer</class>
  <description>FFMPEG MPEG audio demuxer</description>
  <author>Wim Taymans &lt;[hidden email]&gt;, Ronald Bultje
&lt;[hidden email]&gt;, Edward Hervey
&lt;[hidden email]&gt;</author>
  <padtemplate>
   <nametemplate>video_%02d</nametemplate>
   <direction>src</direction>
   <presence>sometimes</presence>
   <caps>ANY</caps>
  </padtemplate>
  <padtemplate>
   <nametemplate>audio_%02d</nametemplate>
   <direction>src</direction>
   <presence>sometimes</presence>
   <caps>ANY</caps>
  </padtemplate>
  <padtemplate>
   <nametemplate>sink</nametemplate>
   <direction>sink</direction>
   <presence>always</presence>
   <caps>application/x-id3</caps>
  </padtemplate>
 </feature>
...
 <feature typename="GstTypeFindFactory">
  <name>application/x-id3v1</name>
  <rank>257</rank>
  <caps>application/x-id3</caps>
  <extension>mp3</extension>
  <extension>mp2</extension>
  <extension>mp1</extension>
  <extension>mpga</extension>
  <extension>ogg</extension>
  <extension>flac</extension>
  <extension>tta</extension>
 </feature>
--snip--

So does this mean ffmpeg has registered an element for application/x-id3?

I have tried this on ARM (OpenEmbedded), amd64 (Gentoo - my main devel PC) &
x86 (Kubuntu). I have searched the mailing list archives and found someone
else posting what I beleive is the same problem on 2007-01-05 in
thread "using fffmpeg demuxers in playbin". I assume the problem is somewhere
in the gst-ffmpeg code, where it registers the various elements (as hinted at
in "using fffmpeg demuxers in playbin").

Questions:
1) Has this already been fixed? I'm using gst-ffmpeg 10.3.
2) If not, is it worth debuging this & sending in a patch? Would it ever be
accepted? I smell patent politics with this bug. Specifically, gstreamer
should prefer a patent-free plugin over a plugin which has a merky patent
status.
3) If it's worth me looking into this, any recomendations where to start
looking? (I looked at my first gst source file today :-) )



Cheers,

Tom


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Michael Smith-32]

On Wed, 2008-02-06 at 16:33 +0100, Tom Cooksey wrote:

> Hi,
>
> Background: I am trying to get the new Qt/KDE Phonon library working on Qtopia
> Core (Qt/Embedded). Linux/Qtopia Core uses the GStreamer backend for Phonon -
> specifically the decodebin element.
>
> I'm having problems getting decodebin (& playbin) to detect & use the ffmpeg
> elements. E.g.
>
> The following works fine:
> gst-launch filesrc location=01_Neighborhood_1_Tunnels_.mp3  ! ffdemux_mp3 !
> ffdec_mp3 ! alsasink
>
> However, using decodebin I get:
>
> $ gst-launch-0.10 filesrc location=01_Neighborhood_1_Tunnels_.mp3 !
> decodebin ! audioconvert ! alsasink

The key difference between these two is that decodebin will only
autoplug elements that have a non-zero rank.

ffdemux_mp3 and ffdec_mp3 have zero rank, because they don't work
properly and there are better ones available in gstreamer. So they're
there, and you can explicitly use them if you want, but we strongly
recommend against it.

gst-plugins-ugly contains a number of mp3-related plugins (including
mpegaudioparse and mad, which are probably the ones you want).

>
> Questions:
> 1) Has this already been fixed? I'm using gst-ffmpeg 10.3.

This is not a bug, as described above.

> 2) If not, is it worth debuging this & sending in a patch? Would it ever be
> accepted? I smell patent politics with this bug. Specifically, gstreamer
> should prefer a patent-free plugin over a plugin which has a merky patent
> status.

This isn't patent politics - it's simply a matter of what works. ffmpeg and
the other mp3-related plugins have exactly the same legal issues, so if you
want to use EITHER of them, you'll have to sort that out, but the ffmpeg mp3
decoder just doesn't work well enough.

Mike

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

On Wednesday 06 February 2008 15:42:04 Michael Smith wrote:

> On Wed, 2008-02-06 at 16:33 +0100, Tom Cooksey wrote:
> > Hi,
> >
> > Background: I am trying to get the new Qt/KDE Phonon library working on
> > Qtopia Core (Qt/Embedded). Linux/Qtopia Core uses the GStreamer backend
> > for Phonon - specifically the decodebin element.
> >
> > I'm having problems getting decodebin (& playbin) to detect & use the
> > ffmpeg elements. E.g.
> >
> > The following works fine:
> > gst-launch filesrc location=01_Neighborhood_1_Tunnels_.mp3  ! ffdemux_mp3
> > ! ffdec_mp3 ! alsasink
> >
> > However, using decodebin I get:
> >
> > $ gst-launch-0.10 filesrc location=01_Neighborhood_1_Tunnels_.mp3 !
> > decodebin ! audioconvert ! alsasink
>
> The key difference between these two is that decodebin will only
> autoplug elements that have a non-zero rank.
>
> ffdemux_mp3 and ffdec_mp3 have zero rank, because they don't work
> properly and there are better ones available in gstreamer. So they're
> there, and you can explicitly use them if you want, but we strongly
> recommend against it.

But surely the ffmpeg plugins should be used if there are no other plugins
avaliable? Can they not just be given a very low (non-zero) rank, so if
there's _anything_ else which will play them, it will be used and if there
isn't, ffmpeg is used as a last resort?

Is it just ffdemux_mp3 & ffdec_mp3 which have a rank of zero? Do any of the
other ffmpeg demuxers & decoders have a higher rank (BTW: where is this
defined? in gst-ffmpeg or decidebin)? If all ffmpeg elements are given a
zero-rank, gst-ffmpeg effectivly becomes useless for our purposes and we
loose all the codecs it supports which aren't covered by other gstreamer
plugins (any idea how big the gap is here?).

Another issue is performance. I've tested cpu usage (with top - not very
scientific I know), and the ffmpeg plugin seems to perform better than even
mad (~23% CPU for mad, ~20-21% for ffmpeg on a 266Mhz armv4). For this
reason, I personally prefer the ffmpeg decoder. When you say "they don't work
properly and there are better ones available in gstreamer", what exactly do
you mean? Are there build issues, runtime crashes, compatability problems,
performance issues, quality issues, etc. I've tried ffmpeg on 3 architectures
now with no issues, although I've not really been paying too much attention
to the quality.


Cheers,

Tom

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Christian Fredrik Kalager Schaller-2]

Hi Tom,
There is a list defining the rank on a per codec basis in one of the
gst-ffmpeg header files if I remember correctly. The reason it got
disabled back in the day was because if you tried seeking in a mp3 file
using that decoder you would get an error and the application would
crash. This might not be the case anymore with the new mp3parse element
taking care of the seeking, but I don't think anyone has verified.

If you are using gst-ffmpeg in your project you can of course change the
rank of any of the codecs easily for your own build/setup if you so
prefer.

Christian


On Wed, 2008-02-06 at 18:35 +0100, Tom Cooksey wrote:

> On Wednesday 06 February 2008 15:42:04 Michael Smith wrote:
> > On Wed, 2008-02-06 at 16:33 +0100, Tom Cooksey wrote:
> > > Hi,
> > >
> > > Background: I am trying to get the new Qt/KDE Phonon library working on
> > > Qtopia Core (Qt/Embedded). Linux/Qtopia Core uses the GStreamer backend
> > > for Phonon - specifically the decodebin element.
> > >
> > > I'm having problems getting decodebin (& playbin) to detect & use the
> > > ffmpeg elements. E.g.
> > >
> > > The following works fine:
> > > gst-launch filesrc location=01_Neighborhood_1_Tunnels_.mp3  ! ffdemux_mp3
> > > ! ffdec_mp3 ! alsasink
> > >
> > > However, using decodebin I get:
> > >
> > > $ gst-launch-0.10 filesrc location=01_Neighborhood_1_Tunnels_.mp3 !
> > > decodebin ! audioconvert ! alsasink
> >
> > The key difference between these two is that decodebin will only
> > autoplug elements that have a non-zero rank.
> >
> > ffdemux_mp3 and ffdec_mp3 have zero rank, because they don't work
> > properly and there are better ones available in gstreamer. So they're
> > there, and you can explicitly use them if you want, but we strongly
> > recommend against it.
>
> But surely the ffmpeg plugins should be used if there are no other plugins
> avaliable? Can they not just be given a very low (non-zero) rank, so if
> there's _anything_ else which will play them, it will be used and if there
> isn't, ffmpeg is used as a last resort?
>
> Is it just ffdemux_mp3 & ffdec_mp3 which have a rank of zero? Do any of the
> other ffmpeg demuxers & decoders have a higher rank (BTW: where is this
> defined? in gst-ffmpeg or decidebin)? If all ffmpeg elements are given a
> zero-rank, gst-ffmpeg effectivly becomes useless for our purposes and we
> loose all the codecs it supports which aren't covered by other gstreamer
> plugins (any idea how big the gap is here?).
>
> Another issue is performance. I've tested cpu usage (with top - not very
> scientific I know), and the ffmpeg plugin seems to perform better than even
> mad (~23% CPU for mad, ~20-21% for ffmpeg on a 266Mhz armv4). For this
> reason, I personally prefer the ffmpeg decoder. When you say "they don't work
> properly and there are better ones available in gstreamer", what exactly do
> you mean? Are there build issues, runtime crashes, compatability problems,
> performance issues, quality issues, etc. I've tried ffmpeg on 3 architectures
> now with no issues, although I've not really been paying too much attention
> to the quality.
>
>
> Cheers,
>
> Tom
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Michael Smith-32]

On Wed, 2008-02-06 at 18:35 +0100, Tom Cooksey wrote:
> But surely the ffmpeg plugins should be used if there are no other plugins
> avaliable? Can they not just be given a very low (non-zero) rank, so if
> there's _anything_ else which will play them, it will be used and if there
> isn't, ffmpeg is used as a last resort?

If they worked, then sure, that would be reasonable. They don't work
properly (though they may work in sufficiently simple cases; I'm not
sure). It's much better to give them zero rank, otherwise people who
have installed gst-ffmpeg, but not gst-plugins-ugly, would get lots of
crashes - it's much better to only autoplug plugins that we expect to
work.


> Is it just ffdemux_mp3 & ffdec_mp3 which have a rank of zero? Do any of the
> other ffmpeg demuxers & decoders have a higher rank (BTW: where is this
> defined? in gst-ffmpeg or decidebin)? If all ffmpeg elements are given a
> zero-rank, gst-ffmpeg effectivly becomes useless for our purposes and we
> loose all the codecs it supports which aren't covered by other gstreamer
> plugins (any idea how big the gap is here?).

Most of the ffmpeg decoders have a non-zero rank. I think there might be
some demuxers with non-zero rank too, but not many - the ffmpeg demuxers
are generally not very good, and gstreamer has native implementations of
most of those.

It's defined inside gst-ffmpeg; you can see the rank using gst-inspect.

>
> Another issue is performance. I've tested cpu usage (with top - not very
> scientific I know), and the ffmpeg plugin seems to perform better than even
> mad (~23% CPU for mad, ~20-21% for ffmpeg on a 266Mhz armv4). For this
> reason, I personally prefer the ffmpeg decoder. When you say "they don't work
> properly and there are better ones available in gstreamer", what exactly do
> you mean? Are there build issues, runtime crashes, compatability problems,
> performance issues, quality issues, etc. I've tried ffmpeg on 3 architectures
> now with no issues, although I've not really been paying too much attention
> to the quality.

I don't recall the specific problems with the ffdec_mp3, I do know that
mad is far more reliable, and far more complete. We generally consider
those to be more important than a very small performance difference.

Mike

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

> Hi Tom,
> There is a list defining the rank on a per codec basis in one of the
> gst-ffmpeg header files if I remember correctly. The reason it got
> disabled back in the day was because if you tried seeking in a mp3 file
> using that decoder you would get an error and the application would
> crash. This might not be the case anymore with the new mp3parse element
> taking care of the seeking, but I don't think anyone has verified.
Yep, got it - gstffmpegdec.c:2301 & gstffmpegdemux.c:1505. At
gstffmpegdemux:1502 there's a comment saying:

   /* Set the rank of demuxers know to work to MARGINAL.
     * Set demuxers for which we already have another implementation to NONE
     * Set All others to NONE*/

My personal view point is that this is the wrong behaviour. Only demuxers
known _not_ to work should have rank set to NONE, and others should be given
MARGINAL. Give GStreamer a fighting chance to play the file. IMO, an
occasional segfault for some people is better than never playing the media.
As mentioned, if a user does experience a segfault, they can just install
another plugin with a higher rank. It might also highlight bugs in ffmpeg &
encorage them to be fixed. :-)

> If you are using gst-ffmpeg in your project you can of course change the
> rank of any of the codecs easily for your own build/setup if you so
> prefer.

Well... This is tricky. Qt is using GStreamer as it's default phonon back end
(for Linux.. at the moment), so all Qt applications using phonon on Linux
will be using GStreamer. I don't want to run into the situation where someone
writes a media player using phonon, but nobody uses it becuse it can't play a
file mplayer, xine or vlc can play. I've been told the KDE devs have written
their own phonon back-end for xinelib - so I'm not sure which phonon backend
KDE applications will be using. For Qt/Embedded, we have to use GStreamer
because we're seeing a lot of embedded boards shipping with GStreamer decode
elements which use hardware acceleration specific to those boards.


Cheers,

Tom


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Christian Fredrik Kalager Schaller-2]

Hi Tom,
That is the behavior we used to use. The problem is that it seemed to
have the opposite effect of the one we wanted. You see people got the
non-problematic packages of GStreamer from the distro (core, base and
good). Then when they wanted mp3 support they realized they needed to
get something else. A lot of them then just grabbed gst-ffmpeg. Problem
was that they got a horrible user experience with all their music
applications crashing constantly. Yet since mp3 sorta did play did
assumed they had the correct packages installed and just concluded that
GStreamer was horribly broken for mp3 playback. So we switched to the
current policy which cause users to try looking for other packages for
mp3 support once the find that gst-ffmpeg do not support it, finding
gst-ugly and getting properly working mp3 playback.

So while we originally agreed with your assessment of the situation our
experience when trying this was that it gave GStreamer a really bad name
and causing a lot more user frustration than the current solution.

Christian

On Wed, 2008-02-06 at 19:33 +0100, Tom Cooksey wrote:

> My personal view point is that this is the wrong behaviour. Only demuxers
> known _not_ to work should have rank set to NONE, and others should be given
> MARGINAL. Give GStreamer a fighting chance to play the file. IMO, an
> occasional segfault for some people is better than never playing the media.
> As mentioned, if a user does experience a segfault, they can just install
> another plugin with a higher rank. It might also highlight bugs in ffmpeg &
> encorage them to be fixed. :-)
>
> > If you are using gst-ffmpeg in your project you can of course change the
> > rank of any of the codecs easily for your own build/setup if you so
> > prefer.
>
> Well... This is tricky. Qt is using GStreamer as it's default phonon back end
> (for Linux.. at the moment), so all Qt applications using phonon on Linux
> will be using GStreamer. I don't want to run into the situation where someone
> writes a media player using phonon, but nobody uses it becuse it can't play a
> file mplayer, xine or vlc can play. I've been told the KDE devs have written
> their own phonon back-end for xinelib - so I'm not sure which phonon backend
> KDE applications will be using. For Qt/Embedded, we have to use GStreamer
> because we're seeing a lot of embedded boards shipping with GStreamer decode
> elements which use hardware acceleration specific to those boards.
>
>
> Cheers,
>
> Tom
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Edward Hervey]

On Wed, 2008-02-06 at 19:33 +0100, Tom Cooksey wrote:
> Well... This is tricky. Qt is using GStreamer as it's default phonon back end
> (for Linux.. at the moment), so all Qt applications using phonon on Linux
> will be using GStreamer. I don't want to run into the situation where someone
> writes a media player using phonon, but nobody uses it becuse it can't play a
> file mplayer, xine or vlc can play. I've been told the KDE devs have written
> their own phonon back-end for xinelib - so I'm not sure which phonon backend
> KDE applications will be using. For Qt/Embedded, we have to use GStreamer
> because we're seeing a lot of embedded boards shipping with GStreamer decode
> elements which use hardware acceleration specific to those boards.

  Fire up xine or mplayer or whatever you want and try to load an mp3
and look at what decoder it's using. I'm betting that ALL distros are
using the libmad decoder and not the ffmpeg one...
  ... Which is exactly the behaviour we're enforcing by default.

   Edward

>
>
> Cheers,
>
> Tom
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Tim-Philipp Müller-2]

On Wed, 2008-02-06 at 19:33 +0100, Tom Cooksey wrote:

> IMO, an occasional segfault for some people is better than never
> playing the media.

Umm, no. Crashing is simply not acceptable, ever.

There are two perfectly adequate and supported mp3 decoders with
licenses that should be perfectly acceptable to anyone for their
(software) licensing needs.

Anything beyond that adds very little value and only increases our
maintenance burden. Not much of a trade-off to be had here for us, I
think. There's only so much we can test and maintain.

Showing the user a message 'You need to install an xyz decoder to play
this file' is better than exposing him/her to plugins of dubious
quality. Recent/decent distros may even install the required packages
automatically for them in this case (via GStreamer's missing plugin
installation API).


> As mentioned, if a user does experience a segfault, they can just
> install another plugin with a higher rank.

Most users will just think "totem-gstreamer sucks", "rhythmbox sucks" or
maybe "GStreamer-based players suck". I doubt they'll go and learn about
how GStreamer and its plugin system work and/or start looking for better
codecs.


> It might also highlight bugs in ffmpeg & encorage them to be fixed. :-)

Sure, but it's usually also a good idea to pick your battles. Which is
what we're doing here :)

 Cheers
  -Tim



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

> That is the behavior we used to use. The problem is that it seemed to
> have the opposite effect of the one we wanted. You see people got the
> non-problematic packages of GStreamer from the distro (core, base and
> good). Then when they wanted mp3 support they realized they needed to
> get something else. A lot of them then just grabbed gst-ffmpeg. Problem
> was that they got a horrible user experience with all their music
> applications crashing constantly. Yet since mp3 sorta did play did
> assumed they had the correct packages installed and just concluded that
> GStreamer was horribly broken for mp3 playback. So we switched to the
> current policy which cause users to try looking for other packages for
> mp3 support once the find that gst-ffmpeg do not support it, finding
> gst-ugly and getting properly working mp3 playback.
>
> So while we originally agreed with your assessment of the situation our
> experience when trying this was that it gave GStreamer a really bad name
> and causing a lot more user frustration than the current solution.

I understand what you mean now, thanks for the clarification. Having said
that, perhaps a new rank could be defined called BETTER_PLUGIN_EXISTS or
something. If decodebin finds that the rank is BETTER_PLUGIN_EXISTS it can
emit a warning saying something like "While this plugin may work, it is
unsupported and better plugins are known to exist. It is highly recomended
that you install the better plugin".

There's still the issue of codecs where it's ffmpeg or nothing. If there's no
alternetive, I still think GStreamer should try ffmpeg, emiting the
appropriate warnings.

Mike> I appreciate you're probably not too bothered about embedded, but the
difference between 21% and 23% CPU on a mobile device is very important. It
can almost be directly translated into 10% longer battery life for example.


Cheers,

Tom



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Edward Hervey]

On Wed, 2008-02-06 at 20:05 +0100, Tom Cooksey wrote:

> > That is the behavior we used to use. The problem is that it seemed to
> > have the opposite effect of the one we wanted. You see people got the
> > non-problematic packages of GStreamer from the distro (core, base and
> > good). Then when they wanted mp3 support they realized they needed to
> > get something else. A lot of them then just grabbed gst-ffmpeg. Problem
> > was that they got a horrible user experience with all their music
> > applications crashing constantly. Yet since mp3 sorta did play did
> > assumed they had the correct packages installed and just concluded that
> > GStreamer was horribly broken for mp3 playback. So we switched to the
> > current policy which cause users to try looking for other packages for
> > mp3 support once the find that gst-ffmpeg do not support it, finding
> > gst-ugly and getting properly working mp3 playback.
> >
> > So while we originally agreed with your assessment of the situation our
> > experience when trying this was that it gave GStreamer a really bad name
> > and causing a lot more user frustration than the current solution.
>
> I understand what you mean now, thanks for the clarification. Having said
> that, perhaps a new rank could be defined called BETTER_PLUGIN_EXISTS or
> something. If decodebin finds that the rank is BETTER_PLUGIN_EXISTS it can
> emit a warning saying something like "While this plugin may work, it is
> unsupported and better plugins are known to exist. It is highly recomended
> that you install the better plugin".
>
> There's still the issue of codecs where it's ffmpeg or nothing. If there's no
> alternetive, I still think GStreamer should try ffmpeg, emiting the
> appropriate warnings.

  The rule is as follow: If we know there's an alternative decoder for a
given format, we set the rank of the ffmpeg plugin for that decoder to
NONE, else we set it to MARGINAL. This will force distributors,
packagers, ... into shipping the other plugins (which are also easier to
maintain).
  Exceptions: Mpeg4, h264 and cook are primary, because they are the
best decoders out ther.

  GST_RANK_MARGINAL implies that there is a better plugin out there.

>
> Mike> I appreciate you're probably not too bothered about embedded, but the
> difference between 21% and 23% CPU on a mobile device is very important. It
> can almost be directly translated into 10% longer battery life for example.
>
>
> Cheers,
>
> Tom
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

> > There's still the issue of codecs where it's ffmpeg or nothing. If
> > there's no alternetive, I still think GStreamer should try ffmpeg,
> > emiting the appropriate warnings.
>
>   The rule is as follow: If we know there's an alternative decoder for a
> given format, we set the rank of the ffmpeg plugin for that decoder to
> NONE, else we set it to MARGINAL.
>   GST_RANK_MARGINAL implies that there is a better plugin out there.
Surely NONE implies there's a better plugin out there? MARGINAL implies there
isn't anything better?

>   Exceptions: Mpeg4, h264 and cook are primary, because they are the
> best decoders out ther.
Right, so for codecs which ffmpeg has the best/only support for, ffmpeg IS
used. Good.

I guess I'm a minority case. I also get the impression people have been
blindly touting "gstreamer sux" because an external plugin caused
applications to crash. Wow... that must have been very fustrating - you have
my sympathy.

For my small case, where ffmpeg works and I want to use it, how would you
recomend I proceed? I know I can patch gstffmpegdec.c & gstffmpegdemux.c, but
is there another way? Can I edit ~/.gstreamer-0.10/registry.xxxx.xml ? Will
this be re-generated everytime a plugin is upgraded/installed/uninstalled? Is
there any way to override the rank at runtime?



Cheers,

Tom

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Edward Hervey]

On Wed, 2008-02-06 at 20:49 +0100, Tom Cooksey wrote:

> > > There's still the issue of codecs where it's ffmpeg or nothing. If
> > > there's no alternetive, I still think GStreamer should try ffmpeg,
> > > emiting the appropriate warnings.
> >
> >   The rule is as follow: If we know there's an alternative decoder for a
> > given format, we set the rank of the ffmpeg plugin for that decoder to
> > NONE, else we set it to MARGINAL.
> >   GST_RANK_MARGINAL implies that there is a better plugin out there.
> Surely NONE implies there's a better plugin out there? MARGINAL implies there
> isn't anything better?

  No, we set them to NONE because we WANT people to use the other
plugins ! This is beyond the point of this thread, but to put it simply,
it's a Pain in the *** to maintain the ffmpeg subset, so we try to limit
the default usage of the ffmpeg plugins.
  For those for which there are no alternatives, we put it to MARGINAL
so that *IF* somebody writes another non-ffmpeg plugin for that format,
he/we can set it to a higher rank and people will be able to enjoy the
pleasure of well supported plugins.

>
> >   Exceptions: Mpeg4, h264 and cook are primary, because they are the
> > best decoders out ther.
> Right, so for codecs which ffmpeg has the best/only support for, ffmpeg IS
> used. Good.
>
> I guess I'm a minority case. I also get the impression people have been
> blindly touting "gstreamer sux" because an external plugin caused
> applications to crash. Wow... that must have been very fustrating - you have
> my sympathy.
>
> For my small case, where ffmpeg works and I want to use it, how would you
> recomend I proceed? I know I can patch gstffmpegdec.c & gstffmpegdemux.c, but
> is there another way? Can I edit ~/.gstreamer-0.10/registry.xxxx.xml ? Will
> this be re-generated everytime a plugin is upgraded/installed/uninstalled? Is
> there any way to override the rank at runtime?
>
>
>
> Cheers,
>
> Tom
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

> > Surely NONE implies there's a better plugin out there?
>
>   No, we set them to NONE because we WANT people to use the other
> plugins !

Yep... what I said. ^^^^^^

> > MARGINAL implies there isn't anything better?
>   For those for which there are no alternatives, we put it to MARGINAL
> so that *IF* somebody writes another non-ffmpeg plugin for that format,
> he/we can set it to a higher rank and people will be able to enjoy the
> pleasure of well supported plugins.

Yep... understand, again what I said.


Thank you all for your time. I believe I have sufficient knowledge now.




Cheers,

Tom


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[David Schleef]

On Wed, Feb 06, 2008 at 08:49:25PM +0100, Tom Cooksey wrote:
> For my small case, where ffmpeg works and I want to use it, how would you
> recomend I proceed? I know I can patch gstffmpegdec.c & gstffmpegdemux.c, but
> is there another way? Can I edit ~/.gstreamer-0.10/registry.xxxx.xml ? Will
> this be re-generated everytime a plugin is upgraded/installed/uninstalled? Is
> there any way to override the rank at runtime?

The registry is actually just a cache of information contained in a
plugin, so the .so file doesn't need to be loaded at every startup.
So a developer can sometimes successfully modify the registry to test
out a desired behavior, but any changes will be overwritten
semi-randomly.

We'd like to have some way to manually modify ranks, but there's a
lot of stop energy among GStreamer developers for taking up the task.
It would be a lot of work to get right, create a lot of user-controllable
knobs and the resulting bug report load, for not much gain.  The primary
gain would be to tweak situations that are "correct but unfortunate",
such as your case, or to fix (er, "hide") actual bugs.



dave...


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Michael Smith-32]

On Wed, 2008-02-06 at 20:49 +0100, Tom Cooksey wrote:
> For my small case, where ffmpeg works and I want to use it, how would you
> recomend I proceed? I know I can patch gstffmpegdec.c & gstffmpegdemux.c, but
> is there another way? Can I edit ~/.gstreamer-0.10/registry.xxxx.xml ? Will
> this be re-generated everytime a plugin is upgraded/installed/uninstalled? Is
> there any way to override the rank at runtime?

If you want to force use of ffmpeg decoders/demuxers where we've
explicitly disabled autoplugging, then:
 1) you have to patch the source code. (the registry is auto-regenerated
whenever anything changes; there's not yet any API for
rank-modification)
 2) Please make sure it's very obvious that you're using a
custom-patched gst-ffmpeg, so when we get bug reports because these
decoders crash, we can reassign to them to you. We're NOT going to
support this.

Mike

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel