Reinhard Nissl wrote:
> James Courtier-Dutton wrote:
>> Reinhard Nissl wrote:
>>> I'm writing a device plugin for VDR
>>> (http://www.cadsoft.de/vdr/index.htm), to provide a software-only
>>> possibilty for playback by using xine. At the moment, I write the
>>> MPEG-PES data to a fifo and use xine to display the stream and that
>>> works very well so far.
>>> But now I need the hints of some xine wizards to direct me onto the
>>> right way.
>>> As next step, I want to display VDR's OSD by using xine's OSD API.
>>> But how do I get the OSD data from VDR to xine?
>>> One way would be to base my VDR plugin on xine-lib. I would then have
>>> the necessary API ready for use. The drawback is, that I will have to
>>> supply a lot of the functionality, that is already available in xine.
>>> So, my other idea is to stay with rich functionality of xine and
>>> write a demuxer plugin for xine too, that then separates MPEG-PES
>>> data from VDR-OSD data and does the necessary xine OSD calls. The VDR
>>> plugin will compose the VDR-OSD and MPEG-PES data together and pipe
>>> it to xine for display.
>>> Which approach is preferable and possible? Any ideas are very welcome.
>> We already have a dvb input plugin in xine.
>> Does this work in any way with your dvb hardware ?
> Well, VDR is a Video Disk Recorder. When playing back a recording (e. g.
> the one I sent you today), there shall be no DVB hardware involved. At
> the moment, VDR requires a full featured DVB card for playback, when it
> comes to displaying a OSD. Simple video playback is already possible
> xine or mplayer.
Ok, I thought you wanted to play live stream using xine.
> So I don't think, that the mentioned input plugin will be of any use for
> me. But I'll give it a try, as soon as I have upgraded my receiving
> equipment for DVB.
>> How is the VDR-OSD data formatted?
> An VDR-OSD can currently have up to 16 windows. Each window is
> represented by a max. 256 color uncompressed bitmap. The color palette
> currently use RGBA format, but I think it should be no problem to
> convert it to YUVA. My idea is to map each VDR window to a xine osd object.
Currently, xine can handle 5 overlays on the screen at once, but that
could be increased by changing a define statement. I just did not see
any need for more the 5 when I started the xine osd-events code.
It would probably be better for the gui front end code to just pass 1
overlay to xine, with the gui front end merging all the 16 windows into
one before sending it to xine. (Purely for performance reasons.)
There are issues with the OSD method used by xine when using the XV
output plugin. The issue is that if xine is de-interlacing, the
resolution of the overlays halves. I.e. Only alternate lines of the OSD
are actually displayed, with the lines in between being interpolated by
the XV hardware.
>> Is there one device for video, and a separate device for program info,
>> and possibly another for index info, or is it all multiplexed into a
>> single stream?
> From the point of VDR a device for playback only needs to support video
> playback, audio playback and (for a primary device) an OSD. The handling
> of all the other stuff is done by VDR internally.
I understand this now. I though you wanted xine to interface directly
with the VDR hardware, with the xine gui acting as the front end.
> Audio and video data is exchanged in MPEG-PES format and plays well with
> xine. But some difficulties arise with xine's metronom. When I playback
> the sample recording twice via VDR, then the second time, xine only
> shows me the last view seconds, because -- as I think -- xine considers
> the beginning of the stream as too old. Therefore, I would need to tell
> xine to reset the metronom at a certain point in time, e. g. when VDR
> informs me, that playback stopped respectively started, or when in
> passthrough mode a channel is switched (LIVE video).
> Multiplexing the MPEG-PES and VDR-OSD data is my idea to use a single
> fifo for data exchange to the existing xine binary.
That issue is probably down to using the fifo input plugin as you
currently are. There are better ways to do this, and I will explain them
at the bottom of this messages. Using the fifo input_plugin makes xine
thing that anything you send it is a single stream, with continuous PTS
values. The fifo plugin is not currently used much, so I doubt it has
any discontinuity detection code behind it.
>> The best thing to do will probably be to get the input plugin working
>> for video first, and then look at what to do with the OSD data.
> What I really would like to hear, is: stay with the xine binary and use
> a VDR-muxer/xine-demuxer combination, or use xine-lib directly from the
> VDR plugin, so you can easily display OSD data and maybe write an xine
> input plugin for direct MPEG-PES data exchange between VDR and xine.
> Your last sentence above points me to the second solution, doesn't it?
> But I fear to implement the numerous options, which the xine binary
> supplies so far.
You don't have to implement much to play a simple stream.
Just init, play, stop, free.
Then you will need to add overlay, seeking, playlist etc. as you need
them. The point is that everything is there in xine-lib, and you can
choose to use it or not.
There is already a xine gui that uses just OSD, called oxine.sf.net. You
might want to take a look at that.
I think that one thing you could do would be to use xine-lib directly,
maybe modify oxine to make it include all the features your current
application has, and then modify a xine-lib input plugin to handle
grabbing of the media stream from the hardware.
oxine acts as the gui front end, handling all the overlay control.
overlay commands are send directly to xine-lib from oxine. (no input
plugins or demuxers used)
oxine also sends messages to xine-lib telling it which stream to play.
e.g. Play from a file on the harddisk, Play live stream from the vdr
It is the input_dvb plugin that talks directly to the dvb hardware in
order to play a live video stream.
It is the input_file plugin that plays from a file on the hard disk.
I assume your current application handles play/stop events from the
user, these would just turn into xine-lib api calls.
It is better to use xine-lib api than just xine binary using the fifo