Category Archives: video

Streaming video with VLC

Occasionally one wants to stream video for various reasons, whether it’s within the institutional network or a live feed from a conference venue. A few years ago Greg Tourte and I wrote a paper about the process of streaming video from a DV camera using FireWire, encoding into Ogg Theora/Vorbis, and transmitting the result to an audience via IceCast. For no adequately explored reason I have found myself playing with VLC’s inbuilt streaming methods for various purposes over the last week or so, and since VLC isn’t especially well documented, I’ve put the results up here.

 

1)  Streaming video to an icecast server.

Once you have the icecast server set up this is actually shockingly easy to do. Set up a mountpoint on the server side, in your icecast.xml setup (/usr/local/etc/icecast.xml by default):

<mount>
<mount-name>/test.ogg</mount-name>
<username>myusername</username>
<password>mypassword</password>
<max-listeners>10</max-listeners>
<burst-size>65536</burst-size>
</mount>

for example.

Now, on the client side (which could be anything from Windows to Linux to MacOS, because VLC is cross-platform, but this example is Windows), try

C:UsersEm>”c:Program Files (x86)VideoLANVLCvlc.exe” “C:UsersPublicVideosMy Video.wmv” –sout=#transcode{vcodec=theo,vb=800,scale=1,acodec=vorb,ab=128,channels=2,samplerate=44100}: std{access=shout,mux=ogg,dst=myusername:mypassword@myicecastserver.domain.com:port/test.ogg}

It should transcode on the fly into Ogg Vorbis/Theora and throw it at your icecast server. Viewers who go to myicecastserver.domain.com:port should be able to view it from there. Note that you can change various settings on the transcode process (for example scale=0.5, vb=400), so you can reduce the network bandwidth required, for example, but that paradoxically reducing some of these settings will actually increase the time taken for the transcoding process, so it can result in the transcode getting laggier than it was already.

Why transcode? Well, icecast only handles a limited format set. It’s really designed for audio data, not audiovisual. It’ll handle pretty well anything in an Ogg wrapper, though, and it is free. So if you want to stream video with Icecast, transcoding will probably be involved somewhere.

2)  Streaming from a DVD (previously recorded event)

One would expect this to be as simple as

“c:Program Files (x86)VideoLANVLCvlc.exe” dvdsimple:///E:/#1

but as it happens this seldom works, and the reason is the reaction time. Icecast is contacted with a header as soon as the streaming process begins. If it takes too long to get the DVD spun up and begin the process of streaming, icecast simply times out on you, leaving an error message along the lines of ‘ WARN source/get_next_buffer Disconnecting source due to socket timeout’.

Having tested this on various platforms, I find that the following string: “vlc dvdsimple:///dev/dvd –sout=’#transcode{vcodec=theo,vb=200,scale=0.4,theora-quality=10,fps=12,acodec=vorb,ab=48,channels=2}:std{access=shout,mux=ogg,dst=username:password@myicecastserver.domain.com:port/destination.ogg}’ –sout-transcode-audio-sync –sout-transcode-deinterlace” works very well in some cases. Apparently the DVD drive I first tested this with is just unusually slow. This DVD, being homegrown, doesn’t require libdvdcss to view/transcode.

3) Streaming with ffmpeg2theora

Bit of a Linux solution, this one. Install libvpx, libkate, scons and ffmpeg (all available as Slackbuilds for those who are that way inclined).  Install ffmpeg2theora. Install libshout and oggfwd.

Then: try a command line along the lines of the following:

ffmpeg2theora /source/material/in/ffmpeg/readable/format.ext -F 16 -x 240 -c 1 -A 32 –speedlevel 2 -o /dev/stdout –  | oggfwd myicecastserver.domain.com server_port password /test2.ogg

Obviously the output of this is not exactly high-quality; it’s been resized to a width of 240 pixels, audio has been reduced in quality, framerate’s been reduced to 16. But all these configuration options can be played with. Here’s a useful help page: http://commons.wikimedia.org/wiki/Help:Converting_video/ffmpeg2theora

Having called this a Linux solution, it’s worth pointing out that ffmpeg2theora is available for Windows (http://v2v.cc/~j/ffmpeg2theora/download.html) and that oggfwd/ezstream (http://www.icecast.org/ezstream.php/) have been used successfully on Windows as well. It’s also worth noting that, again, VLC can do the ogg/theora encoding too (and has done since 2006)- it’s just a question of seeing what’s better optimised for your purpose on your platform.

Note also that in this instance no username is needed, and the password used in this case is that set in the ‘<source-password>’ directive in icecast.xml.

4)  Streaming without icecast

Icecast is a useful default solution if you want to broadcast your event/recording to multiple people across the web. It’s also useful because, operating via HTTP, it doesn’t suffer from the sort of firewall/router problems that UDP-based video streaming, for example, typically encounters. On the other hand, if you’re streaming across a local LAN (for example, into the next room), there’s (usually) no network border police to get in your way — and VLC does also offer a direct VLC-to-VLC HTTP-based streaming solution. Unlike Icecast, though, it’s not ideal for one-to-many broadcast.

The Videolan documentation has a graphical explanation of this setup: http://www.videolan.org/doc/streaming-howto/en/ch02.html

 

5) Mixing video for streaming

An obvious application to test in this context is FreeJ. Sadly it’s a bit of a pain to compile as it doesn’t seem to have been touched for a while. You’ll need to use the following approach for configuring the code:

CXXFLAGS=-D__STDC_CONSTANT_MACROS  ./configure –enable-python –enable-perl –enable-java –disable-qt-ui

Typing ‘make’ will result in : error: ‘snprintf’ was not declared in this scope. Add #include <stdio.h> to any files afflicted in this way.

You then come across a crop of errors resulting from changes in recent ffmpeg. Some of these can be resolved with a patch, the rest, you’re better off going to the git repository rather than trying a stable version.

In principle you probably want to enable-qt-gui, but since it doesn’t currently compile I have left it as an exercise for some other day.

And once you have FreeJ working, you need to read the tutorial. Note this advice regarding addition of an audio track to FreeJ output.

 

 

Project Sunflower: Time to Launch Application, Open a Book and Flip Page

Well, we now have results regarding the time taken for the Apple iPad 2, Amazon Kindle DX and Motorola XOOM to render eBooks. We installed iBooks on iPad and the Kindle App for Android on XOOM. The Google Books app can’t be installed (yet) in UK due to copyright issues. We recorded the time taken by the devices to open the app, open a book, and flip a page.

Since there is no emulator that performs exactly like the physical device, we chose to take a practical approach to measure the times. The render times were measured in two ways. One, manually, and the other using a video camera.

Manual Method

Take a stopwatch in one hand, and have the other hand tap on the device. For example, when using an iPad, what we did was to hold the stopwatch in the left hand, and tap the iPad with the right hand. Start the stopwatch precisely when the iPad is tapped, and stop when the desired action is done. This method depends a lot on the user’s reflexes and you may have your doubts about the level of precision when it comes to results. Let me tell you, the results were surprisingly accurate. Read the figures to see for yourself.

Camera Method

This is a slightly more sophisticated way of measuring, though just as simple. All you need to know is the fps (frames per second) at which the video is recorded, and a video player that can replay the video frame-per-frame. Record the desired action on-camera, and then replay the video frame-per-frame. The number of frames traversed from the start to end of the task gives a more precise time taken to complete the task than the manual method.

Results

We measured the times for six free eBooks per device. Six readings were taken per task, and the average time for each task was calculated.

iPad (Average from six readings)


Kindle DX (Average from six readings)

There is no application load time as all the books are displayed directly on the Homescreen.

XOOM (Average from six readings)


Both the methods gave fairly similar results. The differences in the times on an average are:

The standard deviations for each method are shown below:

iPad (Standard Deviation)


Kindle DX (Standard Deviation)


XOOM (Standard Deviation)


The standard deviation tables show that the camera method showed less variation from the average as compared to the manual method in all but two cases, where the difference is only 1/100th of a second. These two cases may be safely ignored.

Although both methods gave fairly similar results, it must be noted that the manual method would give varied results for every test. It is completely dependent upon user reflexes, and slow reflexes could have seriously bad results. The camera method does take up more time, however the results are more accurate and dependable  So, I’d recommend the camera method.

All the recorded times are an average, and the times may change with the length of the books proportionally. These results give us a fair idea about the various devices when it comes to render speed and page flipping. The iPad and XOOM clearly render faster than Kindle DX. However, these results are only pertaining to the device capabilities and say nothing about the user experience. What makes an eBook reader good or bad does not depend only on the render speeds, but more so on the user experience the device has to offer. A detailed usability study of the devices will be undertaken soon which will shed light on the varied user experience, and help us better understand what the user expects from an eBook reader.

USB webcam fun

Bought a pair of webcams (mostly for the purposes of playing with opencv). When plugged in, the uvcvideo kernel module recognises them, and they self-report to the lsusb command as 18ec:3288. However, by default they fail to work (ioctl error).

v4l2: ioctl set format failed: Invalid argument
v4l2: ioctl set format failed: Invalid argument
v4l2: ioctl set format failed: Invalid argument
tv.c: norm_from_string(pal): Bogus norm parameter, setting default.
v4l2: ioctl enum norm failed: Invalid argument
Error: Cannot set norm!
Selected input hasn't got a tuner!
v4l2: ioctl set mute failed: Invalid argument

As is so often true there is an answer for this problem at the linux UVC dev list. Reproducing for the record the wise words of Laurent Pinchard,

Try setting the quirks parameter to 2 before plugging your webcam (either with ‘modprobe uvcvideo quirks=2‘ if the driver is not already loaded, or with ‘echo 2 > /sys/modules/uvcvideo/parameters/quirks‘ if the driver is already loaded).

To make these settings permanent,you need to create the file /etc/modprobe.d/uvcvideo.conf containing the line:

options uvcvideo quirks=2

From then on, the uvcvideo module will always be loaded with the “quirks=2” option and dmesg will show this line when loading the module:

uvcvideo: Forcing device quirks 0x2 by module parameter for testing purpose.
uvcvideo: Please report required quirks to the linux-uvc-devel mailing list.