Using the Bluecherry hardware compression open source Linux drivers (MPEG-4 / H.264)
Below is a technical overview for using our MPEG-4 and H.264 PCI / PCIe / Mini-PCI capture cards. First, you need to download the driver from Github:
- git clone git://github.com/bluecherrydvr/solo6x10.git
- Optionally, you can download the .tar.gz file here: https://github.com/bluecherrydvr/solo6x10/tarball/master
Once the driver is loaded you will notice that there are two types of v4l2 devices created for each card. One device for the display port (also drives the single composite video output) that produces uncompressed YUV and one for each input that produces compressed video in either MPEG-4 or MJPEG.
We'll start with the display port device. As mentioned the display port is also shared with the RCA video output on the card. So, changing the display port layouts will also change the video output.
When loading the driver, a display port is created as the first device for that card. You can see in dmesg output something like this:
solo6010 0000:03:01.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 solo6010 0000:03:01.0: Enabled 2 i2c adapters solo6010 0000:03:01.0: Initialized 4 tw28xx chips: tw2864 solo6010 0000:03:01.0: Display as /dev/video0 with 16 inputs (5 extended) solo6010 0000:03:01.0: Encoders as /dev/video1-16 solo6010 0000:03:01.0: Alsa sound card as Softlogic0
This is for a 16-port card. The output for a 4-port card would show "Encoders as /dev/video1-4" and similarly for 8-port show /dev/video1-8.
The display port allows you to view and configure what is shown on the video out port of the card. The device has several inputs and depends on which card you have installed:
- 4-port: 1 input per port and 1 virtual input for all 4 inputs in 4-up mode.
- 8-port: 1 input per port and 2 virtual inputs for 4-up on inputs 1-4 and 5-8 respectively.
- 16-port: 1 input per port and 5 virtual inputs for 4-up on inputs 1-5, 5-8, 9-12 and 13-16 and 1 virtual input for 16-up on all inputs.
You do not have to open this device for the video output of the card to work. If you wanted to display channels 1-4 in 'quad view' on the display port you could simply change the inputs with V4L2 ioctl's or with mplayer:
This is useful if you want to have live display to a CRT and use a simple program that rotates through the inputs (or multi-up virtual inputs) a few second intervals.
You can still use vlc, mplayer or whatever to view this device (you can open it multiple times).
Now for the encoder devices. There's one device for each physical input on the card. The driver will allow you to record MPEG-4 and MJPEG from the same device (but you must open it twice, one for each feed). The video format cannot be configured once recording starts. So if you open the device for MPEG-4 and full D1 resultion at 30fps, that's what you're going to get if you also open a simultaneous record for MJPEG.
However, it's good to note here that MJPEG will automatically skip frames when recording. This allows you to pipe the output to a network connection (e.g. MJPEG over HTTP) with no worry of the remote connection being overloaded on bandwidth.
Unlike any card before this supported by v4l2, our hardware compression cards produce containerless MPEG-4 frames. Most v4l2 applications expect some sort of MPEG-2 stream such as program or transport. Since these programs do not expect MPEG-4 raw frames, We are not aware of any that are capable of playing the encoders directly (much less being able to record from them). You can do something simple like 'cat /dev/video1' and pipe it to vlc, or write a program that just writes the frames to disk (most programs can play the raw m4v files produced from the driver).
Below is a mplayer example on how to play the first channels MJPEG feed:
mplayer -tv device=/dev/video1:outfmt=mjpeg tv://
Since most applications will want to record to disk, the easiest way is to write the video frames straight out to disk.
Now on to the audio. The cards produce what is known as G.723, which is a voice codec typically found on phone systems (especially VoIP).
Since Alsa currently doesn't have a format for G.723, the driver shows it as unsigned 8-bit PCM audio. We have sent a patch that was included in alsa-kernel (hopefully getting synced to mainline soon). But this only defines the correct format, it doesn't change the way you handle it at all. You must convert G.723-24 (3-bit samples at 8khz) yourself.