From: Johannes Stezenbach <js@linuxtv.org>
To: rjkm <rjkm@metzlerbros.de>
Cc: linux-media@vger.kernel.org
Subject: Re: How to handle independent CA devices
Date: Tue, 14 Sep 2010 16:43:39 +0200 [thread overview]
Message-ID: <20100914144339.GA9525@linuxtv.org> (raw)
In-Reply-To: <19593.22297.612764.560375@valen.metzler>
Hi Ralph,
On Thu, Sep 09, 2010 at 11:52:25PM +0200, rjkm wrote:
>
> cards like the Digital Devices DuoFlex S2, cineS2 and upcoming
> hardware (octuple, network, etc.) have independent CA devices.
> This means that instead of having the stream routed from the frontend
> through the CI and only then into memory a stream can be sent from
> memory through the CI and back. So, the current device model does not
> fit this hardware.
>
> One could hide this fact inside the driver and send the stream from
> the frontend through the CI transparently to the API but this would
> prevent people from implementing new features like decoding a stream from
> a different DVB card, decoding streams from hard disk or even decoding
> several sub-streams from different transponders.
> The latter works with the current Windows driver but I have not
> implemented it in Linux yet. It also has to be supported by the CI
> modules. Some can decode 12 streams (6 times video/audio) at once.
>
> But decoding single streams already works fine. Currently, I am
> registering a different adapter for the CI.
> On a CineS2 with CI attached at the IO port I then have
>
> /dev/dvb/adapter[01] for the two DVB-S2 frontends and
> /dev/dvb/adapter2 just for the ca0 device.
>
> I am abusing the unused sec0 to write/read data to/from the CI module.
> For testing I hacked zap from dvb-apps to tune on adapter0 but
> use adapter2/ca0 to talk to the CI module.
> I then write the encrypted stream from adapter0/dvr0 into
> adapter2/sec0 and read the decoded stream back from adapter2/sec0.
> The encrypted stream of course has to contain all the PIDs of the
> ca_pmt.
>
> So, I would like to hear your opinions about how to handle such CA devices
> regarding device names/types, the DVB API and user libraries.
it looks like there isn't much interest from DVB developers
in that topic... I'll try...
IMHO there are three sub topics:
1. be compatible with existing applications
(I guess this means: feed stream from frontend through CI transparently)
2. create an API which would also work for CI-only
devices like this Hauppauge WinTV-CI USB thingy
3. how to switch between these modes?
This sec0 device is history (unused and deprecated for years), right?
How about the following:
Rename it to ci0. When ci0 is closed the stream is routed
transparently from frontend through CI, if it's opened one needs to
read/write the stream from userspace.
If you can't get responses here I guess you could talk to
vdr or other application developers. After all they'll have
to use the API.
Cheers,
Johannes
next prev parent reply other threads:[~2010-09-14 14:43 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-09 21:52 How to handle independent CA devices rjkm
2010-09-14 14:43 ` Johannes Stezenbach [this message]
2010-09-14 23:56 ` rjkm
2010-09-15 3:13 ` Emmanuel
2010-09-15 4:05 ` Manu Abraham
2010-09-18 0:47 ` rjkm
2010-09-18 11:27 ` James Courtier-Dutton
2010-09-18 12:23 ` Manu Abraham
2010-09-19 1:20 ` Oliver Endriss
2010-09-16 20:43 ` [linux-media] " Klaus Schmidinger
2010-09-18 1:02 ` rjkm
2017-06-29 20:10 ` Jasmin J.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100914144339.GA9525@linuxtv.org \
--to=js@linuxtv.org \
--cc=linux-media@vger.kernel.org \
--cc=rjkm@metzlerbros.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox