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
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.2010/8/9 cyrille henry <ch@chnry.net <mailto:ch@chnry.net>>
Thanks Cyrille, you threw some light over my confusion.
I now understand what you meant.
I'll give it a try waiting longer.
M
<mailto: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>Pd-list@iem.at <mailto:Pd-list@iem.at> <mailto:Pd-list@iem.at
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.
______________________________________________________________________________________________
<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