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

[Arpi]

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)

> 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

> 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!???
- 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)
- the STREAMTYPE_PLAYLIST hack

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.

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

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.

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)


A'rpi / Astral & ESP-team

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