Kenneth Aafl?y wrote: > 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. Yep, it depends very much on the module.. But as my understanding goes, whichever module you have starting the decoding of a new stream would cause a small glitch, unless specific modules with specific capabilities are used .. but the problem standard consumer CAM's is that it would fail after many zaps, and or long hours, as Marc points out. > > >>>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 I am not using the ci thread at all .. As per the implementation goes, a thread handling would be done in userspace for the current CI API , and in kernelspace for the High Level API. But currently i don't have anything to do with the current CI handling stuff (doing it only for the High Level Interface) > 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. > I do not have new IOCTL's either, just standard ones *only*. > >>>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? > Hmm ... at this point i can't see the end of the tunnel, maybe moving ahead, maybe i can comment on that part .. ? But again it all depends upon the goal we want to achieve .. Which again depends upon the contribution of others too.. My contribution to it is for the High Level API, such that it hides complexities, and is friendly to all while being simple and lean .. With that aspect in mind i started to rewrite ca_zap, which resulted in this way, if you see Johannes's previous mail regarding ca_zap, that it be made simple. > >>>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. It is kind of neutral, since it only matters how you want to use it .. 2 ways are there of using it, the current structure and the High level structure. I have an implementation for the High level structure .. If somebody would write the required stuff for the low level stuff, there is nothing better than that, that it would be a complete CI stack really portable. Well it is even portable to an extent where Ralph suggested that USB devices and PCI devices could also share the same codebase for the communication .. but it would be only an interface to that layer, not that layer itself, as at this point it looks like an overkill. But it would not be too difficult to get that moving on since, once this part is there in place, that layer could also be worked upon .. > > >>>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 Actually it does not even decode, just transfers packets and does some parsing at the moment. Which is what would be the simplest of all .. > handling could even be as simple as setting a flag when telling the library > to start recording a particular channel. > I am nowhere near telling the library when to start recording and all, it is still in it's infancy .. > >>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. I will, give me a bit time, i have to organize my stuff where it belongs to after a disaster recovery .. I need some sleep, atleast tonight .. > liben50221 is an abstraction of that protocol made for the twinhan by you? > In fact an abstraction of a few EN50221 tags, currently i have only tag, but would require other tags too. In fact there is nothing Twinhan specific, but a generic library that is quite clean, small and simple. Not for the Twinhan, it is an abstraction of the few EN50221 tags that i use .. maybe my factorization would help others for reusability .. It is based upon the discussion that we had (The quite long discussions with Ralph a while back). basically you can say the userspace part, and the userspace part i factored out, since many objected to a externel libraries into the CVS. Initially i wrote ca_zap to test the Twinhan driver.. Then i found that it was getting unmaintainable, and as a result i had to factorize code.. Factorizing led me to create a couple of parsers, which ended up as libsi, and the implementation of the High Level CI became as liben50221. This implementation is not limited to Twinhan or other cards, but it can be used as it for anything else since it *just* does only what the EN50221 tags do state. > >>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 That would be nice .. The location for the same was suggested by Johannes like this .. dvb-apps/util/libsi/ and dvb-apps/util/ca_zap/ That time liben50221 had not evolved yet, since i had been refactorizing code, as i was working on them as well .. > processing filters comes to mind. These are very common features in about > every video processing application I've ever seen. The possibilities are limitless ... There isn't a point where there is a limit to dreaming around, and if you can dream about, you can very well achieve that too .. > > ALVA ;) > > Other ideas? > Ideas evolve out of a base platform.. first let's get a small platform in there .. We could get moving on that.. Any suggestions .. ? Johannes suggested thus .. "A lib for all the basic funtionality of szap and scan (tuning, filters, parsing) would be cool, but please keep it simple." Manu
