"One server to satisfy them all" could have been the name of this chapter. We now have a great media server where we can share any media, but we would like to be more independent so that we can choose the functionalities the server can have. The goal of this chapter is to let you cross the bridge, where you are going to increase your knowledge by getting your hands dirty. After all, you want to build your own services, so why not create your own contents as well.
More specifically, here we will begin by building a webcam streaming service from scratch, and we will see how this can interact with what we have implemented previously in the server. We will also see how to set up a service to retrieve RSS feeds. We will discuss the services in the following sections:
- Installing and running MJPG-Streamer
- Detecting the hardware device and installing drivers and libraries for a webcam
- Configuring RSS feeds with Leed
Even though today many webcams are provided with hardware encoding capabilities such as the Logitech HD Pro series, we will focus on those without this capability, as we want to have a low budget project. You will then learn how to reuse any webcam left somewhere in a box because it is not being used. At the end, you can then create a low cost video conference system as well.
As you plug in the webcam, the Linux kernel will detect it, so you can read every detail it's able to retrieve about the connected device.
We are going to see two ways to retrieve the webcam we have plugged in: the easy one that is not complete and the harder one that is complete.
"All magic comes with a price." | ||
| --Rumpelstiltskin, Once Upon a Time | ||
Let's start with the fast and easy way, which is lsusb :
debian@arm:~$ lsusb Bus 001 Device 002: ID 046d:0802 Logitech, Inc. Webcam C200 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
This just confirms that the webcam is running well and is seen correctly from the USB.
Most of the time we want more details, because a hardware installation is not exactly as described in books or documentations, so you might encounter slight differences. This is why the second solution comes in. Among some of the advantages, you are able to know each step that has taken place when the USB device was discovered by the board and Linux, such as in a hardware scenario:
debian@arm:~$ dmesg
A UVC device (here, a Logitech C200) has been used to obtain these messages
Most probably, you won't exactly have the same outputs, but they should be close enough so that you can interpret them easily when they are referred to:
- New USB device found: This is the main message. In case of any issue, we will check its presence elsewhere. This message indicates that this is a hardware error and not a software or configuration error that you need to investigate.
- idVendor and idProduct: This message indicates that the device has been detected. This information is interesting so you can check the constructor detail.
Note
Most recent webcams are compatible with the Linux USB Video Class (UVC), you can check yours at http://www.ideasonboard.org/uvc/#devices.
- Among all the messages, you should also look for the one that says Registered new interface driver interface because failing to find it can be a clue that Linux could detect the device but wasn't able to install it.
Now we know what is seen from the USB level. The next step is to use the crucial Video4Linux driver, which is like a Swiss army knife for anything related to video capture:
debian@arm:~$ Install v4l-utils
The primary use of this tool is to inquire about what the webcam can provide with some of its capabilities:
debian@arm:~$ v4l2-ctl -–all
There are four distinctive sections that let you know how your webcam will be used according to the current settings:
- Driver info (1) : This contains the following information:
- Name, vendor, and product IDs that we find in the system message
- The driver info (the kernel's version)
- Capabilities: the device is able to provide video streaming
- Video capture supported format(s) (2): This contains the following information:
- What resolution(s) are to be used. As this example uses an old webcam, there is not much to choose from but you can easily have a lot of choices with devices nowadays.
- The pixel format is all about how the data is encoded but more details can be retrieved about format capabilities (see the next paragraph).
- The remaining stuff is relevant only if you want to know in precise detail.
- Crop capabilities (3): This contains your current settings. Indeed, you can define the video crop window that will be used. If needed, use the crop settings:
--set-crop-output=top=<x>,left=<y>,width=<w>,height=<h> - Video input (4): This contains the following information:
- The input number. Here we have used
0, which is the one that we found previously. - Its current status.
- The famous frames per second, which gives you a local ratio. This is not what you will obtain when you'll be using a server, as network latencies will downgrade this ratio value.
- The input number. Here we have used
You can grab capabilities for each parameter. For instance, if you want to see all the video formats the webcam can provide, type this command:
debian@arm:~$ v4l2-ctl --list-formats
Here, we see that we can also use MJPEG format directly provided by the cam.
While this part is not mandatory, such a hardware tour is interesting because you know what you can do with your device. It is also a good habit to be able to retrieve diagnostics when the webcam shows some bad signs.