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

[Alban Bedel]

Hello Arpi,

Wednesday, October 23, 2002, 1:39:47 PM, you wrote:

A> 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.

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.

A> If i understood right, you wanted to change not to quit but jump to next
A> url/file instead. So it shoudl be changed _only_in_ mplayer.c, so teh
A> sighandler won't exit, just uninit and jump to next file. it can be tricky
A> anyway, maybe need to use longjmp().
See above it has nothing to do with signal handler or stuff like this.

A> imho it isn't libdemux's job to handle input events.
I agree on this but if ctrl+c(=quit) is the only way to interupt
network/cache it's a pain (like when 1 server in a playlist is down or
way too slow you have to ctrl+c, edit the playlist, restart mplayer)

>> > - 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.
If it's successfull it can also be useful for the af/vf.

>> 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.
A> ok

>> > - 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 ;)

>> > 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, ...
  - Write the stuff to make the config system able to build/fill
    structs if not done during step 1
  - Use the struct based approch inside libmpdemux -> no more dep on
    the config stuff
  - Pluginize the demuxers and the streams

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 :(

 Albeu