Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linux-dvb] Re: Organization, libdvb, DVB driver, dvbtools, etc etc



On Mon, 2002-10-14 at 16:48, Benjamin Forgeau wrote:

> 	I'm very puzzled. What we need is a central library that can evolve 
> with the capabilities of the driver. It should be possible to compile 
> the lib once and use any kind of newer or older version of the modules 
> with it. The lib should find the correct device and determine which 
> capabilities are implemented or not. Of course limited to the 
> capabilities known at the time of writing the lib. We should have only 
> one file to include, something like <dvb.h>. The lib should also 
> propose some functions for parsing DVB data.

I aim to accomplish this with libdvbsak. (I renamed my libdvb to avoid
ambiguities.)

Here are the main goals of the library:

        * Security: We really can't afford to trust the data flowing in
          from various DVB sources. I've seen several DVB data decoding
          implementations where almost no care has been put to verify
          that the data is actually correct. Buffer overflowing is
          trivial in these implementations. Trying to make the code more
          secure demands a lot of work, though, but when I (and the
          others who want to participate in libdvbsak development) do
          the sweaty work, and other projects start using libdvbsak as a
          filtering 'frontend', we should be safe (or at least safer).
        * Several abstraction layers: libdvbsak has, and will have,
          several hooks to allow tying into the DVB datastream at
          various level. E.g. one can tap into the raw TS stream,
          sections, or the fully decoded tables.
        * Performance: For video streaming applications, the copying of
          stream data should be minimal, because the data rates can grow
          quite high when e.g. remuxing 3 transport streams. The
          critical places (e.g. software TS decoder) should also employ
          efficient algorithms.
        * Flexibility: Because of its modular structure, libdvbsak
          should be able to process transport streams from any source
          (e.g. RTP), and should be able to work with all driver
          versions of the Linux DVB drivers.
        * Central storing for configuration information: E.g. the
          channel list should be stored in one place in unified format
          and be easily accessed and modified by the applications. I
          will start writing support for this as soon as I get dvbscan
          in a usable state.
        * CodingStyle as sanctioned by Linus =)

If any of you are developers of a DVB application and don't like some
aspects of libdvbsak, please open your mouth now and say what I'm doing
wrong. Changing the API is much more painful later.

Cheers,
Juha




-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.



Home | Main Index | Thread Index