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

[Michael Niedermayer]

On Fri, Mar 21, 2008 at 07:43:47PM +0000, Robert Swain wrote:
> 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,

Link to the libs as well as using the CLI ... no problem.


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

yes


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

no, send patch :)
some status line in the terminal would not hurt ffplay ...


[...]
> 
> >  > >  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. :)

No its more like using C instead of java with god knows what weird high level
trash.
Ive written some simple menus and font rendering when i needed it on a VESA
framebuffer in DOS, it was trivial and beat windows (at that time) by miles
in terms of looks and speed at that time.

Now when one looks at these ready made open file dialog boxes all the toolkits
provide. I really wonder but are they forking a java interpreter for each
pixel they draw? 10 years ago these things where 100 times faster on the
hardware of that day. And i had thousends of files as well so no its not
the number of files ...
-> so we will at least have to implement our own open file dialog and if the
reason for the speed problem is that the toolkits just have problems with
10000 objects (1 for each filename) then this will not solve it.
Write your own GUI from scratch and you dont have such problems. Computers
these days can execute billions of instructions per second, thats still
a million per filename if you want the thing displayed after 1 sec.


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

Yes and as a sideeffect our wheel will be faster and lighter :)


[...]

-- 
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/c7144be2/attachment.pgp>