[PD] Re: [GEM-dev] Re: pix_video and dv1394 capture on Edgy

[Ivica Ico Bukvic]

As I suspected, issue is much more acute. I just tried the identical setup
on vanilla FC6 and it exhibits *exactly* the same problem (Kino works, but
Gem doesn't using the same ieee1394 device, namely ADVC-100). So, now we
have Dapper, Edgy, and FC6 for sure having this problem and I would not be
surprised to hear that there are more recent distros which exhibit this
issue (Debian for sure due to its relationship to Ubuntu).

Regarding your questions Studio, please see my previous e-mails, they are
pretty verbose as to what is missing and/or what is the behavior. FWIW, I do
not have /dev/dv1394-0, but rather /dev/dv1394/0 device. This is the case on
both FC6 and Ubuntu. The problem is exhibited via pd-extended install,
totally from scratch source install (mine on Ubuntu had everything yes
except for libmpeg1 and ffmpeg; libmpeg3 was also yes), and now also the
CCRMA build.

This may seem that newer udev plus latest ieee1394 libs/drivers are at odds
with the Gem way of addressing them.  I have traced the problem down to
Gem/src/Pixes/videoDV4L.cpp which deals with dv1394 device and from which
all of the errors come. Commenting any of the tripwires simply triggers the
next one (i.e. closed error, then ioctl WAIT_FRAMES, then ioctl GET_STATUS,
etc.). Commenting all "return NULL" evokes these errors on every frame
flodding the shell. I could probably take a stab on this one if I knew more
about ieee1394 and more precisely dv1394 stuff but I don't. Learning so
would take way too much time and more importantly it would be redundant as I
am sure the community already has those who are well-versed in this area. I
will, however, gladly provide necessary access/feedback and even code
provided I am given some help in understanding dv1394 stuff so that the code
is altered accordingly.

I hope you will agree with me that this is a pretty big deal as it will
preclude use of dv1394 in conjunction with Gem without exceptions until this
issue is resolved. My plea is please push this to the top of the TODO list
and I'll do all I can to assist in resolving the issue.

Many thanks!

Best wishes,

Ico

On 12/28/06, Studio Zodiak <studiozodiak at yahoo.ca> wrote:
>
> This is interesting.
> Like I said before,
> I asked this list before with the same problem.
>
> maybe we can share info.
>
> Are you compiling Gem?
>
> I have used the compiling options --with-ieee1394-includes
> and --with-ieee1394-libs
> -I don't know where to set the libs thaugh- /usr/lib/?
>
> Anyway, at the end of the configure, I get no for the ieee1394 option.
>
> even disabling v4l is not doing much.
>
> I went on the ieee1394 website and saw that the api relies on two
> libraries.
>
> Just for you information,
> last time I succeeded in making my dvcamera work with Gem on linux was on
> red hat 9.
>
> This I have tried on breezy and dapper with no success.
>
> I grepped for /dev/ieee1394 in the Gem's src directory and found that it
> is supposed to default to ieee1394 from v4l (is this correct?).
>
> I remember having to send a driver 1 message to pix_video like on a mac.
>
> Only on my Edgy machine the repertoire is /dev/ieee1394-0
>
> could one do as such perhaps?
>
> 1. ln -s /dev/ieee1394 /dev/ieee1394-0
>
> 2. permissions
>
> Anyway, just my 2 cents for now.
>
> Sylvain
>
>
>
>
>
>
>
> *Ivica Ico Bukvic <ico.bukvic at gmail.com>* wrote:
>
> > Despite those thoughts I still haven't had a look at unicap yet, still
> too
> > many other things TODO first.
>
> Well, I just wasted another 2 hours trying to get my 5+ (!) year old
> webcam
> working which is still unsupported in Linux (intel pocket pc cam cs780,
> even
> though CS630 and CS430 are supported). Ironically, in Windoze everything
> "just worked."
>
> Based on my tests I am suspecting that this is a lib/distro-independent
> issue, and as such am also wondering what will happen with pd/gem on Linux
> in 6 months when most of the other distros pump out their next release
> with
> libs similar to Edgy (maybe some of them already are?) leaving gem video
> for
> all intents and purposes broken. I also looked at the videojack project
> Mathieu pointed out and it really looks, well, promising, but it is by no
> means a complete and/or well supported product despite its huge potential.
> Perhaps this video issue should be bumped higher on the gem TODO list
> given
> the current situation?
>
> Thanks for all your help!
>
> Best wishes,
>
> Ico
>
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20061228/a2eb4c66/attachment.htm>