[MPlayer-dev-eng] Size of codecs_t, CODECS_MAX_FOURCC

[Compn]

On Wed, 31 May 2017 10:34:52 +0300, Lauri Kasanen <cand at gmx.com> wrote:

> On Tue, 30 May 2017 13:44:57 -0400
> Compn <tempn at mi.rr.com> wrote:
> > > Having just updated mplayer, I had a quick look at its current size.
> > > The builtin codec arrays take 700kb currently.
> configure args:
> --prefix=/usr --disable-real --disable-xanim --confdir=/etc/mplayer
> --enable-menu --disable-fribidi --disable-win32dll --disable-qtx
> --disable-vidix --disable-vidix-pcidb
> --extra-cflags=-I/usr/X11R7/include --extra-ldflags=-L/usr/X11R7/lib
> --disable-cddb --cc=/opt/gcc52/bin/gcc --disable-relocatable
> --enable-openssl-nondistributable --disable-mencoder --disable-pvr
> 
> 16180612, 16mb.

ehe
i remember someone was able to compile mplayer down to under 2mb

1,533,440 mplayermd.exe

still runs too.

C:\>mplayermd
MPlayer dev-CVS-040406-03:13-3.3.1 (C) 2000-2004 MPlayer Team

> > is there a way to change the code without reducing the max fourcc
> > number, so that it does not require that much size in the binary?
> 
> Certainly, by making dedicated fourcc and fourccmap arrays, and
> replacing those in codec_t with a start index and a count. That's a lot
> more work than just reducing the number, though.

sure.

disabling ffmpeg codecs you dont use will also shrink binary size too.
probably there are also some gcc options as well.

> > unfortunately, i think we will find more mpeg2 fourcc in the wild in
> > the future, so i am not for reducing this max fourcc number.
> 
> Why would that be a blocker? If more mpeg2 fourccs appear, then the max
> would be increased at that time?

if you want to maintain the fourcc max, i wont stop you. i just think
it would be better to fix the code in other ways than to play with the
max fourcc limit. or to even have a limit at all, but what do i know.

other things to try:
switch libs, e.g. gnutls vs openssl
disable other features , like tv:// support if you dont use it.
or dvd://. who still has a dvd drive? or dvd isos ? hmm

it would be interesting to see who could make the smallest mplayer
binary now. while supporting the most features and codecs of course.

-compn