Re: [vdr] Developer versions
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 vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 experimental, but there don't seem to be any packages for version 2 players, nor libxine2-dev packages (not to mention vdpau support) so I don't see what use they If it's just about the VDPAU support, you can use the xine 1.1.19 from my repository which includes VDPAU support an seems to work well on Squeeze. 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've always built vdr and a range of plugins from source, all under Debian. I've just been browsing the contents of your repository and I see that you do have what looks like most of the plugins I'm currently using in there. One question before I test your pre-compiled version... I'm currently using the softdevice plugin but I've never managed to get it to work with any versions of vdr newer than 1.7.0 (probably due to the 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 think all I ever got was a black screen whenever I tried to build CVS softdevice against anything newer than 1.7.0! I also have another plugin which controls some LEDs hung of the parallel port which light up when recordings are active, etc. (based on a plugin I found years back which I'm pretty sure is no longer developed). How easy is it to combine a single plugin built from source into a .deb based setup? Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 plugin which controls some LEDs hung of the parallel port which light up when recordings are active, etc. (based on a plugin I found years back which I'm pretty sure is no longer developed). How easy is it to combine a single plugin built from source into a .deb based setup? Tobias has created some time back a command called debianize-vdr-plugin. Using that it should be matter of minutes to create a deb from your plugin (for your local use). ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 pronouncing it stable ;-) Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 1.7.16, so it will probably not work. I also have another plugin which controls some LEDs hung of the parallel port which light up when recordings are active, etc. (based on a plugin I found years back which I'm pretty sure is no longer developed). How easy is it to combine a single plugin built from source into a .deb based setup? As Steffen already answered, it's as easy as running debianize-vdr-plugin. This works for most of the plugins and should at least give you something, that can be easily tweaked. Tobias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 doesn't contain any special patches for 1.7.16, so it will probably not work. I may give it a quick go: I'll have to work out whether installing it will break my currently working system. I'm pretty sure everything is under /usr/local and so shouldn't be overwritten: it pays to be paranoid! :-) I also have another plugin which controls some LEDs hung of the parallel port which light up when recordings are active, etc. (based on a plugin I found years back which I'm pretty sure is no longer developed). How easy is it to combine a single plugin built from source into a .deb based setup? As Steffen already answered, it's as easy as running debianize-vdr-plugin. This works for most of the plugins and should at least give you something, that can be easily tweaked. 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? Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 upgrade it to HD would probably need some rewriting/patching in core VDR, not just a plugin. I think the ability to antialias the text would be the biggest improvement, it often looks jagged. The next developer version of VDR will contain full True-Color OSD support. I'm in the final stages of implementing all that's necessary to do that, like background image, transparent and movable overlayed pixmaps and the like. Wow, wasn't expecting that! Did you get a new tv or something? ;) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 VDPAU would be easy enough, but to upgrade it to HD would probably need some rewriting/patching in core VDR, not just a plugin. I think the ability to antialias the text would be the biggest improvement, it often looks jagged. The next developer version of VDR will contain full True-Color OSD support. I'm in the final stages of implementing all that's necessary to do that, like background image, transparent and movable overlayed pixmaps and the like. Wow, wasn't expecting that! Did you get a new tv or something? ;) No. It's more like I got sick and tired of permanently hearing how bad VDR's OSD is... Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 powered) video window and therefore is completely independent from the actual video decoding library. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 breaks vsync, so in the end it is unusable. Michal ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 window located exactly over the (xine-lib powered) video window and therefore is completely independent from the actual video decoding library. 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 Both are working. You need a compositing manager like xcompmgr or compiz for the first possibility, or the option --opengl-all (not sure about correct typing for the second possibility. Gerald ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 transparent window located exactly over the (xine-lib powered) video window and therefore is completely independent from the actual video decoding library. Maybe a dumb question, but does that mean, at least in theory, something like XBMC could be extended to be able to talk to vdr-xineliboutout just like vdr-sxfe does for example and also get the genuine VDR OSD and render it over the video streamed from VDR? If yes, what are roughly the things that have to be implemented? I'm asking because I'd like to be able to access _full_ VDR functionality (like editing for example to name just an important one) without leaving XBMC, which is not provided by the current streamdev or VNSI addons in XBMC. That would give us video decoding without xine-lib, a really nice UI and true unification of both VDR and XBMC experiences. Of course, there also has to be a functionality in the event system of XBMC which toggles control between XBMC and VDR... Cheers, Lucian ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 wrote: On Wed, Jan 12, 2011 at 10:31 AM, Tony Houghtonh...@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 vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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, 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 HUD OSD is drawn directly onto transparent window located exactly over the (xine-lib powered) video window and therefore is completely independent from the actual video decoding library. 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 Both are working. You need a compositing manager like xcompmgr or compiz for the first possibility, or the option --opengl-all (not sure about correct typing for the second possibility. Gerald ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 HUD OSD is drawn directly onto transparent window located exactly over the (xine-lib powered) video window and therefore is completely independent from the actual video decoding library. 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 Both are working. You need a compositing manager like xcompmgr or compiz for the first possibility, or the option --opengl-all (not sure about correct typing for the second possibility. i'll try --opengl-all then; i have xcompmgr installed, i do have a very bare install however, i use aterm -e to launch the client, with aterm being my 'window manager'. Gerald ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 just not work at all :S Both are working. You need a compositing manager like xcompmgr or compiz for the first possibility, or the option --opengl-all (not sure about correct typing for the second possibility. Gerald ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 know some people have had success turning VDR into a server/client system but when I tried it, it was trash and a long way from usable in a 'stable' or 'daily use' VDR environment so I'm not that easily convinced the idea is a great one. 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 in the setup tool wasn't completely broken. VDR's inherent limitations are that you can't have more than one client using it at once with separate OSDs etc, but that's acceptable to me as long as I have a choice of which room to watch in. Client-server doesn't have to make it unreliable, but admittedly it does increase complexity and therefore the likelihood of bugs. If written in a modular way the same bits of code could be used in two different plugins, one completely inetgrated and one client-server, so I won't say I'm completely disinterested in an all-in-one plugin. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 served by getting the softdevice plugin actively maintained again, including a developer with an interest in VDPAU. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 monitors, using VDR in a window in a desktop environment. The second you've required the user to have a full blown desktop, you've entered the realm of poor design. The ideal situation would be to have minimal requirements/dependencies and no bloat. Additionally, an OSD that takes advantage of vdpau as well so you not only get full HDTV, but also a full high resolution/high color OSD with low hardware requirements cost to the user to go along with it. I know the OSD has been a point of debate but the truth is people do spend a lot of time in the OSD and because of that, there's no reason that can't be an enjoyable user experience. Chalking it up as mere eye candy completely disregards that fact. It's no different to the reason why people put nice stereos in their car... to have a better experience while using it. Given the choice between a nice Benz or a base model Kia...how many people would actually choose the Kia? Not many, so lets not pretend otherwise. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 for box maintenance. Not computer monitors, using VDR in a window in a desktop environment. The second you've required the user to have a full blown desktop, you've entered the realm of poor design. The ideal situation would be to have minimal requirements/dependencies and no bloat. Client-server doesn't require a desktop environment. You can just as easily arrange for the player client to start automatically and have VDR handle the remote control. My preference for being able to turn the player off goes back a long way though, to when VDR didn't have good support for playing other video files. There are a lot of people who also use XBMC etc. Additionally, an OSD that takes advantage of vdpau as well so you not only get full HDTV, but also a full high resolution/high color OSD with low hardware requirements cost to the user to go along with it. I know the OSD has been a point of debate but the truth is people do spend a lot of time in the OSD and because of that, there's no reason that can't be an enjoyable user experience. Chalking it up as mere eye candy completely disregards that fact. It's no different to the reason why people put nice stereos in their car... to have a better experience while using it. Given the choice between a nice Benz or a base model Kia...how many people would actually choose the Kia? Not many, so lets not pretend otherwise. 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 plugin. I think the ability to antialias the text would be the biggest improvement, it often looks jagged. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 some rewriting/patching in core VDR, not just a plugin. I think the ability to antialias the text would be the biggest improvement, it often looks jagged. The next developer version of VDR will contain full True-Color OSD support. I'm in the final stages of implementing all that's necessary to do that, like background image, transparent and movable overlayed pixmaps and the like. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 plugin. I think the ability to antialias the text would be the biggest improvement, it often looks jagged. The next developer version of VDR will contain full True-Color OSD support. I'm in the final stages of implementing all that's necessary to do that, like background image, transparent and movable overlayed pixmaps and the like. Klaus Wow! The world may be changing!! Will this be a 1.8 release, or still in the 1.7 development train? Any ETA? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 decoder engine.decoder_priorities.ffmpegaudio:1 # priority for ffmpegvideo decoder engine.decoder_priorities.ffmpegvideo:1 Just increase codec priorities. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 the motherboard sound card via SPDIF) but now I can get HD video with multichannel audio through VDR and also switch from the VDR main menu into Boxee (need to add this yourself) to handle playing local media (and free movies provided in the library) as well as running apps such as BBC iplayer and all the hundreds of other TV apps available (You Tube, Browser, Flickr, CNET, NASA TV etc). I also compiled up the vomp mediaplayer plugin to drive my 2 Hauppauge Media MVPs (TV and media distributed through the house) and hooked it up to my rotor (rotor plugin seems pretty unstable though and crashes VDR regularly) and use channel scan to find sat channels. I'm really pleased with it as it makes a great HTPC and Internet TV App solution and it has a high WAF. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 (mostly addressing audio sync issues when I used the motherboard sound card via SPDIF) but now I can get HD video with multichannel audio through VDR and also switch from the VDR main menu into Boxee (need to add this yourself) to handle playing local media (and free movies provided in the library) as well as running apps such as BBC iplayer and all the hundreds of other TV apps available (You Tube, Browser, Flickr, CNET, NASA TV etc). Sounds good. How are you running iPlayer, etc.? Through Firefox or equivalent? My current setup headless setup (control by remote only) so I can't run anything else like a browser withough ssh-ing in (and I'd need X, too!). If I change it all and am forced to use X for the video output, I could also run other apps too, although it would be nice to do it all from just the remote... I also compiled up the vomp mediaplayer plugin to drive my 2 Hauppauge Media MVPs (TV and media distributed through the house) and hooked it up to my rotor (rotor plugin seems pretty unstable though and crashes VDR regularly) and use channel scan to find sat channels. I've got a couple of Media MVPs hanging off of my setup too! They won't do HD, though. :-( Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 Media MVPs hanging off of my setup too! They won't do HD, though. :-( No, but my other screens are both 19 so HD doesn't really matter to me - the screens are too small to warrant HD. There is a Media MVP HD out, but its not supported yet - I think there is some work going on (see VOMP forum) but I wouldn't hold your breath for awhile, if ever, due to the API not being public. Cheers ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 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. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 to play other formats. But then that is part of ffmpeg, so a player based on ffmpeg would have it rulling out the big attraction for some for xineliboutput etc On 1/11/2011 8:32 PM, Torgeir Veimo wrote: On 12 January 2011 13:09, VDR Useruser@gmail.com wrote: On Tue, Jan 11, 2011 at 4:40 PM, Torgeir Veimotorg...@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 device. At any rate vdpau support is a requirement so anything that doesn't have it can automatically be ruled out. I do agree that it would be nice to have an ffmpeg-based vdr plugin but at present the only vdpau capable option I'm aware of depends on libxine. I guess that what you'd really want would be a pure VDPAU playback device, not necessarily using ffmpeg. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 who suggested ffmpeg originally said it's vdpau implementation works much better for him, as I've heard others mention as well. My experience is that libxine-based (I've only used vdr-xine btw) works pretty well. However, it would still be nice to have more options available, especially for those who aren't as lucky as I with libxine. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 Kosunen wrote: 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 decoder engine.decoder_priorities.ffmpegaudio:1 # priority for ffmpegvideo decoder engine.decoder_priorities.ffmpegvideo:1 Just increase codec priorities. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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. 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. 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 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. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 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. 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 recent posts on the subject. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 recent posts on the subject. So you insist on the decoding being done by the VDR plugin? It's far more flexible if the VDR plugin serves a stream without decoding it and the player is separate. And that way we only need a new player, a suitable streaming plugin, including OSD, already exists in xineliboutput. 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 know some people have had success turning VDR into a server/client system but when I tried it, it was trash and a long way from usable in a 'stable' or 'daily use' VDR environment so I'm not that easily convinced the idea is a great one. Don't get me wrong however, I'm not knocking any alternative to something that is completely independent of xinelib. If what you suggests is really so simple, _stable_, and provides _all_ necessary functionality for the user then I'm all for it. Until something exists in reality that we can test though, it's all just tossing around ideas. Although I personally have success with the xinelib+vdr-xine combo, I'm more then willing to test other options that include vdpau support and are 100% independent of xinelib and anything else I don't need or want. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 exclusively use the yaVDR repositories? https://launchpad.net/~yavdr/+archive/stable-vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 bits for that from yaVDR :). Why not exclusively use the yaVDR repositories? https://launchpad.net/~yavdr/+archive/stable-vdr cause its ubuntu and he uses debian ? ;) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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: libmagickcore2 (= 7:6.5.7.8) but it is not installable Depends: libmagickwand2 (= 7:6.5.7.8) but it is not installable Depends: libmodplug0c2 (= 1:0.7-4.1) but it is not installable Depends: libmpcdec3 but it is not installable AFAICT those packages are obsolete in Debian Squeeze or newer. If I try to install them from Lenny I'll probably have problems with other things that depend on ImageMagick. And yavdr doesn't include sxfe for some reason. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 lists source packages so I had to search for xineliboutput instead of sxfe. But you went the extra mile with an insult and a link to a package guaranteed to be of no use to me. Thank you very much. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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)... Except that: I have them running on my box.Your problem are with xine not vdr... True, but I think I need updated xine packages to go with VDR. The stock Debian unstable ones don't seem to work at all with VDR 1.7 (probably because of the change to TS format). Tobias Grimm's ones do, but VDPAU really isn't usable in that version, so I'll have to try compiling 1.2. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 to use the vdr-sxfe frontend. I presume it does work with xinelib 1.2 because it's present in yavdr, but it's a pity it's bundled with the VDR plugin, from the point of view of building just the frontend because I've already got the VDR plugin catered for. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 something. When that comes back to xine, xine crashes and I end up with a black screen with the command prompt in the upper left and the X mouse pointer in the middle and vdr still chugging away in the back ground. I have to restart vdr/xine/xorg to get it back up. He gave me a patch in irc channel 3 months ago which reduce the problem but didn't remove it. A couple weeks ago I updated and found the patch was still not in. Hopping a better fix had been put in, I used it stock and now have to restart several times a week, sometimes a day. Signal is strong, but the local broadcasters are morons and even with a strong signal and steady picture it will just crash because of some very minor blip in the stream. I also see the picture and audio go to a freeze frame studder. but that is fixable by simply switch channels. I have turned it on and found a green screen with no audio. This also corrects with a channel change. Xine also has too much extra junk and its related dependencies which are not needed. On 1/11/2011 11:33 AM, Tony Houghton wrote: 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 to use the vdr-sxfe frontend. I presume it does work with xinelib 1.2 because it's present in yavdr, but it's a pity it's bundled with the VDR plugin, from the point of view of building just the frontend because I've already got the VDR plugin catered for. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 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. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 plugin so it seems you're not alone there. I believe ffmpeg is more actively developed as well which would explain why it has better vpdau support. Xine's vdpau support has come a long way but there are still a few bugs that need to be addressed. Guess we'll see which comes first, an ffmpeg VDR plugin, or xine being fixed. Not sure I would hold my breath for either however. ;) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 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. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 required did solve the problem. In other words, its the patches series that breaks HD for me not original vdr1.7.16. I did not spend the time to manually apply each package one by one as unfortunately you need to recompile plugins as well (live, streamdev, epgserach, ...). --eric ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 with the atsc stream. You can always try softdevice, which is mostly a playback interface using ffmpeg. It't not a full client - server solution like xineliboutput is, but it does have a shmem client server setup which might work for you. It doesn't support vdpau though, if that's what you need. I've recently tries out yavdr 0.3a setting up a vdr box from scratch and I'm very impressed by how easy it was to get everything set up. I only had to configure channels.conf and the lirc remote setup, and everything was working out of the box, even vdpau with 1080p support. -- -Tor ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 using ffmpeg. It't not a full client - server solution like xineliboutput is, but it does have a shmem client server setup which might work for you. It doesn't support vdpau though, if that's what you need. Isn't softdevice abandoned? Someone had told me that it's no longer developed. At any rate vdpau support is a requirement so anything that doesn't have it can automatically be ruled out. I do agree that it would be nice to have an ffmpeg-based vdr plugin but at present the only vdpau capable option I'm aware of depends on libxine. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 while, but should still work as a software only playback device. At any rate vdpau support is a requirement so anything that doesn't have it can automatically be ruled out. I do agree that it would be nice to have an ffmpeg-based vdr plugin but at present the only vdpau capable option I'm aware of depends on libxine. I guess that what you'd really want would be a pure VDPAU playback device, not necessarily using ffmpeg. -- -Tor ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 device. At any rate vdpau support is a requirement so anything that doesn't have it can automatically be ruled out. I do agree that it would be nice to have an ffmpeg-based vdr plugin but at present the only vdpau capable option I'm aware of depends on libxine. I guess that what you'd really want would be a pure VDPAU playback device, not necessarily using ffmpeg. That would be great actually. Or just having another option period besides something dependent on libxine. The guy who suggested ffmpeg originally said it's vdpau implementation works much better for him, as I've heard others mention as well. My experience is that libxine-based (I've only used vdr-xine btw) works pretty well. However, it would still be nice to have more options available, especially for those who aren't as lucky as I with libxine. As is always the case though, user needs/wants depend on developers time, effort, and interest. I'm not sure what all it would take to write an output plugin for VDR that uses the ffmpeg vdpau library but maybe someone with the ability to do one will give it a shot. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 lot easier than gathering the bits and pieces and getting it to live nicely on my system. Any chance of a 1.8 release soon? Most users will agree that VDR is very stable regardless of its stable or developer status. I have nearly no problems at all and am running the latest developer version. For that matter, I update to every version that see's release. I've never used debian package sources to compile from. Instead, I just grab all the sources I use from their respective host locations and compile -- a process that's very easily scriptable (which is what I've done). I wouldn't hold my breath on VDR-1.8.0 being released soon. And I also wouldn't hold much value to it aside of being an announcement because as previously mentioned, the current developer version works great and is very stable for most users. 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 packages for version 2 players, nor libxine2-dev packages (not to mention vdpau support) so I don't see what use they are. 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 It's simple to compile and again, something easily scriptable. VDPAU support in xine-lib-1.2 isn't flawless (depending on circumstances), but it works great. I'd definitely, and do, recommend it. My advice would be you stop insisting on using debian sources for this stuff. Both VDR and xine-lib-1.2 are easily obtainable from their original sources, compile easily, and no hassling with screwy debian sources necessary. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 packages for version 2 players, nor libxine2-dev packages (not to mention vdpau support) so I don't see what use they If it's just about the VDPAU support, you can use the xine 1.1.19 from my repository which includes VDPAU support an seems to work well on Squeeze. 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 Tobias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 clarify this. I meant there's only one official xine-lib-1.1 tree and one official xine-lib-1.2 tree so I'm not sure what you're confused about unless you're considering whatever cloned trees may exist. Honestly, I see no reason to bother with anything other then the official tree unless it provides you something you need which is missing from the official tree. Other people may offer other options but FWIW I used the official xine-lib-1.1 tree for vdpau up until vdpau support was merged into xine-lib-1.2, at which time I switched to xine-lib-1.2 and haven't touched 1.1 since. It's always been easy and I've never used anything other then the official trees. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 experimental, but there don't seem to be any packages for version 2 players, nor libxine2-dev packages (not to mention vdpau support) so I don't see what use they If it's just about the VDPAU support, you can use the xine 1.1.19 from my repository which includes VDPAU support an seems to work well on Squeeze. 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 I get a lot of audio problems too, I was hoping maybe this had improved, especially pulseaudio support, in the 1.2 branch. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 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 alongside xine-lib-1.2 despite your saying it was merged in. It's simple to compile and again, something easily scriptable. VDPAU support in xine-lib-1.2 isn't flawless (depending on circumstances), but it works great. I'd definitely, and do, recommend it. My advice would be you stop insisting on using debian sources for this stuff. Both VDR and xine-lib-1.2 are easily obtainable from their original sources, compile easily, and no hassling with screwy debian sources necessary. I use my HTPC for other stuff as well as VDR so I'd rather hack VDR to make it compatible with a (some would say the) standard Linux distro than the other way round. Therefore I think the Debian packages' screwiness saves me a lot of hassle instead of adding to it. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 experimental, but there don't seem to be any packages for version 2 players, nor libxine2-dev packages (not to mention vdpau support) so I don't see what use they If it's just about the VDPAU support, you can use the xine 1.1.19 from my repository which includes VDPAU support an seems to work well on Squeeze. 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 I see you have VDR 1.7 packages there too, I'd definitely be interested in those. Would you recommend multipatch over standard? -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 alongside xine-lib-1.2 despite your saying it was merged in. VDPAU support was merged into xine-lib-1.2 some time ago. The old tree xine-lib-1.2-vdpau is simply an alias for xine-lib-1.2. -- boro ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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: http://tinyurl.com/6zljrra Tobias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 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 alongside xine-lib-1.2 despite your saying it was merged in. Well, no.. I'll explain... As you said, the top level repository lists several tree's. However, there are only two tree's for xine-lib: xine-lib/xine-lib Media player library back end (1.1; stable development branch) xine-lib/xine-lib-1.2 Media player back end (1.2; unstable development branch) Both clearly marked as 1.1 and 1.2. There isn't any and hasn't been a separate vdpau development tree for quite some time. Any leftover tree's now would simply point to one of the two listed above. A quick search of the changelog for xine-lib-1.2 reveals: 13 months ago Merge from 1.1; merge vdpau (with adjustments for 1.2). changeset Darren Salt li...@youmustbejoking.demon.co.uk [Fri, 20 Nov 2009 03:46:10 +] rev 11335 Merge from 1.1; merge vdpau (with adjustments for 1.2). Hopefully that takes care of any confusion you have. It's simple to compile and again, something easily scriptable. VDPAU support in xine-lib-1.2 isn't flawless (depending on circumstances), but it works great. I'd definitely, and do, recommend it. My advice would be you stop insisting on using debian sources for this stuff. Both VDR and xine-lib-1.2 are easily obtainable from their original sources, compile easily, and no hassling with screwy debian sources necessary. I use my HTPC for other stuff as well as VDR so I'd rather hack VDR to make it compatible with a (some would say the) standard Linux distro than the other way round. Therefore I think the Debian packages' screwiness saves me a lot of hassle instead of adding to it. 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. Best regards, Derek ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 editing a few paths in the Makefile I want to avoid, I also like runvdr supplied with Debian packages, I'd miss that. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
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 currently includes the following patches: http://tinyurl.com/6zljrra 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 :). -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
