Re: [vdr] Developer versions

2011-01-14 Thread L. Hanisch
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

Re: [vdr] Developer versions

2011-01-14 Thread Laz
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

Re: [vdr] Developer versions

2011-01-14 Thread Steffen Barszus
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

Re: [vdr] Developer versions

2011-01-14 Thread Klaus Schmidinger
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

Re: [vdr] Developer versions

2011-01-14 Thread Tobi
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

Re: [vdr] Developer versions

2011-01-14 Thread Laz
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

Re: [vdr] Developer versions

2011-01-14 Thread Tobi
Am 14.01.2011 16:30, schrieb Laz: Sounds good. Where can I get the script? Is it in one of your packages? I assume I'd also need to install the source for vdr to build against, or does that get pulled in as a build dependency? Just install vdr-dev. This includes the script and all header

Re: [vdr] Developer versions

2011-01-14 Thread VDR User
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

Re: [vdr] Developer versions

2011-01-14 Thread Klaus Schmidinger
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

Re: [vdr] Developer versions

2011-01-13 Thread Rolf Ahrenberg
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

Re: [vdr] Developer versions

2011-01-13 Thread Michal
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

Re: [vdr] Developer versions

2011-01-13 Thread Gerald Dachs
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

Re: [vdr] Developer versions

2011-01-13 Thread Lucian Muresan
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

Re: [vdr] Developer versions

2011-01-13 Thread Timothy D. Lenz
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

Re: [vdr] Developer versions

2011-01-13 Thread Timothy D. Lenz
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,

Re: [vdr] Developer versions

2011-01-13 Thread Oliver Schinagl
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

Re: [vdr] Developer versions

2011-01-13 Thread Gerald Dachs
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

Re: [vdr] Developer versions

2011-01-13 Thread Tony Houghton
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

Re: [vdr] Developer versions

2011-01-13 Thread Tony Houghton
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

Re: [vdr] Developer versions

2011-01-13 Thread VDR User
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

Re: [vdr] Developer versions

2011-01-13 Thread Tony Houghton
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

Re: [vdr] Developer versions

2011-01-13 Thread Klaus Schmidinger
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

Re: [vdr] Developer versions

2011-01-13 Thread Simon Baxter
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

Re: [vdr] Developer versions

2011-01-12 Thread Pertti Kosunen
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

Re: [vdr] Developer versions

2011-01-12 Thread Morfsta
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

Re: [vdr] Developer versions

2011-01-12 Thread Laz
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

Re: [vdr] Developer versions

2011-01-12 Thread Morfsta
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

Re: [vdr] Developer versions

2011-01-12 Thread Timothy D. Lenz
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

Re: [vdr] Developer versions

2011-01-12 Thread Timothy D. Lenz
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

Re: [vdr] Developer versions

2011-01-12 Thread Timothy D. Lenz
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

Re: [vdr] Developer versions

2011-01-12 Thread Timothy D. Lenz
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

Re: [vdr] Developer versions

2011-01-12 Thread Tony Houghton
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.

Re: [vdr] Developer versions

2011-01-12 Thread VDR User
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

Re: [vdr] Developer versions

2011-01-12 Thread VDR User
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

Re: [vdr] Developer versions

2011-01-12 Thread VDR User
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

Re: [vdr] Developer versions

2011-01-11 Thread Dominic Evans
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

Re: [vdr] Developer versions

2011-01-11 Thread Steffen Barszus
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

Re: [vdr] Developer versions

2011-01-11 Thread Eric Valette
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

Re: [vdr] Developer versions

2011-01-11 Thread Tony Houghton
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:

Re: [vdr] Developer versions

2011-01-11 Thread Gerald Dachs
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

Re: [vdr] Developer versions

2011-01-11 Thread Tony Houghton
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

Re: [vdr] Developer versions

2011-01-11 Thread Tony Houghton
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)...

Re: [vdr] Developer versions

2011-01-11 Thread Tony Houghton
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

Re: [vdr] Developer versions

2011-01-11 Thread Timothy D. Lenz
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

Re: [vdr] Developer versions

2011-01-11 Thread Tony Houghton
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

Re: [vdr] Developer versions

2011-01-11 Thread VDR User
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

Re: [vdr] Developer versions

2011-01-11 Thread VDR User
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

Re: [vdr] Developer versions

2011-01-11 Thread Eric Valette
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

Re: [vdr] Developer versions

2011-01-11 Thread Tony Houghton
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?

Re: [vdr] Developer versions

2011-01-11 Thread Torgeir Veimo
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

Re: [vdr] Developer versions

2011-01-11 Thread VDR User
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

Re: [vdr] Developer versions

2011-01-11 Thread Torgeir Veimo
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

Re: [vdr] Developer versions

2011-01-11 Thread VDR User
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

Re: [vdr] Developer versions

2011-01-10 Thread VDR User
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

Re: [vdr] Developer versions

2011-01-10 Thread Tobias Grimm
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

Re: [vdr] Developer versions

2011-01-10 Thread VDR User
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

Re: [vdr] Developer versions

2011-01-10 Thread Tony Houghton
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

Re: [vdr] Developer versions

2011-01-10 Thread Tony Houghton
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

Re: [vdr] Developer versions

2011-01-10 Thread Tony Houghton
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

Re: [vdr] Developer versions

2011-01-10 Thread Pauli Borodulin
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

Re: [vdr] Developer versions

2011-01-10 Thread Tobias Grimm
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:

Re: [vdr] Developer versions

2011-01-10 Thread VDR User
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

Re: [vdr] Developer versions

2011-01-10 Thread Tony Houghton
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

Re: [vdr] Developer versions

2011-01-10 Thread Tony Houghton
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