[MPlayer-dev-eng] Offer of help to get me started

[Arpi]

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