Re: [Totem] Browser plugin gstreamer

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

On Tue, Aug 19, 2008 at 8:21 PM, Bastien Nocera <hadess hadess net> wrote:
> On Tue, 2008-08-19 at 19:55 +0300, Felipe Contreras wrote:
>> On Tue, Aug 19, 2008 at 6:38 PM, Bastien Nocera <hadess hadess net> 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