[PD] recording GEM output weird framerate

Marco Donnarumma devel at thesaddj.com
Mon Aug 16 12:58:50 CEST 2010


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 at 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 at chnry.net <mailto: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>
>>        <mailto: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> <mailto: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
>>
>>
>>
>> _______________________________________________
>>
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20100816/4a81f525/attachment-0001.htm>


More information about the Pd-list mailing list