Hi all,
Here I am 6 months later trying to upgrade my laptop and a new issue has cropped up with my video capture in Gem.
System: Ubuntu 6.10 (edgy) i386 using udev Graphics: ATI 9600 running fglrx Kernel: 2.6.18-rt7 Video capture: el-cheapo camcorder run through ADVC-100 firewire device
When running Kino, the camera gets captured just fine and everything "just works" as expected. However, in Gem (tried 0.90, CVS from November and another one from today's snapshot), I need to send following messages for Gem capture to work at all:
device /dev/dv1394/0 mode NTSC driver 1
This starts capture reporting DV capture quality at 5, but the captured stuff is black. The only proof that things are getting captured comes from disconnecting the feed in the middle of the capture by pulling the video cable that connects camcorder with the ADVC-100 and then one can notice change in the color and/or momentary flicker of the captured area.
Aaaargh, accidentally pressed "send" button...
The only thing left to report is that /dev tree has dv1394/0 video/0 video -> video/0 symlink raw1394
Modules loaded are the usual bunch ohci1394 ieee 1394 dv1394 raw1394. I also tried manually modprobing video1394 with no effect.
/dev/ieee1394 tree is missing but recreating it manually (/dev/ieee1394/.../in and .../out simply makes "device0" also work with the same effect as described below.
0.90 gem is worse since it does not allow non-standard choice of devices but it does not appear to be any better off than the 0.91.
Obviously this suggests that there is something fishy with Edgy, but the question is what?
Any help is most appreciated!
Best wishes,
Ico
On 12/27/06, Ivica Ico Bukvic ico.bukvic@gmail.com wrote:
Hi all,
Here I am 6 months later trying to upgrade my laptop and a new issue has cropped up with my video capture in Gem.
System: Ubuntu 6.10 (edgy) i386 using udev Graphics: ATI 9600 running fglrx Kernel: 2.6.18-rt7 Video capture: el-cheapo camcorder run through ADVC-100 firewire device
When running Kino, the camera gets captured just fine and everything "just works" as expected. However, in Gem (tried 0.90, CVS from November and another one from today's snapshot), I need to send following messages for Gem capture to work at all:
device /dev/dv1394/0 mode NTSC driver 1
This starts capture reporting DV capture quality at 5, but the captured stuff is black. The only proof that things are getting captured comes from disconnecting the feed in the middle of the capture by pulling the video cable that connects camcorder with the ADVC-100 and then one can notice change in the color and/or momentary flicker of the captured area.
A small correction:
apparently device 0 does not work no matter what, but /dev/dv1394/0 works sometimes but only with black output.
Here's the relevant output from the Pd:
Open example video/00.SimpleVideo.pd
Shell (from which Pd was started): /dev/video0: No such file or directory (i guess this is expected since ADVC-100 is dv1394 device)
Click on device 0 and driver 1: No feedback
Start rendering: Pd window: Direct Rendering enabled! GEM: Start rendering [pix_videoNEW]: starting transfer DV4L: closed GL: invalid enumerant Shell: /dev/ieee1394/dv/host0/NTSC/in: Is a directory
Stop rendering: Pd window: GEM: Stop rendering
Make message device /dev/dv1394/0, click on it: Shell: get capabilities: Invalid argument get capabilities: Invalid argument (yes, twice) Pd window: [pix_videoNEW]: device-err: 0
Click on mode NTSC and then driver 1: Pd window: DV4L: DV decoding quality 5
At this point when I enable the rendering I consistently get (unlike before): Pd window: Direct Rendering enabled! GEM: Start rendering [pix_videoNEW]: starting transfer DV4L: closed GL: invalid enumerant Shell: /dev/dv1394/0: Device or resource busy
/dev/raw1394, and /dev/video1394/0 or /dev/video yields invalid argument for capabilities and does not work.
Again, I would greatly appreciate your insight in this matter before I resort to switching to a different distro/version.
Many thanks!
Best wishes,
Ico
On 12/27/06, Ivica Ico Bukvic ico.bukvic@gmail.com wrote:
Aaaargh, accidentally pressed "send" button...
The only thing left to report is that /dev tree has dv1394/0 video/0 video -> video/0 symlink raw1394
Modules loaded are the usual bunch ohci1394 ieee 1394 dv1394 raw1394. I also tried manually modprobing video1394 with no effect.
/dev/ieee1394 tree is missing but recreating it manually (/dev/ieee1394/.../in and .../out simply makes "device0" also work with the same effect as described below.
0.90 gem is worse since it does not allow non-standard choice of devices but it does not appear to be any better off than the 0.91.
Obviously this suggests that there is something fishy with Edgy, but the question is what?
Any help is most appreciated!
Best wishes,
Ico
On 12/27/06, Ivica Ico Bukvic ico.bukvic@gmail.com wrote:
Hi all,
Here I am 6 months later trying to upgrade my laptop and a new issue has cropped up with my video capture in Gem.
System: Ubuntu 6.10 (edgy) i386 using udev Graphics: ATI 9600 running fglrx Kernel: 2.6.18-rt7 Video capture: el-cheapo camcorder run through ADVC-100 firewire device
When running Kino, the camera gets captured just fine and everything "just works" as expected. However, in Gem (tried 0.90, CVS from November and another one from today's snapshot), I need to send following messages for Gem capture to work at all:
device /dev/dv1394/0 mode NTSC driver 1
This starts capture reporting DV capture quality at 5, but the captured stuff is black. The only proof that things are getting captured comes from disconnecting the feed in the middle of the capture by pulling the video cable that connects camcorder with the ADVC-100 and then one can notice change in the color and/or momentary flicker of the captured area.
I tried to get 1394 running with ubuntu edgy without success also. Maybe try using a webcam before you die of frustration.
I did. It changed my life : )
Sylvain
Ivica Ico Bukvic ico.bukvic@gmail.com wrote: A small correction:
apparently device 0 does not work no matter what, but /dev/dv1394/0 works sometimes but only with black output.
Here's the relevant output from the Pd:
Open example video/00.SimpleVideo.pd
Shell (from which Pd was started): /dev/video0: No such file or directory (i guess this is expected since ADVC-100 is dv1394 device)
Click on device 0 and driver 1: No feedback
Start rendering: Pd window: Direct Rendering enabled! GEM: Start rendering [pix_videoNEW]: starting transfer DV4L: closed GL: invalid enumerant Shell: /dev/ieee1394/dv/host0/NTSC/in: Is a directory
Stop rendering: Pd window: GEM: Stop rendering
Make message device /dev/dv1394/0, click on it: Shell: get capabilities: Invalid argument get capabilities: Invalid argument (yes, twice) Pd window: [pix_videoNEW]: device-err: 0
Click on mode NTSC and then driver 1: Pd window: DV4L: DV decoding quality 5
At this point when I enable the rendering I consistently get (unlike before): Pd window: Direct Rendering enabled! GEM: Start rendering [pix_videoNEW]: starting transfer DV4L: closed GL: invalid enumerant Shell: /dev/dv1394/0: Device or resource busy
/dev/raw1394, and /dev/video1394/0 or /dev/video yields invalid argument for capabilities and does not work.
Again, I would greatly appreciate your insight in this matter before I resort to switching to a different distro/version.
Many thanks!
Best wishes,
Ico
On 12/27/06, Ivica Ico Bukvic ico.bukvic@gmail.com wrote: Aaaargh, accidentally pressed "send" button...
The only thing left to report is that /dev tree has dv1394/0 video/0 video -> video/0 symlink raw1394
Modules loaded are the usual bunch ohci1394 ieee 1394 dv1394 raw1394. I also tried manually modprobing video1394 with no effect.
/dev/ieee1394 tree is missing but recreating it manually (/dev/ieee1394/.../in and .../out simply makes "device0" also work with the same effect as described below.
0.90 gem is worse since it does not allow non-standard choice of devices but it does not appear to be any better off than the 0.91.
Obviously this suggests that there is something fishy with Edgy, but the question is what?
Any help is most appreciated!
Best wishes,
Ico
On 12/27/06, Ivica Ico Bukvic ico.bukvic@gmail.com wrote: Hi all,
Here I am 6 months later trying to upgrade my laptop and a new issue has cropped up with my video capture in Gem.
System: Ubuntu 6.10 (edgy) i386 using udev Graphics: ATI 9600 running fglrx Kernel: 2.6.18-rt7 Video capture: el-cheapo camcorder run through ADVC-100 firewire device
When running Kino, the camera gets captured just fine and everything "just works" as expected. However, in Gem (tried 0.90, CVS from November and another one from today's snapshot), I need to send following messages for Gem capture to work at all:
device /dev/dv1394/0 mode NTSC driver 1
This starts capture reporting DV capture quality at 5, but the captured stuff is black. The only proof that things are getting captured comes from disconnecting the feed in the middle of the capture by pulling the video cable that connects camcorder with the ADVC-100 and then one can notice change in the color and/or momentary flicker of the captured area.
_______________________________________________ GEM-dev mailing list GEM-dev@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
Thanks for the advice but I am hoping to avoid webcam due to inherent quality/fps decrease. Also, what makes me wonder is because Kino works fine but Gem doesn't and given that Edgy is more-or-less supposed to draw from the bleeding edge lib versions that this kind of a problem will eventually trickle down to other distros which may be currently relying upon older versions of supporting libs, hence requiring update in Gem. If this is so, I think sooner rather than later is probably a good idea.
Best wishes,
Ico
On 12/28/06, Studio Zodiak studiozodiak@yahoo.ca wrote:
I tried to get 1394 running with ubuntu edgy without success also. Maybe try using a webcam before you die of frustration.
I did. It changed my life : )
Sylvain
*I*
On Thu, 28 Dec 2006, Ivica Ico Bukvic wrote:
Thanks for the advice but I am hoping to avoid webcam due to inherent quality/fps decrease.
USB2 is 40 times faster than USB1: at 400 mbps, in 720x576, full color 24 bits per pixel, cameras could do 40 fps... but typically they don't, they use half the data rate (decimation of chroma columns, as in most broadcast video) and have a cap at 30 fps because anyway the motion is already blurry enough at 30 fps.
You may also need a special program to unlock the framerate of the camera. For Philips cameras (most of the modern Logitech/Labtec) the setpwc program will allow you to get away from the default framerate of 10 fps.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Thanks for the info. However, ADVC-100 that I use is a firewire A/V device so the default behavior is 30fps at 720x480 (NTSC) with the only bottleneck being the quality of the camcorder (which in this case is still better than a webcam). But all this is moot as Gem worked just fine a month ago when I was working on Hoary 5.04 and now on 6.10 it doesn't (either the extended nightly builds or my own build). And this worries me since my project depends upon transportability/transparency which is currently sorely missing in this setup...
Best wishes,
Ico
On 12/28/06, Mathieu Bouchard matju@artengine.ca wrote:
On Thu, 28 Dec 2006, Ivica Ico Bukvic wrote:
Thanks for the advice but I am hoping to avoid webcam due to inherent quality/fps decrease.
USB2 is 40 times faster than USB1: at 400 mbps, in 720x576, full color 24 bits per pixel, cameras could do 40 fps... but typically they don't, they use half the data rate (decimation of chroma columns, as in most broadcast video) and have a cap at 30 fps because anyway the motion is already blurry enough at 30 fps.
You may also need a special program to unlock the framerate of the camera. For Philips cameras (most of the modern Logitech/Labtec) the setpwc program will allow you to get away from the default framerate of 10 fps.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Thu, 28 Dec 2006, Ivica Ico Bukvic wrote:
Thanks for the info. However, ADVC-100 that I use is a firewire A/V device so the default behavior is 30fps at 720x480 (NTSC) with the only bottleneck being the quality of the camcorder (which in this case is still better than a webcam). But all this is moot as Gem worked just fine a month ago
What I'm saying is that if ever you are stuck with having to use something else than last month, then you still have a way out that isn't completely bad. It's not like 160x120 at 5fps...;)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Thu, 28 Dec 2006, Studio Zodiak wrote:
I tried to get 1394 running with ubuntu edgy without success also. Maybe try using a webcam before you die of frustration. I did. It changed my life : )
Both GEM and GridFlow would benefit from supporting a camera interface based on libraw1394, libavc1394, etc., instead of the rather unstable and deprecated direct interface to the kernel.
Another possibility would be to support videojack/unicap as a uniform interface to cameras. I think that this might be a good idea because there's only so much effort that we can bother to do trying to support V4L1, V4L2, lib*1394.so (both DV and DC), (btw what is/was libdv1394? it doesn't exist on Ubuntu), and then SANE and... did I forget any? And then it's a good idea to have it in a separate thread/process (don't you love a V4L driver that doesn't support non-blocking mode and ignores SIGALRM ?).
Despite those thoughts I still haven't had a look at unicap yet, still too many other things TODO first.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
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
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@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@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
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@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?
ln -s /dev/ieee1394 /dev/ieee1394-0
permissions
Anyway, just my 2 cents for now.
Sylvain
*Ivica Ico Bukvic ico.bukvic@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@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
FWIW, here are some pointers that may help. I just investigated kino package which apparently works and the same site hosts a very simple dvgrab shell app which captures dv stream into an avi file. At a first glance it appears simple enough to be adapted for Gem use, but I may be totally wrong about this too... Now, if someone could please point out what kind of packets does videoDV4L.cpp send out to Gem...
Best wishes,
Ico
hi ivica/all,
--- Ivica Ico Bukvic ico.bukvic@gmail.com wrote:
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
hey, this prophecy became true here on gentoo yesterday: same symptoms as you described, dv input hardly worked at all: doing the driver 1 / open /dev/1394 magic made it work sometimes, altough the chroma and luma planes were appearantly swapped (red became blue and vice versa, pix_colormatrix with a 0 0 1 0 1 0 1 0 0 matrix corrected this). today i re-compiled gem from cvs, and now it doesn't work at all :-( i had the idea to frameserve video into gem, but that concept doesn't seem to exist on linux yet. both ffmpeg and dvgrab are able to output to a pipe, but that doesn't help very much in this case. hopefully avisynth 3 will become usable soon, making gem gstreamer-aware might also be a good idea ... I've read that you also tried vloopback, have you had any success with this?
with kind regards, thoralf.
___________________________________________________________ New Yahoo! Mail is the ultimate force in competitive emailing. Find out more at the Yahoo! Mail Championships. Plus: play games and win prizes. http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk
-
Ivica Ico Bukvic -
Mathieu Bouchard -
Studio Zodiak -
Thoralf Schulze