[Gridflow-dev] missing include linux/videodev.h in src/videodev.cxx

[Claude Heiland-Allen]

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):

https://gitorious.org/hsv4l2/v4l2/blobs/master/Graphics/V4L2/Control.hs#line83

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.

Cool.

> 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?).


Claude