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

[Michael Niedermayer]

On Fri, Mar 21, 2008 at 05:28:23PM +0000, Robert Swain wrote:
> 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:
[...]

> 
> >  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.

No matter if it uses the libs or CLI it must querry them (see AVOption)
and present this reasonably (GUI style) to the user.


[...]
> Why do we need a GUI for ffplay? :) 

Because it would look cool :)
And besides it would be quite nice to be able to change AVFilters/PP/lowres/
idct/... via a GUI menu. Sure we could implement it by using the keyboard but
the primary failure of such "1 key combo for each" interfaces is that noone
will ever remember them, a simple GUI menu is much more efficient for rarely
used things, no timeconsuming RTFM/RTFS to find the keycombo.


> 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.

What is it missing for an every day player? Ive used it >50% of the time
lately to watch movies.


> 
> >  * 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.

yes


> 
> >  * 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.

Skins dont contradict these goals.


> 
> >  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.

My idea was that the interface code between the GUI and the 
"platform display server" would be no more than a simple
open/close window
put rectangle of pixels

The code this would need per "platform display server" would be very
small.
The API above might seem very limiting at first but actually it is not.
Each window would be a image supplied by the skin. The skin would also
supply information of areas for each button, and "clicked" images for them.
To render a list of AVOptions the same code could be used which we will need
for rendering UTF-8 subtitles.


> 
> >  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.

Reimplementing the whole ffmpeg and ffplay is completely idiotic. The only
thing one needs is some communication between the GUI and ffmpeg.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct awnser.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080321/95e405d8/attachment.pgp>