[FFmpeg-devel] GSoC with FFMpeg waht a combination!

Robert Swain robert.swain
Fri Mar 21 18:28:23 CET 2008


On 21/03/2008, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Fri, Mar 21, 2008 at 04:39:30PM +0200, Jason (spot) Brower wrote:
>  > We could have multiple frontends that are recommended by the ffmpeg
>  > project. Windows in it's eviron, Linux in Gnome or KDE, and mac in
>  > cocoa.
>
> gnome and kde are also bloated (and dying as there are better window
>  managers around) monsters

I'm not sure dying is an accurate comment. But anyway...

>  Now the requirements for a GUI would be IMO
>  * supports all functions of the command line tool (ffmpeg for converter,
>   ffplay for player), theres no need to do both ffplay and ffmpeg in the
>   same project though.

I think having fields in the GUI for pasting command line options has
some use for maintainability. Interfacing directly with the libs is
probably preferable but I'm wary of such a GUI not being maintained
and subsequently having less probability of success than one that
interfaces with the CLI. Unless we invent some way that it can
maintain itself by querying the libraries for lists of available
codecs/presets or whatever.

Using the CLI itself would allow people to update the ffmpeg CLI
they're using (maybe have a path to FFmpeg binary in the
configuration) in the background though I suppose people can compile
against the libraries... I don't know what's best.

Why do we need a GUI for ffplay? :) I've always considered it merely a
test tool to check codecs are decoding stuff properly as opposed to
considering it as a serious option for an every day player.

>  * works on win32 and X11

Working in X11 on OS X isn't good enough in my opinion. Something
somewhat native (in the sense of not needing X11 running to run
itself) would be hugely preferable.

>  * no dependancies on unrelated libs (libgtk/libqt maybe, gnome/kde no)

Agreed.

>  * fully skinable to completely customize its look

Why do we care about skins? I'm not personally interested skins at
all. I'd rather mandate that the GUI be simple, well-arranged and
usable.

>  Ideally a GUI should be written to be independant of the toolkit, and i
>  would lean toward directly using X11 with no toolkit.

The problem with this is losing the capability of the toolkit to serve
a GUI for various platforms while maintaining only one set of code. If
you work directly with X11 then it's tied to X11 and won't work with
anything else. I'd consider this a bad move when we're so adamant
about portability for the core code... We could work directly with
platform display server (or whatever correct terminology is) APIs but
then we'd have to maintain multiple GUI code bases which is the
current Firefox route afaik. Do we have enough developers dedicated to
GUI development to do that? I doubt it.

>  And about using ff* vs. using the libs. Later would be redundant work IMHO
>  using the existing command line tools and changing them so they can be
>  properly integrated with a GUI seems simpler to me.

I'm not sure.

>  Also ffplay should be extended to support other VOs not just SDL but thats
>  a seperate project i guess.

Agreed. That + libavfi would make it into a more viable base for a player.

Rob




More information about the ffmpeg-devel mailing list