[MPlayer-dev-eng] userfriendly release? don't flame...

Anders Rune Jensen root at gnulinux.dk
Thu Mar 14 20:08:57 CET 2002


* Arpi <arpi at thot.banki.hu> [2002-03-14 19:39:42]:
> Hi,
> 
> We're getting closer to the next release every day.
> No, do not ask the date, I don't know yet. But we really should
> make something, as ppl still downloading 0.60, ~ 1000 times per day.
> And - as you know - 0.60 is really old "shit", we've solved many
> bugs and also implemented some of the most wanted features, like 'f'
> or audio from separate file, and also some speed stuff like DR,
> faster libavcodec etc... Not talkin' about dxr3 and dvb drivers,
> they were unusable buggy/slow in 0.60.
> 
> But. If we ever make a new release in the near future, we should at least:
> code side:
> - switch to fully GPL - is it possible by now? (by removing opendivx src)

Since ffmpeg is very good there should be no problem leaving the opendivx
out and making a fully GPL release, which would be very nice!

> - enable runtime cpu detection stuff to make binary packagers happy

GPL and binary packeges would allow a lot of distributions to include
mplayer, this is both good and bad. Good because there will be lots of
mirrors, but bad because they might download old versions of mplayer (I mean
downloading 0.6 is ...!). Maybe it would be possible to release more often.

> - check XviD - we should include it in the release, but only if it's
>   really GPL and bugfree.

Lately there has been a lot of updates to Xvid (like core rewrite!), so I
don't think you'll get a stable version. Also b-frames are just around the
corner :-)

> - do deep testing of player, with various codecs and file formats
>   (using sample collection at mphq)
> - do portability checks (compiling on *bsd, solaris, etc)
> - review users' feature requests - many of them are easy to implement
> ui side:
> - fix gui bugs, or disable buggy code (like nonworking playlist stuff)
> - finish installer, add codec downloading from M$ etc if needed.
> - add more hints to messages, like 'use -ni' to buffer overflow error,
>   or descriptive hints for signal crashes, depending on signal no. and
>   module name crashed.
> - update help_*.h files to contain new warning/error messages over the
>   source - or maybe switch to the gnu localization stuff?

This would really help the translaters (like me :)). Maybe even the
developers, since they don't have to bother so much about the translation 
...
If a language doesn't have a definition it just falls back to english for 
only that!
Also this would allow usage of several languges after install so no 
recompile :) Put this in the binary packages perspective.

> pr side:
> - review and update docs. it really needs some reorganizing, and the
>   review of options, facts, and other things changed in last months.
> - find more mirrors. at time of 0.60 release, the avg bandwith usage of
>   mphq server was around 300kbyte/s for a week. it's too much here :(
> - new homepage design (DONE) - switch to mhtml and allow users to change
>   'web theme', i mean between the 3 design schemes (prev, current and new).
> 
> 
> A'rpi / Astral & ESP-team
> 
> --
> Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu

Med venlig Hilsen / Sincerely

Anders Rune Jensen (icq: #52926571)








More information about the MPlayer-dev-eng mailing list