[PD] recording GEM output weird framerate

Marco Donnarumma devel at thesaddj.com
Mon Aug 9 15:31:49 CEST 2010


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 at 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 at chnry.net <mailto:ch at 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 at iem.at <mailto:Pd-list at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20100809/e5e1db47/attachment-0001.htm>


More information about the Pd-list mailing list