And you are back to layer on layer on layer. If someone is going to
write something, let it be the plugin that talks to vdr and ffmpeg.
Forget xineliboutput, libxine, etc. The more middle ware we can dump the
On 1/12/2011 12:15 PM, Tony Houghton wrote:
On 12/01/11 18:42, VDR User wrote:
On Wed, Jan 12, 2011 at 10:31 AM, Tony Houghton<h...@realh.co.uk> wrote:
1. A stream server plugin.
2. An integrated player plugin based on xine.
3. Standalone xine-based players for connecting to the server.
I propose using 1, ignoring 2 (you can disable it with CLI options, I do
this anyway because it's more convenient for me to use a client-server
setup) and replacing 3 with something based on ffmpeg and/or gstreamer.
From xineliboutput's README:
: (xine-lib is not required for server in network-only usage)
network usage can include localhost.
And you get VDR's full osd doing this?
Yes, if you use a libxine-based player which supports it (the support is
now in libxine). So to replace xine with something else someone needs to
work out how xineliboutput serves up the OSD and write something to read
it. If it's embedded as private data packets or whatever in the TS I
think it should be possible to hook into ffmpeg's or gstreamer's
demuxers to get access to it.
vdr mailing list