Here's the basic strategy for how DryIce is built:

src/core.c contains the core functionality of DryIce.  Think: backend.

Initially, core.c also contains main(), but this is just a placeholder.  
Frontends will eventually be written for ncurses, gtk, python, etc which 
will allow the user to setup and control DryIce.  These frontends will 
each contain their own main() and link core.c for the base functions.

Since DryIce is intended to eventually support multiple concurrent 
streams it does not make sense to have core.c be a dynamic library, and 
since the frontends are quite diverse in how they operate making them 
seperate programs would make integration more difficult.

Currently I am working with a OV519 based camera made by DLink.  This is 
supported by the v4l_jpeg input module for video frames, eventually 
audio as well as this camera has a built-in microphone.  


THOUGHT PROCESS (my in-development brainstorming):

core.c will process:

1) Initialize
 a) load appropriate input module(s)
 b) connect to Icecast with libshout
 c) init camera and precache first video frame
 d) init microphone and precache some audio data

2) Run
 a) decode YUV data to theora buffer
 b) decode PCM data to vorbis buffer
 c) tell camera to fetch next frame
 d) encode theora frame
 e) encode vorbis data
 f) grab available pages, mux them properly
 g) send (raw) to libshout
 -- repeat

Now the sequence of these is important for flexibility.  We want, for 
example, to be able to display the raw YUV data locally in the GUI 
client without having to decode the outputted stream, and Python may 
(ie) want to do some processing to see how similar two frames are and 
switch to a prerecorded scene if there's no motion for several seconds,
or how bright the frame is so it can automatically turn on a light if 
it's too dark (via X10, etc).  

This means that the "run" sequence needs to be broken down to seperate 
pieces which must be called in order rather than be a continuous loop.

IE (working draft):

Fetch():
 a) decode YUV data to theora buffer
 b) decode PCM data to vorbis buffer
 c) tell camera to fetch next frame

Encode():
 d) encode theora frame
 e) encode vorbis data
 f) grab available pages, mux them properly

Send():
 g) send (raw) to libshout

We also may want to seperate the audio and video processes for extra 
flexibility.  IE, one channel could be audio-only but draw off the same 
encoded source.  This moves step f) into Send().

Additionally, we want to make sure that the decoded data from Fetch(), 
the encode channels in Encode(), and the shout connections in Send() are 
kept seperate.  This allows us to, for example, re-use the same camera 
input data in two seperate video Encode() calls for two different 
bitrates, then send these to two seperate libshout connections with 
seperate Send() calls.