[MPlayer-dev-eng] The path to RC2

[Benjamin Zores]

> Hello,
> On Sat, Nov 04, 2006 at 08:39:37AM +0100, Attila Kinali wrote:
>> On Fri, 3 Nov 2006 11:12:40 +0100
>> Benjamin Zores <ben at geexbox.org> wrote:
> [...]
>> > - A MUST HAVE: having a libmplayer to allow being controlled and tuned
>> more easily and from a more generic way than slave mode currently
>> allows.
>> > For VLC (again) wasn't meant to be used as a lib neither but they
>> implemented a library on top of their slave mode for external apps to
>> control it easily.
>> > Currently with MPlayer, everyone wanting to use slave mode has to
>> re-invent the wheel.
>> > Of course, having a _REAL_ library (i.e. no slave mode) would be the
>> best, making mplayer/gmplayer/mencoder code unified and they'll only
>> be frontends to this lib then.
>>
>> A lot of people wish this for a damn lot of time. But nobody
>> does it. And IMHO we should not do it before 1.0 as it is
>> a huge change in the code base.
>
> I absolutely disagree, there are libxine and ffmpeg (etc?), we don't need
> to do stuff because everyone else does, the close binding of libraries
> comes with many disadvantages up to and including weird crashes because
> of e.g. X threading issues (as discussed recently on the xine lib).
> I will veto any change in that direction in favour of any improved
> slave-mode systems which seems to me quite unique and gives bash-only
> "programmers" much easier access.


My proposition was not to have a complete rewrite of MPlayer to a
lib-based engine (even if it would be better to me but no one will ever do
so, so point closed). The idea was more to write an official libmplayer
wrapper to the slave mode (that's actually what VLC does through their
libvlc).

It'll help a lot C programmers to interact with MPlayer more easily
without having to re-invent the wheel each time (i.e writing to fifo and
parsing console output). Doing something like mpl_init (...) will spawn an
MPlayer instance with -idle -slave and then more functions can be defined
to actually control it through slave mode.

So frontends will only have a unique official libmplayer API to control it
through slave mode more easily.

But this will require adding 2 things:
- more slave mode controls (which would be required anyhow, with or
without a libmplayer wrapper) to allow changing MPlayer parameters on the
fly.
- some kind of event notification (i sent some incomplete patch dealing
about that a while ago) which would provide a fifo for output this time
and no longer for input.

Ben