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 <[hidden email]>, Ronald Bultje <[hidden email]>, Edward Hervey <[hidden email]></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 |
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 |
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 |
In reply to this post by thomas.cooksey@trolltech.com
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 |
In reply to this post by 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. 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 |
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 |
Administrator
|
In reply to this post by thomas.cooksey@trolltech.com
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 |
In reply to this post by thomas.cooksey@trolltech.com
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 |
In reply to this post by Christian Fredrik Kalager Schaller-2
> 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 |
Administrator
|
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 |
Administrator
|
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 |
In reply to this post by thomas.cooksey@trolltech.com
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 |
In reply to this post by thomas.cooksey@trolltech.com
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 |
Free forum by Nabble | Edit this page |