Multimedia on the Raspberry Pi with omxplayer - Page 2

Installing omxplayer & more

omxplayer is a command-line multimedia player for the Raspberry Pi, which runs under both the console and X Windows. omxplayer has not been packaged for Raspbian, so we have to compile the application. Before doing so, we need to install a few libraries. Fortunately, the process is pretty simple. At the shell, we type at the ($) prompt:

The only other thing to do is to copy the generated executables (omxplayer and omxplayer.bin) to /usr/bin/ or another directory in the PATH. PATH is an environmental variable that tells the shell which directories to search for executable files.

omxplayer is a long way behind our favorite Linux video players, particularly in terms of functionality. Typing omxplayer at the shell lists the limited options that are available; the output is shown in the screenshot below:

Whilst there are keyboard shortcuts available to navigate a video in playback, these controls are very limited. Further, when the application is running, either on the console or in X Windows, there is no built-in option to clear the display. This is an issue when a video file has an aspect ratio that does not match the display device. An inelegant solution on the console is to run omxplayer with the following command:

Unfortunately, the console display remains hidden after omxplayer exits. To get output back, we need to type setterm -blank poke. An alternative is to turn off the cursor blinking (when logged in as the root user), and pipe the text messages generated by omxplayer to /dev/null, as follows:

The fact that omxplayer is the only external video player that uses the Raspberry Pi's GPU hardware acceleration makes it indispensable. This is because the low powered Broadcom CPU on the Raspberry Pi simply cannot cope with playing video files. Not surprising when the CPU benchmarks we ran in this article highlighted the limitations of the CPU.

We next need to make some multmedia files available to the Raspberry Pi. The obvious way is to copy a multmedia file over ethernet to the SD card. We had previously resized the partition to use the full capacity of the SD card, so we had space to store multmedia files. These files are centrally stored on a Buffalo NAS drive which does not have stellar performance. Using a Core i7 machine with gigabit ethernet, transferring a 477MB file from the NAS drive to the Core i7 machine took 16 seconds, which is about 30MB/sec. Copying the same file from the NAS drive to the Raspberry Pi took a whopping 117 seconds, which is a mere transfer rate of 4MB/sec. To investigate the slow transfer rate, the top utility comes in handy. The output of top is below showing a file transfer in progress.

From the two screenshots, we can see that the I/O wait percentage is 23.2% and 97.7%. The I/O wait measurement is the canary for an input/output bottleneck. I/O wait is the percentage of time the processor is waiting on the SD card. The SD card we are using has pretty good specs (it is a Class 10 card). In the first screenshot we can see that the cp and cifsd processes are consuming about 30% of the CPU, in the second screenshot, the processor is idle, waiting on the SD card.

With the slow transfer rate, we found it convenient to stream multimedia direct from the NAS device.

Next Page: In Operation & Summary

1. Introduction
2. Installing omxplayer & more
3. In Operation & Summary

Last Updated Sunday, June 17 2012 @ 01:23 PM EDT