[Gridflow-dev] missing include linux/videodev.h in src/videodev.cxx
claude at goto10.org
Fri Dec 30 10:52:21 EST 2011
On 26/12/11 21:49, Mathieu Bouchard wrote:
> Le 2011-12-22 à 17:39:00, Claude Heiland-Allen a écrit :
>> The future-proof (until the kernel changes again, heh) solution is to
>> use <linux/videodev2.h> and libv4l2(-convert), but this would be quite
>> a lot of work (especially for controls) as V4L2 is somewhat
>> complicated - I have experimented a little with this stuff in Haskell,
>> perhaps I'll be able to find some time in mid-January to transfer my
>> knowledge to C++/GridFlow.
> Wow, that would be awesome !
libv4l2 makes it really easy to capture frames with a blocking read
interface whether the underlying driver supports it or not, also
performing some colour space conversions if needed/desired.
Enumerating controls (possible use cases: knowing which #io.v4l2 methods
to register, or even generating a Pd controller GUI patch for that
particular device) is somewhat tricky but certainly possible (something
like calling an ioctl() incrementing an id until it fails, do this twice
for two different control id ranges):
TV tuners are another layer of complication altogether, I've not really
touched this yet (I do have a BTTV PCI card somewhere in a cupboard,
maybe I should dig it out for experimentation before analogue TV
broadcast end here...).
> As you can see, I've started writing a module named v4l2.cxx
> ([#io.v4l2]) but I have not finished it.
> I think that we could also be talking about how to add threading to
> camera modules and perhaps to input modules in general.
> Something like :
> [#in v4l2 /dev/video0, auto]
> [#camera, auto]
> In which auto means that the object itself will drive its own clock,
> enabling the work to be done in a separate thread.
> This topic is more detailed and complicated than what I'm stating now,
> but this is just to inform you of what I have in mind.
> Currently, most camera modules use a blocking interface, that can
> interfere a lot with sound and any other duties (I think that
> [#io.quicktimecamera] is the exception).
It should be easiesst to use blocking interfaces (eg "v4l2_read()") in
another thread, the tricky part (as always..) is the communication
between threads (what about frame dropping if the camera captures faster
than the pd/gridflow processing can support?).
More information about the Gridflow-dev