hledat:

Real-time Transcoding and Scalable Data Distribution for Video Streaming

CESNET technical report number 30/2006
also available in PDF, PostScript, and XML formats.

Jiří Denemark, Miloš Liška
18.12.2006

1   Introduction

For the purposes of distribution of live streamed lectures at the Faculty of Informatics at Masaryk University we enhanced the concept of the packet reflector (RUM, [HHD04]) with transcoding of the video and audio streams being processed within the packet reflector. In the conditions given by the network setup and characteristics, transcoding of the content helps us to deliver it to more students with the highest possible quality allowed by their last hop network connection to the university network. The biggest constraint is the fact that the multicast is not supported all over the university network. Moreover some other constraints are given by firewall and accounting rules at dormitories where most of the students live and obviously watch the live lecture stream.

2   Video Stream Distribution

In our distribution schema (see Figure) there are basically two types of video stream sources. MPEG-2 hardware encoder such as Teracue ENC-100 or a regular MPEG-4 streaming PC with video capture card and VideoLAN Client installed. In both cases it is important that the video stream is sent as a standard MPEG Transport Stream (MPEG-TS). Because the streaming machines are connected to the network without a multicast support and because of the fact that we consider a unicast transmissions to be generally more reliable, we are sending the source high quality MPEG stream (encoded approximately at 2 Mbps) using unicast transmission to the packet reflector for further processing.

As there are users connecting their computers to the university network using wireless connection, we need to provide a lower quality and low bandwidth stream for them. Furthermore, there may be even many users behind a shared router or firewall with no multicast support or with some Fair User Policy rules applied which means that they usually tend to save their bandwidth as much as possible. For this purpose, we added a transcoding capability to the packet reflector which is able to transcode the stream for lower bandwidth and deliver the resulting stream using a unicast transmission to the users. For users who are connected to a network with multicast support and no Fair User Policy or other limitations, the packet reflector provides the original stream just redirected to a multicast group. If there are users connected to a network behind some shared router with limited bandwidth available, it is possible to deploy an additional packet reflector to that network and redirect the transcoded stream to that reflector using one unicast transmission. Thus all users behind the shared router will use the packet reflector within their local network saving a lot of bandwidth on the router. This may be a typical scenario for university dormitories.

3   VLC

VLC (VideoLAN Client) is a media player capable of playing various multimedia formats profiting especially from the ffmpeg project decoder and exploitation of some original Windows codecs. Furthermore, VLC is very strong in handling a streamed multimedia content allowing to play streams sent by streaming servers, another VLC or even hardware encoders. VLC is capable of handling streams transmitted using RTP or bare UDP protocols over unicast as well as multicast networks. These features are ideal for our purposes where the VLC is responsible for unpacking the multimedia data from the UDP stream, transcoding the data and repacking them again to the UDP stream.

The only issue to solve with the VideoLAN Client was the fact that the user interface of the client is graphically oriented and data sent from RUM to VLC for transcoding are passed on using standard Unix input and output. The GUI issue was solved by not linking VLC with any widgets library. However, VLC requires at least one user interface mode. The telnet interface turned out to be the only one usable because it leaves the standard input and output untouched and thus not crashing whole VideoLAN client when the packet reflector sends a multimedia stream directly to VLC's standard input. In other words, user interface should be, for example, telnet. Remote interface is not usable as it reads from stdin and VLC is killed by signal 11 when data are sent to it through a pipe. For our purposes, we have built the VideoLAN client with the following options:

./configure -disable-wxwidgets -disable-skins2 -disable-ncurses
  

VLC can then be started as follows:

vlc - -playlist-autostart -intf telnet -sout '<transcoding parameters>'
  

4   Packet reflector internals

The processor/vlc module (see Figure), which takes the responsibility for the stream transcoding within the packet reflector starts VLC with specified options and uses it as a transcoding filter for all data packets. Incoming packets are passed to VLC's stdin through a pipe and transcoded video is received from VLC through a UDP socket bound to a local loopback interface.

This module can be used for transcoding of just a single stream. All packets passed through a single processor/vlc module have to be sent by the same sender to a single listener module and they must be processed by an identical sequence of processor module before they reach the vlc processor. For more complicated setups, several processor/vlc modules have to be used.

Users may control the module in the same manner as the reflector itself - using RAP protocol [DHH03].

4.1   Starting the Module

The module is started using general START method with some additional parameters

vlc-start-params    = vlc-options
                      [ vlc-path ]
  

When starting the module, user has to specify VLC options with "Options" header.

vlc-options         = "Options" ":" header-body CRLF
  

As VLC is started using a standard shell, the option string must be properly escaped. Special sequences "%h" and "%p" must be used instead of host and port to which VLC will sent output data. "%%" may be used for including "%" sign in the option string. Any undefined sequence (i.e., other than "%%", "%h", and "%p") is left untouched but should be avoided by users. Path to a VLC binary may be specified using "Path" header. If this header is omitted, "/usr/bin/vlc" binary will be started.

vlc-path            = "Path" ":" header-body CRLF
  

4.2   Controlling the Module

The module can be controlled using several RAP request methods. All of them must contain "Target" header filled in with the exact name of the processor/vlc module which should receive the request (e.g., "processor/vlc-1").

4.2.1   Method VLC-RESTART

Restarts VLC transcoding filter. Optionally, new vlc path and/or options can be passed on to override those specified when starting the module.

vlc-restart        = "VLC-RESTART" SP version CRLF
                     target
                     [ vlc-options ]
                     [ vlc-path ]
                     CRLF
  

4.2.2   Method VLC-LOG

Gets recent output (from stderr and stdout) of VLC. The output is stored into a fixed length buffer which always contains the most recent characters of VLC's output. The "Remove" header can be used to clear the content of output buffer after it is sent within the response to the current request.

vlc-log            = "VLC-LOG" SP version CRLF
                     target
                     [remove]
                     CRLF
  

4.2.3   Method STAT

Detailed information on running module and VLC transcoding process can be obtained by sending a request with a general STAT method. Basic information concerning VLC process state, its PID, exit code, and a signal by which it was killed are filled directly in response headers "State", "PID", "Exit-Code", and "Signal", respectively.

vlc-stat-header    = vlc-stat-running
                     / vlc-stat-stopped
                     / vlc-stat-killed
vlc-stat-running   = "State" ":" SP "running" CRLF
                     "PID" ":" 1*DIGIT CRLF
vlc-stat-stopped   = "State" ":" SP "stopped" CRLF
                     "Exit-Code" ":" 1*DIGIT CRLF
vlc-stat-killed    = "State" ":" SP "stopped" CRLF
                     "Signal" ":" SP 1*DIGIT CRLF
  

5   Conclusions

In this report, we have described a distribution schema base both on multicast and unicast data transmission for delivering video streams to end users. The distribution is handled by a modular packet reflector equipped with a special transcoding module.

References

[HHD04]	Eva Hladká, Petr Holub, Jiří Denemark. User Empowered Virtual Multicast for Multimedia Communication. In ICN'2004 Conference Proceedings. March 2004. Pages 338-343. ISBN 0-86341-325-0.
[DHH03]	Jiří Denemark, Petr Holub, Eva Hladká. RAP - Reflector Administration Protocol. CESNET Technical Report 9/2003, CESNET, z.s.p.o., November 2003. 32 pages.