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
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


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 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-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 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

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 pronouncing it stable ;-)

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


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 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

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 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

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 files 
required to build VDR-plugins.


Tobias

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


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
 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

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 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

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 
(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

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 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

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 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

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 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

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 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

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, 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

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 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

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 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

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 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

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 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

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 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

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 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

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 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

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 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

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 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

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 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

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 (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

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 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

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 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

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 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

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 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

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 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

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.
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

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 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

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 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

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 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

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 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-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 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

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
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


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: 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

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
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


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 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

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)...


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

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 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

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 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

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 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

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 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

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 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

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 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

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? 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.


Perhaps I misunderstood how xineliboutput works, but I thought that when
using a remote client the VDR plugin component doesn't actually depend
on libxine, but just streams to a socket in a format that libxine can
decode. And that stream is just a standard TS except that some of the
packets contain OSD data? MPlayer and VLC can read the stream (not sure
about with VDR 1.7, but they could with the old PES version and I don't
see why they wouldn't work with TS too) and ignore the OSD. So any
client based on gstreamer and/or ffmpeg can already understand most of
the stream, it just needs a way to extract and display the OSD. Using
the existing xineliboutput plugin would save writing a new
VDR plugin which would just duplicate the functionality of one we
already have.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


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 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

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
 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

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 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

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 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

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 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

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 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

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 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

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 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

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 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

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 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

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 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

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:

http://tinyurl.com/6zljrra


Tobias






___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


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 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

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 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

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 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