hi there,
i'm trying to get a high-resolution live feed into gem. since using a dv camera is not a viable option (frame rate to low, cpu consumption to high), i decided to give some usb webcams a go.
unfortunately, things seem to look even worse here. quarter-vga resolutions are no problem, but for higher resolution (i settled for 640x480), the choices are rather limited ... for the cheap ones, there are just no v4l/v4l2-drivers available. i have a logitech quickcam pro 5000 for evaluation right now - while this one works relatively okay with the libuvc driver (which provides a v4l2 interface), i cannot get it to cooperate with gem. creating a pix_video object triggers the following messages on the shell:
vidioc_s_crop: Invalid argument VIDIOC_S_FMT: Invalid argument
and these in the pd window:
video driver 0: video4linux2 video driver 1: video4linux video driver 2: ieee1394 for linux startTransfer: 0 start transfer device: /dev/video0 wanted 6408, got 'RGB4' error: should exit! error: unknown format 'MJPG' changed size from 64x64 to 320x240 buf.index==0 buf.index==1 buf.index==2 buf.index==3 format: MJPG -> 6408 colorconvert=1 waiting for thread to come up waiting for thread to come up waiting for thread to come up GEM: pix_video: Opened video connection 0x6
looking at the source of the driver, there is the following remark in uvc_driver.c:
* The driver doesn't support the deprecated v4l1 interface. It implements the * mmap capture method only, and doesn't do any image format conversion in * software. If your user-space application doesn't support YUYV or MJPEG, fix * it :-). Please note that the MJPEG data have been stripped from their * Huffman tables (DHT marker), you will need to add it back if your JPEG * codec can't handle MJPEG data.
sending a |colorspace YUV( to pix_video does not fix it ... so i assume that uvcvideos YUYV colour space is not the same as gem's YUV. is there any chance of getting this cam to work, anyway? if no, do you know of any affordable webcams that go along well with gem on linux and deliver 640x480 with 25 fps?
thank you for your help, thoralf.
___________________________________________________________ The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html
On Sat, 10 Mar 2007, Thoralf Schulze wrote:
for the cheap ones, there are just no v4l/v4l2-drivers available. i have a logitech quickcam pro 5000 for evaluation right now
You might be better off using older QuickCams supported by the pwc.ko driver. The uvc driver is still very new, and last time I checked, it seemed a bit flaky, though maybe this has already changed (?).
- The driver doesn't support the deprecated v4l1 interface.
Exactly. That's my main problem with it. My software is still v4l1 only. V4l2 is in the plans, but it's only in the plans. Now my main incentive for v4l2 is the quickcam pro 5000, though I don't have any. There's supposed to be an automatic adapter from v4l2 to v4l1 afaik, but it doesn't work in this case, i don't know why. Just because the interface is deprecated doesn't mean most programs still rely on it.
- and doesn't do any image format conversion in software.
This is a policy of the linux kernel. Basically, Linux doesn't care that colorspace its interface is difficult to use directly, so all the burden is on the user, and because the whole thing is based on ioctl, it's essentially not possible to emulate it as a user-space library without redefining ioctl to be something else, so as far as V4L2 goes, there's no difference between the user and the userspace, because it's just a kernel interface.
If your user-space application doesn't support YUYV or MJPEG, fix it :-)
This basically means that V4L2 is difficult to support because one is supposed to be supporting all of its color models. (Is it me, or the smiley makes it sound worse than without a smiley?)
sending a |colorspace YUV( to pix_video does not fix it ... so i assume that uvcvideos YUYV colour space is not the same as gem's YUV.
The V4L1 header alludes to the sarcastic quote "The nice thing about standards is that there are so many of them" in reference to the multitude of YUV bit-level formats - YUYV, UYVY, etc.
if no, do you know of any affordable webcams that go along well with gem on linux and deliver 640x480 with 25 fps?
The quickcam 4000 pro stops at 15 fps for that resolution. At 320x240 it goes up to 30 fps but limited to increments of 5 fps.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
hi mathieu,
thank you for your answer ...
[quickcam pro 5000 with uvc]
driver. The uvc driver is still very new, and last time I checked, it seemed a bit flaky, though maybe this has already changed (?).
it seemed to be quite stable with the few applications that support its v4l2-interface - namely, ekiga and its very own uvcview.
[v4l/v4l2]
redefining ioctl to be something else, so as far as V4L2 goes, there's no difference between the user and the userspace, because it's just a kernel interface.
This basically means that V4L2 is difficult to support because one is supposed to be supporting all of its color models. (Is it me, or the smiley makes it sound worse than without a smiley?)
phew, that might be okay from a kernel programmers viewpoint - it really sucks for anyone else. as long as there is no tried-and-tested middleware that does color conversations, decodes mjpeg streams and all those things, it's up to the developers of v4l2-applications to reinvent those wheels for every usb camera and every colour space out there. that's plain - inefficient. gstreamer might be able to do exactly this one day, hopefully. the loopback device for v4l looked promising as well, but is not maintained anymore.
The quickcam 4000 pro stops at 15 fps for that resolution. At 320x240 it goes up to 30 fps but limited to increments of 5 fps.
blimey. i kind of came to terms with using a dv cam already and live with the 50% performance penalty ...
with kind regards, thoralf.
___________________________________________________________ What kind of emailer are you? Find out today - get a free analysis of your email personality. Take the quiz at the Yahoo! Mail Championship. http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk
On 3/21/07, Thoralf Schulze thoralf_schulze@yahoo.de wrote:
The quickcam 4000 pro stops at 15 fps for that resolution. At 320x240 it goes up to 30 fps but limited to increments of 5 fps.
blimey. i kind of came to terms with using a dv cam already and live with the 50% performance penalty ...
Are you able to use a PCI capture card? That is ideal for desktop machines, but obviously not suitable for laptops.
hi chris,
Are you able to use a PCI capture card? That is ideal for desktop machines, but obviously not suitable for laptops.
great idea ... although the video signal will be sent through an unneccessary digital -> analog -> digital converting loop in this case. do you know how this solution fares in terms of cpu usage? and did you get something like this actually running with pd/gem?
thank you, 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
On 3/21/07, Thoralf Schulze thoralf_schulze@yahoo.de wrote:
hi chris,
Are you able to use a PCI capture card? That is ideal for desktop machines, but obviously not suitable for laptops.
great idea ... although the video signal will be sent through an unneccessary digital -> analog -> digital converting loop in this case.
Not if the source is a DV camera live feed. The compression is only applied to the tape signal.
do you know how this solution fares in terms of cpu usage? and did you get something like this actually running with pd/gem?
This largely depends on the hardware. The BT848 or 878 chips have good Linux support. The question is what colorspace they deliver and how much the driver has to touch the pixels. GEM uses 2vuy format internally which is fairly standard among codecs and devices (that's why I picked it). I think IOhannes and others have a fair amount of experience with these PCI capture cards.
thank you chris,
i'm just trying to score a hauppauge wintv primio card on *bay, which is supposedly built around a bt8x8 chipset. i'll let you know how it fares ...
with kind regards, thoralf.
___________________________________________________________ What kind of emailer are you? Find out today - get a free analysis of your email personality. Take the quiz at the Yahoo! Mail Championship. http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk
This largely depends on the hardware. The BT848 or 878 chips have
I am confused exactly because for this reason since I have a FW ADVC-100 which is obviously hw-based. I would be seriously surprised if it did not have a decoder (there are jumpers on the device for NTSC/PAL etc.), especially given its price point. Then again, what do I know...
Best wishes,
Ico
On 3/21/07, Ivica Ico Bukvic ico.bukvic@gmail.com wrote:
I am confused exactly because for this reason since I have a FW ADVC-100 which is obviously hw-based. I would be seriously surprised if it did not have a decoder (there are jumpers on the device for NTSC/PAL etc.), especially given its price point. Then again, what do I know...
That device encodes analog video to DV25. The frames need decoding before display which costs CPU cycles.
hi chris,
This largely depends on the hardware. The BT848 or 878 chips have good Linux support. The question is what colorspace
got one of the latter - it's a charm and beats anything out of those firewires ... thanks for the hint. it takes less than half cpu cycles to get the frames into gem (at 640x480), the job gets done almost in realtime and with 25 fps. and there are solid plugs, too :-)
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
Thoralf Schulze wrote:
it takes less than half cpu cycles to get the frames into gem (at 640x480), the job gets done almost in realtime and
it would be interesting to know why it is only _almost_ realtime and not truely. do you have to save the video to harddisk before you can use it?
mfg.sd IOhannes
hi iohannes,
it would be interesting to know why it is only _almost_ realtime and not truely.
no worries: with regard to gem, everything happens in realtime. i was referring to the lag caused by the capture board and / or the bttv drivers ... it is hardly noticeable at all and absolutely negligible compared to the delay that occurs when using firewire-hardware, which was at least 100 milliseconds.
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
... ah, i forgot: i had to recompile gem without support for v4l2 to get it working. it locked up otherwise after sending channel- or device- messages to pix_video, can't remember which.
with kind regards, thoralf.
___________________________________________________________ Inbox full of unwanted email? Get leading protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html
Thoralf Schulze wrote:
... ah, i forgot: i had to recompile gem without support for v4l2 to get it working. it locked up otherwise after sending channel- or device- messages to pix_video, can't remember which.
that's why v4l2 support is still experimental and not enabled by default.
i might have a look at this later; it would be cool if you could file a bug-report at the http://sf.net/projects/pd-gem just to keep me reminded.
mfga.d IOhannes