Re: [vdr] Question about VDR changes for a high-color osd.

[Torgeir Veimo]

Why not go all the way and implement an opengl rendered OSD with vdpau?
This would of course require information from vdr in a slightly different
form; ie. semantically instead of pixels. I'd suggest trying to get the OSD
information as HTML from VDR, then allowing the frontend to render it in any
way it deems suitable, with fancy animation, transition effects, icons etc.
This might also make it easier to implement text-only OSD, eg for terminal
connections.

2009/4/14 VDR User 

> On Mon, Apr 13, 2009 at 11:31 AM, Udo Richter  wrote:
> > This will hopefully be a true-color OSD with transparency and the
> > ability to scale to the needs of the output device? Like having a HD OSD
> > even on SD playback? And (even if these times are almost history) the
> > ability to switch between 4:3 and 16:9 based on what the output device
> > needs?
>
> Let's all keep our fingers crossed tight for that.  You know the
> saying, if you're gonna do it, might as well do it right!  ;)
>
> Klaus, this is great to hear since I know many guys have been
> interested in this for some time (myself included).  It seems the news
> is traveling fast too, have already seen several inquiries about it
> elsewhere!
>
> It looks like I'll be loading Photoshop later and getting back to the
> high color/res yaepghd themes I was working on now. :)
>
> Cheers,
> Derek
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>



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

Re: [vdr] reel netclient

[Georg Acher]

On Mon, Apr 13, 2009 at 08:48:44PM +0100, Andrew Herron wrote:
> What is the hardware platform then? What CPU & GPU is used? Are you running
> closed or open graphics drivers etc?

It's a typical System-on-Chip for STBs. Details will be announced later.

-- 
 Georg Acher, ac...@in.tum.de 
 http://www.lrr.in.tum.de/~acher
 "Oh no, not again !" The bowl of petunias  

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

[vdr] [PATCH] jumpplay patch 1.0 for VDR-1.7.5

[Thomas Günther]

Hi!

The jumpplay patch for vdr-1.7.5 is available:
http://toms-cafe.de/vdr/download/vdr-jumpplay-1.0-1.7.5.diff

This patch changes the replay behaviour for recordings that contain
editing marks. It allows to immediately continue the replay after
jumping forward to the next mark, and to automatically jump over the
commercial break to the next "start" mark, if an "end" mark is reached.

The features of this patch can be turned on or off in the replay setup.

See README.jumpplay included in the patch for details, history and
contributors.

Tom

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

[vdr] [PATCH] undelete-0.0.6 for VDR >= 1.7.3

[Thomas Günther]

Hi!

Here is a patch for the undelete plug-in and VDR >= 1.7.3:

http://toms-cafe.de/vdr/download/undelete-0.0.6-1.7.3.diff

Tom

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

[vdr] [PATCH] vompserver-0.3.0 for VDR >= 1.7.3

[Thomas Günther]

Hi!

Here is a patch for the vompserver plug-in and VDR >= 1.7.3:

http://toms-cafe.de/vdr/download/vompserver-0.3.0-1.7.3.diff

Tom

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

[vdr] [PATCH] vcd-0.9 for VDR >= 1.7.3

[Thomas Günther]

Hi!

Here is a patch for the vcd plug-in and VDR >= 1.7.3:

http://toms-cafe.de/vdr/download/vcd-0.9-1.7.3.diff

Tom

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

Re: [vdr] xineliboutput cvs broken osd scaling

[Malte Schröder]

On Mon, 13 Apr 2009 13:02:39 +0200
Malte Schröder  wrote:

> On Mon, 13 Apr 2009 12:35:24 +0200 (CEST)
> "gimli"  wrote:
> 
> > Hi,
> > 
> > with the latest cvs version of xineliboutput the OSD scaling is broken
> > using HD content. The OSD seems way to large on HD content.
> > 
> > My setup is :
> > 
> > Soft :
> > 
> > vdr-1.7.5
> > xineliboutput from today
> > xine-lib-vdpau
> > 
> > Hard :
> > For video out i use vdpau on an IGP8300 motherboard.
> > 
> > Anyone else noticed that behavior ?
> 
> Yes, but the other way around: The OSD is too small when viewing
> sub-PAL resolutions. Didn't try HD-stuff yet.
> 
> I made a screenshot, viewable here:
> http://www.vdrportal.de/board/thread.php?threadid=85767
> 
> BTW. the problem does not occur when using HUD-Mode, but that doesn't
> play nice with VDPAU yet ...

I just checked, it works when using --video=vo, it only happens with
vdpau.

-- 
---
Malte Schröder
malte...@gmx.de
ICQ# 68121508
---



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

Re: [vdr] let vdr ignore non vdr directories ?

[Matthias Schwarzott]

On Montag, 13. April 2009, Steffen Barszus wrote:
> Hi all!

Hi!

>
> is there any way to let vdr ignore any directories which do not belong
> to it ?
>
> What i have seen is that vdr is recursive checking all directories even
> on second and third video directory.
>
> If the logic is that all needs to be in video.0 directory and its
> subdirectories and symlinks will be required to let vdr find the
> recordings, it should not check the other video directories.
>
[deleted some text that did not made sense to me]
>
> Think there might be others as well that are using the big disks for
> other space consuming things - nobody else run into this ?

I don't understand why people do put other stuff into vdr video directories?
If I want to have video directory and a directory containing iso images why 
not do

mkdir video
mkdir iso

and put the stuff there?
Still I support the opinion that vdr should not silently delete files it does 
not know.

Regards
Matthias

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

Re: [vdr] reel netclient

[Andrew Herron]

What is the hardware platform then? What CPU & GPU is used? Are you running
closed or open graphics drivers etc?

On Mon, Apr 13, 2009 at 6:27 PM, Georg Acher  wrote:

> On Mon, Apr 13, 2009 at 05:46:14PM +0100, Andrew Herron wrote:
> > But does the Reel Smart-Client box run vdr?
>
> Yes, but like on the Avantgarde it's the Reel-variant (based on 1.4.x with
> our own HDTV extensions).
>
> --
>  Georg Acher, ac...@in.tum.de
> http://www.lrr.in.tum.de/~acher
> "Oh no, not again !" The bowl of petunias
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>



-- 
Convergent Home Technologies Ltd
www.dianemo.co.uk
Tel: +44 (0)1245 330101
Fax: +44 (0)1245 263916

Unit 205 Waterhouse Business Centre
Cromar Way
Chelmsford
Essex CM1 2QE
UK

Watch Dianemo Videos here;
http://www.dianemo.co.uk/index.php/your-home/overview-videos/8-your-home/31-dianemo-overview-videos
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] let vdr ignore non vdr directories ?

[Steffen Barszus]

Hi all!

is there any way to let vdr ignore any directories which do not belong 
to it ?

What i have seen is that vdr is recursive checking all directories even 
on second and third video directory.

If the logic is that all needs to be in video.0 directory and its 
subdirectories and symlinks will be required to let vdr find the 
recordings, it should not check the other video directories.

Background: I accidently remounted /proc vdr readable in video.01 
directory for doing some chroot. The result is that i lost 3 recordings. 
The log has grown to a few GB in no time and vdr made the system be 
occupied by that job. Those i think it should be enough to scan video.00 
and the symlinks therein or check for some .vdrignore file before 
traversion. The first solution should also speedup re-reading recordings.

Hope i did not missed a change in behaviour in newer vdr versions as i 
am still using 1.4.7

Think there might be others as well that are using the big disks for 
other space consuming things - nobody else run into this ?

Thanks and kind regards

Steffen





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

Re: [vdr] Question about VDR changes for a high-color osd.

[VDR User]

On Mon, Apr 13, 2009 at 11:31 AM, Udo Richter  wrote:
> This will hopefully be a true-color OSD with transparency and the
> ability to scale to the needs of the output device? Like having a HD OSD
> even on SD playback? And (even if these times are almost history) the
> ability to switch between 4:3 and 16:9 based on what the output device
> needs?

Let's all keep our fingers crossed tight for that.  You know the
saying, if you're gonna do it, might as well do it right!  ;)

Klaus, this is great to hear since I know many guys have been
interested in this for some time (myself included).  It seems the news
is traveling fast too, have already seen several inquiries about it
elsewhere!

It looks like I'll be loading Photoshop later and getting back to the
high color/res yaepghd themes I was working on now. :)

Cheers,
Derek

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

Re: [vdr] Question about VDR changes for a high-color osd.

[Udo Richter]

On 13.04.2009 20:17, Klaus Schmidinger wrote:
> On 13.04.2009 20:11, VDR User wrote:
>> There's been recent talk in #xine-vdpau about expanding VDR to allow
>> for a high color osd.
>
> I believe the right way to go is to implement a full 24 (32 with alpha
> channel) bit OSD, as was already done for the Reelbox. This will soon
> be added to the core VDR code.

This will hopefully be a true-color OSD with transparency and the 
ability to scale to the needs of the output device? Like having a HD OSD 
even on SD playback? And (even if these times are almost history) the 
ability to switch between 4:3 and 16:9 based on what the output device 
needs?


Cheers,

Udo


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

Re: [vdr] Question about VDR changes for a high-color osd.

[Gerald Dachs]

Am Mon, 13 Apr 2009 20:17:50 +0200
schrieb Klaus Schmidinger :

> On 13.04.2009 20:11, VDR User wrote:
> > There's been recent talk in #xine-vdpau about expanding VDR to allow
> > for a high color osd.  Does anyone happen to know any bad
> > implications of changing tIndex from uint8_t to a uint16_t for
> > allowing access to more of a color palette?
> 
> I believe the right way to go is to implement a full 24 (32 with alpha
> channel) bit OSD, as was already done for the Reelbox. This will soon
> be added to the core VDR code.

Great news! I bite to my tongue, to not ask when this will happen.

Gerald

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

Re: [vdr] Question about VDR changes for a high-color osd.

[Klaus Schmidinger]

On 13.04.2009 20:11, VDR User wrote:
> There's been recent talk in #xine-vdpau about expanding VDR to allow
> for a high color osd.  Does anyone happen to know any bad implications
> of changing tIndex from uint8_t to a uint16_t for allowing access to
> more of a color palette?

I believe the right way to go is to implement a full 24 (32 with alpha
channel) bit OSD, as was already done for the Reelbox. This will soon
be added to the core VDR code.

Klaus

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

[vdr] Question about VDR changes for a high-color osd.

[VDR User]

There's been recent talk in #xine-vdpau about expanding VDR to allow
for a high color osd.  Does anyone happen to know any bad implications
of changing tIndex from uint8_t to a uint16_t for allowing access to
more of a color palette?

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

Re: [vdr] reel netclient

[Georg Acher]

On Mon, Apr 13, 2009 at 05:46:14PM +0100, Andrew Herron wrote:
> But does the Reel Smart-Client box run vdr?

Yes, but like on the Avantgarde it's the Reel-variant (based on 1.4.x with
our own HDTV extensions).

-- 
 Georg Acher, ac...@in.tum.de 
 http://www.lrr.in.tum.de/~acher
 "Oh no, not again !" The bowl of petunias  

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

Re: [vdr] reel netclient

[Andrew Herron]

But does the Reel Smart-Client box run vdr?


On Mon, Apr 13, 2009 at 2:50 PM, Georg Acher  wrote:

> On Mon, Apr 13, 2009 at 06:28:36PM +1000, Torgeir Veimo wrote:
> > http://www.reel-multimedia.com/en/shop_netclient.php describes a new
> > product by reel that allows streaming of HD content over the network.
> > It includes a hw decoder that supports mpeg2/4 and is to be used with
> > the reelbox avantgarde as server. I'd assume reel has implemented
> > something a bit more sophisticated than streamdev for this, but given
> > the open source nature of their products, I'm wondering if someone has
> > tried looking into using this client with pure VDR?
>
> The thing is not yet available, so the current SVN doesn't contain most of
> the new code. But in general it uses the same "reel"vdr-base as the
> Avantgarde (just with a different output plugin for the SoC). The live TV
> streaming is not done by the vdr on the Avantgarde, but directly via
> IPv6-multicast by the NetCeiver-hardware. This is the same way the
> Avantgarde gets its data, so the NetCeiver traffic is just bridged into the
> LAN for other clients.
>
> --
> Georg Acher, ac...@in.tum.de
> http://www.lrr.in.tum.de/~acher
> "Oh no, not again !" The bowl of petunias
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>



-- 
Convergent Home Technologies Ltd
www.dianemo.co.uk
Tel: +44 (0)1245 330101
Fax: +44 (0)1245 263916

Unit 205 Waterhouse Business Centre
Cromar Way
Chelmsford
Essex CM1 2QE
UK

Watch Dianemo Videos here;
http://www.dianemo.co.uk/index.php/your-home/overview-videos/8-your-home/31-dianemo-overview-videos
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] [ANNOUNCE] runvdr extreme 0.4.1

[Udo Richter]

Hi list,

I've updated the runvdr extreme script to version 0.4.1

This release mainly sums up several bug fixes that were available 
before, and some internal changes.


Get it at:
http://www.udo-richter.de/vdr/scripts.en.html#runvdr-extreme
http://www.udo-richter.de/vdr/scripts.html#runvdr-extreme

Cheers,

Udo


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

Re: [vdr] reel netclient

[Torgeir Veimo]

That might be, but one of the reasons that I run VDR is the ability to tweak
the capabilities and the user experience. So changing the client is just as
interesting as implementing a suitable backend.

2009/4/14 Matthias Müller 

> Hi,
>
> Torgeir Veimo schrieb:
> > If the netclient hardware runs GPL software I assume that in theory
> > someone could implement a streamdev client that facilitated the hw
> > mepg2/4 decoder?
>
> If you look at the specs and the description Georg provided, a
> streamdev-client isn't needed, only a proper streamdev-server, that
> relays the transport stream from the transponder to the network and
> implements a feedback-channel to provide infos like supported demuxes
> and so on.
> >
> > 2009/4/14 Georg Acher mailto:ac...@in.tum.de>>
> >
> > On Mon, Apr 13, 2009 at 04:03:02PM +0200, Matthias Müller wrote:
> >
> > > I have no netceiver to play with and didn't look at the sources.
> But
> > > it's nice to see a real world use for IPv6 in consumer hardware
> > (if you
> > > can call the reel boxes consumer hardware, it's probably only for a
> > > limited, but sophisticated market.
> >
> > The client and the also available standalone NetCeiver should
> > bring it more
> > to the "masses" as the price will be comparable to typical HDTV
> > receivers.
> >
> > > Does it just use a fixed multicast-address to receive the stream
> > and if
> > > yes, how is the communication to the tuner realized? Is this
> > something
> > > reel-specific or could this be used to start a unified
> > streaming-concept
> > > for vdr based on standards (and using IPv6 to avoid all that
> > ugly IPv4
> > > stuff...)
> >
> > It is a proprietory protocol in the sense as it is no standard.
> > When there
> > are so many IPTV standards to choose from, why make not a new one?
> > ;-) At
> > the time we started, DVB-IPTV was not even named and still I think
> > it is so
> > bloated that it cannot be efficiently used to use cheap hardware as a
> > server.
> >
> > However, our protocol uses standard protocols like MLDv2 just with a
> > different interpretation to make it light-weight and use hardware
> > supported
> > streaming. In the end, one NetCeiver can stream up to 6 full
> > S2-transponders
> > (~40MByte/s), only the zapping time increases a bit... Do that
> > with a PC :p
> >
> > The protocol translates (almost) all DVB specifics to ethernet, so
> > it was no
> > problem to wrap it back to DVB-API. The multicast address is not
> > static but
> > contains all relevant reception parameters. The basic
> > communication only
> > exchanges a few MLDv2-messages (no XML), so it can be processed
> > very fast
> > and also gains from MLDv2-aware switches. Only tuner capabilities
> > and tuning
> > states (SNR, lock, ...) are transmitted regularly in a side band
> > via XML on
> > a specific multicast address. That also allows zero configuration
> > for the
> > client. We will write a "white paper" about the protocol,
> > currently we just
> > don't have enough time...
> >
> > For the client side, the sources will be published as GPL.
> > Currently we use
> > a closed source daemon with a dvb loopback driver in the kernel,
> > but that
> > makes it hard to fully use the tuner virtualization and costs some
> > overhead
> > for small CPUs. Since we already have a native vdr plugin for
> > that, the
> > network code will be then forced to be GPL anyway ;-)
> >
> > --
> > Georg Acher, ac...@in.tum.de 
> > http://www.lrr.in.tum.de/~acher
> > 
> > "Oh no, not again !" The bowl of petunias
> >
> > ___
> > vdr mailing list
> > vdr@linuxtv.org 
> > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> >
> >
> >
> >
> > --
> > -Tor
> > 
> >
> > ___
> > 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
>



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

Re: [vdr] reel netclient

[Matthias Müller]

Hi,

Torgeir Veimo schrieb:
> If the netclient hardware runs GPL software I assume that in theory 
> someone could implement a streamdev client that facilitated the hw 
> mepg2/4 decoder?

If you look at the specs and the description Georg provided, a 
streamdev-client isn't needed, only a proper streamdev-server, that 
relays the transport stream from the transponder to the network and 
implements a feedback-channel to provide infos like supported demuxes 
and so on.
>
> 2009/4/14 Georg Acher mailto:ac...@in.tum.de>>
>
> On Mon, Apr 13, 2009 at 04:03:02PM +0200, Matthias Müller wrote:
>
> > I have no netceiver to play with and didn't look at the sources. But
> > it's nice to see a real world use for IPv6 in consumer hardware
> (if you
> > can call the reel boxes consumer hardware, it's probably only for a
> > limited, but sophisticated market.
>
> The client and the also available standalone NetCeiver should
> bring it more
> to the "masses" as the price will be comparable to typical HDTV
> receivers.
>
> > Does it just use a fixed multicast-address to receive the stream
> and if
> > yes, how is the communication to the tuner realized? Is this
> something
> > reel-specific or could this be used to start a unified
> streaming-concept
> > for vdr based on standards (and using IPv6 to avoid all that
> ugly IPv4
> > stuff...)
>
> It is a proprietory protocol in the sense as it is no standard.
> When there
> are so many IPTV standards to choose from, why make not a new one?
> ;-) At
> the time we started, DVB-IPTV was not even named and still I think
> it is so
> bloated that it cannot be efficiently used to use cheap hardware as a
> server.
>
> However, our protocol uses standard protocols like MLDv2 just with a
> different interpretation to make it light-weight and use hardware
> supported
> streaming. In the end, one NetCeiver can stream up to 6 full
> S2-transponders
> (~40MByte/s), only the zapping time increases a bit... Do that
> with a PC :p
>
> The protocol translates (almost) all DVB specifics to ethernet, so
> it was no
> problem to wrap it back to DVB-API. The multicast address is not
> static but
> contains all relevant reception parameters. The basic
> communication only
> exchanges a few MLDv2-messages (no XML), so it can be processed
> very fast
> and also gains from MLDv2-aware switches. Only tuner capabilities
> and tuning
> states (SNR, lock, ...) are transmitted regularly in a side band
> via XML on
> a specific multicast address. That also allows zero configuration
> for the
> client. We will write a "white paper" about the protocol,
> currently we just
> don't have enough time...
>
> For the client side, the sources will be published as GPL.
> Currently we use
> a closed source daemon with a dvb loopback driver in the kernel,
> but that
> makes it hard to fully use the tuner virtualization and costs some
> overhead
> for small CPUs. Since we already have a native vdr plugin for
> that, the
> network code will be then forced to be GPL anyway ;-)
>
> --
> Georg Acher, ac...@in.tum.de 
> http://www.lrr.in.tum.de/~acher
> 
> "Oh no, not again !" The bowl of petunias
>
> ___
> vdr mailing list
> vdr@linuxtv.org 
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
>
>
>
> -- 
> -Tor
> 
>
> ___
> 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] reel netclient

[Torgeir Veimo]

If the netclient hardware runs GPL software I assume that in theory someone
could implement a streamdev client that facilitated the hw mepg2/4 decoder?

2009/4/14 Georg Acher 

> On Mon, Apr 13, 2009 at 04:03:02PM +0200, Matthias Müller wrote:
>
> > I have no netceiver to play with and didn't look at the sources. But
> > it's nice to see a real world use for IPv6 in consumer hardware (if you
> > can call the reel boxes consumer hardware, it's probably only for a
> > limited, but sophisticated market.
>
> The client and the also available standalone NetCeiver should bring it more
> to the "masses" as the price will be comparable to typical HDTV receivers.
>
> > Does it just use a fixed multicast-address to receive the stream and if
> > yes, how is the communication to the tuner realized? Is this something
> > reel-specific or could this be used to start a unified streaming-concept
> > for vdr based on standards (and using IPv6 to avoid all that ugly IPv4
> > stuff...)
>
> It is a proprietory protocol in the sense as it is no standard. When there
> are so many IPTV standards to choose from, why make not a new one? ;-) At
> the time we started, DVB-IPTV was not even named and still I think it is so
> bloated that it cannot be efficiently used to use cheap hardware as a
> server.
>
> However, our protocol uses standard protocols like MLDv2 just with a
> different interpretation to make it light-weight and use hardware supported
> streaming. In the end, one NetCeiver can stream up to 6 full
> S2-transponders
> (~40MByte/s), only the zapping time increases a bit... Do that with a PC :p
>
> The protocol translates (almost) all DVB specifics to ethernet, so it was
> no
> problem to wrap it back to DVB-API. The multicast address is not static but
> contains all relevant reception parameters. The basic communication only
> exchanges a few MLDv2-messages (no XML), so it can be processed very fast
> and also gains from MLDv2-aware switches. Only tuner capabilities and
> tuning
> states (SNR, lock, ...) are transmitted regularly in a side band via XML on
> a specific multicast address. That also allows zero configuration for the
> client. We will write a "white paper" about the protocol, currently we just
> don't have enough time...
>
> For the client side, the sources will be published as GPL. Currently we use
> a closed source daemon with a dvb loopback driver in the kernel, but that
> makes it hard to fully use the tuner virtualization and costs some overhead
> for small CPUs. Since we already have a native vdr plugin for that, the
> network code will be then forced to be GPL anyway ;-)
>
> --
> Georg Acher, ac...@in.tum.de
> http://www.lrr.in.tum.de/~acher
> "Oh no, not again !" The bowl of petunias
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>



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

Re: [vdr] reel netclient

[Matthias Müller]

Hi,

Georg Acher schrieb:
>> I have no netceiver to play with and didn't look at the sources. But 
>> it's nice to see a real world use for IPv6 in consumer hardware (if you 
>> can call the reel boxes consumer hardware, it's probably only for a 
>> limited, but sophisticated market.
>> 
>
> The client and the also available standalone NetCeiver should bring it more
> to the "masses" as the price will be comparable to typical HDTV receivers.
>   
Indeed, 299€ announced on the website sounds good for an out of the box 
client with the functionality of the reelbox (or a vdr-server).

>> Does it just use a fixed multicast-address to receive the stream and if 
>> yes, how is the communication to the tuner realized? Is this something 
>> reel-specific or could this be used to start a unified streaming-concept 
>> for vdr based on standards (and using IPv6 to avoid all that ugly IPv4 
>> stuff...)
>> 
>
> It is a proprietory protocol in the sense as it is no standard. When there
> are so many IPTV standards to choose from, why make not a new one? ;-) At
> the time we started, DVB-IPTV was not even named and still I think it is so
> bloated that it cannot be efficiently used to use cheap hardware as a
> server.
>
>   
I can understand these arguments, I was thinking about a protocol more 
like upnp/av extended for real dynamic streaming. But something 
lightweight is really needed. Especially for the future of vdr and vdr 
based systems. Extending and fixing streamdev isn't a way for the 
future, but implementing a server-plugin for vdr, that could 'emulate' a 
netceiver could unify the reel-way and the stalled streamdev-way.

> However, our protocol uses standard protocols like MLDv2 just with a
> different interpretation to make it light-weight and use hardware supported
> streaming. In the end, one NetCeiver can stream up to 6 full S2-transponders
> (~40MByte/s), only the zapping time increases a bit... Do that with a PC :p
>   
I just had a short look von the RfC for MLDv2 and on the first look it 
doesn't look so bloated (in a way that an implementation could limit 
throughput on typicall pc hardware, especially as this shouldn't affect 
the streaming-part at all). But I'd like to be corrected ;-) For a 
typicall vdr scenario streaming 6 full transponders is probably nothing 
that is really needed, but it's nice to know that your hardware (and 
software) scales to that throughput.

> The protocol translates (almost) all DVB specifics to ethernet, so it was no
> problem to wrap it back to DVB-API. The multicast address is not static but
> contains all relevant reception parameters. The basic communication only
> exchanges a few MLDv2-messages (no XML), so it can be processed very fast
> and also gains from MLDv2-aware switches. Only tuner capabilities and tuning
> states (SNR, lock, ...) are transmitted regularly in a side band via XML on
> a specific multicast address. That also allows zero configuration for the
> client. We will write a "white paper" about the protocol, currently we just
> don't have enough time...
>
>   
That sounds very good and would allow an easy way to map a dvb-stream to 
a network stream and feed it back on the client via standard kernel 
interfaces. That could be even interesting for my boss. Do you have a 
recommendation for a small hardware-setup with a netceiver that would 
work in a dvb-c environment (I only have dvb-c at the moment, enough pc 
hardware and if necessary even a sat-dish to play with)? After my 
vacation I'll check with my boss, perhaps he'll pay for it ;-)

> For the client side, the sources will be published as GPL. Currently we use
> a closed source daemon with a dvb loopback driver in the kernel, but that
> makes it hard to fully use the tuner virtualization and costs some overhead
> for small CPUs. Since we already have a native vdr plugin for that, the
> network code will be then forced to be GPL anyway ;-
Sounds even better, so there's working code to verify the functionality. 
I'm only a networking guy with a little bit experience with dvb, but 
that seems to be a project worth while to invest some time.

Bye,
Matthias

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

[vdr] [Announce] xxv-1.3 - Feature release (1.4 rc)

[Andreas Brachold]

Hello,

The xxv project team announce this feature release of xxv. 
xxv-1.3 is a release candidate of our next major release for XXV the
"Xtreme eXtension for VDR",its containing a large number of bug fixes
and enhancements and more.

Major changes are :
--
  * Support multiple video disk recorder 
  * New module to manage keywords within recordings
  * New import module for XML-TV sources and template for scheme
based programs.
  * and many more

Read the full announcement : http://xxv.berlios.de/content/view/43/1/

Please note :
--
Maybe your must check your installed perl modules, because some new
external perl modules are needed. After the installation of an update,
you should call first always the script contrib/update-xxv.

See also our section with installation hints and tips : 
http://xxv.berlios.de/content/blogcategory/17/33/


Enjoy, 
Andreas


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

Re: [vdr] reel netclient

[Georg Acher]

On Mon, Apr 13, 2009 at 04:03:02PM +0200, Matthias Müller wrote:
   
> I have no netceiver to play with and didn't look at the sources. But 
> it's nice to see a real world use for IPv6 in consumer hardware (if you 
> can call the reel boxes consumer hardware, it's probably only for a 
> limited, but sophisticated market.

The client and the also available standalone NetCeiver should bring it more
to the "masses" as the price will be comparable to typical HDTV receivers.

> Does it just use a fixed multicast-address to receive the stream and if 
> yes, how is the communication to the tuner realized? Is this something 
> reel-specific or could this be used to start a unified streaming-concept 
> for vdr based on standards (and using IPv6 to avoid all that ugly IPv4 
> stuff...)

It is a proprietory protocol in the sense as it is no standard. When there
are so many IPTV standards to choose from, why make not a new one? ;-) At
the time we started, DVB-IPTV was not even named and still I think it is so
bloated that it cannot be efficiently used to use cheap hardware as a
server.

However, our protocol uses standard protocols like MLDv2 just with a
different interpretation to make it light-weight and use hardware supported
streaming. In the end, one NetCeiver can stream up to 6 full S2-transponders
(~40MByte/s), only the zapping time increases a bit... Do that with a PC :p

The protocol translates (almost) all DVB specifics to ethernet, so it was no
problem to wrap it back to DVB-API. The multicast address is not static but
contains all relevant reception parameters. The basic communication only
exchanges a few MLDv2-messages (no XML), so it can be processed very fast
and also gains from MLDv2-aware switches. Only tuner capabilities and tuning
states (SNR, lock, ...) are transmitted regularly in a side band via XML on
a specific multicast address. That also allows zero configuration for the
client. We will write a "white paper" about the protocol, currently we just
don't have enough time...

For the client side, the sources will be published as GPL. Currently we use
a closed source daemon with a dvb loopback driver in the kernel, but that
makes it hard to fully use the tuner virtualization and costs some overhead
for small CPUs. Since we already have a native vdr plugin for that, the
network code will be then forced to be GPL anyway ;-)

-- 
 Georg Acher, ac...@in.tum.de 
 http://www.lrr.in.tum.de/~acher
 "Oh no, not again !" The bowl of petunias  

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

Re: [vdr] reel netclient

[Georg Acher]

On Mon, Apr 13, 2009 at 11:54:14PM +1000, Torgeir Veimo wrote:
> So it does not allow viewing of channels received as DVB-C/S/T on the
> avantgarde, or such recordings, only IPTV transmissions?

The NetCeiver IS a DVB-S/C/T headend to IPTV. So the tuners the
Avantgarde-vdr uses are already sourced by that way, a new client makes no
difference. The PC mainboard and the NetCeiver in the AVG just happen to be
in the same casing and share the same power supply. Beyond that they are
totally seperated devices. The tuner data is delivered by a loop back
ethernet cable on the backside. It's similar to a USB tuner, but with all
advantages of ethernet, especially more than one client ;-)

Of course the NetClient can also access recordings over NFS etc. There's
also a multiroom-setup that transfers timers to the AVG. So there is a
"full" vdr running on the client, just the tuners are external.

-- 
 Georg Acher, ac...@in.tum.de 
 http://www.lrr.in.tum.de/~acher
 "Oh no, not again !" The bowl of petunias  

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

Re: [vdr] reel netclient

[Matthias Müller]

Hi,

Georg Acher schrieb:
> The thing is not yet available, so the current SVN doesn't contain most of
> the new code. But in general it uses the same "reel"vdr-base as the
> Avantgarde (just with a different output plugin for the SoC). The live TV
> streaming is not done by the vdr on the Avantgarde, but directly via
> IPv6-multicast by the NetCeiver-hardware. This is the same way the
> Avantgarde gets its data, so the NetCeiver traffic is just bridged into the
> LAN for other clients.
>
>   
I have no netceiver to play with and didn't look at the sources. But 
it's nice to see a real world use for IPv6 in consumer hardware (if you 
can call the reel boxes consumer hardware, it's probably only for a 
limited, but sophisticated market.
Does it just use a fixed multicast-address to receive the stream and if 
yes, how is the communication to the tuner realized? Is this something 
reel-specific or could this be used to start a unified streaming-concept 
for vdr based on standards (and using IPv6 to avoid all that ugly IPv4 
stuff...)

A very interested Matthias

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

Re: [vdr] reel netclient

[Torgeir Veimo]

So it does not allow viewing of channels received as DVB-C/S/T on the
avantgarde, or such recordings, only IPTV transmissions?

2009/4/13 Georg Acher 

> On Mon, Apr 13, 2009 at 06:28:36PM +1000, Torgeir Veimo wrote:
> > http://www.reel-multimedia.com/en/shop_netclient.php describes a new
> > product by reel that allows streaming of HD content over the network.
> > It includes a hw decoder that supports mpeg2/4 and is to be used with
> > the reelbox avantgarde as server. I'd assume reel has implemented
> > something a bit more sophisticated than streamdev for this, but given
> > the open source nature of their products, I'm wondering if someone has
> > tried looking into using this client with pure VDR?
>
> The thing is not yet available, so the current SVN doesn't contain most of
> the new code. But in general it uses the same "reel"vdr-base as the
> Avantgarde (just with a different output plugin for the SoC). The live TV
> streaming is not done by the vdr on the Avantgarde, but directly via
> IPv6-multicast by the NetCeiver-hardware. This is the same way the
> Avantgarde gets its data, so the NetCeiver traffic is just bridged into the
> LAN for other clients.
>
> --
> Georg Acher, ac...@in.tum.de
> http://www.lrr.in.tum.de/~acher
> "Oh no, not again !" The bowl of petunias
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>



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

Re: [vdr] reel netclient

[Georg Acher]

On Mon, Apr 13, 2009 at 06:28:36PM +1000, Torgeir Veimo wrote:
> http://www.reel-multimedia.com/en/shop_netclient.php describes a new  
> product by reel that allows streaming of HD content over the network.  
> It includes a hw decoder that supports mpeg2/4 and is to be used with  
> the reelbox avantgarde as server. I'd assume reel has implemented  
> something a bit more sophisticated than streamdev for this, but given  
> the open source nature of their products, I'm wondering if someone has  
> tried looking into using this client with pure VDR?

The thing is not yet available, so the current SVN doesn't contain most of
the new code. But in general it uses the same "reel"vdr-base as the
Avantgarde (just with a different output plugin for the SoC). The live TV
streaming is not done by the vdr on the Avantgarde, but directly via
IPv6-multicast by the NetCeiver-hardware. This is the same way the
Avantgarde gets its data, so the NetCeiver traffic is just bridged into the
LAN for other clients.

-- 
 Georg Acher, ac...@in.tum.de 
 http://www.lrr.in.tum.de/~acher
 "Oh no, not again !" The bowl of petunias  

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

Re: [vdr] xineliboutput cvs broken osd scaling

[gimli]

It's half working with 1.7.5. Audio on HD channel is also broken. Only
tested on ORF 1 HD.

> gimli wrote:
>> Hi,
>>
>> with the latest cvs version of xineliboutput the OSD scaling is broken
>> using HD content. The OSD seems way to large on HD content.
>>
>> My setup is :
>>
>> Soft :
>>
>> vdr-1.7.5
>> xineliboutput from today
>> xine-lib-vdpau
>>
>> Hard :
>> For video out i use vdpau on an IGP8300 motherboard.
>>
>> Anyone else noticed that behavior ?
>>
>> cu
>>
>> Edgar (gimli) Hucek
>>
>>
>>
>> ___
>> vdr mailing list
>> vdr@linuxtv.org
>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>>
>>
> Yes, I've had the very same problem for weeks. It looks as though I only
> see the upper left 720x576 pixels no matter what content I play. So for
> 1080i I hardly see any OSD at all. Dose xineliboutput CVS work with
> 1.7.5 already?
> /Magnus H
>
>
>



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

Re: [vdr] xineliboutput cvs broken osd scaling

[Magnus Hörlin]

gimli wrote:
> Hi,
>
> with the latest cvs version of xineliboutput the OSD scaling is broken
> using HD content. The OSD seems way to large on HD content.
>
> My setup is :
>
> Soft :
>
> vdr-1.7.5
> xineliboutput from today
> xine-lib-vdpau
>
> Hard :
> For video out i use vdpau on an IGP8300 motherboard.
>
> Anyone else noticed that behavior ?
>
> cu
>
> Edgar (gimli) Hucek
>
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
>   
Yes, I've had the very same problem for weeks. It looks as though I only 
see the upper left 720x576 pixels no matter what content I play. So for 
1080i I hardly see any OSD at all. Dose xineliboutput CVS work with 
1.7.5 already?
/Magnus H

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

Re: [vdr] xineliboutput cvs broken osd scaling

[Malte Schröder]

On Mon, 13 Apr 2009 12:35:24 +0200 (CEST)
"gimli"  wrote:

> Hi,
> 
> with the latest cvs version of xineliboutput the OSD scaling is broken
> using HD content. The OSD seems way to large on HD content.
> 
> My setup is :
> 
> Soft :
> 
> vdr-1.7.5
> xineliboutput from today
> xine-lib-vdpau
> 
> Hard :
> For video out i use vdpau on an IGP8300 motherboard.
> 
> Anyone else noticed that behavior ?

Yes, but the other way around: The OSD is too small when viewing
sub-PAL resolutions. Didn't try HD-stuff yet.

I made a screenshot, viewable here:
http://www.vdrportal.de/board/thread.php?threadid=85767

BTW. the problem does not occur when using HUD-Mode, but that doesn't
play nice with VDPAU yet ...




> 
> cu
> 
> Edgar (gimli) Hucek
> 
> 
> 
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> 


-- 
---
Malte Schröder
malte...@gmx.de
ICQ# 68121508
---



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

[vdr] xineliboutput cvs broken osd scaling

[gimli]

Hi,

with the latest cvs version of xineliboutput the OSD scaling is broken
using HD content. The OSD seems way to large on HD content.

My setup is :

Soft :

vdr-1.7.5
xineliboutput from today
xine-lib-vdpau

Hard :
For video out i use vdpau on an IGP8300 motherboard.

Anyone else noticed that behavior ?

cu

Edgar (gimli) Hucek



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

Re: [vdr] xineliboutput and PrimaryDVB

[Lauri Tischler]

Pertti Kosunen wrote:
> Lauri Tischler wrote:
>> I wonder if it is possible to somehow make xinelibout automagically
>> detect correct PrimaryDVB, now, every time I plug/unplug usb-devices
>> I need to manually edit setup.conf for correct PrimaryDVB.
> 
> vdr --help
> 
>-p--primary  Force xineliboutput to be primary device when
> there are active frontend(s)
> 
> Give -p option to xineliboutput-plugin.

Aargh... Thank You, I did not think of looking for plugin options
in vdr itself, these is no mention of -p option in plugin itself.
I did RTFM (README) of xineliboutput.

I think that 'vdr -help' is not the correct place for any plugin options.


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

Re: [vdr] xineliboutput and PrimaryDVB

[Pertti Kosunen]

Lauri Tischler wrote:
> I wonder if it is possible to somehow make xinelibout automagically
> detect correct PrimaryDVB, now, every time I plug/unplug usb-devices
> I need to manually edit setup.conf for correct PrimaryDVB.

vdr --help

   -p--primary  Force xineliboutput to be primary device when
there are active frontend(s)

Give -p option to xineliboutput-plugin.

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

[vdr] xineliboutput and PrimaryDVB

[Lauri Tischler]

I wonder if it is possible to somehow make xinelibout automagically
detect correct PrimaryDVB, now, every time I plug/unplug usb-devices
I need to manually edit setup.conf for correct PrimaryDVB.
ie, I have
- dev 1 DVB-S FF PCI
- dev 2 DVB-T PCI
- dev 3 DVB-T USB (occasionaly)
this setup requires PrimaryDVB = 4 to work
If I now remove USB-device and restart VDR, PrimaryDVB reverts to 1
and I need to edit setup for 3.

Cheers, Happy Easter...

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

[vdr] reel netclient

[Torgeir Veimo]

http://www.reel-multimedia.com/en/shop_netclient.php describes a new  
product by reel that allows streaming of HD content over the network.  
It includes a hw decoder that supports mpeg2/4 and is to be used with  
the reelbox avantgarde as server. I'd assume reel has implemented  
something a bit more sophisticated than streamdev for this, but given  
the open source nature of their products, I'm wondering if someone has  
tried looking into using this client with pure VDR?

-- 
Torgeir Veimo
torg...@pobox.com





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