On Tue, Aug 19, 2008 at 8:21 PM, Bastien Nocera <[EMAIL PROTECTED]> wrote: > On Tue, 2008-08-19 at 19:55 +0300, Felipe Contreras wrote: >> On Tue, Aug 19, 2008 at 6:38 PM, Bastien Nocera <[EMAIL PROTECTED]> wrote: >> > On Tue, 2008-08-19 at 16:46 +0300, Felipe Contreras wrote: >> > <snip> >> >> >> Is playlist support a must-have feature? If so, probably should be >> >> >> handled by a GStreamer element. Fullscreen support should not be that >> >> >> difficult, but I leave that to somebody else. >> >> > >> >> > Yes, it's a must-have. >> >> >> >> If you are trying to emulate other plugins then yes, I see how that >> >> could be required. >> > >> > Even a plugin that doesn't try to support the APIs of those foreign >> > plugins will certainly need playlist support to be competitive... >> >> Competitive against what? > > Do you think website designers will use your plugin if it doesn't > support the basics? Your plugin would need to support enough features > for website developers to consider using it, otherwise they'll target > WMP or Quicktime, or possibly VLC if they're nice people.
The context was non-emulating plugins. >> I don't recall ever seeing a site embedding >> a playlist. > > Pretty much all the websites using WMP, or Real as plugins will have > playlists. Quicktime also uses them (link references, metalinks as well > as movie redirections). > > And if you want to play files in succession, you need playlist support. Sames as before. >> Again, if it was really important I guess GStreamer should >> handle it. > > It's already been discussed in bugzilla. Supporting playlists in > GStreamer is far too low down in the stack. Feel free to use the code in > totem-pl-parser to write an element and the API needed on top. But I > still don't see what that would buy us. We are talking about a browser plugin for other multimedia applications, not totem. >> >> > FWIW, you can probably have a complete web browser plugin in not much >> >> > space by packaging it properly in a sub-package. >> >> > >> >> > $(libdir)/mozilla/plugins/* >> >> > $(libexecdir)/totem-plugin-viewer >> >> >> >> This is one of the things I didn't like when I analyzed the totem >> >> plugin: why require an external process? >> > >> > Because video decoders are rubbish, and you don't want to do video >> > decoding in the same space as the web browser. A crafted video playing >> > inside the web browser could make it send your whole password wallet to >> > some website. With a separate program, it will just crash :) >> >> Hmm, true. It seems to be a remote possibility to me, so I'm not sure >> if it's worth the trouble. > > It's called security. It's only got to hurt once for it to be a problem. > Take a look at MPlayer's and Xine's recent CVE advisories, or even > Flash's. For it to be crafted to hurt might be unlikely, but crafted to > crash on some systems doesn't even have to be on purpose. Yeah, I know. It's even more secure to don't bother developing it in the first place. >> If all the code is contained in the plugin then packaging becomes very >> easy: one file. Which I guess helps for plugin autoinstallation. > > Why would it help plugin auto-installation. Whether it's one or three > files shouldn't make a difference to the installer (whatever it could > be), and Totem's browser plugin is already shipped by default on a good > number of distributions. Automatic installers don't have access to /usr/share/totem or /usr/libexec. >> >> > $(libdir)/libbaconvideowidget.so.0.0.0 (shared with Totem itself) >> >> > $(pkgdatadir)/mozilla-viewer.ui >> >> > $(pkgdatadir)/fullscreen.ui (shared with Totem itself) >> >> > >> >> > That comes in under a meg stripped... >> >> >> >> I guess it depends on what is required. >> > >> > Can certainly be smaller if you remove some of the compatibility >> > plugins. >> >> I meant, if you are interested in simple playback (not emulating other >> plugins) then ideally the plugin can be contained in one file. > > And which websites would use your plugin? http://commons.wikimedia.org/ >> Personally I would like to be able to install a plugin in my >> "~/.mozilla/plugins" directory, and not require anything else. Adding >> an application in the same directory to be run as a separate process >> seems reasonable too, but adding those .ui files doesn't appeal me. >> >> All this discussion makes me wonder about some ideas: >> >> a) Is it possible to pack all the "compatibility plugins" into a single >> plugin? > > No, because browsers expect one plugin per shared library. You can't > have a single shared library have multiple names, descriptions (unless > you employ gross hacks including symbolic links...). But you could have one plugin that handles different object types. >> b) Would it make sense to have a configuration to choose an >> application other than "totem-plugin-viewer"? > > Why? The IPC API is very ad-hoc as well, and will probably change (or > have to change) to support more features. That was the original question from Mark Trompell: so other multimedia players don't have to write their own browser plugin. Best regards. -- Felipe Contreras _______________________________________________ gnome-multimedia mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-multimedia
