We are trying to record the classroom session in a real time.
The “real time” part is probably your biggest problem here…
[…]
At the end of the classroom the “discrete blocks” and “continous
blocks” are stored in a propritery format to be played back later.
^^^^^^^^^^
You mean you have to use a file format that’s fundamentally
cripled and made useless right from the start, rather than a
Free/Open file format? 
Is this the right solution to store a classroom ?
Well, the basic idea is pretty much the only way I can think of… What
other ways are there, apart from adding/removing “special features” like
the discrete/continuous block distinction?
BTW, with a proper “compression” algo, I don’t really see the point in
the discrete mode. Compressing N frames with no changes should result in
the same output as 1 frame with any algo suitable for this kind of
applications.
What would be the appropriate file sizes.
How about “the smallest possible that meets the quality requirements”?
Seriously, most of the time, you’re just moving the mouse around, popping
up a tiny menu, or switching to the next “page”. So, first off after
grabbing each frame, you should probably do a simple and fast diff test
between the new frame and the last frame. (For example, chop the screen
up into 32x32 tiles, and then test them one by one, adding the ones with
an old/new difference to a linked list, table or whatever.) Only consider
the changed areas for storage. Depending on your input, this alone might
be sufficient!
If not (ie too big areas change too often), keep in mind that you’ll need
a very fast CPU to compress anything near a full screen per frame, if
you want a frame rate high enough not to force the teacher to run a
"slowmotion demo" for video viewers to be able to follow the action.
Simple, non-destructive RLE encoding helps a lot for normal application
GUIs and the like, and relatively fast implementations aren’t too hard to
code. It won’t do much for animations with lots of gradients and stuff,
though - can’t think of any simple algorithms for compressing that kind
of stuff, so you’re probably better off with some tried video compression
algo there.
Finally, think about buffering - done right, it will make things run a
lot smoother. I don’t know what you’ll be recording exactly, but I
suspect that there will be extended periods of time where there’s very
little work for the compressor, while occasionally, almost the whole
screen will change. Setting up sufficient buffering (corresponding to
several full screens, if possible) in between the initial "tile changed"
test and the actual compression (in another thread) might help. Queue up
full screen buffers, or preferably tiles, in a FIFO queue or similar
construct between the threads, so that the grabbing + testing code can
run at full speed all the time, as long as there is free buffer space.
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Sunday 11 November 2001 13:44, Karthick Purushothaman wrote: