cygnal/README

   1 This will enventually hold the code for a Flash compatible
   2 streaming media server. Most of this file is oriented towards the
   3 Adobe Communication server's features, as these will determine a
   4 rough feature set for Cygnal. Some of the limitations commented on in
   5 these notes should be consider a place where Cygnal can do better.
   6
   7 General Communication Server features:
   8 -------------------------------------
   9
  10 The most common way of streaming Flash movies is using progressive
  11 streaming. Progressive streams don't allow seeking within the data
  12 once it is playing. The only control is "play" and
  13 "pause". Progressive streaming doesn't even require a Media server, it
  14 can be done with any web server, which doesn't do any special
  15 handling. This is often reffered to as RTMP over HTTP, but there isn't
  16 any RTMP protocol used within the client-server communication. The
  17 protocol is purely HTTP using GET and POST directives.
  18
  19 A Flash media server has several abilities other than just sending a
  20 file stream to the player. Using the RTMP protocol, it is possible to
  21 dynamically seek within the stream. This puts the control of the movie
  22 on the server side instead of the client side. This is called dynamic
  23 streaming.  Along with seeking, dynamic streaming also supports
  24 capturing a stream, which allows one to send a data stream to the
  25 server, where it can be stored, and then later replayed.
  26
  27 The server collects statistics on the mumber of connections, the
  28 bandwidth consumed, which files are streamed, the frame rate,
  29 etc... This data can be used to tune the performance of the server
  30 when running. Some statistics modify the stream while it is playing,
  31 and the other are for load balancing on larger installations, like a
  32 cluster.
  33
  34 The server can also transcode between codecs. The Adobe server
  35 can only convert MPEG4. Since the Cygnal server is using Gstreamer, it can
  36 convert between any supported codec. Along with this, by using the
  37 statistics collected for each data transfer, the server can also
  38 change the resolution of the movie to adjust to varying network
  39 connectivity issues. Transcoding will allow a media stream to be read
  40 by the server, and the codec and network protocol changed dynamically
  41 to FLV.
  42
  43 Along with progressive and dynamic streaming support, Cygnal also
  44 supports multicasting. This way a single source, often a 'real-time"
  45 one, like a sports game, can be viewed by multiple clients without
  46 duplicating the data. This source can't be seeked, so it functions
  47 like a variation on progressive streaming.
  48
  49 There are several utility functions builtin to the servers as well for
  50 navigation purposes. The main one is used to generate thumbnails or a
  51 short preview of a movie automatically, without having to do this as
  52 part of another operation. This features can also be used to merge
  53 clips from multiple movies.  Each clip is played for the specified
  54 amount of time, and then the next clip is played starting and stopping
  55 at the specificied times, and so on until all the clips are played.
  56
  57 If there are multiple camera angles support in the movie being played,
  58 it can switch between them.
  59
  60 This is a list of features extracted from the O'Reilly book on the
  61 Adobe Media server. While not all of these are probably worth
  62 implementing in Cgynal, the list is interesting.
  63
  64 * Seeking in downloading movies only works for the cached part that
  65 has already been transferred. Seek to the undownloaded part of a
  66 stream are forbidden.
  67 * Video and Audio can be uploaded into a safe sandbox area for later
  68 downloading.
  69 * Current Flash Communication server supports only server side
  70 ActionSript 1, the newer one supports Server side ActionScript 2.
  71 * Server can directly connect streams between clients.
  72 * Only supports point to point connections, multicasting isn't
  73 supported.
  74 * All server side extensions are written in ActionScript.
  75 * Can upload and store Shared AMF Objects.
  76 * The software license limits the number of permitted connections.
  77 * Tracks statistics on online users.
  78 * Needs seperate copies of media, to handle different bandwidth
  79 network connections.
  80 * Only dynamically transcodes from mpeg4.
  81 * Audio and data have the highest priority, video packets are thrown
  82 away to stay synchronized.
  83
  84 Cygnal Internals:
  85 ----------------
  86
  87 Since all data streams need no knowledge of other streams, each
  88 incoming connection will get a new thread to handle it. If the CPU
  89 load of the machine is above a set value, then the server will stop
  90 making new connections.
  91
  92 3rd party load balancing software will be used to redirect more
  93 incoming requests to the next available machine.
  94
  95 Each server will maintain it's own statistics, as well as support an
  96 optional remote logging ability. A cache of statistics will be kept in
  97 memory to enable faster processing of things like the bitrate that
  98 require some historical data to make a calculation.
  99
 100
 101 Sources:
 102 --------
 103 cygnal.cpp:             The main routine that gets everything going.
 104 http.cpp, http.h:       Simple server-side HTTP protocol support.
 105 alloc.cpp               Memory allocator for multi-threaded
 106                         applications, redefines new and delete.
 107 stream.cpp, stream.h:   Streaming support. This also allows one to
 108                         upload a file..
 109 statistics.cpp, statistics.h:   Collect statistics on bandwidth,
 110                         connections, memory, and CPU load.
 111
 112 # transcode.cpp, transcode.h:   Convert between codecs using Gstreamer.
 113 # flash.cpp, flash.h:   SharedObject support using AMF.
 114
 115
 116 cpus         4
 117 threads per cpu 1
 118 spawn limit 4
 119
 120
 121 connection_handler - start a server waiting for incoming
 122     connections. This blocks waiting for new client requests. When a
 123     client connects, a dispatch_handler is created.
 124
 125 A new dispatch_handler is created for each incoming connection up to
 126     the 'spawn_limit'. After the spawn_limit is reached, future
 127     connections get added to the data each dispatch thread is waiting
 128     for. Each dispatch_handler has a network connection.
 129
 130 dispatch_handler - waits on a set of file descriptors, returning a set
 131     of file descriptors with activity. When it sees activity, the
 132     event handler for the appropriate protocol is called, but no data
 133     is read.
 134
 135 http_handler - gets invoked when there is data ready to be
 136    processed. It is invoked directly by the dispatch handler when
 137    there is data to be read. This controls all I/O for this file
 138    descriptor.
 139
 140 rtmp_handler - ditto.
 141
 142 ../../../rtmp-logs/red5-rtmpstream-test.log
 143 connect #3
 144 ping    #2
 145 _result #3
 146 createStream #3 -> streamid #2
 147 _result #3      -> streamid #2, #1
 148 _play   #8
 149 ping    #2
 150 onStatus #4     <- reset
 151 onStatus #4     <- play
 152 deleteStream #3
 153
 154 .Reset 12 bytes
 155 .Play  8 bytes
 156
 157
 158 ../../../rtmp-logs/ngrep-flowplayer-seek.log
 159 connect #3
 160 ping    #2
 161 _result #3
 162 createStream #3 -> streamid #3
 163 _result #3      -> streamid #d
 164 _play   #8
 165 ping    #2
 166 onStatus #4     <- reset -> streamid #1
 167 onStatus #5     <- play -> streamid #1
 168 onStatus #5     <- data start
 169 onMetaData #5   <- flv file
 170
 171 .Reset 12 bytes
 172 .Play  8 bytes
 173
 174 -----------------------------------------------------------
 175 The main process also handles communication with other Cygnal instances.
 176
 177 Invoke and SharedObjects are sent to the cgi-bin. SharedObjects are
 178 send to all the clients connected for that sandbox by the main process.
 179 The main process has a map of the other server processes (usually cgi-bins)
 180 and multimedia streams.
 181
 182 Video/Audio Streams are routed by the main process, and never go to the
 183 cgi-bin. All multimedia streams should have the abilty to add a filter
 184 before reading or writing the raw data.
 185
 186 Output to clients just reads a file descriptor, and sends it. Doesn't matter
 187 if it's network or diskfile. File streaming should work like the cgi-bins,
 188 where it has to parse the NetStream and FCSSubscribe messages.
 189
 190 Should add a pass-through mode, where messages can be routed to another machine
 191 and port, like Red5 for their server side applications.