[MPlayer-dev-eng] review of mplayer application

[Alban Bedel]

Hi DINH Viêt Hoà,

on Tue, 1 Apr 2003 15:28:34 +0200 you wrote:

> I saw some minor problems in mplayer.
> 
> 1 - playlist with 100000 entries take a long to read, is there any 
> description of the philosophy of the playlist (for example, why a tree 
> and not a simple list ?) so that I can produce a patch to read it 
> faster.
The main idea as Colin said is to allow grouping of files. Each file/group
can have his own settings and heritate those from his parents in the tree.
Yeah it's somewhat wired, you like it or not.
Ok it was newer coded with speed in mind and i never thought that one will
create such big lists. Ok it's really slow. I tried a list of 10^5
entries. I got bored after more than 5 min and hitted Ctrl-C ;(
10^4 need about 6sec (on a K6-2 333) wich is ok imho, i mean that's a
very long list.
You can take a look at DOCS/tech/playtree. I wrote that once for .so,
it's old now but it may be usefull. Good luck anyway ;)

> 2 - filename is not freed :
> in mplayer.c 
>   filename = play_tree_iter_get_file(playtree_iter,eof);
> the string returned by play_tree_iter_get_file is never freed.
You got one :) MPlayer is sadly full of mem leak :(

> 3 - int get_sub_packet(void)
> this function is declared inside another function, which is does not 
> conform to C standard.
that's not so much of a problem as mplayer require gcc (and even only
some versions). But iirc on some systems the stack isn't executable so
regarding this it's a problem and should be fixed.

Can you send a patch ?

	Albeu