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

[Jason spot Brower]

Comments embeded:

On Fri, Mar 21, 2008 at 8:31 PM, 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.
>
>
>  [...]
>
> > Why do we need a GUI for ffplay? :)
I don't think a gui would be needed for a play.  It could use the
window managers default player.  It would simply be able to show what
the video or audio sound/looks like as before you are done encoding.
That way you can go back and make changes before you finish.
>
>  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.
Well, the further you pull from an environment then more unintegrated
your program becomes.  At least I like it when all my program look
like the work together.
>  >
>
>  > >  * 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 are the bane of usability.  I have too many friends that would
shoot me in my sleep if I started skinning things.  The create
confusing for users and problems with visually and physically
impaired.  This is a gui, not a toy.
>
>  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.
Let the program go it's way, I say.  We know that windows,linux, and
mac users are different.  The expect something.  For example, many
windows users expect a next button where as gnome users get annoyed
with them.  Mac users want to have the whole "steel" look with all the
cocoa features.  One toolkit will never cover all of that.  Let one
then one frontend accure.  That's what open source is about.
>
>  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.
>
> -----BEGIN PGP SIGNATURE-----
>  Version: GnuPG v1.4.6 (GNU/Linux)
>
>  iD8DBQFH4/7pYR7HhwQLD6sRApOpAJ4wn17Jk10ng3Kb7OYnXCYmyZ0y2gCfW1nk
>  Sqm2iMPimEQp3Lv0cBuupG8=
>  =v/Uc
>  -----END PGP SIGNATURE-----
>
> _______________________________________________
>  ffmpeg-devel mailing list
>  ffmpeg-devel at mplayerhq.hu
>  https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>



-- 
Jason Brower
Gmail has over 2.7gb of storage space and it is growing?
What does your web mail have?