[MPlayer-dev-eng] Offer of help to get me started
Arpi
arpi at thot.banki.hu
Mon Mar 24 11:15:09 CET 2003
Hi,
> > > > I became noticeably faster at editing the HTML docs after I had
> > > > completely and nicely reformatted them in one run. No more
> > > > reformatting has happened since that day.
> > > >
> > > > Another point evil tries to make is code readability for beginners or
> > > > people new to MPlayer. I think he has a point there that is a blind
> > >
> > > agree, some of the code is hard to read&understand IMHO, but iam not sure
> > > if reformating alone would solve this ...
> >
> > I don't think it would make much difference at all. A short tech doc
> > on the flow of execution between the demuxers, decoders, etc. would
> > probably be a lot more beneficial.
RTFtech/general.txt and its references
> agree, and some docs about each demuxer
why?
> 1. doc about the format (mainly if there is no doc about it/it was reverse
> engeneeered)
mike melanson already wrote them, i also wrote some docs for his site
about avi, smjpeg etc
and there is a general overview at docs/tech/formats.txt
> 2. doc about how the specific demuxer works
i see no much sense of it, the author/maintainer of demuxer knows it, and
everyone can understand it by reading the code or at least the comments.
demuxers aren't black magic. (with some exception like demux_real :))
> for example i spended some time looking at demux_real.c and still dont
> completly understand it
hehe
demux_real... don't even its coders understand it :)
(no, no, indent change won't help this case)
> IMHO, adding a if(){...} around a large part of code should be an allowed
> exception
and not only exception, but recommendation too
> > > * avoid wrong indention like
> > > int main(int argc,char* argv[]){
> > > static demux_stream_t *d_audio=NULL;
> > > [... no {()}]
> > > dvb_prev_next.prev = dvb_prev_next.next = -1;
> > > dvb_history = &dvb_prev_next;
> > > [... no {()}]
> > > srand((int) time(NULL));
> >
> > At the risk of annoying Michael, I'd like to also add:
> >
> > * No javaStyle variableNames which lookHorrible to cCoders. :)
agree
> ok, but only if we add to the style guide
> * No c_style variable_names which look_horrible to every_one :)
:)
> what 4B0Ut EL13t3 sT1L3_Ph4Ri4bl3 N4M3Z? ;)
soundz c00l :}
hey, Evil, why don't you replace all the variables/symbols in mplayer
to such elite names? it would bring more 31334 scriptkiddiz to mplayer
development for sure :)
> > > about the reformating/reindetion of existing code crusade, iam not sure
> > > if its a good idea, it should at least be limited to the cases where it
> > > helps readability
> >
> > I think we could come up with a compromise where we just reformat a
> > few really ugly cases, and leave the rest of the code alone.
> > mplayer.c, mencoder.c, and probably lots of the demuxer stuff I've
> > never bothered to read (although that will be rewritten anyway) come
> agree, IMHO mplayer/mencoder.c + demuxers would benefit from some reformating
> ...
not sure
if you really want to improve mplayer/mencoder.c, it should be modularized
(move some parts to functions, split to multiple files maybe etc), and
reduce the number of globals. just running indent won't help it...
> [...]
> > BTW, what happened to MPCF??? Is selecting a name the only thing left?
> chapters, playlists, ... are still missing/incomplete, but they can be added
ehh
afair we decided to ignroe that mess
A'rpi / Astral & ESP-team
--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu
More information about the MPlayer-dev-eng
mailing list