Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 31 Mar 2011 13:56:19 +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:  <AANLkTimVY1FpiCYjYC5iH4H2pQBmkvR6nwH0kpDtFsjx@mail.gmail.com>
In-Reply-To: <201103311337.17780.hselasky@c2i.net>
References:  <AANLkTikz6QLPa=nz=PjYQC6_NmReUYQVZf3CyjAPOTpa@mail.gmail.com> <201103311247.44164.hselasky@c2i.net> <AANLkTik=dbS0eSbA-dd=7uRRTpxRS=%2BjwFJjB8nNJ9d2@mail.gmail.com> <201103311337.17780.hselasky@c2i.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi,

On Thu, Mar 31, 2011 at 1:37 PM, Hans Petter Selasky <hselasky@c2i.net> wro=
te:
> On Thursday 31 March 2011 13:20:17 Markus Rechberger wrote:
>> Hi,
>>
>
> Hi,
>
>> What I was thinking was
>> [ kaffeine ] [ vdr ] [ mplayer ] [ tvtime ]
>>
>> [libdvbaccess]
>>
>> [ plugin for webcamd bsd ] =A0[ plugin for our system ] [ plugin for
>> native linux access ] etc.
>
> Looks good.
>
>> 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.
>
> You are probably aware that this library would need to support V4L/DVB AP=
I's,
> hence having two interfaces into webcamd is more trouble than it is worth=
 I
> think. Adding some parameter to register devices by libmediaccess is no
> problem however!
>

libmediaaccess should just be a library which helps to access it - it
shouldn't be a daemon.
We have support for V4L and DVB in our Multimediastack (however it's
closed source since
we are basically reusing the windows drivers and have some restrictions on =
it).
We'll definitely contribute opensource to libmediaaccess.

>>
>> we currently support DVB-C, DVB-T, DVB-S/S2, ATSC, ISDB-T, AnalogTV,
>> FM-Radio, Composite and S-Video
>>
>
> Your library will also support hardware transcoding of streams - right?
>
> I indulged into an USB based sat system myself using techotrend based ada=
pters
> working good so far. Webcamd usually does not consume very much CPU. Some=
thing
> like 5% is typical for streaming.
>

that's also my experience with our stack, does it work reliable with webcam=
d?
It even starts with 0% CPU but slowly goes up and down for some
reason, maybe there's
still some incompatibility which is running in the background.
On Linux it heavily depends on the architecture, while it uses 0% on
MIPS platforms it uses
2-10% on Intel platforms.

>> 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.
>
> This might be a buffering issue. In the latest version of webcamd I've tu=
ned
> all the buffers to reduce the interrupt rate.
>

currently we are using 64 microframes =E0 940 bytes double buffered with 2 =
xfers.
The full DVB-C bandwidth is usually ~50 Mbit here, while DVB-S/S2 is usuall=
y
only 38 MBit.

>>
>> > 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.
>
> Ok.
>
> Do you plan to support DiSEQ's and card readers aswell?
>

Diseqc support we already have, we can ship a DVB-S/S2 or DVB-C/T sample
to you so you'll see what I'm talking about and we can at least make
both systems
work with each other instead of replacing each other.

DVB-C:
http://www.sundtek.de/images/freebsd-screenshot.jpg

DVB-S/S2 is basically the same here.

BR,
Markus



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTimVY1FpiCYjYC5iH4H2pQBmkvR6nwH0kpDtFsjx>