mpeg/mp3

开发平台：
C/C++

index.sgml：源码内容
							<!doctype book PUBLIC "-//Davenport//DTD DocBook V3.0//EN" [
 ]>
<book>
  <bookinfo>
    <date>$Date: 1999/03/13 03:06:34 $</date>
    <title>Stony Brook Video Server project</title>
    <subtitle>$Id: index.sgml,v 1.21 1999/03/13 03:06:34 andrew Exp $</subtitle>
  </bookinfo>
  <toc></toc>
  <!-- We are done with the preliminaries, now we can start with
  the body of the document -->
  <!-- chapter -->
  <chapter>
    <title>Legal notice</title>
    <para>
      This document and the source code of the program have different 
      copyrights.
    <para>
      The description of Video Server (this document) 
      and any project documentation including the automatically generated code
      description visible from this document
      have the following copyright:
    <para>
      This document is copyrighted by Andrew V. Shuvalov under GPL ( GNU 
      public license ). The copy of the GPL may be obtained from www.gnu.org
    <para>
      <function>Warning.</function> The license terms of 
      the program itself are not 
      strictly compatible with OpenSource and/or GPL. This program is not 
      copyrighted by me so all license terms are beyond my control.
    <para>
      This soft is released with as much open license terms as it is 
      possible.
      So while terms are politically 
      incorrect from the point of view of OpenSource ideology, and that 
      unfortunately prohibit it to be integrated into GPL'd projects, 
      practically it is very open. You can modify sources and you have no
      restriction to redistribute and repackage all changes until the 
      source code is open and license is kept unchanged. 
      You can put this software on any CD-ROM
      that carry useful software and sell it. And what is the most important 
      you can use this software for free unless you do not charge fee for
      using it. That means you cannot use it for profit
      without permission. So it is free like free beer, 
      but not like free speech. If you want to use it for profit, you 
      should contact the copyright holder and reach the agreement.
    <para>
      The video server source code is copyrighted by State University of
      New York at Stony Brook.
    <para>
      Andrew V. Shuvalov 
      <ulink url=
        "http://www.ecsl.cs.sunysb.edu/~andrew">
         http://www.ecsl.cs.sunysb.edu/~andrew</ulink>
  </chapter>
  <chapter>
    <title>Overview</title>
    <para>
      <emphasis>Stony Brook Video Server</emphasis> is the distributed video
      server application that provides indexing, searching and video streaming
      in a convenient way to the clients over the network.
    <para>
      Video information is indexed by title in database accompanied with
      additional information:
      <ITEMIZEDLIST MARK="bullet" SPACING="compact">
        <listitem>
        <para>
          Complete text of each movie, each line has a timestamp for 
          back reference
        <listitem>
        <para>
          Statistical information on each movie
        <listitem>
        <para>
          Location of movie data. Actual movie data may be distributed over
          the network. This allows scalability of the database and
          reduction of the network traffic.
        <listitem>
        <para>
          Additional description of movie
      </ITEMIZEDLIST>
    <para>
      The client provides the easy and convenient access to multimedia data.
      Client may browse the complete list of movies, search the closed 
      captioned text by keywords and 
      boolean expressions and play selected video from the beginning or 
      from the point matching search query. The displayed fragment is 
      synchronized with closed captions text information.
    <para>
      Direct broadcast to client is provided as well. The up-to-date list of 
      channels available for this local network is listed to the client.
      It may select the channel and receive the video and closed captions.
    <para>
      Several data acquisition 
      servers may record data from video source ( acquisition server ), 
      broadcast the live video over network and store data for playback on
      demand.
    <para>
      At the same time push video servers may provide each client 
      with individual data stream from
      storage. Client may choose the nearest push server to receive data.
    <para>
      Administration of all components is performed from client after 
      successful "superuser" authorization. All configuration is edited 
      with convenient dialog-based representation.
  </chapter>
  <!--         chapter             -->
  <chapter>
    <title>Snapshot</title>
    <para>
        <graphic fileref="../images/snapshot01.jpeg"></graphic>
    <para>
      Snapshot shows the client application that displays the list of 
      available movies, shows closed-captioned text of two of them and plays a
      movie.
  </chapter>
  <!-- chapter -->
  <chapter>
    <title>Take me to the software</title>
    <sect1>
      <title>Download</title>
      <para>
      Download the package from URL: 
      <ulink url=
        "ftp://sequoia.ecsl.cs.sunysb.edu/pub/distributed_video_server/">
         ftp://sequoia.ecsl.cs.sunysb.edu/pub/distributed_video_server/</ulink>
    </sect1>
    <sect1>
      <title>Install</title>
      <para>
        To build any component, the whole package source code must be unpacked,
        because many headers are shared among components. The best way to build
        NT acquisition server is to export source directory via Samba.
      <para>
        <TABLE FRAME="none">
          <title>System requirements</title>
          <tgroup cols="2" colsep="16" rowsep="4">
          <tbody>
            <row>
              <entry morerows="3"><function>Acquisition server
                </function></entry>
              <entry>Windows NT</entry>
            </row>
            <row><entry>Visual C++ 5.0 (4.2 is buggy for that)</entry></row>
            <row><entry>"Mpegator" video board SDK</entry></row>
            <row><entry>"Text grabber" to read closed captions - 
              it should be connected to the serial port</entry></row>
            <row>
              <entry morerows="1"><function>Database server</function></entry>
              <entry>Java</entry>
            </row>
            <row><entry>JDBC and any database (I use freeware PostgreSql)
              </entry></row>
            <row>
              <entry morerows="1"><function>Push server</function></entry>
              <entry>Unix</entry>
            </row>
            <row><entry>C++</entry></row>
            <row>
              <entry morerows="4"><function>Client</function></entry>
              <entry>Unix</entry>
            </row>
            <row><entry>C++</entry></row>
            <row><entry>GTK+ GUI toolkit (see release notes for version
              requirements)</entry></row>
            <row><entry>Gtk-- C++ front-end to GTK+</entry></row>
            <row><entry>MpegTV SDK</entry></row>
          </tbody>
          </tgroup>
        </table>
      <para>
      <function>Build</function>
      <para>
        <emphasis>Configure</emphasis> scripts, <emphasis>configure.in,
        Makefile.am</emphasis> files for <emphasis>autoconf/automake</emphasis>
        tool are provided. This should help to auto detect the system.
    </sect1>
    <sect1>
      <title>Release notes</title>
      <para>
      <function>version 0.6.2</function> 12 Mar
        <itemizedlist MARK="bullet" SPACING="compact">
          <listitem><para>
            Snapshot release with numerous bug fixes. Migrated to GTK+ 1.2
            ( i need help with pixmaps in gtk_main.cc ).
        </itemizedlist>
      <para>
      <function>version 0.6.1</function> 1 Mar
        <itemizedlist MARK="bullet" SPACING="compact">
          <listitem><para>
            Snapshot release with numerous bug fixes.
        </itemizedlist>
      <para>
      <function>version 0.6.0</function> 28 Feb
        <itemizedlist MARK="bullet" SPACING="compact">
          <listitem><para>
            After selecting the final design of network topology of the video 
            server everything related to the control flow, data storage and
            obtaining configuration was re-engineered. The database format 
            was changed as well. It seems that now all those issues take
            the shape that will be used for setup the software at my
            department. But this is still very alpha release.
          <listitem><para>
            License clarifications are put into documentation.
        </itemizedlist>
      <para>
      <function>version 0.5.4</function> 14 Feb
        <itemizedlist MARK="bullet" SPACING="compact">
          <listitem><para>
            Finally broadcast is working. But there are some problems with SIH
            plug-in to debug. A lot of bug fixes. All components handshake
            correctly, most connections reconnect after timeout when fail
            happens.
        </itemizedlist>
      <para>
      <function>version 0.5.3</function> 10 Feb
        <itemizedlist MARK="bullet" SPACING="compact">
          <listitem><para>
            The snapshot release to provide a better starting point for 
            occasional examiner. The broadcasting topology, handshake,
            setup, protocols completely reorganized :-) Documentation 
            partially explains that.
        </itemizedlist>
      <para>
      <function>version 0.5.2</function> 20 Jan
        <itemizedlist MARK="bullet" SPACING="compact">
          <listitem><para>
          Mostly a snapshot release to produce better hacker's starting point.
          <listitem><para>
          Still working on broadcast mode: many improvements in acquisition 
          server and push server. Full broadcast mode is expected soon.
        </itemizedlist>
      <para>
      <function>version 0.5.1</function> 18 Jan
        <itemizedlist MARK="bullet" SPACING="compact">
          <listitem><para>
          Documentation updated. Everything compiles. Off-line mode works.
          Broadcast mode not finished yet - but most code is here.
        </itemizedlist>
      <para>
      <function>version 0.5.0</function> 13 Jan
        <itemizedlist MARK="bullet" SPACING="compact">
          <listitem><para>
          That's the alpha-release, do not download.
        </itemizedlist>
    </sect1>
    <sect1>
      <title>Feedback</title>
      <para>
      That project is not very old - I started it at January of '98.
      Please contact me for any build, install and hack assistance.
      <para>
      My e-mail: 
      <ulink url="mailto:andrew@ecsl.cs.sunysb.edu">andrew@ecsl.cs.sunysb.edu
        </ulink>
      <para>
      Don't forget to check the project's main page:
      <ulink url="http://www.ecsl.cs.sunysb.edu/~andrew/VideoServer/videoserver/index/book1.html">http://www.ecsl.cs.sunysb.edu/~andrew/VideoServer/videoserver/index/book1.html</ulink>
    </sect1>
  </chapter>
  <!-- chapter -->
  <chapter>
    <title>Architecture</title>
    <sect1>
      <title>Components</title>
      <para>
	Video server consists from several components: master server, slave 
	servers and clients.
      <para>
	<emphasis>Database server</emphasis> (master server), 
	which stores different kind
	of information and manage the video data network configuration.
	It receives incoming connections from clients and acquisition servers,
	answer to informational queries, performs actions requested by
	super-user authorized clients and sends commands to slave acquisition
	and push servers.
      <para>
	<emphasis>Acquisition server </emphasis> is one of two slave servers.
	This is NT-based program that captures <emphasis>Mpeg</emphasis>
	data using the <emphasis>Mpegator</emphasis> board and reads
	closed captions with <emphasis>Text grabber</emphasis> device.
        This server does not store any data locally, instead, it transmit the
        mpeg video stream to several push servers and closed captioned 
        text stream to both database server as well as push servers.
  	Video (mpeg) data are stored by push servers at local discs 
	and all text data is stored at database server.
      <para>
	<emphasis>Push server </emphasis> is the second slave server.
        It performs two types of activities at the same time. Firstly, it
        receive live broadcasting video/text stream, store it on local storage 
        for later playback and push that data to various broadcast destinations
        as specified. Secondly, it pumps locally stored mpeg data to
	the specific client by request.
        Same data may be, but not necessary, duplicated in
	various locations to optimize the access speed. Push server may
	transmit live broadcast data as well as the stored data at the same
	time. Various clients may request different movies from the same
	push server.
      <para>
	<emphasis>Client </emphasis> is the Linux/Unix application, which
	uses a convenient user interface to show data and perform actions.
	Mpeg video is displayed by MpegTV library, which is available for
	all major Unix platforms. User interface is written with GTK+ 
	toolkit and the Gtk-- front-end for it.
	Windows client is not planned due the lack 
	of requests from end-users.
    </sect1>
    <sect1>
      <title>Services provided by the Client to the end user</title>
      <sect2>
	<title>Broadcast service</title>
	<para>
          
      </sect2>
      <sect2>
	<title>Playback service</title>
	<para>
          
      </sect2>
      
    </sect1>
    <sect1>
    <title>The network topology, data flow and protocols</title>
      <sect2>
	<title>The network topology for the broadcast service</title>
	<para>
          The broadcast service provides the availability of live data to
          several destinations. Usually, each destination should be the 
          specific LAN broadcast address. The description of the video content
          and the port number to view the broadcast together are named as 
          <emphasis>channel</emphasis>.
          Each client located on this 
          particular local network may display the video and closed captioned
          text on the screen. But each client is free to switch to another
          channel or playback the old video selected from the database.
          The client may play only single video at the time.
	<para>
        <function>The problem: consuming network resources.</function>
          Transmitting the live video data over the network means sending
          approximately 100 UDP packets per second to this LAN broadcast 
          address with typical data rate 150 K/s. That consume resources of
          network and routers. This immediately imply that the Video Server
          must provide the mechanism to transmit data only to those 
          destinations where it finds at least one interested client.
          
	<para>
        <function>Dynamic vs. static topology.</function> The dynamic topology
          means that the explicit command from the user interested to
          view the channel selected from the list activates the selection
          of push server which may or already is the transmitter for this 
          channel. The activation of the previously inactive transmitting push
          server means that the topology have been changed. 
          In fact, acquisition 
          server must add another push server to the list of data recipients, 
          database server which manage all the topology must add this LAN as
          active recipient of the channel.
        <para>
        <function>Design decision.</function> As opposite to the dynamic 
          topology the static one was selected as the design decision. Let
          describe it and let show that this simplification does not decrease
          the set-up and use flexibility.
        <para>
        <function>The static topology.</function> 
          Database server loads the network topology from properties as the 
          static graph. The initial source of broadcast video stream is the 
          acquisition server. That data availability should appear to the 
          final destination, client, as the description and the port number
          to listen for UDP data packets: we define this as the 
          <emphasis>channel</emphasis>.
          Thus, the particular acquisition server is the only one source of
          the particular channel. At the same time, the particular channel 
          is coming only from this acquisition server and have no way to
          be sourced from anything else. This does not restrict that 
          different acquisition servers may receive the same TV program - 
          at that case two absolutely different channels may have the same 
          description and the same content while been defined as different
          channels and have no way to appear to the client 
          on the same UDP port. Thus, the unique <emphasis> channel ID
          </emphasis> is assigned to each 
          channel and may appear in any program logic to specify it.
          The acquisition server does not knows the final destinations of 
          the broadcasting and never loads this information. Instead, at the 
          boot time it receives from the database server the list of 
          push servers that will (may) work as transmitters and will (may)
          store the data locally. 
        <para>
          The push server should be located on the computer that have 
          a convenient access to all local networks where it should 
          broadcast. In case if the broadcast destination is the multicast 
          address this computer should support multicasting.
          The push server may have only one connection with acquisition
          server to receive data, but it may have several broadcast
          destinations. This does not restrict the flexibility to have
          multiple channels to be broadcasted by this computer because 
          several push servers may coexist at the the same computer.
          The database server loads from properties the list of all push
          servers with the channel ID assigned to the each one. For
          each push server it loads also the list of all broadcast 
          destinations. So given the client network address we may get
          the unique list of all channels that are (or may be) broadcasted
          to this user. In current implementation the simple algorithm is
          used and it will not work properly with multicast addresses.
        <para>
          The static topology should not imply that all data are broadcasted
          permanently in all possible destinations. This problem is resolved
          requiring clients to acknowledge the interest of the channel to
          transmitter, i.e. the push server. If given some fixed timeout
          the push server had not received any acknowledge of interest from
          the specific destination, this channel should be suspended. 
          We should not confuse the <emphasis>suspended transmission
          </emphasis> of channel with <emphasis>inactive channel</emphasis>.
          While the channel is suspended the network topology is not affected.
          The database server that controls the graph of the network is 
          not interested about the details of transmit-ion. From the other side
          the client distinguish only active and inactive channels, but
          don't know if the transmission is suspended. When the client 
          wants to receive the channel, it starts the periodical posting of
          packets of interest to the push server. Its the push server business
          to change the status of transmission to not suspended.
        <para>
          What is active and inactive channel? The static network topology
          does not imply that all components are required to operate, been
          located in permanently accessible networks on computers that never 
          crash or reboot. Instead, we define the status of the channel 
          relatively to the particular destination. The status may be active
          or inactive. If the acquisition server does not operates or is 
          unreachable, its channel ID may not be used by another source, so
          this channel is defined to be inactive relatively to all 
          destinations. If the particular local network is not listed as the 
          destination in any push server destinations list, this channel is 
          not listed by request of any client from that network and its
          status is undefined. If the acquisition server successfully 
          transmit data to some push servers while some others are not
          operating, the status of this channel will be different relatively 
          different clients. If several push servers may transmit the same 
          channel to the same destination, this is not the error, but that 
          means that user may not distinguish which push server it wants 
          to listen because by definition this channel have only one ID.
          So one of push servers will be selected. If one push server is 
          operating while another does not work by some reason, the program
          must ensure that only the operating one is selected. 
      </sect2>
      <sect2>
	<title>Start-up order of components</title>
	<para>
	  All components in Video server talk to each other by various 
          protocols using TCP and UDP sockets. The destination for any
          particular service may be unavailable at the present time. 
          But all connections in the system are subject to reconnect after
          the timeout. At the same time, if the service accept connections 
          and this particular connection is lost by any reason, the service
          is returned back into waiting state.
	<para>
          <emphasis>
          So the start-up order of components in fact is not important to 
          get the system functional. </emphasis>
          But this topic describes the order in with connections are 
          established - the way to eliminate all reconnects.
	<para>
	  First, start-up all <emphasis>push server</emphasis>. When started,
	  push server quietly waits for incoming commands.
	<para>
	  The real squid of program is the <emphasis>database server
          </emphasis>,
	  which holds all the metadata, system setup and manage the data flow 
	  of all the system. <emphasis>database server</emphasis> should 
	  start-up the second. Then, <emphasis>acquisition server</emphasis>
	  starts and try to setup the connection to database server. On
	  success, it receives the address and the port number of 
          <emphasis>push 
	  server</emphasis>, which will be responsible to broadcast data among
	  specified networks. If the connection fails, acquisition server will 
	  repeat the connection after the timeout.
	<para>
	  When database server starts, it should post the command to 
	  <emphasis>push server</emphasis> to configure the list of networks 
	  and the port number to broadcast.
	<para>
	  If no <emphasis>acquisition servers</emphasis> are registered,
	  the <emphasis>database server</emphasis> will assume that we
	  work in off-line mode and broadcast is not available. When the first
	  acquisition server registers itself, the live broadcasting is
	  available to any client.
	<para>
	  When on-line mode is (re)established, <emphasis>Database server
	  </emphasis> posts to <emphasis>Acquisition server</emphasis> 
	  (with protocol 5 - look next section) the 
	  address of push server to which it must post all data (protocol 6). 
	  If <emphasis>acquisition server</emphasis> cannot connect to it, 
	  it must post the error notification back and drop the connection.
      </sect2>
      <sect2>
	<title>Data stream</title>
	<para>
	  Picture: all protocols and default port numbers
	  <graphic fileref="../images/data_stream"></graphic>
	<para>
	  <function>1. Acquisition server - database server TCP protocol. 
	    </function>
	  Initiated by the acquisition server. It registers itself, request
	  address for immediate broadcasting and periodically checks for 
	  new commands.
	<para>
	  <function>2. Client - database server TCP protocol. </function>
	  Initiated
	  by the client. First, lets the client to acquire all 
          sort of data from
	  Database server. Second, if client passed the authorization and 
          is operated in superuser mode, lets it
	  to configure all servers and
	  lets the client to post some commands to a acquisition server.
	<para>
	  <function>3. Acquisition server to push( broadcast ) server TCP
	  protocol.</function> It uses the same data format as 
          broadcast protocol
	  #x, except it is TCP and there are only one destination.
	<para>
	  <function>4. Push server UDP control protocol. </function>
	  All other components use this UDP connection to post 
	  commands to push server.
	<para>
	  <function>5. Individually requested UDP data stream. </function>
	<para>
	  <function>6. Permanently broadcasted UDP data stream. </function>
      </para>
      </sect2>
    </sect1>
  </chapter>
  <!-- chapter -->
  <chapter>
    <title>Links to software components documentation</title>
    <para>
      <ulink url="../videoserver/Package-edu.sunysb.cs.ecsl.videoserver.html">
      Database Video server </ulink>
    <para>
      <ulink url="../videoclient/index.html">
      Video client </ulink>
    <para>
      <ulink url="../pusher/index.html">
      Push server </ulink>
    <para>
      <ulink url="../acquisition/index.html">
      Acquisition server </ulink>
      
  </chapter>
  
</book>

						