Bug#448072: Video thumbnailing should not rely on a particular media player

[Josselin Mouette]

Le dimanche 21 septembre 2008 à 19:09 +0200, Reinhard Tartler a écrit :
> reassign 448072 nautilus
> stop
> 
> Josselin Mouette <joss at debian.org> writes:
> 
> > this sounds like a cool idea, but if it requires ffmpeg for running, it
> > sounds like it should be contained in the ffmpeg package.
> 
> It would only be used by nautilus, so it should be in that package.
> 
> I'd suggest to modify it to not depend on ffmpeg but behave in a sane
> way if ffmpeg is not available.
> 
> If you insist having it in ffmpeg, please try to convince upstream to
> include it.

Nautilus only provides a way for programs to register thumbnailers for
some MIME types. I don’t consider its job to set these handlers,
especially when it is not possible to know whether the handler will
actually work or not. Just like application handlers, thumbnailers must
be registered by the software providing it.

Currently, the thumbnailers are registered by totem-common, using an
alternative named gnome-video-thumbnailer. It is not such good thing to
use an alternative since the list of supported MIME types depends on the
implementation, but this is the only way to have it configurable.

If we really want to be able to use ffmpeg as the thumbnailer, we need
to do the following:
      * study the list of supported MIME types, to know if a single
        alternative is enough;
      * put the common files (picture border and schemas registration)
        in a new package;
      * have each implementation register the gnome-video-thumbnailer
        alternative.

Frankly, I’m not interested enough. We currently have a working solution
in GNOME, and if people really want to install a thumbnailer for videos
without actually installing a video player (!), we can let them
configure their systems as they wish.

Cheers,
-- 
 .''`.
: :' :      We are debian.org. Lower your prices, surrender your code.
`. `'       We will add your hardware and software distinctiveness to
  `-        our own. Resistance is futile.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20080922/98264d4d/attachment.pgp