[MPlayer-dev-eng] comprehensive lavcopts test - in progress.

Roman Gaufman hackeron at dsl.pipex.com
Sun Jul 4 20:35:29 CEST 2004


Very interesting. I'm still learning python, so my script is coming along 
quite slowly :) -- I would really like to see your java code, so if you could 
email it to me, I'd be very grateful.


On Sunday 04 July 2004 15:35, Romain Dolbeau wrote:
> Roberto Ragusa wrote:
> > May I suggest to use a genetic algorithm?
>
> [snip nice explanations]
>
> > This method is really powerful.
>
> I'm trying that ATM. Seems pretty efficient. After exploring
> 0.001% of the design space, some options are already more
> or less washed out from the top 102. Exemple:
> "Float: [tcplx_mask]: null = 69 (67.6470588235294 %) tcplx_mask=0.1 = 28
> (27.45098039215686 %) tcplx_mask=0.2 = 5 (4.901960784313726 %)" That was
> after 340 results (out of 3359232 :-) were obtained
> (initial step of 102 then 7 steps of 34), and the original
> (random) distribution was:
> "Float: [tcplx_mask]: null = 42 (41.1764705882353 %) tcplx_mask=0.1 = 30
> (29.41176470588235 %) tcplx_mask=0.2 = 30 (29.41176470588235 %)"
>
> If someone is interested (and has a lot of computing power :-),
> I can supply the Java code. You need a recent JDK (on Linux/x86,
> j2sdk1.4.2_01 works but j2sdk1.4.1_01 locks up sometimes).
>
> Basically, the main process generate the options & handle
> the genetic algorithm, and distribute the work through RMI
> to RMI services on the server machines. Better have many
> of those :-)
>
> After each step, the code displays the best result (PSNR
> wise), the fastest result within x% of the best result
> (sometime losing 1% means a 10x speed increase :-), and
> the above stats.




More information about the MPlayer-dev-eng mailing list