Date: Thu, 31 Mar 2011 13:20:17 +0200 From: Markus Rechberger <mrechberger@gmail.com> To: Hans Petter Selasky <hselasky@c2i.net> Cc: freebsd-multimedia@freebsd.org Subject: Re: RFC libdvbaccess Message-ID: <AANLkTik=dbS0eSbA-dd=7uRRTpxRS=%2BjwFJjB8nNJ9d2@mail.gmail.com> In-Reply-To: <201103311247.44164.hselasky@c2i.net> References: <AANLkTikz6QLPa=nz=PjYQC6_NmReUYQVZf3CyjAPOTpa@mail.gmail.com> <201103311247.44164.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
On Thu, Mar 31, 2011 at 12:47 PM, Hans Petter Selasky <hselasky@c2i.net> wrote:
> On Thursday 31 March 2011 12:12:49 Markus Rechberger wrote:
>> Also the design that userspace drivers have to pass everything back to
>> kernelland does not really seem to be nice, userspace drivers came up
>> since it's possible
>
> Hi,
>
> You are referring to webcamd and similar technologies - right? You know that
> cuse4bsd supports mmap on on its nodes, which allows passing data directly
> from the driver to the client?
>
cuse4bsd, yes but it still uses the kernel layer for device
registration etc. that's just not
needed it seems. Also I do not really trust the linux cuse
implementation since it was very unstable
last time I tested it (and reporting issues about it does not clearly
point out that things are getting fixed
or got fixed, on the other side there are now many broken linux-cuse
systems out there which makes
this interface too unreliable for linux at this time)
webcamd, and our driver nearly do the same although we do not pass
anything back to the kernel again
we have libmedia.so which basically implements
wrapper functions for open/close/ioctl/read/mmap/etc ->
net_open/net_close/net_ioctl/net_read etc.
What I was thinking was
[ kaffeine ] [ vdr ] [ mplayer ] [ tvtime ]
|
[libdvbaccess]
|
[ plugin for webcamd bsd ] [ plugin for our system ] [ plugin for
native linux access ] etc.
in order to coexist - webcamd or our stack would need to be able to
report the current allocated device nodes
but that should not be a problem.
libmediaaccess would probably be a better name for it.
we currently support DVB-C, DVB-T, DVB-S/S2, ATSC, ISDB-T, AnalogTV,
FM-Radio, Composite and S-Video
currently we are facing performance issues for transferring a full
DVB-C transponder ~5 mb/sec, enabling hardware PID filter
to lower the bandwidth requirement works, the analog TV part still
needs to be tested on FreeBSD.
So far everything works on Linux and MacOSX.
> BTW: Looking forward to your libdvbaccess!
>
> Is there any source code or API available at the present moment?
>
not for libdvbaccess, just putting together some specifications/ideas first.
BR,
Markus
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTik=dbS0eSbA-dd=7uRRTpxRS=%2BjwFJjB8nNJ9d2>