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