Cubieboard2 A20

Any further updates on Cubieboard2 performance (excluding networking which we've already examined) or its features or community support or anything else of interest?  Is the SATA working properly?

If I understand it correctly, S/PDIF output is available only on a Cubieboard2 header as TTL, but I'd like to get that converted and socketed in the usual coaxial or optical form.  I have a big x86 machine currently acting as my digital audio gateway delivering audio notifications from the computer room, and I'd like to have that function served by a frugal ARM board instead.

What a pity that the Wandboard never appeared in the UK, as it provides optical S/PDIF output directly.

Morgaine Dinova wrote:

 

Any further updates on Cubieboard2

Not really, I've not had a lot of time to spend on it just yet.

What has appeared is that it's locking up randomly, mostly overnight, but can take up to 3-4 days to do so.  I've been trying to work out why, but it's slow going.  Nothing helpful in the logs or any output to the serial console when it happens.  I've gradually been taking bits of software out of the Debian image I'm using, trying to eliminate possible causes, but no luck so far.

Despite the Debian image, the kernel they're using for it is built for Android, so I don't yet know if it's a case of missing a bit of android userspace that's supposed to be doing something, or whether it's a hardware problem.

A couple of thing I have left to try are to boot the Android image from NAND and see if that has the same problem, and to build my own kernel that has enough features in it to hopefully get some debugging info.

There seems to be a community that spans most of the Allwinner based boards centered around http://sunxi.org/ you'll find Olimex stuff there too. Havent dug too deeply yet, mostly looking for resources on building a new kernel. A20 stuff seems a bit scarce so far, there's much more A10 info available.

Looking at the schematics, spdif does go to one of the expansion headers, but it looks like there a resistor (R132) that may not be installed. Unfortunately most of the components don't have any refdes on the silk screen, so finding it will be fun.

Hi Douglas,

I don't know what the use-case is, but in general you'll get much better results if your camera is H.264. The MJPEG is good for video stills (e.g. a snapshot every second), but H.264 is better for motion video (and saves a lot of disk space).

The BBB (or any Linux platform) can handle any of these streams, since it is just network traffic.

EDIT: Sorry I thought Ethernet was being used. If USB, then a driver that runs on the platfom is needed.

If USB, then a driver that runs on the platfom is needed

By that, do you mean V4L2, or a BBB-specific USB driver?

Hi Douglas,

Some webcams will be supported in Linux, and a driver may already be compiled and available on the platform, or it may need to be compiled. However, I think not all webcams are supported in Linux because the manufacturer may not have made a driver available for Linux, compiled for the target device (e.g. ARM).

As long as the driver is in source form then it should be possible to compile it for any linux distro. The problem usually appears when your kernel is 3.11.4 and the vendor driver only supports 2.6.24 or vice versa.

Supplying binary drivers for linux is difficult, since you'd need to supply one for every possible distro and kernel version.  The likes of nvidia sidestep that problem by providing a driver that's mostly binary but that comes with an adaption layer that you compile against your kernel. This mostly reduces the problem to needing three versions for x86, x86_64 and Arm.

Whether cheap webcams go to those extremes is uncertain.

So.... I don't need V4L2 then, if the webcam I'm using is already supported in Linux?  Or do you mean that there are different 'flavours' of V4L2 for different types of webcam?  Or have I completely misundestood what V4L2 is, and what it's used for (which wouldn't surprise me!)?

Having scoured the internet for months on end on this subject, it seems to me that V4L2 is the minimum requirement to read a video from USB, but I've yet to find a website that states what it actually is, whether or not it is always required, and how you build a version of it for the specific SBC and camera that you are using.

All the websites I've visited about Linux - and in particular, about video capture - seems to be aimed at people who already know what they're talking about, but I've yet to find one that describes the process to a newbie.

Douglas Ponsford wrote:

 

If USB, then a driver that runs on the platfom is needed

By that, do you mean V4L2, or a BBB-specific USB driver?

A linux driver specific to the USB webcam.  You can get some idea of what's easily available here http://linuxtv.org/wiki/index.php/Webcam_Devices the problem of course is that it's sometimes difficult to work out which driver goes with any given webcam as they don't tend to tell you which chip is inside on the outside of the box.  You can find out by plugging it in and reading the vendor and device ID's, but you've spent the money by that point !

Douglas Ponsford wrote:

 

This blog lists a Logitech C920 as having H.264 compression, which sound exactly right for me!

Something that produces h.264 directly in the camera is ideal, much less bandwidth required for a given resolution and the bonus is that you don't have any processing to do, just save to a file.

I've still got to establish whether I can reliably store the resultant video stream to a file (with ffmpeg, I assume), but whether that's on a SATA disk on the Cubieboard2, or SDCard on the BBB is probably acedemic at this stage.

You don't have to use ffmpeg, as long as the camera driver gives you a normal v4l2 style /dev/video0 interface then you have a choice of many applications.

When thinking about SDcards, take into account that they can be quite slow and that a lot of SBC's don't support the high speed SDcard modes.  So you could find yourself being able to deal with your multiple h264 streams over USB, but unable to save them to SDcard fast enough.

Very simplistic tests show that the SATA interface on the Cubieboard is fairly good, better than the Sabre-Lite for example. As with anything, one piece of the puzzle is not enough, you want everything your use case needs to be good as the overall application is only as good as the weakest link.

OK, I think that's where my confusion about V4L2 has been coming from.  V4L2 is not a particular piece of code as such, nor an application, it's a standard for reading video streams from USB devices, and there can be many incarnations, or flavours, of a V4L2-compliant driver.

So, in layman's terms:

"V4L2" means "Any Linux driver that is specific to the USB webcam",

in the same way as:

"Hoover" means "Any cleaning device that sucks dust out of carpets by use of a vacuum".

Does that sum it up?

So, if I have an H.264 stream coming in, made available in the /dev/videoN interface by the V4L2-compliant Linux driver, then - as you say - I can just write that byte-stream to a file, and the 'saving video to a file' bit is already done for me.

But, presumably, if I also wanted to simultaneously display the incoming video stream on a monitor (LCD in my case), I'd still need to use ffmpeg to decode the H.264 stream for writing out the live video to a display device?

Your comments about the SATA Vs. SDCard are also a very good point.  Having a ready-made H.264 video stream means that CPU performance is less of an issue, so the BBB is then a good choice because of it's support and price.  But that SATA spec-point in particular makes me think the CB2 is still the one to go for - thanks for pointing that out!

Douglas Ponsford wrote:

 

So, in layman's terms:

"V4L2" means "Any Linux driver that is specific to the USB webcam",

in the same way as:

"Hoover" means "Any cleaning device that sucks dust out of carpets by use of a vacuum".

 

Does that sum it up?

Think of V4L2 as more along the lines of a generic "video capture" driver.  It doesn't need to be a USB webcam, it could be a composite video capture device, a digital-tv tuner, a satellite-tv receiver etc.  It could also use USB, firewire, PCI or any number of other connection methods.

The Hoover analogy works quite well, less bothered about 'how', focus more on accomplishing the task.

V4L2 is the plumbing that provides a standard API for the applications to use.

So, if I have an H.264 stream coming in, made available in the /dev/videoN interface by the V4L2-compliant Linux driver, then - as you say - I can just write that byte-stream to a file, and the 'saving video to a file' bit is already done for me.

It's a bit more complex, but maybe not much. You need to tell V4L2 what resolution you want from the source, fps and such like. Then when you save the stream you probably want a container format like avi, mp4 etc. but most of that is trivial stuff that the application (ffmpeg, vlc, mplayer) can take care of for you.

But, presumably, if I also wanted to simultaneously display the incoming video stream on a monitor (LCD in my case), I'd still need to use ffmpeg to decode the H.264 stream for writing out the live video to a display device?

Yep, you'd need something to do it. I'd maybe suggest taking a look at VLC which has all sorts of options like streaming over ethernet. It may be that you can take care of some things easier with a particular app, or use a combination of different ones to get your end result.

How you get from A to B probably also depends on what OS you use, choice of applications may well be different on Android vs Debian for example.

OK, that all sounds good.  If I can source a camera or video frame grabber that that outputs an H.264 compressed video stream, then it seems less important that I have the very fastest multi-core device, which means I can go back to looking at Android on the CB2 again - in the fullness of time, maybe the Cubie Android will re-enable the 2nd CPU core.  Android looks better supported on the CB2 than BBB anyway, and it has that SATA interface.

That's all good Intel @selsinork, so all I need now is to source an LCD/touch screen and an H.264 video grabber and that's enough to get started.

Many thanks for all your comments - I know I've still got a ways to go before being able to bring up a board with the right kernel/options etc, but at least I've got a starting point now.

Thanks again!

Doug.

OK, that all sounds good.  If I can source a camera or video frame grabber that that outputs an H.264 compressed video stream, then it seems less important that I have the very fastest multi-core device, which means I can go back to looking at Android on the CB2 again - in the fullness of time, maybe the Cubie Android will re-enable the 2nd CPU core.  Android looks better supported on the CB2 than BBB anyway, and it has that SATA interface.

That's all good Intel @selsinork, so all I need now is to source an LCD/touch screen and an H.264 video grabber and that's enough to get started.

Many thanks for all your comments - I know I've still got a ways to go before being able to bring up a board with the right kernel/options etc, but at least I've got a starting point now.

Thanks again!

Doug.