hi andrew, list,here is a test patch which shows quite some jitter. but jpeg compression and uncompressed alike. i'd like to hear from some gem pros what they think on how to minimize the jitter. also i wonder why the movie loops not always in the same speed - do i need a realtimemetro? btw. this patch can be used to reduce the gem framerate automatically if the rendering is slower than the framrerate to avoid gem locking up the computer (thanks sven for that hint).
GEMvariable_framerate.pd
Description: Binary data
Am 03.12.2007 um 08:11 schrieb Andrew Brouse:
Hi Max,JPEG decompression should be very fast on any modern CPU, it is however possible that at those frame sizes and 30 FPS, you may be seeing some jitter. If you are at 30 FPS, try reducing it to 15 or even 10 FPS and see what happens.cheers, Andrew -- On Sun, 2 Dec 2007, Max Neupert wrote:Am 02.12.2007 um 16:35 schrieb Andrew Brouse:If you want to do any scrubbing, varispeed or playing backwards of thevideo, you need a CODEC which does not use temporal compression.Photo-JPEG is in fact a very good choice in this case and if compressed at320 X 240 you get a good balance of file-size, picture quality and processor load. JPEG 2000 should also be a good choice (supported byQuickTime and there are libraries which support it on Linux but not sureif it will play in GEM).hi andrew,i wonder if the photo-jpeg compression does introduce a jitter in the decoding speed depending on the complexity of the content. gem would need a different time to decode each time a different frame is called. i am working now with 1024x768 video compressed with 75% quality photojpeg and sometimes see lags in the decoding.. but maybe it's just my imagination.max
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
