dryice/HACKING

   1 Here's the basic strategy for how DryIce is built:
   2
   3 src/core.c contains the core functionality of DryIce.  Think: backend.
   4
   5 Initially, core.c also contains main(), but this is just a placeholder.
   6 Frontends will eventually be written for ncurses, gtk, python, etc which
   7 will allow the user to setup and control DryIce.  These frontends will
   8 each contain their own main() and link core.c for the base functions.
   9
  10 Since DryIce is intended to eventually support multiple concurrent
  11 streams it does not make sense to have core.c be a dynamic library, and
  12 since the frontends are quite diverse in how they operate making them
  13 seperate programs would make integration more difficult.
  14
  15 Currently I am working with a OV519 based camera made by DLink.  This is
  16 supported by the v4l_jpeg input module for video frames, eventually
  17 audio as well as this camera has a built-in microphone.
  18
  19
  20 THOUGHT PROCESS (my in-development brainstorming):
  21
  22 core.c will process:
  23
  24 1) Initialize
  25  a) load appropriate input module(s)
  26  b) connect to Icecast with libshout
  27  c) init camera and precache first video frame
  28  d) init microphone and precache some audio data
  29
  30 2) Run
  31  a) decode YUV data to theora buffer
  32  b) decode PCM data to vorbis buffer
  33  c) tell camera to fetch next frame
  34  d) encode theora frame
  35  e) encode vorbis data
  36  f) grab available pages, mux them properly
  37  g) send (raw) to libshout
  38  -- repeat
  39
  40 Now the sequence of these is important for flexibility.  We want, for
  41 example, to be able to display the raw YUV data locally in the GUI
  42 client without having to decode the outputted stream, and Python may
  43 (ie) want to do some processing to see how similar two frames are and
  44 switch to a prerecorded scene if there's no motion for several seconds,
  45 or how bright the frame is so it can automatically turn on a light if
  46 it's too dark (via X10, etc).
  47
  48 This means that the "run" sequence needs to be broken down to seperate
  49 pieces which must be called in order rather than be a continuous loop.
  50
  51 IE (working draft):
  52
  53 Fetch():
  54  a) decode YUV data to theora buffer
  55  b) decode PCM data to vorbis buffer
  56  c) tell camera to fetch next frame
  57
  58 Encode():
  59  d) encode theora frame
  60  e) encode vorbis data
  61  f) grab available pages, mux them properly
  62
  63 Send():
  64  g) send (raw) to libshout
  65
  66 We also may want to seperate the audio and video processes for extra
  67 flexibility.  IE, one channel could be audio-only but draw off the same
  68 encoded source.  This moves step f) into Send().
  69
  70 Additionally, we want to make sure that the decoded data from Fetch(),
  71 the encode channels in Encode(), and the shout connections in Send() are
  72 kept seperate.  This allows us to, for example, re-use the same camera
  73 input data in two seperate video Encode() calls for two different
  74 bitrates, then send these to two seperate libshout connections with
  75 seperate Send() calls.
  76