Page ThesisDPPXIIIProgramming

Details about the implementation of Screensharing for Saros

The rough architecture of the screenshare feature will be MVC.

• model (data basis)
  • encoder, which can have several sources of images
    • screen
    • webcam
    • …
• views (at client)
  • decoder
  • responses from actions (not needed yet, maybe later)
  • displaying videos, Videoplayer
• controller, directly conncted to their streams
  • sending images to client and control used bandwidth (see ConnectionManager)
  • receiving activities from client (see ActivityManager)

Modules

A list of modules used and their responsibilities.

ImageSource

A source object for images to be shared. First implementation of it will be the Screengrabber. It is an interface, which only contains one method to get the actual image, e.g. BufferedImage toImage(). That makes it possible to change the source which will be shared to a webcam or something else.

ScreenGrabber

Takes screenshots of the desktop. Those can be fullscreen, defined area or defined area around the mousepointer. The configuration can be changed while running.

Encoder

The encoder is responsible for transforming single images to an OutputStream (the network) for transferring it later to the client. During runtime it should possible to scale down the quality of the output, more precisely the bandwidth used. The underlying implemention should be able to apply it on the fly by changed the needed videoproperties (e.g. fps, bitrate … or in very worse cases to restart the stream).

The encoder has direct access to the view (Decoder) through a stream (see ConnectionFactory), which breaks the MVC pattern.

An encoder has a configuration for the properties of the outputcontainer. These settings must not apply on the fly.

• bitrate
• bitratetolerance
• resolution
• fps
• codec
• maybe containerformat, but in our case only useful for saving the share

It's planned to implement two encoder's.

• java-based encoder which can be provided with saros
• native encoder which can efficiently encode, but can not be provided with saros (for every platform, too big)
  • will use xuggler

Later the ability to encode more than one ImageSource could be realized, many videostreams. This includes some changes

• overall qualitysetting
• decoder must be aware
• each stream can be paused
• opt adding streams dynamically

Decoder

Decode the videostream to BufferedImages which can be displayed in a window. There should be the possibility to record the received stream into a file (not sure whether it should be an extra module).

Like the encoder, two different decoders will be implemented

• one java-based
• native, xuggler

The decoder sends periodically statistics about decoding (fps, bitrate, delay).

VideoPlayer

in development

Displaying the video in a given frame and receive position of mousepionter and clicks.

ConnectionManager

Monitors and controls the usage of bandwidth between host and client. Decides how and when to de- or increase the quality of video by using the running encoder instance.

ActivityManager

Receives and executes, when client is allowed to, the activities of the client, which are

• clicks or pointings
• zoom in, zoom out

ConnectionFactory

Responsible for creating connection between two sarosusers.

It creates two connections (bidirectional streams).

One for transmitting the video to client, with additional capabilities

• buffered
• public access to usage of buffer (for ConnectionManager)

and receiving info about decodingstatus at the client

• how much fps
• bitrate
• delay in videostream

The other one is for activities and their responses.

Not sure about needed module for client.

VideoSharing

Main class for starting, stopping the whole process of sharing. Is a facade for the whole feature.

Comments