[Swfdec] some thoughts about both ffmpeg and gnome

[Benjamin Otte]

Hey

>  The choice, however, makes me think. first, the standalone-player needs
>  gnome and not just gtk+. i'm running xfce and thus can't use it.
>
I'm not gonna argue that that's not true as you can just install it
now, as I guess you know that mantra. What I can however tell you is
that swfdec-gnome was specifically designed to be a part of Gnome, so
it's no wonder that it depends on a lot of Gome stuff. It'll probably
get more dependencies as time goes on.
However, you could just copy the relevant parts and start a
swfdec-xfce if you think it's important. I'm very interested in making
Swfdec portable to different desktop systems. I'm however not
interested in coding that stuff myself. And so far, not a lot of
people have shown up. KDE has been pretty silent after an initial
commit, as has the DirectFB stuff.

>  second, one can choose ffmpeg instead of gstreamer. however, there's no
>  stable ffmpeg-release, which makes swfdec hanging behind and not being
>  able to use the installed ffmpeg,
>
I'm sorry to disappoint you here, but the next Swfdec version will
likely not have any ffmpeg support at all, because I am about to rip
it out and depend on GStreamer. GStreamer works flawlessly and is
maintained well (both from the upstream side and from our side). The
same cannot be said about ffmpeg.

>  possibly, depending on xine-lib, which includes its own ffmpeg-version,
>  would be better? xine is also, beside mplayer, the most common
>  alternative to gstreamer.
>
The problem so far has been that there is a shortage of hackers in
Swfdec. So we decided early on to make stuff work with one thing and
make that one thing work really well. If however new hackers turned up
that wanted to hack on specific backends, we'd be very interested in
it. Maintaining backends for Swfdec is however not a simple one-time
task as the code base is still rapidly evolving and seeing changes to
all parts of the code regularly. Plus, we have quality requirements
(our no-crashes policy). So that might explain why we're more dropping
supported backends than gaining them.

But that being said, the Swfdec code base itself is modular enough to
make libswfdec run with multiple rendering backends or multiple codec
providers. But no one wanted to do that so far. Multiple choices
usually only exist because we are not sure which choice we want to
support so we try them out until we do.
And the choices for codec providers (GStreamer) and the gtk backend's
audio output (Pulse Audio) have been finalized. So expect them to be
the only choices in Swfdec 0.8.

Cheers,
Benjamin

Cheers,
Benjamin