i was thinking about this some more and it seems that one way of dealing with the problem would be to create a dead simple totem firefox plugin that supports one codec, and the actualy codec name/mimetype/etc could be specified via defines. then we could compile multiple copies of the totem firefox plugin, one copy for each codec we might want to support.
then have an smf startup service which looks at the firefox plugin directory, and if it'ss timestamp is newer than a saved copy of the timestamp, then it cycles through all the codecs that we compiled plugins for, and runs gst-inspect to see if the system supports that codec, and if so, it adds a link to the plugin in the firefox plugin directory. totally simple... i'm sure there'd be zaro problem with this implementation. ;) ed On Wed, Feb 18, 2009 at 02:38:33PM +0800, Alfred Peng wrote: > Hi Ginn, > > As I check the source code, pluginreg.dat is generated from the information > (mimetype, description, extension) passed by the plugin files > (libtotem-basic-plugin.so for example) through NPAPI framework. I think if > Totem passes dynamic information, Firefox will update pluginreg.dat to > reflect the change. > > From the Totem side, it might be possible to get the dynamic information > from GStreamer. Not sure about the detail of GStreamer though. > > -Alfred > > Ginn Chen wrote: >> On Feb 18, 2009, at 12:57 PM, Alfred Peng wrote: >> >>> Hi Edward, >>> >>> Thanks for the report. The Totem source code shows that the mimetype >>> support is hardcoded. A dynamic way of detecting the GStreamer codecs >>> will be great. >>> >> I'm afraid if it is possilbe. >> The mimetypes are registered in pluginreg.dat in firefox profile >> directory. >> >> Ginn >> >>> Edward Pilatowicz wrote: >>>> [ i'm not on this alias, so please cc me on any replies. ] >>>> >>>> hey all, >>>> >>>> i've filed an rfe for improved totem firefox plugin support. >>>> unfortunately it isn't visible via monaco yet, but when it is, it should >>>> be at the following url: >>>> http://bugs.opensolaris.org/view_bug.do?bug_id=6804284 >>>> >>> Wrong link? This link goes to "avahi-browse --dump-db dies due to memory >>> corruption". >>>> i'm including the content of the rfe here because i think other people >>>> might be interested in it and might also have some valuable potential >>>> feedback on the idea. >>>> >>> defect.opensolaris.org could be a good place to post the RFE and get >>> better publicity and feedback from the community. >>> >>> Thanks, >>> -Alfred >>>> thoughts? >>>> ed >>>> >>>> ---8<--- >>>> so by default we ship: >>>> /usr/lib/firefox/plugins/libtotem-basic-plugin.so >>>> >>>> i've gone ahead and purchased the gstreamer fluendo plugins, so >>>> naturally, i'd like to have those codecs accessible via totem in >>>> firefox. but it seems that the firefox plugin design is a little poor >>>> in that the information about what objects a plugin supports is hard >>>> coded into the plugin library. so to allow me to use these codecs with >>>> firefox, it seems like i'd need to have a new firefox plugin. >>>> >>>> now, at first glance, since i got the additional gst plugins from >>>> fluendo it seems like perhaps they should deliver this plugin. but >>>> then, thinking about it a bit we realize that fluendo only delivers gst >>>> plugins, and by having to deliver a totem/firefox plugin, they would >>>> have to do version tracking of two additional (and not directly gst >>>> related) pieces of software, which becomes a royal pain once one os.o >>>> release has ff3.0, and another has ff3.1, etc. each release of their >>>> codecs would have to ship with multiple totem/firefox plugins for every >>>> totem/ff version combination in every os.o distro they want to support. >>>> it seems much easier to just have os.o deliver the plugin. >>>> >>>> so on that note, it would be great if we shipped more ff/totem plugins. >>>> these plugins could be delivered in say /usr/lib/totem/firefox, and we >>>> could provide a new smf upgrade service that detects which gst plugins >>>> are currently installed on the system and automatically links the >>>> correct plugins into /usr/lib/firefox/plugins. >>>> ---8<--- >>>> _______________________________________________ >>>> desktop-discuss mailing list >>>> desktop-discuss at opensolaris.org >>>> >>> >>> _______________________________________________ >>> desktop-discuss mailing list >>> desktop-discuss at opensolaris.org >> >> -------- >> Ginn Chen >> Software Engineer, Browser Team >> Sun Microsystems, Inc. >> Phone: x82869 / +86-10-62673869 >> Fax: +86-10-62780969 >> >>
