Yves,
Here's the patch and an abstraction for it, I added some comments to make it a bit clearer. At this point it displays 2 160x120 videos (one live, one captured from the live one) at any one of 9 places on the pdp_canvas (it's intended to have 8 recorded clips and 1 stream running). Use the [pd make001.mov] to capture a clip from the stream for the yqt player.
Could the pdp_dumps be from having a slow hard drive? The main difference between this and the Gem replacement I've done for it, is that Gem is using buffers to store images, rather than the hard drive.
Thanks for your help, Ian
From: "Yves Degoyon" ydegoyon@free.fr Date: Wed, May 05, 2004 6:54 am To: "Ian Smith-Heisters" heisters@0x09.com Cc: pd-list@iem.at
For now I've switched to Gem, so I'm not in a hurry to figure this out
any longer. But PDP/PiDiP has features
that are much more powerful for video (as opposed to 3D), so I would
like to figure this out. Running a webcam
stream and a quicktime stream at the same time is something I'll
probably want to do in PDP a lot.
i'd like to figure that out too as i used to run a pdp_yqt and a webcam on a quite modest machine without pdp_dumps..
could you send your patch over to localize the problem?
cheers, sevy
hello,
nice patch )
well, this patch revealed a bug in the pdp_canvas object, the packets were not internally freed and that led to huge memory leaks.
you can find a fixed version here : http://ydegoyon.free.fr/pidip-0.12.14.tar.gz
this fix also removes the effect of remanence you could see in the canvas : previous packets were still displayed although they should have disappeared from the system. now, this effect has gone and maybe you really wanted it. in that case, you have to simulate this by using pdp_reg objects.
as regards to the pdp dumps, these only happen in threaded mode, it means than a pdp object didn't had the time to process a packet before the next one arrives. well, you can have a little of this and still have a stable system, that was not really the problem here. if you want to remove them totally, run in non-threaded mode.
cheers, sevy
Ian Smith-Heisters wrote:
Yves,
Here's the patch and an abstraction for it, I added some comments to make it a bit clearer. At this point it displays 2 160x120 videos (one live, one captured from the live one) at any one of 9 places on the pdp_canvas (it's intended to have 8 recorded clips and 1 stream running). Use the [pd make001.mov] to capture a clip from the stream for the yqt player.
Could the pdp_dumps be from having a slow hard drive? The main difference between this and the Gem replacement I've done for it, is that Gem is using buffers to store images, rather than the hard drive.
Thanks for your help, Ian
this fix also removes the effect of remanence you could see in the canvas : previous packets were still displayed although they should have disappeared from the system. now, this effect has gone and maybe you really wanted it. in that case, you have to simulate this by using pdp_reg objects.
i made a new fix that keeps that remanence effect now, so, forget that remark.
cheers, sevy
-
Ian Smith-Heisters -
Yves Degoyon