[linux-dvb] What do you think of mpsys library ? (for ca_zap)
manu at kromtek.com
Sat Apr 2 18:52:30 CEST 2005
Kenneth Aafløy wrote:
> On Friday 01 April 2005 17:53, Dominique Dumont wrote:
>>Manu and I are currently exchanging ideas (and code) related to the
>>next ca_zap (i.e. the small user space application in charge of
>>sending a ca_pmt message to the CAM on a Twinhan card).
>>We are thinking about providing a library to parse PAT and PMT and to
>>generate an EN50221 CA_SET_PMT message.
>>I've seen that mpsys library  alreasy provides a C library to parse
>>PMT and most of a TS stream. Using the XML protocol description, it
>>should be quite easy to provide an EN50221 parser also. (although,
>>I'm not so sure about the encoding part of the EN50221 messages ... I
>>may have to dust off my XSLT cookbook )
>>What do you think of this library ?
>>Is there any reason not to use it with dvb application ?
>>Or not to recommend it ?
> I'm not sure why you want to bring xml into this picture? Abstracting?
> I'm thinking:
> We merge the code from *zap and scan in a library, similar to the alsa library.
Exactly.. My idea was that i have a ca_zap application, for which the
code can be easily factorized out... and that is what exactly i am
doing, rather than have another library into the picture, such that we
loose a lean architecture ...
> Importing common features such as the vdr ci code (which is used by at least
> mythtv and iirc videolan), then provide a common method of tuning that includes
> the quirks of handling an associated cam. The library would have control over
> a configuration file that resides in etc, which the application may or may not
With the ca_zap factorized out, the communication happens to be purely
EN50221 style paclet exchange, which was exactly as we discussed earlier
regarding the design of the High Level CI interface.
With this interface, the translation is carried out by the driver,
rather than a library. The advantage would be that, hardware that does
not fit into the current scheme can be very well associated with that
way ( i really mean all of them, if you are really interested to know
more , i have Documentation/ci.txt in the experimental branch depicting
how to use it further.)
> use as it sees fit. Both the in kernel frontend and ci threads could
> potentionally be moved to userspace, reducing the kernel driver footprint.
No, moving the ci threads out from the driver would raise the very same
questions that we had been discussing earlier. The point is to
accomodate new hardware !
> The interface of this library must offcourse be pondered on, as it should remain
> very stable and allow extensions that potentially could be introduced by new
> adapter types. IIRC there is also an implementation of ts2ps (or similar) in
> the kernel that could be ripped out.
The interface of the library is very similar to the ones found in scan
and so on, so i don't think there is much of an issue there.
> The CAM handling could then be very simplyfied, allowing either the application
With this way the CAM handling is extremely simplified...
Once the packets are exchanged, the driver takes care of the rest ..
> or the library (plugins?) to handle the features of decrypting the stream. IIRC
> Marcus Metzler pointed out to me that there are meny methods of controlling
> decrypting a stream, that involves controlling a remote device, which also
> would fit well in this picture.
Yes it could very well fit into the picture (as the interface of the USB
devices are different, this way it would be very effecient, since this
does *only* EN50221 style exchange and not tied to any specific style,
or hardware interface.), i was currently doing some basic parsing and
some Application level EN50221 style packet exchange. Whatever new could
be very well added to it without any difficulty as it is relatively simple.
> We could start simple, just providing the features of handling decryption, then
> put in other blocks to handle other aspects of dvb.
That's what exactly what i am doing .. I am right now providing
(factorizing) the code that would otherwise go into ca_zap.
> What do you think?
Currently my architecture is like this, ca_zap is linked against 2 tiny
libs, libsi and liben50221, which are nothing but factored code from
ca_zap as you might have already seen from my earlier patches ...
I had been restoring my system from a relatively low level and hence the
delay in getting things up as expected.. :-(
> To radical a goal?
Let me know what you think ..
More information about the linux-dvb