Tony Houghton skrev 2011-01-13 18:44:
The client-server model is almost essential to me. I wouldn't be
interested in a solution that ties me to watching on one PC only and
won't let me turn off playback without also preventing background
recording. I'd be using mythtv by now if the DVB-S support
AIUI VDR generates the OSD as a bitmap no matter which output plugin is
used and the player only has the choice of how to overlay it on the
video. So getting it rendered by VDPAU would be easy enough, but to
upgrade it to HD would probably need some rewriting/patching in core
VDR, not just a plugi
On 13.01.2011 21:42, Tony Houghton wrote:
> ...
> AIUI VDR generates the OSD as a bitmap no matter which output plugin is
> used and the player only has the choice of how to overlay it on the
> video. So getting it rendered by VDPAU would be easy enough, but to
> upgrade it to HD would probably nee
On 13/01/11 18:57, VDR User wrote:
I agree, the less layer upon layer upon layer, the better. I also
want to point out that there are a large number of users who have
dedicated VDR boxes connected directly to tv's in an htpc environment,
using only a remote control to navigate the menus and ssh
I agree, the less layer upon layer upon layer, the better. I also
want to point out that there are a large number of users who have
dedicated VDR boxes connected directly to tv's in an htpc environment,
using only a remote control to navigate the menus and ssh for box
maintenance. Not computer mo
On 13/01/11 16:50, Timothy D. Lenz wrote:
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
better.
So maybe your needs would be best se
On 13/01/11 00:11, VDR User wrote:
So instead of maintaining just a plugin (which depends on ffmpeg
decoding rather then xinelibs decoding), you think maintaining a new
player altogether in addition to a plugin that streams data into it?
Not to mention forcing VDR into being a backend only. I kn
> oh, so now we need opengl and a compositing manager on top of
> everything else? You miss the point.
If you would quote mails right you would have noticed that I answered
a sentence that told that it doesn't work at all. How did I
miss this point?
> > have been far from successful. It appears t
On 01/13/11 15:46, Gerald Dachs wrote:
>>
>> On 01/13/11 13:31, Rolf Ahrenberg wrote:
>>> On Wed, 12 Jan 2011, VDR User wrote:
>>>
And you get VDR's full osd doing this?
>>> FYI, xineliboutput provides three different OSD implementations:
> xinelib, composite HUD, and opengl HUD. For example
oh, so now we need opengl and a compositing manager on top of everything
else? You miss the point.
I don't have a problem with vdr being usable as client/server. There are
advantages. But it doesn't need to be so complex and it is seperate form
the local renderer.
On 1/13/2011 7:46 AM, Geral
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
better.
On 1/12/2011 12:15 PM, Tony Houghton wrote:
On 12/01/11 18:42, VDR User wrot
On 13.01.2011 13:31, Rolf Ahrenberg wrote:
> On Wed, 12 Jan 2011, VDR User wrote:
>
>> And you get VDR's full osd doing this?
>
> FYI, xineliboutput provides three different OSD implementations:
> xinelib, composite HUD, and opengl HUD. For example the composite HUD
> OSD is drawn directly onto t
>
>
> On 01/13/11 13:31, Rolf Ahrenberg wrote:
>> On Wed, 12 Jan 2011, VDR User wrote:
>>
>>> And you get VDR's full osd doing this?
>>
>> FYI, xineliboutput provides three different OSD implementations:
xinelib, composite HUD, and opengl HUD. For example the composite HUD
OSD is drawn directly ont
On 01/13/2011 03:24 PM, Oliver Schinagl wrote:
I'm curious as to how you got the composite and opengl HUD's working, I
have been far from successful. It appears to just not work at all :S
I've tried composite HUD and it works and looks really nice. The bad is
that enabling composite extension
On 01/13/11 13:31, Rolf Ahrenberg wrote:
> On Wed, 12 Jan 2011, VDR User wrote:
>
>> And you get VDR's full osd doing this?
>
> FYI, xineliboutput provides three different OSD implementations:
> xinelib, composite HUD, and opengl HUD. For example the composite HUD
> OSD is drawn directly onto tra
On Wed, 12 Jan 2011, VDR User wrote:
And you get VDR's full osd doing this?
FYI, xineliboutput provides three different OSD implementations:
xinelib, composite HUD, and opengl HUD. For example the composite HUD
OSD is drawn directly onto transparent window located exactly over the
(xine-lib
16 matches
Mail list logo
