Kenneth Aafl?y wrote: > Hi, > > 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 [1] 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 .. Manu
