Thanks Cyrille, I made different tests and I noticed what you said about the fps, that's a very good tip.
Besides, I realized that I can gain 5/6 fps moving the gemwin in another workspace (different from the one I actually see).
M
On Mon, Aug 9, 2010 at 2:44 PM, cyrille henry ch@chnry.net wrote:
if you want a 1 min video, use a delay 60000 to start/stop. then, it will be perfect, even it it take 2 or 3 min to record...
c
Le 09/08/2010 15:31, Marco Donnarumma a écrit :
oh, ok. Thanks Cyrille, you threw some light over my confusion.
I now understand what you meant. I'll give it a try waiting longer.
M
2010/8/9 cyrille henry <ch@chnry.net mailto:ch@chnry.net>
Le 09/08/2010 13:58, Marco Donnarumma a écrit :
@ Lazzaro: yes I know, thanks for specifying, but the problem is that the duration of audio and video files I record don't match each other. @ Cirylle: ok, now maybe I understand. I'm actually already using a similar abstraction of yours to monitor fps :) My patch is completely automatic, it's a sonification/visualization of large amount of data, thus I just press a toggle to start it. So: if while recording the fps monitor shows 10fps, it means that also pix_write will record only 10 frames per second and _not_ 20 as I stated in gemwin, is that correct?
no, it will take 2 min to record 1min of video at 20fps.
I was probably wrong assuming that whatever fps is stated in gemwin will be the recorded fps, even though the machine can't reproduce it in real-time. Ok, so, if I can only record at 10 fps, what do you suggest to finally have a recorded video with a decent framerate? (apart from changing machine...)
waite longer...
I guess I could use ffmpeg to double the framerate, but the video might be jittery...
no, the video will be perfect, since everything is done with pd time. pd time is no more real time, but that just a question of cpu/gpu. everything else should be exactly the same.
c
M 2010/8/9 cyrille henry <ch@chnry.net <mailto:ch@chnry.net> <mailto:ch@chnry.net <mailto:ch@chnry.net>>> here is a simple abstraction that output the real rendering frequency. it help a lot to track this kind of problem. c Le 09/08/2010 13:02, Lazzaro Nicolò Ciccolella a écrit : Il 09/08/10 12.26, Lazzaro Nicolò Ciccolella ha scritto: Il 09/08/10 12.17, Marco Donnarumma ha scritto: Hi all, it's been a week now I'm struggling to record properly a GEM output, reading archives and forums. I have fairly complex audiovisual patch with multiple geos, four pix_snaps to create motion blur effect for 1280x320 res, and data exchange through local network. However I can record in a really good quality using both pix_record or pix_write. The problem is the recorded video is faster than
the actual one.
Hi, apologize me if it is a dumb answer, but if you apply very intensive motion bur and other stuf in your patch the speed of what you see in your gem box will be very slow. The sequence of images that is generated will necessarily faster than what you see when the patch is running. _______________________________________________ Pd-list@iem.at <mailto:Pd-list@iem.at> <mailto:Pd-list@iem.at <mailto:Pd-list@iem.at>> mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list -- Marco Donnarumma aka TheSAD Independent New Media Arts Professional, Performer, Teacher - Edinburgh, UK PORTFOLIO: http://marcodonnarumma.com LAB: http://www.thesaddj.com | http://cntrl.sourceforge.net | http://www.flxer.net EVENT: http://www.liveperformersmeeting.net
-- Marco Donnarumma aka TheSAD Independent New Media Arts Professional, Performer, Teacher - Edinburgh, UK
PORTFOLIO: http://marcodonnarumma.com LAB: http://www.thesaddj.com | http://cntrl.sourceforge.net | http://www.flxer.net EVENT: http://www.liveperformersmeeting.net
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list