Ideas for future work on v4l4j

These are some of the ideas I came up with, to add functionality to v4l4j and achieve better integratation it with other projects:

• Review and perhaps improve the way frames are given to the user. For now, ByteBuffers are used but they involve a memory copy operation, at least to transfer the contents of the ByteBuffer to a byte array which can be then passed on to other SWING objects for display. It might not be necessary when doing video streaming over the network for instance (I believe it is possible to  send the contents of the ByteBuffer to a socket without extra copy, but I have not tested this). Also worth investigating is whether implementing a push model would be useful.
  
• Add support for MPEG image format: in order to achieve this, libvideo must first be modified to return not just a pointer to the frame buffer, but most of the fields present in the struct v4l2_buffer so as to report timecode, frame type, ... The reason I havent implemented things this way originally, is because MPEG is only available in v4l2, and I wanted to investigate more how to emulate (or fake) these fields that are present in v4l2 but missing in v4l1. However, with a bit more experience now and after making libvideo fake (a lot) of missing things to make it behave like v4l2 in a lot of ways, I believe it shouldnt be too hard to implment.
  
• Integration with FMJ: FMJ is an open source implementation of the (now dead) JMF (Java Media Framework). FMJ is API-compatible with JMF, so applications written to use JMF can (in theory, not tested) work with FMj without modification. Alexandra has submitted some sample code to quickly create a JMF DataSource out of a v4l4j VideoDevice, but it needs some refactoring.
• Since I am currently deeply involved with DirectShow at work, I cant help but thinking about making v4l4j use DirectShow to capture video streams. Of course, the v4l part in v4l4j wont be too relevant there, but I think a project rename is acceptable if it means supporting addtional platforms.
  

This is all I can think for now.  As always, comments (on the mailing list please) are welcome.

Changelog for v0.8.6

v4l4j 0.8.6 packs in support for a brand new feature: dealing with capture frame rate.

With this version, an application can dynamically find out wheter a video device supports adjustable capture frame rates, enumerate them and set an appropriate one for capture.
Of course, this feature is available only if the driver and video device support it. I have made a few test with the hardware I have at hands and I managed to achieve capture rates of up to 30 frame per seconds ! I have listed my results on this wiki page.

First post

I have just setup this blog about a project I have been running for a while now: v4l4j. In short, the goal of v4l4j is to bring video capture capability & video device control to Java. It is an API through which a Java application can :

• enumerate capabilities of a video device, such as the supported image format, resolution and frame rate,
• setup a video device and capture images from it,
• enumerate video controls and act on them.

A lot more information is available on the website.

With this blog, I am hoping to post design ideas, future directions & improvements as well as keeping a changelog of updates to v4l4j.