v0.0.4

This release introduced crucial bug fixes and other features including:

• Support for extended controls (i.e. querying, value get/set, enumerating)
• Capture sequence refactor to fix device-open bug
• Memory leak identified when running video capture programs for long period

Support for extended video controls

This release introduces support for V4L2 extended controls.

• Use existing control types, values for V4L2 extended control features
• Addition of low level Go functions to query, get, and set control values
• Ability to enumerate extended controls and their values.

The following example shows how to retrieve all available extended controls from the driver.

func main() {
	device, err := dev.Open("/dev/video0")
	if err != nil {
		log.Fatalf("failed to open device: %s", err)
	}
	defer device.Close()

	ctrls, err := v4l2.QueryAllExtControls(device.Fd())
	if err != nil {
		log.Fatalf("failed to get ext controls: %s", err)
	}
	if len(ctrls) == 0 {
		log.Println("Device does not have extended controls")
		os.Exit(0)
	}
	for _, ctrl := range ctrls {
		printControl(ctrl)
	}
       
       func printControl(ctrl v4l2.Contro) { ... }
}

See full example here

Capture sequence refactor

Since the inception of the project, it was known there were some bugs that needed to be revisited. We found out that some of the examples were failing when running on a Raspberry PI and capturing from a Raspberry Pi HD camera module. The code's use of the Go's standard library os.OpenFile was causing the device to report busy (when compared to similar programs in C).

So this called for an overhaul of the entire capture sequence which delivered the followings

• Fix device open failure by providing a simpler device operation that make system calls directly
• Successful test using the Raspberry Pi's HD camera module connected as a capture device
• Add more aggressive system call error handling for v4l2 calls including open, ioctl VIDIOC_QBUF, VIDIOC_DQBUFF, etc. This causes to run smoother, remove internal flickers that would happen sometimes

Memory leak fix

User @oyarzun reported a memory leak when running the webcam example (see issue #22). After a few hours of Go program profiling, it was found that the internal stream loop was leaking Go channel resources (by reinitialize the channel in the loop). After a simple fix (moving the channel initialization outside of the loop), the leak went away. After running the webcam program for over 25 hours on a RPi 3, it was observed that the memory consumption did not go over 1%. That was an awesome find.