Client
Client is the only GUI application in SBSVS. It was much more easier to develop the standalone application than to write the Netscape plug-in. But any real business implementation must use plug-ins in such a case. Client provides broadcast and playback services and it operates in user or superuser modes. Third-party mpeg playback library is used.
Functionality
Broadcast service
Client may play the broadcast stream from push server. First, it receives the list of available channels from the database server. Each channel has the corresponding acquisition server and one of push servers, which can broadcast video stream to this particular local network. If an acquisition server is not operating, this specific channel is marked inactive. User may select one of the active channels and look at video playback as well as at incoming closed captioned text.
If the client operates in the superuser mode, it may start or stop recording a channel. The channel will appear in the database with the default name and then client authorized as superuser may rename the movie and add comments.
Playback service
When the program starts-up, client receives the list of TV programs in the database. Then it may start the playback of any movie or perform the boolean keyword search over the selected TV programs. Then it may start the playback directly from the point located by search.
Database server may maintain several databases of movies, for example news programs may be separated from the films. Users may reload another database by selecting its name.
If the user is authorized as the superuser, he can perform several editing tasks. He can join two movies into single one, rename or delete the movie.
The following is the screenshot of a client performing playback on demand.
Implementation
Client is made with intention to be portable, so it is written on C++ with the autoconf/automake environment to take care of small differences between different platforms. Client uses the GTK+ graphics library and the GTK-- C++ binding for it. The MPEG1 stream playback is supported by MpegTV library.
Client consists of the application logic block that dispatches all messages inside the program and catches all exceptions, the interface with the database server, the user interface and the MpegTV proxy library. Application logic layer receives user commands from the user interface, interacts with the database server interface and displays results. It may perform also some additional logic, like keyword search. When the playback of a selected TV program is initiated, the MpegTV proxy library send commands to and parse messages from the standalone MpegTV application. The separate shared library, called SIH plug-in is linked with the MpegTV. This library listen for TV program broadcast over the network, buffer and transfer data to the MpegTV player.
Graphic User Interface is written on GTK+ library with the GTK-- C++ extension for it. Previous experience and reports suggest that the GTK+ GUI library is probably the most advanced graphics library in the industry. Other libraries that fell well behind includes TK and Microsoft GUI and MFC. The Qt library is maybe comparable, but it seems that GTK+ is developing much faster. The drawback is that during the development of Video server GTK+ was a moving target, thus sometimes breaking compatibility with earlier codes.
Search
At start-up, the client opens a connection with the database server and displays the list of movies in the main window. The database server may keep TV metadata in different databases, for example separating cartoons from news. The client may access another database anytime. Then, by double-clicking on a movie, user opens the separate window for this movie where the complete text is displayed. In that text, one line is always selected, it specifies the point from which the movie will be played, and when movie starts, this pointer is synchronized with the picture. Each line have the displayed timestamp.
User may also perform the keyword search to find the fragment to play. The search is performed on selected movies in the current database. Text of those movies is downloaded into the client memory and the search is performed locally. At present, the server-side search is not implemented. The reason for that is the expected cost of this operation: it seems to be much faster to download the entire text to the client than to waste the time on the server. The size of the text is not so big to consume network and memory resources: in fact the typical text of the average movie has only 100 kbytes of size.
The search keywords are joined by boolean expressions and the convenient graphic interface is developed for that purpose. The following example shows the search for "name" and "product". To match the search, those two words must be located within 5 seconds from each other.
If user is not satisfied with the result, the program may suggest similar words. This may help to avoid spelling mistakes as well. The next example shows that the system finds several words starting by "name", for example "names".
Lets discuss the implementation of the search. When the text is loaded, each word is inserted into a tree data structure. The root node holds the map where keys are the first character from each of encountered words. The value for the key is the node of the tree. Each node have the associated word fragment and the map of all encountered sequent characters as keys. All leafs of the tree contains completed words and each node contains the fragment of completed word, which may be a word itself. So, the search of the word in the tree takes the time linear by the pattern length.
When the boolean keyword expression is entered, the Expression Tree is build. The leafs of the tree are keywords, while the nodes are operations: "and", "or", "andnot". The tree is executed recursively, with the root executed the last. Boolean operations are not fully symmetric: when "and" is executed, it uses the resulting sorted set from one branch to execute the second one. Unmatched items are removed. In the case of the "or" operation, two sets are simply joined.
Mpeg library
In our implementation the MpegTV library was chosen as the most stable among all possible MPEG playback tools. The drawback of this choice was that MpegTV is closed-source, so in many cases the troubleshuting was very time-consuming. MpegTV operates as a standalone application which is connected to a library stub via pipes. The pipe do not carry any data, only the command stream. The library is customized to the specific application needs by loading so-called SIH plug-in. This plug-in is the dynamic shared library, which provides the MpegTV application with callbacks. The player itself doesn't know the source of the data. It is only interested in receiving correct answers to its requests. No command stream exists between SIH plugin and the outside world - all execution logic must pass through the player itself.
The stream to play is identified by URL. When a new URL is passed to the MpegTV player, it starts to query each of its SIH plug-ins in sequence. Each plug-in must indicate whether it understands this URL and can handle it. If no plug-ins can handle the URL an error is reported. In our case the plug-in handles the URL starting by "sbvideo://". Then player calls several callbacks to open the stream and set position and other parameters. When the stream is open, player periodically calls the "SIH_read" callback, which must operate as non-blocking read. If data are available, it must provide up to the amount. If there is no data available, SIH_read should return -1 with errno set to EAGAIN, defined in unistd.h.
SIH plug-in performs the buffering of incoming data as well. When the "SIH_read" is called, it polls the incoming UDP socket and read as much data as available. When a new portion of video is transferred to the player, plug-in passes its timestamp trough the so-called feedback call. That way the client synchronizes the video and text streams.