• English
• German

Streaming

If one wants to show parts of a local video to a participant simultaneously to an already running video conference in order to discuss its content, transmitting of single A/V streams separately has to be possible. For this purpose, Homer enables sending single A/V data in real-time (also without a simultaneously running video conference) via separate transmission channels. Infrastructure is not needed for this application. The remote station can directly receive the data and use it as input for further processing. In general, Homer uses known codecs for transmission for both video (H.261, H.263(+), H.264, MPEG1/2/4,..) and audio data (MP3, aLAW, uLAW,..). The applied quality level for the A/V transmission can be adjusted by the help of the GUI. It is possible to transmit A/V stream both with very low and very high quality (e.g. HDTV). The actual possibilities are limited by the used hardware. But the software architecture of Homer is constructed for parallelization of internal processing steps. In order to enable high quality settings, as much as possible of the available CPU cores are used simultaneously.

Network protocols

Homer supports for the transmission of A/V stream basically both IPv4 and IPv6. The protocol version is selected automatically. For the transmission of A/V data, Homer does not only support the classic transport protocols TCP and UDP, but also alternative protocols, e.g., SCTP and UDPLite, are supported. The possibilities in this context are limited by the used operating system and the therefore available functions.

Experiments

Additionally to standard application, Homer is also used for experiments by some developers, and it therefore provides in the so called developer/debug mode some extra functions. For example, one can assign additional transmission requirements to an A/V stream. They could include QoS parameters or define that transmitted data has to be delivered to receiver side without any data loss. Homer is able to signal such transmission requirements towards the network. The possible impacts of such extra requirements depend on the used network API and can vary accordingly. Additionally, by the help of the GUI the maximum packet size of an A/V stream can be defined and therefore the behavior during packet creation can be influenced. However, the officially available release versions do not include an explicit support of experiments. The are limited to the standard case, which uses the known Berkeley sockets as interface towards the network. Only the packet size limitation is included and can be used for the optimization of the transmission quality.