Version 1 (modified by Nat Meysenburg, 9 years ago) (diff)


May First/People Link is committed to supporting video streaming, as well as free software. These two goals have have challenged us to use tools that allow for high quality video streams using entirely free software.

The problem with how streaming is currently done

Currently the state of video streaming on the Internet revolves mainly around a set of protocols and software owned by one company, Adobe. There are essentially two video formats that are used for the streaming done on most of the Internet today; FLV is used primarily for prerecorded video (Youtube), and RTMP which is used for streaming (uStream) as well as prerecorded video (Hulu). Both formats are owned in full by Adobe (and previously Macromedia), to be used with Flash Player. There are very few video sites on the Internet today that are not mostly or wholly dependent on Adobe software.

There are all sorts of technical reasons why Flash is a bad choice for video. In short, it boils down to the fact that Flash decodes the video at the software layer rather than taking full advantage of the video hardware. This offloads all of the decoding to the CPU; this slows machines down, and spikes power usage.

While the Flash Player is free to download, it is not Free Software in any sense. Flash implements a non-open web "standard" for streaming video.

Video streaming with free software

The method and tool set that we are now using and recommending was first developed for streaming the annual Debian Developers Conference. MFPL uses Debian on all of our servers, and many of our personal machines, so this setup allows us to use tools that we already use every day. Any examples given here are assuming Debian Squeeze -- though they might well work for other releases.

Many of the notes, and background information comes from steady reference to the DVswitch Wiki, particularly the component interaction.

Basic Software Components


Depending on the hardware, bandwidth, LAN, and other physical constraints, there can be some flexibility in how much hardware this requires. There are some general things that will make your life easier.

  • A DV camera with firewire (or USB). Firewire transfers data at a higher rate, however many newer cameras do not have Firewire. In this case you may be better off with a slightly older camera. DV cams are preferable to other USB cams, like cheap webcams; these can be made to work, but are not well supported.
  • A computer with appropriate ports for the camera, and a working NIC (runs dvsource).
  • A computer with good graphics support, reasonable processor, at least 2G of RAM and a working NIC (runs dvswitch).
  • A computer with a good processor a working NIC with an connection to the Internet
  • A computer with running icecast2 with a high speed NIC and good bandwidth (more on that later).
  • Ideally a gigabyte switch, with gigabyte NICs on all of the computers should be used on the LAN to cut down on latency, but it should work on a 10/100 LAN just fine.

The three computers running dvsource, dvswitch and dvsink is an ideal setup. In a pinch all three pieces can be run on fewer machines. We have successfully run all three on an x61 Thinkpad, but the machine ran hot. Dvsource is very lightweight, and can be run on an old machine with little RAM. DVswitch can be moderately CPU intensive and depending on how many dvsources you are using that scales up. DVsink is processor intesnive, mainly because ffmpeg has to convert the dv stream to ogg. If using two machines, it is best to split the sink from the switch.

You can add more cameras and source computers.

Networking and Bandwidth

There are multiple layers of bandwidth and networking in this setup. On site you will need two things, a functional LAN (preferably wired), and at least one connection to the Internet that can be used for forwarding the stream to a server. This connection does not need to be astonishingly fast to achieve a quality stream. It is more important to attempt establishing a stable route to the server than a high bandwidth one.

Depending on your expected audience size, the bandwidth needs of your Icecast server may vary. In our limited testing, the Icecast software can handle several thousand streams at once, without a huge impact on the hardware, so it is likely that you will hit bandwidth limits before you hit a hardware bottleneck. For MFPL's streams, we have Icecast running from data center connections.

Formats and Protocols

Provided you are using devices that generate DV, there is only one main conversion; from DV to ogg/theora. DVsource and DVswitch pass their video in DV, DVsink allows you to pipe the DV to other software. Using ffmpeg2theora we convert the DV stream directly to theora, and then forward the ogg stream using oggfwd.

Embedding streams onto web sites

Once you have an ogg stream running, it is important to make it easy to find and view. Embedding it into the browser is the common choice. There has been a significant growth of support for the HTML5 video tag as well as in browser support for ogg/theora. Firefox/Iceweasel, Chrome/Chromium, Opera will all embed a video player with just a video tag and functional stream.

However, there is still the looming problem of proprietary browsers refusing to support ogg/theora. This problem has been addressed by cortado, which uses a Java applet to supply oggs to browsers that don't support HTML5.

A Basic Example

Here is a simple set up, with some commands to illustrate how the flow of stream works; there are of course different ways to do this.

Again we are assuming that all machines in question have working Debian Squeeze installs, and that there is a functional LAN and functional connection to the Internet. All of which are out of scope for this example.

On the Icecast server

  • Double check Icecast is running and make sure you know the port it is listening on, and the password.
  • (TODO: Add a link to some good information about installing and configuring Icecast)

On the DVswitch machine

  • Make sure it is connected to the LAN
  • Launch "dvswitch" either from a terminal or a window manager launcher.
  • NOTE: You have to start DVswitch before starting the source or the sink.

On the machine connected to the camera

  • Connect a DV cam via Firewire the machine
  • Double check your LAN connection.
  • In a terminal run:
dvsource-firewire -h DVSWITCHHOST -p 2000

Where DVSWITCHHOST is either the domain, IPV4 or IPV6 address of the machine running DVswitch. The "-p" flag specifies the port on which the DVswitch is listening.

On the DVsink machine

  • Make sure that you have the "ffmpeg2theora" and "oggfwd" packages installed.
  • Run:
dvsink-command -- ffmpeg2theora - -f dv -F 25:5 --speedlevel 0 -v 4 -a 0 -c 1 -H 9600 -o - | oggfwd ICECASTHOST ICECASTPORT ICECASTPASS /mountpoint.ogg

Consult the ffmpeg2theora man pages for different conversion values.

ICECASTHOST is the hostname or IP of the icecast server. ICECASTPORT is the port on which Icecast is listening. The default is 8000. ICECASTPASS is the password for the Icecast server. mountpoint.ogg is the mountpoint of your stream name.

Testing the Stream

You're now ready to test the stream. In a browser that supports ogg/theora, or a standalone player (like VLC or mplayer), and open: http://ICECASTHOST/mountpoint.ogg . If you see a video you have a working single camera stream.

More source machines can be added. DVswitch allows you to switch sources, as well as use varied audio sources (alsa), and DV files.

Attachments (1)

Download all attachments as: .zip