"Fossies" - the Fresh Open Source Software Archive

Member "gnash-0.8.10/cygnal/README" (19 Jan 2012, 7796 Bytes) of package /linux/www/old/gnash-0.8.10.tar.gz:

As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file.

    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.
    7 General Communication Server features:
    8 -------------------------------------
   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.
   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.
   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.
   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.
   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.
   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.
   57 If there are multiple camera angles support in the movie being played,
   58 it can switch between them.
   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.
   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.
   84 Cygnal Internals:
   85 ----------------
   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.
   92 3rd party load balancing software will be used to redirect more
   93 incoming requests to the next available machine.
   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.
  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. 
  112 # transcode.cpp, transcode.h:	Convert between codecs using Gstreamer.
  113 # flash.cpp, flash.h:	SharedObject support using AMF.
  116 cpus	     4
  117 threads per cpu 1
  118 spawn limit 4
  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.
  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.
  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.
  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.
  140 rtmp_handler - ditto.
  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
  154 .Reset 12 bytes
  155 .Play  8 bytes
  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
  171 .Reset 12 bytes
  172 .Play  8 bytes
  174 -----------------------------------------------------------
  175 The main process also handles communication with other Cygnal instances.
  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.
  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.
  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.
  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.