On Saturday 02 April 2005 18:52, Manu Abraham wrote: > Kenneth Aafl?y wrote: > 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.) Concerning the application to library interface I would say it should be as simple as telling it to 'try decode this stream' or asking the library if it potentionally can decode a particular stream. For example I've been doing work on a new media application, in which I have had partiall success with decoding multiple streams at once (even on standard consumer cams), but some issues are there; starting a decoding of a new stream in the middle of another on my conax cam will create a 'dent' in the stream that had already started decoding. And only a certain number of pids (could be bandwith limited) can be decoded simultainusly. > > 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 ! Iirc, you are not even using the ci thread are you? You basically want to provide a thin layer from your driver to the library, which handles the real quirks of the twinhan interface. Afaik adding new ioctls is no danger to binary compatability, we'll just provide an interface for probing for features. > > 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. Well, this depends on how far we want to go with this library. Should it for example hide differences between v3 and v4 api? > > 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 .. Indeed, but I must emphasize on the fact that the library could handle any interface internally. > > 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. As mentioned above, I think the application to library interface should be as simple as decode pid x on the currently tuned transponder. The actually cam handling could even be as simple as setting a flag when telling the library to start recording a particular channel. > 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.. :-( I have not had a good look at libsi, please direct me to more info. liben50221 is an abstraction of that protocol made for the twinhan by you? > Let me know what you think .. Well, I'm thinking even more exciting features could be brought into this library as it grows out of infacy, for example handling v4l devices and frame processing filters comes to mind. These are very common features in about every video processing application I've ever seen. ALVA ;) Other ideas? Kenneth
