Re: [Totem] Browser plugin gstreamer

["Felipe Contreras" <felipe contreras gmail com>]

On Tue, Aug 19, 2008 at 9:30 PM, Bastien Nocera <hadess hadess net> wrote:
> On Tue, 2008-08-19 at 21:17 +0300, Felipe Contreras wrote:
>> On Tue, Aug 19, 2008 at 8:21 PM, Bastien Nocera <hadess hadess net> wrote:
> <snip>
>> > 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.
>
> Website designers need to target a specific mime-type/plugin that will
> support a documented API. You can either create your own mime-type, thus
> plugin API, and nobody will use it (look on Google for the number of
> sites supporting application/x-totem-plugin). Or you can emulate widely
> used plugins from other platforms.
>
> Which mime-type would your plugin support then?

video/x-msvideo
video/divx
video/avi
video/ogg

> <snip>
>> > 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.
>
> What would those be? Give me a use case.

A simple video player without any special dependency.

> <snip>
>> > 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.
>
> That's very helpful...

The point is something is better than nothing.

>> >> 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.
>
> I don't plan on supporting those.

A simple application might, without much problem.

>> >> >> > $(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/
>
> In which case exactly?

I'm not sure I'm following. There's only audio, video and image
there... audio and video... ogg vorbis and ogg theora.

>> >> 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.
>
> Yes, that's easy.

Cool.

>> >> 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.
>
> No, he asked about the video widget to be shared.

No, Milosz Derezynski was the one who suggested that, possibly
assuming that the issue Mark saw with totem was the fact that it
needed too many dependencies.

As a reference there is gst-simple-player which is a bare-bones
application I started.
http://freshmeat.net/projects/gst-player/

And there's a couple of GTK+ widgets David Schleef started:
http://diracvideo.org/git?p=gst-gtk-widgets.git

I believe what Mark Trompell was looking for was a simple browser
plugin that could use simple stuff as those above.

Best regards.

-- 
Felipe Contreras