On 11/01/11 20:52, VDR User wrote:
On Tue, Jan 11, 2011 at 12:41 PM, Tony Houghtonh@realh.co.uk wrote:
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 already have.