Hi all!
There are two things about libgpf to solve and we need ideas. At first a short overview about how libgpf works to give you a better understanding. libgpf builds a pipeline at runtime, optimized to the data to transfer. The pipeline consists of sublibs like libggi's targets, for example. libgpf has three kind of sublibs: protocol lib, target lib and pipe lib. A pipeline looks always as this structure shows: source <protocol><target><pipe><target><protocol> senk The data stream goes always from left to right. The pipe sublib is optional and there can be more than only one as well. The input-target and output-target can be the same lib, but they usually differ. Same for the protocol lib. Now to the problems: The first thing is related how to handle frames with and without timestamps. There are three scenarious to handle. 1) Both input and output target support frames 1.a) The input target has as much frames as the output one. 1.b) The input target has more frames than the output one. 1.c) The input target has less frames than the output one. 2) Input target has frames, but not the output one 3) Output target has frames, but not the input one Currently, there are only ideas about scenario 2) and 3): 2: The user select the frame to extract ... or an image containing all the frames is generated (like a movie strips) 3: The data gets transfered to the output target to the selected frame by the user. But before we can actually start implementing frame support into libgpf, we must have a clue about to handle _all_ scenarious cleanly to do it right. The second thing is about target<->protocol lib communication. Basically the protocol takes care to transfer the data from/to the physical device to/from the target without having a clue _what_ it transfers. It also takes care about caching issues. The target doesn't know where the data comes from, but it knows what kind of data it transfers to the next level lib in the pipeline. The protocol provides a flush() mechanism intended to flush the cached data. Brian has been come up with an idea, that gives the target more control about its behaviour. His idea is to add an additional parameter that let the protocol to throw away the whole cached data to an given offset. The disadvantage is, that this parameter is unused, when the protocol acts as output. Thus, I suggested to bypass a number of bytes to flush/throw away and 0 simply means everything. This way, the additional param has a use in both ways: as input and as output. That means, when the protocol lib acts as input, then the param tells it how much data to throw away from the cache and how much data to flush, when it acts as output. Full documentation about libgpf is available in the source of libgpf (doc/ subdirectory) as plain text (It will be converted into docbook/xml later). If there's still something unclear, then feel free to ask. Any ideas, comments and feedbacks are very appreciated! -- Thanks in advance, Christoph Egger E-Mail: [EMAIL PROTECTED] GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
