[Gambas-devel] v4l2 patch for gb.v4l

[Gareth Bult]

.. In principle it sounds great .. 

.. If the implementation does what it says on the tin it would certainly simplify things ..

Pro's:

If the library is going to be actively developed and maintained, then effectively the hard work is being handed off to another developer who seems to have a particular interest in v4l?.

Assuming the library does what the spec says, all formats will already be handled and issues such as reporting unhandled formats simply goes away.

Con's:

I would "guess" that it will mean rewriting the current v4l code from scratch. I very much doubt it will be a plug and play with the current code. (albeit most of the re-write will involve removing redundant code)

The library "may" contain bugs / leaks which are not currently present.

..

I guess it comes down to the quality of the library and whether someone has the time to evaluate it and re-write the module again, but in principle it would be a great idea. As with all things re-using someone else's code always a good head start .. I've recently started to use qdbm and thought it was fantastic .. only to find it's been replace by "tokyo cabinet", which looks to be even better (!) Knowing which libraries are available and which are the best to use always seems to be a major part of the problem .. 

:(

Gareth.

----- Original Message -----
From: "Benoît Minisini" <gambas at ...1...>
To: "mailing list for gambas developers" <gambas-devel at ...494...t>
Sent: Friday, 20 February, 2009 10:27:29 PM GMT +00:00 GMT Britain, Ireland, Portugal
Subject: Re: [Gambas-devel] v4l2 patch for gb.v4l

> Hi,
>
> IMHO the v4l code in G2 won't actually work on many cameras, I would
> consider it more of a "demo" than the finished article .. certainly the
> Logitec camera's I've bought recently "all" only work on v4l2. (I only have
> one camera for V4l testing which is ~ 5 years old)
>
> If the patch works on G2, great, however v4l->v4l2 is significant and the
> chances of it introducing "issues" into what should be the "release" code
> might be "high".
>
> I recall we did have a number of issues relating to memory leaks while
> getting this code going - I don't know how many of these were down to G3
> development and how many were exposed / inherent issues ..
>
> (if v4l2 is required in G2, it "might" be a better idea to back-port the
> new v4l2 code ??)
>
> Gareth.
>

The memory leaks were just bugs in the new gb.image component. They should all 
be gone now.

I think the better way of dealing with v4l is using the libv4l library Silvan 
talked about: http://hansdegoede.livejournal.com/3636.html. This library seems 
to be able to use v4l1 and v4l2 indifferently: it provides a v4l1-like API to 
v4l2 device, so you can use the same code for both. You have an API for v4l2-
only devices too, and a library that converts between different device image 
formats.

What do you think about that?

-- 
Benoît

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Gambas-devel mailing list
Gambas-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gambas-devel

-- 
Gareth Bult (Gareth at ...624...)