[MPlayer-dev-eng] Slideshow

Herman Tamas hermantom at dunasoft.com
Fri Dec 13 13:54:40 CET 2002


this should go 2 private but the dest address is unknown, sorry.

On Fri, 13 Dec 2002 06:31:36 -0500
"Daniel A. Nagy" <nagydani at mast.queensu.ca> wrote:

> On Thu, Dec 12, 2002 at 08:33:06PM -0500, D Richard Felker III wrote:
> > Do you have any idea what you're talking about? I certainly don't. As
sorry, i was terribly tired that night. also made a lot of syntactic
mistakes. so iwasnt clear, i should agree on that. im gonna b more clear
next time.

but conscisely again:
- dont use buggy libs & make workarounds outside if its possible
  2 fix the bug inside. it requires continous manual sync 2 the lib
  later what is a tedious work what involves a lot of text scrolling
  & lot of typing. but the result is a pretty high quality sw.
  (see ffmpeg&mplayer. they r a nice example of this methodology)
- C is 2 terse & not highlevel enough 2 express the top/surface/most
  outside mechanisms of a more complex program, like mplayer, in
  terse/conscise/clean & easily understandable fashion. adding such
  an extra language layer is obviously lowers performance unless
  u use the proper language... BUT! it can also boost productivity!
  and eases further development & MAINTENENCE... wheather such a
  higher level lang been incorporated or not in2 mplayer, programmers
  should write mplayer such a way so putting any HLL over it should
  b an obvious task.. the only thing is required 4 this is a very
  high level of modularization, even factorization, ithink...
  (also Arpi whats a more modular design...)

the above things sound obvious of course but still not taken
care of. so hear my meassage 2 the developers: do more design
b4 doing the actual coding! its gonna make everybodys life
easier, even yours.

a practical adivce: do more fine architectural descriptions jsut
like Arpi did eg, in DOCS/tech/libmpcodecs.txt . draw such graphs
more!



More information about the MPlayer-dev-eng mailing list