On 11/01/11 20:52, VDR User wrote:
On Tue, Jan 11, 2011 at 12:41 PM, Tony Houghton<h...@realh.co.uk>
I would prefer a ffmpeg (mplayer) based interface and dump xine
because xine/vdpau combo doesn't properly handle problems with
the atsc stream.
What about something based on gstreamer? Someone who understands
that could probably knock together a basic player that works with
xineliboutput in one day, but working out how to get the OSD would
be a bit harder. If whatever plugins gstreamer chooses
automatically to handle the TS etc turn out not to be suitable it
can easily be forced to use ffmpeg (or any other compatible plugin)
instead. It also has VDPAU and VA plugins.
I think the idea is that he'd like to get away from using xinelib
altogether in place of something else (ffmpeg). I'm not sure how
using gstreamer, that uses xineliboutput, that uses xinelib would
provide that. However, it sounds like gstreamer can just be forced
to use ffmpeg so that may be a solution. So you're suggesting for
example, a vdr-gstreamer plugin which uses ffmpeg to decode right?
Would be nice to have the option available but afaik the only
vdpau-supported output plugins for vdr are all based on xinelib.
And by all I mean vdr-xine and xineliboutput.
Perhaps I misunderstood how xineliboutput works, but I thought that when
using a remote client the VDR plugin component doesn't actually depend
on libxine, but just streams to a socket in a format that libxine can
decode. And that stream is just a standard TS except that some of the
packets contain OSD data? MPlayer and VLC can read the stream (not sure
about with VDR 1.7, but they could with the old PES version and I don't
see why they wouldn't work with TS too) and ignore the OSD. So any
client based on gstreamer and/or ffmpeg can already understand most of
the stream, it just needs a way to extract and display the OSD. Using
the existing xineliboutput plugin would save writing a new
VDR plugin which would just duplicate the functionality of one we
vdr mailing list