[MPlayer-users] Re: Encoding quality advices

Steffen Barszus st_barszus at gmx.de
Wed Dec 4 16:08:02 CET 2002


On Wednesday 04 December 2002 15:05, Moritz Bunkus wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> Hi.
>
> > No, it doesn't have to be a contradiction... Adding for example profiles
> > or presets doesn't change anything of it's power and flexibility...
> > Adding a GUI on top of it doesn't change that either...
>
Hmm want to see a gui, that can 
- easily be expanded for the options of mencoder
- show all the options and did not get a monster at the same time.
mplayer is big anough (for modem users) and a gui does not give any pros if 
they is included. But I guess this wasn't the point, you meant simplicity 
does not imply lesser flexibility, I just dont agree in the case of a gui ...

> Why add a GUI? A GUI for mencoder does not require any special support
> from mencoder (like mplayer's GUI uses internal hooks and not simply
> the slave mode), so it's much better to make a separate program that
> uses mencoder as its backend. 

Agree on that. 

> Of course you can bloat mencoder into something huge and ugly, but this
> is a case where a completely separate program is suited better.

Yes and there is one for a longer time, don't know if the catched the fast 
development in the last time => KMencoder. The profiles thingy sound 
reasonable to me: 
- clear interface 
- makes it easier cause you don't have these huuuge lines ;)
- profiles can be easy shared

More than a gui is needed:
- let it be fast and stable
- don't make things easier than they are (hide options behind a gui)

of course 

-- 
____________________
counter.li.org : #296567.
machine: 181800
vdr-box : 89
____________________
Please dont CC me, since if I have replied I'll watch the tread. Both mails 
will be filtered to the ML-folder. Thanks




More information about the MPlayer-users mailing list