The next developer version of VDR will contain full True-Color OSD support.
^
Will this be a 1.8 release, or still in the 1.7 development train?
I guess it would still be a 1.7.x.
Lars.
___
vdr mailing list
On Monday 10 Jan 2011, Tobias Grimm wrote:
Am Montag, den 10.01.2011, 18:51 + schrieb Tony Houghton:
I'd also be interested in the developer version of xine with VDPAU
support. The trouble is there's a bewildering set of mercurial
branches. There are some libxine2 packages in Debian
2011/1/14 Laz l...@club-burniston.co.uk:
On Monday 10 Jan 2011, Tobias Grimm wrote:
deb http://e-tobi.net/vdr-experimental squeeze vdr-multipatch addons
base backports
deb-src http://e-tobi.net/vdr-experimental squeeze vdr-multipatch
addons base backports
Intriguing...
I also have another
On 14.01.2011 09:19, L. Hanisch wrote:
The next developer version of VDR will contain full True-Color OSD
support.
^
Will this be a 1.8 release, or still in the 1.7 development train?
I guess it would still be a 1.7.x.
It will be 1.7.17 - gotta test it before
Am 14.01.2011 11:19, schrieb Laz:
change to TS). You have the softdevice built against vdr-1.7.16 in your
repository. Does this work properly or has it just that it compiles and
hasn't been widely tested?
I guess nobody tested it yet, including me. It doesn't contain any
special patches for
On Friday 14 Jan 2011, Tobi wrote:
Am 14.01.2011 11:19, schrieb Laz:
change to TS). You have the softdevice built against vdr-1.7.16 in
your repository. Does this work properly or has it just that it
compiles and hasn't been widely tested?
I guess nobody tested it yet, including me. It
On Thu, Jan 13, 2011 at 1:40 PM, Klaus Schmidinger
klaus.schmidin...@tvdr.de 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
On 14.01.2011 18:33, VDR User wrote:
On Thu, Jan 13, 2011 at 1:40 PM, Klaus Schmidinger
klaus.schmidin...@tvdr.de 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
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
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
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 transparent
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
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
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,
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 the composite
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 to
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
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
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
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
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 need
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
On 11.1.2011 22:20, Timothy D. Lenz 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.
You can use ffmpeg decoding with xineliboutput.
~/.xine/config_xineliboutput:
# priority for ffmpegaudio
Why not exclusively use the yaVDR repositories?
My winter project has been to migrate my old hand compiled VDR-1.7.0
system using Reel EHD to yaVDR (distro) using a Nvidia GT210 with HDMI
audio. Its taken a bit of tweaking to get somewhere near (mostly
addressing audio sync issues when I used
On Wednesday 12 Jan 2011, Morfsta wrote:
Why not exclusively use the yaVDR repositories?
My winter project has been to migrate my old hand compiled VDR-1.7.0
system using Reel EHD to yaVDR (distro) using a Nvidia GT210 with HDMI
audio. Its taken a bit of tweaking to get somewhere near
On Wed, Jan 12, 2011 at 12:02 PM, Laz l...@club-burniston.co.uk wrote:
Sounds good. How are you running iPlayer, etc.? Through Firefox or
equivalent?
No. Boxee (and XBMC) provide BBC iplayer apps formatted for the big
screen that require only a remote control to navigate.
I've got a couple of
xineliboutput still uses xine. So it sounds like you are saying dump vdr
and keep xine. xine is the problem, not vdr.
On 1/11/2011 1:41 PM, Tony Houghton wrote:
On 11/01/11 20:20, Timothy D. Lenz wrote:
I would prefer a ffmpeg (mplayer) based interface and dump xine because
xine/vdpau combo
When vdr was using the hardware video out of a nexus card, it worked
great. I had a LOT fewer problems. The video interface plugin should be
just that and nothing more.
It doesn't need support for irc in it
It doesn't need lirc support, that is in vdr
There is an mplayer plugin if you need
Didn't nvidia do the early ffmpeg patch as part of the example of how to
support vdpau? That would explain why they work better together.
On 1/11/2011 9:30 PM, VDR User wrote:
That would be great actually. Or just having another option period
besides something dependent on libxine. The guy
But you still need xine to use xineliboutput. Even if not using it for
decoding. I tried onec before when someone said it could use ffmpeg and
found it still depended on xine. Just like xine needs a lot of crap
installed to compile it that is never used. KISS
On 1/12/2011 3:04 AM, Pertti
On 12/01/11 18:09, Timothy D. Lenz wrote:
xineliboutput still uses xine. So it sounds like you are saying dump vdr
and keep xine. xine is the problem, not vdr.
You misunderstand. xineliboutput has a number of components:
1. A stream server plugin.
2. An integrated player plugin based on xine.
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
On Wed, Jan 12, 2011 at 11:15 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
On Wed, Jan 12, 2011 at 2:33 PM, Tony Houghton h...@realh.co.uk wrote:
So there's no vdr output plugin option available that uses ffmpeg for
vdpau decoding and also provides the user with VDR's osd.
Hopefully someone capable of writing an output plugin will take
interest after reading all the
On 11 January 2011 01:14, Tony Houghton h...@realh.co.uk wrote:
Hm, probably not unless ttxtsubs is useful in the UK. I've been using
the Freesat patch up till now, but I'd probably be better off using the
Eepg plugin. I can probably borrow Debian bits for that from yaVDR
:).
Why not
2011/1/11 Dominic Evans oldma...@gmail.com:
On 11 January 2011 01:14, Tony Houghton h...@realh.co.uk wrote:
Hm, probably not unless ttxtsubs is useful in the UK. I've been using
the Freesat patch up till now, but I'd probably be better off using the
Eepg plugin. I can probably borrow Debian
https://launchpad.net/~yavdr/+archive/stable-vdr
cause its ubuntu and he uses debian ? ;)
The yavdr packages works fine on debian (or at least as on ubuntu)...
-- eric
___
vdr mailing list
vdr@linuxtv.org
On 11/01/11 12:16, Eric Valette wrote:
https://launchpad.net/~yavdr/+archive/stable-vdr
cause its ubuntu and he uses debian ? ;)
The yavdr packages works fine on debian (or at least as on ubuntu)...
Except that:
The following packages have unmet dependencies:
libxine2 : Depends:
And yavdr doesn't include sxfe for some reason.
That is complete nonsense:
https://launchpad.net/~yavdr/+archive/stable-vdr/+files/xineliboutput-sxfe_1.0.6%2Bcvs20110110.1350-0yavdr0_i386.deb
Gerald
___
vdr mailing list
vdr@linuxtv.org
On 11/01/11 14:37, Gerald Dachs wrote:
And yavdr doesn't include sxfe for some reason.
That is complete nonsense:
https://launchpad.net/~yavdr/+archive/stable-vdr/+files/xineliboutput-sxfe_1.0.6%2Bcvs20110110.1350-0yavdr0_i386.deb
You could have just pointed out that launchpad's index only
On 11/01/11 15:51, Eric Valette wrote:
On 01/11/2011 03:18 PM, Tony Houghton wrote:
On 11/01/11 12:16, Eric Valette wrote:
https://launchpad.net/~yavdr/+archive/stable-vdr
cause its ubuntu and he uses debian ? ;)
The yavdr packages works fine on debian (or at least as on ubuntu)...
On 11/01/11 18:23, Timothy D. Lenz wrote:
xine-lib-1.2-vdpau is just a link to xine-lib-1.2. Use ether one and you
get the same. You want:
hg clone http://hg.debian.org/hg/xine-lib/xine-lib-1.2
and if you are using vdr-xine plugin:
hg clone http://hg.debian.org/hg/xine-lib/xine-ui/
I prefer
I would prefer a ffmpeg (mplayer) based interface and dump xine because
xine/vdpau combo doesn't properly handle problems with the atsc stream.
The way I understand it according to rnissl in #xine, when there is any
corruption to the stream, vdpau changes the image size, rounding the
number or
On 11/01/11 20:20, Timothy D. Lenz 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
On Tue, Jan 11, 2011 at 12:20 PM, Timothy D. Lenz tl...@vorgon.com 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.
I've seen several users express the want for an ffmpeg-based video
output
On Tue, Jan 11, 2011 at 12:41 PM, Tony Houghton h...@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
On 11/01/2011 19:11, Tony Houghton wrote:
I don't get any picture at all on HD channels, with or without VDPAU.
Last time I checked the yavdr packages, I was not getting HD either.
Manually compiling vdr doing removal from the debian patches series of
everything that was not tagged as
On 12 January 2011 10:23, Tony Houghton h...@realh.co.uk wrote:
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
On Tue, Jan 11, 2011 at 4:40 PM, Torgeir Veimo torg...@netenviron.com 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.
You can always try softdevice, which is mostly a playback interface
On 12 January 2011 13:09, VDR User user@gmail.com wrote:
On Tue, Jan 11, 2011 at 4:40 PM, Torgeir Veimo torg...@netenviron.com wrote:
You can always try softdevice, which is mostly a playback interface
using ffmpeg.
Isn't softdevice abandoned?
It hasn't seen any new features added for a
On Tue, Jan 11, 2011 at 7:32 PM, Torgeir Veimo torg...@netenviron.com wrote:
You can always try softdevice, which is mostly a playback interface
using ffmpeg.
Isn't softdevice abandoned?
It hasn't seen any new features added for a while, but should still
work as a software only playback
I don't find VDR 1.6.0 very reliable and I'm wondering whether 1.7 is
mature enough now to be worth setting up. At the moment I use Debian
packages and although I have to recompile it to add the Freesat patch
it's still a lot easier than gathering the bits and pieces and getting
it to live nicely
On Mon, Jan 10, 2011 at 10:51 AM, Tony Houghton h...@realh.co.uk wrote:
I don't find VDR 1.6.0 very reliable and I'm wondering whether 1.7 is
mature enough now to be worth setting up. At the moment I use Debian
packages and although I have to recompile it to add the Freesat patch
it's still a
Am Montag, den 10.01.2011, 18:51 + schrieb Tony Houghton:
I'd also be interested in the developer version of xine with VDPAU
support. The trouble is there's a bewildering set of mercurial branches.
There are some libxine2 packages in Debian experimental, but there don't
seem to be any
On Mon, Jan 10, 2011 at 11:09 AM, VDR User user@gmail.com wrote:
You appear to want xine-lib-1.2, although I have no clue why you would
be confused about the trees. To my knowledge, there is only one
available at: hg clone http://hg.debian.org/hg/xine-lib/xine-lib-1.2
Sorry, I should
On 10/01/11 19:28, Tobias Grimm wrote:
Am Montag, den 10.01.2011, 18:51 + schrieb Tony Houghton:
I'd also be interested in the developer version of xine with VDPAU
support. The trouble is there's a bewildering set of mercurial branches.
There are some libxine2 packages in Debian
On 10/01/11 19:09, VDR User wrote:
You appear to want xine-lib-1.2, although I have no clue why you would
be confused about the trees. To my knowledge, there is only one
available at: hg clone http://hg.debian.org/hg/xine-lib/xine-lib-1.2
That's fine if you know what you're looking for, but
On 10/01/11 19:28, Tobias Grimm wrote:
Am Montag, den 10.01.2011, 18:51 + schrieb Tony Houghton:
I'd also be interested in the developer version of xine with VDPAU
support. The trouble is there's a bewildering set of mercurial branches.
There are some libxine2 packages in Debian
On 10.1.2011 22:52, Tony Houghton wrote:
[...]
That's fine if you know what you're looking for, but the front page of
xine's official site links to the top-level of hg.debian.org which
contains getting on for 50 xine-lib branches. Including
xine-lib-1.2-vdpau which is apparently being developed
Am Montag, den 10.01.2011, 20:56 + schrieb Tony Houghton:
I see you have VDR 1.7 packages there too, I'd definitely be interested
in those. Would you recommend multipatch over standard?
Depends on your needs - decide for yourself - multipatch currently
includes the following patches:
On Mon, Jan 10, 2011 at 12:52 PM, Tony Houghton h...@realh.co.uk wrote:
You appear to want xine-lib-1.2, although I have no clue why you would
be confused about the trees. To my knowledge, there is only one
available at: hg clone http://hg.debian.org/hg/xine-lib/xine-lib-1.2
That's fine if
On 11/01/11 00:55, VDR User wrote:
There's no hassle involved by avoiding using debian sources. If you
ever decide you would like to try it and see, I'll even help you with
a script that does it all automagically.
Thanks, but I think I'll use Tobias' packages. It isn't just little
things like
On 10/01/11 22:36, Tobias Grimm wrote:
Am Montag, den 10.01.2011, 20:56 + schrieb Tony Houghton:
I see you have VDR 1.7 packages there too, I'd definitely be
interested in those. Would you recommend multipatch over standard?
Depends on your needs - decide for yourself - multipatch
Rolf Ahrenberg wrote:
On Wed, 27 Jun 2007, Luca Olivetti wrote:
I just commented out these lines and it seems to work (though lately I'm
not using it very much).
Thank you Luca it works if i comment out four lines in ttxtsubsdisplay.c.
Well, I guess it only works if your VDR is
Magnus Andersson wrote:
Hello!
Does vdr-ttxtsubs plugin work with any of the latest vdr developer versions?
Not for me. I get compile errors (although different) with and without
the kermanekka-patch.
/Magnus Hörlin
I have patched vdr with
vdr-1.5.5-subtitles-0.5.0-and-ttxtsubs-0.0.5
En/na Magnus Andersson ha escrit:
ttxtsubsdisplay.c: In member function ‘void cTtxtSubsDisplay::ShowOSD()’:
ttxtsubsdisplay.c:415: error: ‘SetCode’ is not a member of ‘cFont’
ttxtsubsdisplay.c:415: error: ‘I18nCharSets’ was not declared in this scope
ttxtsubsdisplay.c:438: error: ‘SetCode’ is
Magnus Andersson wrote:
Hello!
Does vdr-ttxtsubs plugin work with any of the latest vdr developer versions?
Not for me. I get compile errors (although different) with and without
the kermanekka-patch.
/Magnus Hörlin
I have patched vdr with
vdr-1.5.5-subtitles-0.5.0-and-ttxtsubs-0.0.5
67 matches
Mail list logo
