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

[Arpi]

Hi,

> >> > - 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.
> 
> A> I don't really understand the goal of that code.
> A> If user press ctrl+c, mplayer's sighandler will be called, it will uninit
> A> all layers, including stream, and exit.
> The hack in question allow you to interrupt a blocking operation
> without having to use ctrl+c wich quit mplayer. To be clear it work
> like this : when libmpdemux do a blocking operation it call a function
> that must check for user interupt. If that function return true then
> the current operation is aboarded an libmpdemux return an error code.
> Currently the function wich check for interrupt will return true if
> an event like quit,next file, etc come. In that case it will reput
> the event in the events queue to have it processed when we come
> back to mplayer.c All other events are discarded.
> On the mplayer side if the call to libmpdemux failed we check if it
> was bcs of an user interupt by checking if there's any event to
> process.
> So if the check function do nothing (ie always return false) it's like
> it was before.

ok.
so it should be completely libmpcemux-independent, an external func (in
mplayer.c??) called as callback from libmpdemux.

we could either
- force libmpdemux users to implement at least a dummy function for this
  (always returning false)
- use function pointer, set to NULL (or internal dummy impl.) by default,
  and teh caller can override it if it needs this callback.

it would bring out the input dependency from libmpdemux

nice to hear it isn't so messy just is implementd at wrong place.

> >> > - 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.
> A> maybe. or just use globals :)
> A> but the config struct sounds better.
> A> this way we could "atatch" the config struct to stream/demuxer structs, and
> A> the demuxer plugins can access it, but we can use multiple demuxers at the
> A> same time.
> imho we really need smthg to setup muliple instance of the same thing.
yes

> If it's successfull it can also be useful for the af/vf.
af/vf can handle ultiple instances now - no need to change

> >> > - the STREAMTYPE_PLAYLIST hack
> >> I"ll look at it, but it's no big issue.
> A> maybe put a flag into steram_t struct and set it if you detect it's a
> A> playlist, so the caller (mplayer.c) will know how to handle it.
> A> changing the stream type is an ugly hack, and it also disallow reading
> A> playlist from non-file/network media (hm. probably reading playlist from vcd
> A> is nonsense too - but maybe reading it from memory isn't)
> You'r right and it must be fixed but it's a detail atm, imho we don't
> need to worry about this until we really do something at the stream
> level (bcs stream with STREAMTYPE_PLAYLIST are only used by the
> playlist parsers, it never reach the demuxer level). BTW it work with
> netwok media as it's the only use of this ;)
but it's hack and also misleading.
with a modular design we wouldn't even have streamtype, just pointer to the
selected stream handler (function pointers to read/seek/close etc).
how do you imagine this playlist hack then?

> >> > 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
> A> no
> A> it doens't solve the problems inside teh mplayer tree, only if someone moves
> A> libmpdemux to other projects.
> A> for example, if i want to implement a small tool to append avi files, i have
> A> to include at least half of non-libmpdemux parts of mplayer to get it
> A> 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.
> A> yes
> Ok so my plans are :
>   - Finish the cleanup/rewrite of the config stuff (it should also make it
>     easy to add new kind of argument (like geometry) without having to
>     bothering with the internal of the various parsers)
>   - Lower the dependency of libmpdemux to mp_msg and the config stuff,
>     remove the STREAMTYPE_PLAYLIST hack, ...
no
it should NOT depend on mplayer's config stuff at all.
i see no reason to have any dependency.
it should be configurable by teh caller - via globals or struct passed at
init.

>   - Write the stuff to make the config system able to build/fill
>     structs if not done during step 1
huh?

please don't bring more mess and dependency to the config stuff.

> I hope to have a first patch ready in the next days for the first
> step. I must said that i'm a bit afraid in touching this config stuff
> again but it relly need a big cleanup :(

then left it as-is. the config part works, the playtree part is messy but we
used to it already.


A'rpi / Astral & ESP-team

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