Hi, Reinhard Nissl wrote:
Thomas Weber wrote:
The UI must be completely controlable from within vdr. Also we need some feedback from the UI. Hence there needs to be a bidirectional communication channel in some form (domain socket, tcpip, shared mem, whatever). All of the current xine plugin OSD code has to go into the new UI as well.
I'd like to avoid this, if possible.
...
I even don't like patching xine-ui to much, as every new feature (e. g. remote control) must be reimplemented in all other frontends too, to make them available for the users. And there are quite a lot frontends, as you can see on xine's home page.
...
Hey! I dont mind, of course ;-) Approach 2 looks fine to me.
Some different ideas:
1.) Why not writing a "super" demuxer plugin, which is a wrapper for the real demuxer plugins. Then it should be much easier to switch to a different demuxer, but the VDR part (something similar to the mplayer plugin) would then have to determine and select the correct demuxer plugin.
2.) Or what do you think about opening a second stream from within input_vdr? Despite what I wrote in the previous email, it should be worth a try. The second stream would use the same video and audio output as the first stream and finding the proper plugins to handle it would be done by xine-lib itself. And VDR's OSD would still be provided by the first stream.
I hope, you don't mind, that I'm not so happy with your suggested approach. But I would be very thankful, if you could find time to do some research on idea 2. As I'm currently getting ready for inclusion of input_vdr into xine, I won't find the time to do it myself.