You can use "make menuconfig" in /usr/src/multiproto and find the following
information:
Empia EM2800/2820/2840 USB video capture support (VIDEO_EM28XX) [N/m/?]
Key the "N".
Last,repeat "make".> From: [EMAIL PROTECTED]> Subject: vdr Digest, Vol 42,
Issue 11> To: vdr@linuxtv.org> Date: Sat, 12 Jul 2008 12:00:02 +0200> > Send
vdr mailing list submissions to> vdr@linuxtv.org> > To subscribe or unsubscribe
via the World Wide Web, visit>
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr> or, via email, send a
message with subject or body 'help' to> [EMAIL PROTECTED]> > You can reach the
person managing the list at> [EMAIL PROTECTED]> > When replying, please edit
your Subject line so it is more specific> than "Re: Contents of vdr digest...">
> > Today's Topics:> > 1. Re: multiproto_plus is ancient (Lauri Tischler)> 2.
Re: multiproto_plus is ancient (Lauri Tischler)> 3. Re: multiproto_plus is
ancient (Artem Makhutov)> 4. Control VDR with RF remote (Michael Stepanov)> 5.
Vdr-xine OSD question (Todd Luliak)> 6. Re: Control VDR with RF remote (Peer
Oliver Schmidt)> 7. Re: Vdr-xine OSD question ( Antti Sepp?l? )> 8. xine tvtime
parameters explained (Lauri Tischler)> > >
----------------------------------------------------------------------> >
Message: 1> Date: Fri, 11 Jul 2008 13:14:56 +0300> From: Lauri Tischler <[EMAIL
PROTECTED]>> Subject: Re: [vdr] multiproto_plus is ancient> To: VDR Mailing
List <vdr@linuxtv.org>> Message-ID: <[EMAIL PROTECTED]>> Content-Type:
text/plain; charset=ISO-8859-1; format=flowed> > VDR User wrote:> > On Thu, Jul
10, 2008 at 4:13 AM, Lauri Tischler <[EMAIL PROTECTED]> wrote:> >> What 'FF mod
card' are you referring to ?> > > > There's a hardware hack to allow the full
transport stream to be> > passed by the Nexus. By default it doesn't so when
there's heavy> > load, a lot of packets are dropped.> > > >> I have basic
Hauppauge NEXUS-S FF card and a pair of Hauppauge NOVA-T> >> cards, in near
future I will get some S2 capable card.> >> So, what tree should I use for VDR
1.7.xx ?> > > > For a stock Nexus-s, you can use any tree. V4L with the vdr
api> > wrapper patch, or *multiproto*.> > Hmmm.. compile error....> ----> CC
[M] /usr/src/multiproto/v4l/em28xx-audio.o> In file included from
/usr/src/multiproto/v4l/em28xx-audio.c:39:> include/sound/core.h:281: error:
'SNDRV_CARDS' undeclared here (not in a > function)>
/usr/src/multiproto/v4l/em28xx-audio.c:58: error: array index in > initializer
not of integer type> /usr/src/multiproto/v4l/em28xx-audio.c:58: error: (near
initialization > for 'index')> make[3]: ***
[/usr/src/multiproto/v4l/em28xx-audio.o] Error 1> make[2]: ***
[_module_/usr/src/multiproto/v4l] Error 2> make[2]: Leaving directory
`/usr/src/linux-headers-2.6.24-19-generic'> make[1]: *** [default] Error 2>
make[1]: Leaving directory `/usr/src/multiproto/v4l'> ----> > > >
------------------------------> > Message: 2> Date: Fri, 11 Jul 2008 16:13:05
+0300> From: Lauri Tischler <[EMAIL PROTECTED]>> Subject: Re: [vdr]
multiproto_plus is ancient> To: VDR Mailing List <vdr@linuxtv.org>> Message-ID:
<[EMAIL PROTECTED]>> Content-Type: text/plain; charset=ISO-8859-1;
format=flowed> > Lauri Tischler wrote:> > VDR User wrote:> >> On Thu, Jul 10,
2008 at 4:13 AM, Lauri Tischler <[EMAIL PROTECTED]> wrote:> >>> What 'FF mod
card' are you referring to ?> >> There's a hardware hack to allow the full
transport stream to be> >> passed by the Nexus. By default it doesn't so when
there's heavy> >> load, a lot of packets are dropped.> >>> >>> I have basic
Hauppauge NEXUS-S FF card and a pair of Hauppauge NOVA-T> >>> cards, in near
future I will get some S2 capable card.> >>> So, what tree should I use for VDR
1.7.xx ?> >> For a stock Nexus-s, you can use any tree. V4L with the vdr api>
>> wrapper patch, or *multiproto*.> > > > Hmmm.. compile error....> > ----> >
CC [M] /usr/src/multiproto/v4l/em28xx-audio.o> > In file included from
/usr/src/multiproto/v4l/em28xx-audio.c:39:> > include/sound/core.h:281: error:
'SNDRV_CARDS' undeclared here (not in a > > function)> >
/usr/src/multiproto/v4l/em28xx-audio.c:58: error: array index in > >
initializer not of integer type> > /usr/src/multiproto/v4l/em28xx-audio.c:58:
error: (near initialization > > for 'index')> > make[3]: ***
[/usr/src/multiproto/v4l/em28xx-audio.o] Error 1> > make[2]: ***
[_module_/usr/src/multiproto/v4l] Error 2> > make[2]: Leaving directory
`/usr/src/linux-headers-2.6.24-19-generic'> > make[1]: *** [default] Error 2> >
make[1]: Leaving directory `/usr/src/multiproto/v4l'> > ----> > otoh the
v4l-dvb tree compiles just fine but multiproto does not.> > > >
------------------------------> > Message: 3> Date: Fri, 11 Jul 2008 15:30:25
+0200> From: Artem Makhutov <[EMAIL PROTECTED]>> Subject: Re: [vdr]
multiproto_plus is ancient> To: VDR Mailing List <vdr@linuxtv.org>> Message-ID:
<[EMAIL PROTECTED]>> Content-Type: text/plain; charset=us-ascii> > Hi,> > On
Fri, Jul 11, 2008 at 01:14:56PM +0300, Lauri Tischler wrote:> > VDR User
wrote:> > > On Thu, Jul 10, 2008 at 4:13 AM, Lauri Tischler <[EMAIL PROTECTED]>
wrote:> > >> What 'FF mod card' are you referring to ?> > > > > > There's a
hardware hack to allow the full transport stream to be> > > passed by the
Nexus. By default it doesn't so when there's heavy> > > load, a lot of packets
are dropped.> > > > > >> I have basic Hauppauge NEXUS-S FF card and a pair of
Hauppauge NOVA-T> > >> cards, in near future I will get some S2 capable card.>
> >> So, what tree should I use for VDR 1.7.xx ?> > > > > > For a stock
Nexus-s, you can use any tree. V4L with the vdr api> > > wrapper patch, or
*multiproto*.> > > > Hmmm.. compile error....> > ----> > CC [M]
/usr/src/multiproto/v4l/em28xx-audio.o> > In file included from
/usr/src/multiproto/v4l/em28xx-audio.c:39:> > include/sound/core.h:281: error:
'SNDRV_CARDS' undeclared here (not in a > > function)> >
/usr/src/multiproto/v4l/em28xx-audio.c:58: error: array index in > >
initializer not of integer type> > /usr/src/multiproto/v4l/em28xx-audio.c:58:
error: (near initialization > > for 'index')> > make[3]: ***
[/usr/src/multiproto/v4l/em28xx-audio.o] Error 1> > make[2]: ***
[_module_/usr/src/multiproto/v4l] Error 2> > make[2]: Leaving directory
`/usr/src/linux-headers-2.6.24-19-generic'> > make[1]: *** [default] Error 2> >
make[1]: Leaving directory `/usr/src/multiproto/v4l'> > ----> > You need this
patch:> > http://linuxtv.org/hg/v4l-dvb/raw-diff/b0815101889d/v4l/compat.h> >
Please take a look at>
http://www.linuxtv.org/pipermail/linux-dvb/2008-February/023819.html> > > Maybe
the patch should be directly merged into the multiproto tree...> > Regards,
Artem> > -- > Artem Makhutov> Unterort Str. 36> D-65760 Eschborn> > > >
------------------------------> > Message: 4> Date: Fri, 11 Jul 2008 17:35:36
+0300> From: "Michael Stepanov" <[EMAIL PROTECTED]>> Subject: [vdr] Control VDR
with RF remote> To: vdr@linuxtv.org> Message-ID:> <[EMAIL PROTECTED]>>
Content-Type: text/plain; charset="iso-8859-1"> > Hi,> > Does anybody use RF
remote control with VDR instead of IR? How to configure> such remotes?> >
Thanks in advance.> > -- > Cheers,> Michael> -------------- next part
--------------> An HTML attachment was scrubbed...> URL:
http://www.linuxtv.org/pipermail/vdr/attachments/20080711/0ecc1aee/attachment-0001.htm
> > ------------------------------> > Message: 5> Date: Fri, 11 Jul 2008
10:10:14 -0700 (PDT)> From: Todd Luliak <[EMAIL PROTECTED]>> Subject: [vdr]
Vdr-xine OSD question> To: vdr@linuxtv.org> Message-ID: <[EMAIL PROTECTED]>>
Content-Type: text/plain; charset="us-ascii"> > I am running vdr + vdr-xine
plugin + coreavc + xine being output at> 1080i to an HDTV as the only display.
Is there a simple way to lock the> OSD to the resolution of the output device
such that the OSD is not> rescaled when switching between SD and HD sources? I
played with> X-overlay, but that was not what I was after. If not, could it be
done> in the source somewhere or is the OSD anti-aliased and overlayed on the>
video before being sent to the output device (xine, in my case)? I've> looked
around quite a bit on the net but I guess my google-foo is> failing me on this
one. I just miss the rock-solid OSD of the FF card> setup...> > Thanks!> > > >
> > -------------- next part --------------> An HTML attachment was
scrubbed...> URL:
http://www.linuxtv.org/pipermail/vdr/attachments/20080711/f6f5c05d/attachment-0001.htm
> > ------------------------------> > Message: 6> Date: Fri, 11 Jul 2008
21:04:07 +0200> From: Peer Oliver Schmidt <[EMAIL PROTECTED]>> Subject: Re:
[vdr] Control VDR with RF remote> To: VDR Mailing List <vdr@linuxtv.org>>
Message-ID: <[EMAIL PROTECTED]>> Content-Type: text/plain; charset=ISO-8859-1;
format=flowed> > Hello Michael,> > > Does anybody use RF remote control with
VDR instead of IR? How to > > configure such remotes?> > I used the ATI
RemoteWonder with it. LIRC has support for it.> > ps: But you should stay with
lmce ;)> -- > Best regards> > Peer Oliver Schmidt> the internet company> PGP
Key ID: 0x83E1C2EA> > > > > ------------------------------> > Message: 7> Date:
Fri, 11 Jul 2008 22:14:01 +0300> From: " Antti Sepp?l? " <[EMAIL PROTECTED]>>
Subject: Re: [vdr] Vdr-xine OSD question> To: "VDR Mailing List"
<vdr@linuxtv.org>> Message-ID:> <[EMAIL PROTECTED]>> Content-Type: text/plain;
charset=ISO-8859-1> > 2008/7/11 Todd Luliak <[EMAIL PROTECTED]>:> > I am
running vdr + vdr-xine plugin + coreavc + xine being output at 1080i to> > an
HDTV as the only display. Is there a simple way to lock the OSD to the> >
resolution of the output device such that the OSD is not rescaled when> >
switching between SD and HD sources? I played with X-overlay, but that was> >
not what I was after. If not, could it be done in the source somewhere or is> >
the OSD anti-aliased and overlayed on the video before being sent to the> >
output device (xine, in my case)? I've looked around quite a bit on the net> >
but I guess my google-foo is failing me on this one. I just miss the> >
rock-solid OSD of the FF card setup...> > Thanks!> >> > In an effort to create
something to solve such issues with> xineliboutput plugin I came up with an
idea of this HUD type OSD.> Basically it means that OSD is rendered to a
separate transparent> surface on top of video and then these are blended
together by the> display hardware. This way the size of the OSD is bound to the
size of> the used window rather than the size of the video stream. In other>
words no OSD scaling will be necessary even though the video size> changes.> >
The HUD implementation has been integrated into the CVS of> xineliboutput
plugin. To operate it requires support for xorg render> extension and presence
of composite display manager such as xcompmgr.> It also requires powerful
display adapter and drivers with support for> these modern extensions. Maybe
you can try it to see if it produces> results that you are hoping for?> >
Regards,> > -- > Antti Sepp?l?> <[EMAIL PROTECTED]>> > > >
------------------------------> > Message: 8> Date: Sat, 12 Jul 2008 11:23:49
+0300> From: Lauri Tischler <[EMAIL PROTECTED]>> Subject: [vdr] xine tvtime
parameters explained> To: VDR Mailing List <vdr@linuxtv.org>> Message-ID:
<[EMAIL PROTECTED]>> Content-Type: text/plain; charset=ISO-8859-1;
format=flowed> > Trying to google for manual, info or article where all
parameters for> xine tvtime command are explained, what they do, why, etc.> No
luck yet, any pointers ??> > > > ------------------------------> >
_______________________________________________> vdr mailing list>
vdr@linuxtv.org> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr> > > End
of vdr Digest, Vol 42, Issue 11> ***********************************
_________________________________________________________________
这里好多好玩的视频，用鼠标点到视频看看，有惊喜！
http://cnweb.search.live.com/video/results.aspx?q=%E5%A5%A5%E8%BF%90%E5%9C%A3%E7%81%AB&mkt=zh-cn&FORM=WLMTWC
_______________________________________________
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
