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

[Alban Bedel]

Hi Arpi,

on Tue, 22 Oct 2002 16:56:23 +0200 you wrote:

> Hi,
> 
> > I rewrote the lirc code to remove the fork, attached is a patch that i
> RTFM DOCS/tech/patches.txt :))))
> (please include [PATCH] in subject next time)
I'm sloooowly coming back ;))

> > can't test bcs i
> > haven't any remote atm. If someone can test it (and fix it if needed and
> > possible ;).
> maybe you should send it to -users too
Too much traffic for me atm :(

> > PS Arpi : You told me on irc that you want to start to cleanup libmpdemux. Many
> > things have been said about the futur capabilities of libmpdemux but all
> > this is
> > split across 100 mails. So I think it may be good to summuries all this
> > and discuss
> > it a bit deeply.
> 
> Yes. I had many big plans mostly abandoned or delayed.
> 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.

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

> - the STREAMTYPE_PLAYLIST hack
I"ll look at it, but it's no big issue.

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

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

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

> Then, i have some far plans... like multiple audio/video stream support in
> demuxers (useful for mencoder), rewriting combined 3-level mpeg demuxer
> (TS/PS/ES level, both audio & video), rewriting AVI demuxer (opendml
> support, runtime index rebuilding etc). These new demuxers could be the
> first 'reference implementation' of the new interface with multiple a/v
> support. Modifying teh MOV and REAL demuxers shouldn't be hard then, as they
> already operates on per-stream private structs. Maybe .ogm too.
> 
> Btw, ogm. Could you please fix teh big memleak in demux_ogg.c, allocating
> ~600k memory at opening the libogg stream while doing filetype detection?
> (so even if you play an mpeg, it opens first as ogg, recognizes it isn't ogg
> but libogg isn't uninited - i've added teh destroy...() call but it makes
> memory corruption somewhere, probably i didn't do uin right ordre or dunno)
Ok, I'll look.

	Albeu