[MPlayer-dev-eng] A new little feature, and lirc without fork

[Arpi]

Hi,

> > As a start, and an undelayable requirement, i want to split libmpdemux to
> > some modular plugin-like interface as libao/libvo/libmpcodecs.
> > Currently there are switch{} everywhere, you know...
> > Also, and to make it easier to test, i want to have it compile without
> > the bloat of mplayer core. Currently - thanks to you or/and Bertrand -
> > - it has some hack for ctrl+c handling while waiting for network connection,
> >   using some ugly callbacks to mplayer.c!???
> The hack in question depend only on input. In case of blocking operation
> a function is called to check for user interrupt.  The only avaible
> implementation 
> use input, but no callback. In short a #ifdef block solve this.

I don't really understand the goal of that code.
If user press ctrl+c, mplayer's sighandler will be called, it will uninit
all layers, including stream, and exit.

If i understood right, you wanted to change not to quit but jump to next
url/file instead. So it shoudl be changed _only_in_ mplayer.c, so teh
sighandler won't exit, just uninit and jump to next file. it can be tricky
anyway, maybe need to use longjmp().

imho it isn't libdemux's job to handle input events.

> > - deep usage of the playtree functions - imho in unneeded deep
> >   (yes i know you wanted to kill globals, and use get_value_of_XXX() instead
> >   but it didn't reach tits goal, but made it messy and have endless dependancy
> >   on everything)
> I know all this is a big mess. I'm currently cleaning up (rewriting ??)
> the config stuff.
> Most dependency problems come from the fact that the 'config system' (wich only
> allow setting the option) is completly mixed with the command line parser
> (wich need
> both the config and playtree stuff).  With the current 'design' libmpdemux
> only need
> the config stuff or less static declaration.
> Btw I thought to smthg about all this. If libmpdemux (or any other lib)
> may be used
> outside of mplayer it need to be easily configurable in a program. My idea
> is to
> define a few struct in libmpdemux that we use to pass the setting wanted
> by the user.
maybe. or just use globals :)
but the config struct sounds better.
this way we could "atatch" the config struct to stream/demuxer structs, and
the demuxer plugins can access it, but we can use multiple demuxers at the
same time.

> Then on the mplayer side we use the config stuff to automaticly build the
> struct out
> of the command line. So we don't need globals in libmpdemux and don't depend at
> all on the config stuff of mplayer inside of libmpdemux wich would be the best.
ok

> > - the STREAMTYPE_PLAYLIST hack
> I"ll look at it, but it's no big issue.
maybe put a flag into steram_t struct and set it if you detect it's a
playlist, so the caller (mplayer.c) will know how to handle it.
changing the stream type is an ugly hack, and it also disallow reading
playlist from non-file/network media (hm. probably reading playlist from vcd
is nonsense too - but maybe reading it from memory isn't)

> > I need to solve these first, to have a clean libmpdemux _again_.
> > It's actually a cleanup process, should not break anything. I hope, you can
> > help, as i don't understand your configtree/playtree code, especially the
> > network part.
> So in short it can be made kickly independent with a bunch of #ifdef and
> turning
no
it doens't solve the problems inside teh mplayer tree, only if someone moves
libmpdemux to other projects.
for example, if i want to implement a small tool to append avi files, i have
to include at least half of non-libmpdemux parts of mplayer to get it
compile... there is a test.c in libmpdemux, it should compile as-is.

> a few vars to global (so a host prog can set them). But imho it may be a
> better idea
> to first clearly decide how we pass the user setting to the sub parts of
> mplayer.
yes

> > libmpdemux should be an independent library, and should compile and work
> > without including 90% of other mplayer code. some parts, like mp_msg may be
> > ok, but don't depend on libinput, playtree and mplayer.c ...
> I agree, it would be even better if that was true for all libs ;)
atm only libmpdemux and libmpcodecs are kept independent.
actually libmpcodecs depends on libmpdemux but it's ok.

later we can look at libao/libvo, but it isn't so important.

> > Then i can do the pluginization of the demux_* and maybe the stream.c /
> > open.c files, and adding some new functions to demuxers at the same time.
> >
> > If we're fast, we can finish this before the 0.90.
> Sadly I don't have much time atm :(
:(


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu