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

[Robert Swain]

On 21/03/2008, Michael Niedermayer <michaelni at gmx.at> wrote:
> 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.

I thought it might be easier to query for available codecs/options
from the libraries than from the CLI. If it's using the CLI, how does
it use AVOption without also using the libs? But however it will work,
I think it would be good if when a new encoder is added, for example,
it shows up in whatever codec list might be in the UI.

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

That's a good point. If nothing else, as a testbed for filters in
libavfi being able to alter them and their parameters while playing
might be nice.

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

Features. :) I do like to have a time readout somewhere telling me how
long the video is and at what position I am watching. I don't know, I
should think about this a bit more and make a list.

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

I'm glad you agree.

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

True, but I think the other points are more important. So maybe
flexibility of a skinnable UI plus a default skin focusing on those
points would be a good approach.

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

OK. By platform display server, I meant whatever X11 and its equivalents are.

>  The code this would need per "platform display server" would be very
>  small.

I suppose it would.

>  The API above might seem very limiting at first but actually it is not.

It's a bit like starting with asm to write a GUI. :)

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

I suppose this can be done well. Winamp/XMMS have been successful with
skinnable GUIs. It still seems a bit strange to me to need a skinnable
GUI for a transcoder, but as the code would (could) be shared with any
sort of FFplay GUI, it would be more like writing our own little
toolkit. Let's reinvent the wheel again... ;)

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

That was my main consideration against using the libs.

Rob