-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
hi,
would it be a problem for you if we moved this thread onto a mailing list? i really prefer this way of communication, as it allows more than a single person to profit (and help!)
On 2011-01-23 13:55, kubro bubro wrote:
sorry, right now i cant offer you money, but ill try to do something with that.. i need to wait for payed project
picture is still white. unicap is loaded, but transfer doesnt start, because failed to query format:
[...]
verbose( 1):[pix_video]: starting transfer verbose( 1):failed to query format
oha, it's a bit weird that you cannot even _query_ the format. i'm a bit at a loss, as to how to react on this (but fail).
right now, only system buffer support is implemented in Gem, assuming the unicap will always provide a "fake" system buffer, if the underlying device cannot do so. (i'm not sure about this though). but even if i implemented user buffer support, i still would need to know which transport is actually used and thus the "query" has to succeed.
maybe this is normal, but im not able to set properties: directly setting menu-value to 'Composite 1' (please report if this works!) verbose( 1):could not set property 'source'
unfortunately i cannot test menu-values, as i don't have any device that offers a menu-value :-.(
just to make sure: how exactly do you try to set your source? i think it should be something like: |...\ (symbolbox) | [set source $1( | [pix_video]
and then type "Composite 1" into the symbolbox (this is an easy way to create a symbol with spaces)
another way that _should_ work, is
[set source 0( | [pix_video]
if you can confirm that this (source <int>) works and that (source <symbol>) does not, i have an idea how to fix the underlying code)
apart from all that, i found that unicap does not reliably start the transfer.
e.g. using my PS3 i have to first set the size with "dimen 640 480" to the only support dimension of the device (i'm using the normal kernel drivers), since unicap always believes that the only supported size is 768x576, but then fails to capture images. it is also crucial in which order things are called (e.g. i have to do [dimen 640 480( and only then start rendering/capturing/transfer, else i don't get an image for the rest of the Pd-session. on my eeePC, it is slightly different, but i have to explicitely set the device before i can acquire images.
all in all, unicap support is still quite experimental.
i'm using stock debian's unicap though, which is a bit outdated (0.9.5)
fgmasdr# IOhannes