[vdr] Re: VDR/Xine video integration (was ANNOUNCE vdr-xine-0.4.3plugin)

[Reinhard Nissl <rnissl@gmx.de>]

Hi,

Thomas Weber wrote:

> In the other thread we ended up with this discussion:
>
> > > > I wonder, however, if its possible/planned to enhance the plugin to 
> > > > play also other media types like divx or mp3?
> > > > It would be cool to have a plugin similiar to the mplayer-plugin to 
> > > > watch movies. Reencoding (mpeg-pes) wouldnt be needed anymore,
> > > > so performance should be better compared to the current mplayer 
> > > > approach.
> > > Such thing I would like too. To enable this cDevice should be 
> > > extended to selectCodec (vcodec,acodec), so that we vdr-xine and 
> > > vdr-softdevice
> > > may select all of ffmpegs available codecs.
> > Well, it's not that easy. xine has a multistage plugin architecture: 
> > input-, demuxer-, decoder-, postprocess- and output-plugins.
> > I've written a new input plugin which interfaces VDR. All other stages 
> > are handled by already available plugins in xine. Typically, at least 
> > the input plugin is selected by the mrl (vdr:) and optionally the 
> > demuxer might be selected (#demux:mpeg_pes). Otherwise it is detected 
> > by looking on some sample data, which the input plugin must provide in 
> > that case. The demuxer relies on the input plugin to provide data in a 
> > certain format (e. g. MPEG PES packets) and then decides, which data 
> > is contained in the packets (e. g. BUF_VIDEO_MPEG, BUF_AUDIO_MPEG, 
> > BUF_AUDIO_A52). After that, xine decides which decoder to use.
> > ...
> > Finally, I hope that I could point out, why it is not that easy to 
> > support other formats transparently. But if someone finds a solution, 
> > I'll do my best to include it into my plugin.
> Well, can think of a possible approach to do it:
>
> We modify the Input Plugin and Xine-UI.
>
> 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. When I started this project, there where 
already some people pointing into this direction: create a new frontend and 
use xine-lib to play the stream.

I didn't want to go this way, because it takes a lot of time to create a full 
featured frontend like xine-ui. And what about the people who don't want to 
use xine-ui, but fbxine? You would have to code a further frontend to satisfy 
them.

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.

> After this work, the Input Plugin is only needed to transfer VDR video 
> (TV and Records) to the frontend. For Video/MP3 mode we could implement 
> a vdr plugin to "switch" the ui to another MRL. The OSD would still be 
> usable because of the separated control/communication channel.
>
> @Reinhard: Do you think this is possible? Is it worth a try?
Shure, it would be possible. But one would either get a new frontend or a 
patched xine-ui, which is not commitable to CVS.

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.

Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl@gmx.de