Hi all,
I'm trying to figure something out [again] with pix_video. How does the playback from pix_video work and can I influence the playback with a different metro?
Right now, I've a webcam connected and the playback seems to be a little slow and a bit blurry; I just want to try what I can do to change speed of the playback, but cannot find anything in the helpfile of pix_video.
I tried to connect a metro [40] to pix_video but that doesn't work.
Thanks,
Sara
On Mon, 10 Jan 2005, sara kolster wrote:
I'm trying to figure something out [again] with pix_video. How does the playback from pix_video work and can I influence the playback with a different metro? Right now, I've a webcam connected and the playback seems to be a little slow and a bit blurry; I just want to try what I can do to change speed of the playback, but cannot find anything in the helpfile of pix_video. I tried to connect a metro [40] to pix_video but that doesn't work.
Most camera/digitiser hardware has a maximum framerate, so for example there is almost no hardware that allows you to drive it with better than [metro 33.3667] (which is 1000 divided by the north-american TV framerate). When using PAL (European TV), the best possible is instead [metro 41.708].
Webcams often have much lower framerates. For example, I have USB cameras that can't do better than [metro 100] or even [metro 285] (really!). In some cases, the camera is advertised to be quick, but it uses a compression scheme that is considered a trade secret, so that you often cannot get the full speed unless you are using the manufacturer's driver, and that requires using one of the manufacturer's preferred OS'es. (and this is currently the topic of hot debates on some other mailing-lists, especially the big one called "linux-kernel")
Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju
sara kolster wrote:
Hi all,
I'm trying to figure something out [again] with pix_video. How does the playback from pix_video work and can I influence the playback with a different metro?
Right now, I've a webcam connected and the playback seems to be a little slow and a bit blurry; I just want to try what I can do to change speed of the playback, but cannot find anything in the helpfile of pix_video.
I tried to connect a metro [40] to pix_video but that doesn't work.
this seems to be complicated...
[pix_video] captures the input-stream of a capture-device; as capturing is done in real-time you cannot speed [pix_video] up (at least not in our space-time-continuum where we cannot travel into future)
however, if you think that the latency is to high (the time between you waving before the lens and the movement appearing on the screen) read on
connecting [metro 40] to [pix_video] is an interesting idea, but unfortunately this is not the way it works. gem builds its own "render-clock", which you cannot speed up (or change at all!) with a [metro]. if you want higher frame-rates, you can send a "rate" message to the [gemwin], like [rate 60( (the default of 20 is a bit low); you can even set the default frame-rate as an argument to [gemwin] (like [gemwin 60])
because you had the idea of using [metro] i guess you have used pdp before, and thus are on linux (or rather os-X, as your mail-client seems to imply)
as for linux: gem captures from the video-input as fast as possible in a separate thread; this should make videoIN as smooth as possible; however, the captured images are displayed only once a render-cycle, so incrementing the framerate (see above) might help (a bit)
as for osX: in theory it should be very similar, except that jamie and chris have done huge accelerations, so it should be even faster. otoh, osX-users tend to use USB or ieee1394 cameras which have a very high latency (read: it takes a long time from the image to be "shot" until it appears on the screen); this is due to the hardware-limitations of ieee1394/usb; you (and me neither) cannot do anything about it
do you know of any application that captures _way_ faster with the same hardware ?? (would be interesting to know)
mfg.asd.r IOhannes
Hi Iohannes,
this seems to be complicated...
[pix_video] captures the input-stream of a capture-device; as capturing is done in real-time you cannot speed [pix_video] up (at least not in our space-time-continuum where we cannot travel into future)
Would be nice sometimes ;)
however, if you think that the latency is to high (the time between you waving before the lens and the movement appearing on the screen) read on
connecting [metro 40] to [pix_video] is an interesting idea, but unfortunately this is not the way it works. gem builds its own "render-clock", which you cannot speed up (or change at all!) with a [metro]. if you want higher frame-rates, you can send a "rate" message to the [gemwin], like [rate 60( (the default of 20 is a bit low); you can even set the default frame-rate as an argument to [gemwin] (like [gemwin 60])
I will try this. Indeed I used pdp before and i'm on an osx-platform; that's why i was thinking of connecting a metro. So if I understand it correctly, you cannot change the speed of the different individual video-sources [when using separator 4 example] but only the render-speed of Gemwin, which means all the individual sources are affected. Is there then a way to 'delay' one source from the other when using separator?
I have to compare some capturing-software to see if it is actually faster then pd/Gem. Will tell you the results if they are remarkable enough.
Thanks, Sara
mfg.asd.r IOhannes
sara kolster wrote:
Hi Iohannes,
this seems to be complicated...
[pix_video] captures the input-stream of a capture-device; as capturing is done in real-time you cannot speed [pix_video] up (at least not in our space-time-continuum where we cannot travel into future)
Would be nice sometimes ;)
yes, we are working har don this, but we are still at the stage of designing the basic concepts.
I will try this. Indeed I used pdp before and i'm on an osx-platform; that's why i was thinking of connecting a metro. So if I understand it correctly, you cannot change the speed of the different individual video-sources [when using separator 4 example] but only the render-speed of Gemwin, which means all the individual sources are affected. Is there then a way to 'delay' one source from the other when using separator?
well [pix_delay] delays a video-stream framewise. [pix_buffer] is a table that holds images, so you can basically do almost anything that is related to time-manipulation with it (assuming you have enough memory)
I have to compare some capturing-software to see if it is actually faster then pd/Gem. Will tell you the results if they are remarkable enough.
would be great.
mfg.a.dr IOhannes
Hello,
I read about ieee1394 support in gem's pix_video, I immediately tried it out since my bttv died today. I used the example video patch in the helpfiles, I told it to use driver 1, it did say I had v4l AND ieee1394; I did a search on the mailinlist archive, but nothing came up like the problem I encountered:
fglX11AllocateManagedSurface: __FGLTexMgrCreateObject failed!! FGLTexMgr: open of shared memory object failed (Function not implemented) __FGLTexMgrCreateObject: __FGLTexMgrSHMmalloc failed!!! fglX11AllocateManagedSurface: __FGLTexMgrCreateObject failed!! shutting down dv1394 after 140 usec
I note that suspicious three letter combo fgl there: and yes I have a radeon - is this the problem and is my video setup correct? I can view camera image with kino...
other question: afaik, dv cams use compressed video; I see cpu usage of kino is very high when only displaying frames - does this mean the video is being read from the camera and decompressed on the fly? does the dv1394 implementation on GEM work the same ( decompressing) and can I expect the same amount of cpu usage? using the bttv I know it's cpu friendly, but dv cam until now was cpu expensive.
i don't know, but i rubbed google's tummy and it said this:
http://www.ati.com/support/infobase/4687.html
pix.
On Tue, Jan 11, 2005 at 01:04:14AM +0100, MvH wrote:
Hello,
I read about ieee1394 support in gem's pix_video, I immediately tried it out since my bttv died today. I used the example video patch in the helpfiles, I told it to use driver 1, it did say I had v4l AND ieee1394; I did a search on the mailinlist archive, but nothing came up like the problem I encountered:
fglX11AllocateManagedSurface: __FGLTexMgrCreateObject failed!! FGLTexMgr: open of shared memory object failed (Function not implemented) __FGLTexMgrCreateObject: __FGLTexMgrSHMmalloc failed!!! fglX11AllocateManagedSurface: __FGLTexMgrCreateObject failed!! shutting down dv1394 after 140 usec
I note that suspicious three letter combo fgl there: and yes I have a radeon - is this the problem and is my video setup correct? I can view camera image with kino...
other question: afaik, dv cams use compressed video; I see cpu usage of kino is very high when only displaying frames - does this mean the video is being read from the camera and decompressed on the fly? does the dv1394 implementation on GEM work the same ( decompressing) and can I expect the same amount of cpu usage? using the bttv I know it's cpu friendly, but dv cam until now was cpu expensive.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
-
IOhannes m zmoelnig -
Mathieu Bouchard -
MvH -
pix -
sara kolster