[PD] file format for GEM

Stephan Elliot Perez dreamoftheshoreofanotherworld at gmail.com
Sun Mar 3 20:34:00 CET 2013


I am not using the auto message because I often want to play the files
backwards or only play a certain part of them. Unless there is a variant of
auto for this?

When I use the patch for a performance it will be on a laptop, which I am
not certain will have multiple hard drives. Would a solid state drive
definitely fix my problem? Otherwise, I suppose I will be stuck with a
lower resolution for the videos.

-Stephan

On Sun, Mar 3, 2013 at 7:22 PM, chris clepper <cgclepper at gmail.com> wrote:

> Are you using 'auto 1' to play the files?  That uses Quicktime to
> determine the current position which is more efficient than sending a frame
> number.  You may also want to try 'frame 60' into the gemwin with the auto
> message for smoother looking output.  That basically syncs the render
> output with the screen and 'auto 1' only loads a new frame at the rate of
> the file.
>
> Those CPU figures seem about right.  The ProRes HQ files are probably much
> larger on disk than the AIC files, so the extra CPU time might be waiting
> for the disk.  That might also be why the AIC files spike at certain points
> because the drive is working more.  Disk speed is an important factor here:
> I would spread the files over multiple drives if possible. Obviously, SSD
> is a good option too.
>
> Chris
>
> On Sun, Mar 3, 2013 at 1:05 PM, Stephan Elliot Perez <
> dreamoftheshoreofanotherworld at gmail.com> wrote:
>
>> So, I added the -nomidi -noaudio and -nrt commands as instructed by Mr.
>> Clepper. This seems to help stop lag in Pure Data itself (so cues are
>> executed punctually) when using HD-files.
>>        However, I then converted my files to 1920 x 1080 at 100% using
>> the prores 422 (HQ) codec. The CPU load still climbs to into the 80s and
>> 90s (even over 100 once) with two videos and into the 120s-160s with three.
>>        Oddly, with the Intermediary Codec, the load is sometimes much
>> lower (in the 50s for two files) but sharply climbs at other moments
>> (higher than with the pro-res codecs).
>>
>> -Stephan
>>
>>
>>
>> On Sun, Mar 3, 2013 at 10:10 AM, Peter Venus <news at petervenus.de> wrote:
>>
>>> Hello!
>>> i did not know, that you wanted  to playback HD-material.
>>> with HD material, i notice problems as well, also with the mjpeg codec.
>>>
>>> anyone having experience with fullHD and other codecs?
>>>
>>> under OSX i found, that apples ProRes 422 codec works best for that
>>> matter. The only thing being, that its comes with final cut.
>>> right now, i am running a show, where i use mjpeg in 720p resolution
>>> with no problems for simultaneous playback of 3 videos.
>>>
>>> cheers, peter
>>>
>>> Am 01.03.13 21:39, schrieb Stephan Elliot Perez:
>>>
>>>> So, I reduced the resolution of the files from 1920 x 1080 to 800 x 450
>>>> with the Apple Photo -Jpeg codec and now I have no lag.
>>>>
>>>> The loss in quality is of course noticable, but tolerable...
>>>>
>>>> Thanks again for you help,
>>>> Stephan
>>>>
>>>> On Thu, Feb 28, 2013 at 9:13 AM, <news at petervenus.de> wrote:
>>>>
>>>>  Hello!
>>>>>
>>>>> what video codec are you using?
>>>>> in my experience, a big issue when playing back video with gem,
>>>>> comes from the codecs and container, resulting in extreme differences
>>>>> in
>>>>> cpu-load.
>>>>> i found, that mov-container work way better than avi-container, even
>>>>> though
>>>>> the same codec is used and packed in the container.
>>>>> try  converting your videos to a motion-jpeg codec packed in a
>>>>> quicktime-mov.
>>>>> you could use mpeg-streamclip [1] for that purpose on win /mac
>>>>> machines or
>>>>> ffmpeg on linux.
>>>>>
>>>>> [1] http://www.squared5.com/  free tool for video conversion
>>>>>
>>>>> regards, peter
>>>>>
>>>>>   *Gesendet:* Mittwoch, 27. Februar 2013 um 23:55 Uhr
>>>>> *Von:* "Stephan Elliot Perez" <dreamoftheshoreofanotherworld**
>>>>> @gmail.com <dreamoftheshoreofanotherworld at gmail.com>>
>>>>> *An:* "Cyrille Henry" <ch at chnry.net>
>>>>> *Cc:* pd-list at iem.at
>>>>> *Betreff:* Re: [PD] file format for GEM
>>>>>
>>>>>   A more urgent problem: Although the CPU usage stays under 100 (peak
>>>>> is
>>>>> around 84 with three videos overlapping), there is a substantial
>>>>> amount of
>>>>> lag. If I turn off video processing, a command that should be executed
>>>>> after 30 seconds via the cue list is executed punctually. If I turn it
>>>>> on,
>>>>> the command is 11 seconds late.
>>>>>
>>>>> I can attach the patch if you like, but I probably will not be able to
>>>>> send the video clips as one attachment.
>>>>>
>>>>> Best regards,
>>>>> Stephan
>>>>>
>>>>>
>>>>> On Wed, Feb 27, 2013 at 8:19 PM, Stephan Elliot Perez <
>>>>> dreamoftheshoreofanotherworld@**gmail.com<dreamoftheshoreofanotherworld at gmail.com>>
>>>>> wrote:
>>>>>
>>>>>  What is a shader, and how do I use it?
>>>>>>
>>>>>>
>>>>>> On Wed, Feb 27, 2013 at 7:25 PM, Cyrille Henry <ch at chnry.net> wrote:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Le 27/02/2013 19:17, Stephan Elliot Perez a écrit :
>>>>>>>
>>>>>>>   Thanks, it works now. For some reason, turning "auto" on and off
>>>>>>> (with
>>>>>>>
>>>>>>>> pix_film) causes the video to lag temporarily, but I do not have
>>>>>>>> this
>>>>>>>> problem if I use line-objects to go through the frames. The
>>>>>>>> cpu-usage goes
>>>>>>>> above 100 if I have more than two videos playing at once, but I
>>>>>>>> suppose I
>>>>>>>> don't need more than two for this project...
>>>>>>>>
>>>>>>>> Also, what can I do if I want an additive blend instead of a normal
>>>>>>>> cross-blend?
>>>>>>>>
>>>>>>>>
>>>>>>> i would use a shader for this.
>>>>>>> it offer great flexibility, even if it's a bit harder to begin with.
>>>>>>> but that's the way openGL wants you to do now.
>>>>>>> cheers
>>>>>>> c
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Tue, Feb 26, 2013 at 10:16 PM, Cyrille Henry <ch at chnry.net<mailto:
>>>>>>>> ch at chnry.net>> wrote:
>>>>>>>>
>>>>>>>>      hello,
>>>>>>>>      Gem is mostly design to work on the GPU, and not on the CPU.
>>>>>>>>      GPU have hundreds of core, they are faster than CPU for image
>>>>>>>> manipulations.
>>>>>>>>
>>>>>>>>      pix_add come from the 20th century and should now be avoid
>>>>>>>> since it
>>>>>>>> use cpu not gpu ;-)
>>>>>>>>
>>>>>>>>      in order to make a fade transition between 2 videos, you can
>>>>>>>> use
>>>>>>>> transparency on one video.
>>>>>>>>      add a [alpha] object after Gemhead, and send number between 0
>>>>>>>> and 1
>>>>>>>> in the last inlet of the colorRGB object to make the video appear /
>>>>>>>> disapear.
>>>>>>>>
>>>>>>>>      cheers
>>>>>>>>      c
>>>>>>>>
>>>>>>>>
>>>>>>>>      Le 26/02/2013 21:33, Stephan Elliot Perez a écrit :
>>>>>>>>
>>>>>>>>          Hello,
>>>>>>>>                   So, looking at the help file for [pd~], it seems
>>>>>>>> to be
>>>>>>>> primarily for audio. How can I use multiple cores to work purely
>>>>>>>> with GEM?
>>>>>>>>                    I am trying to have a simple transition between
>>>>>>>> video
>>>>>>>> clips, but if I have two instances of pix_film and then connect
>>>>>>>> them to
>>>>>>>> pix_add, the CPU-ussage skyrockets well above 100... is there a more
>>>>>>>> efficient object for blending two video clips?
>>>>>>>>
>>>>>>>>          Best regards,
>>>>>>>>          Stephan
>>>>>>>>
>>>>>>>>          On Sun, Feb 3, 2013 at 10:54 PM, Thomas Mayer <
>>>>>>>> thomas at residuum.org <mailto:thomas at residuum.org> <mailto:
>>>>>>>> thomas at residuum.org <mailto:thomas at residuum.org>>> wrote:
>>>>>>>>
>>>>>>>>               Hi,
>>>>>>>>
>>>>>>>>               On 03.02.2013 22:48, Stephan Elliot Perez wrote:
>>>>>>>>                > I am talking about PD's CPU meter. I don't have the
>>>>>>>> impression that PD
>>>>>>>>                > takes full advantage of 2 quad-core processors.
>>>>>>>> When
>>>>>>>> processing audio,
>>>>>>>>                > anything over 100 in PD's meter will lead to
>>>>>>>> glitched
>>>>>>>> audio. I am just
>>>>>>>>                > wondering if it will be much more when I load other
>>>>>>>> videos and transition
>>>>>>>>                > between them.
>>>>>>>>
>>>>>>>>               Pd will only use one core, and one core for the GUI.
>>>>>>>> There
>>>>>>>> are ways to
>>>>>>>>               distribute the load over several cores, e.g. [pd~] or
>>>>>>>> use
>>>>>>>> several
>>>>>>>>               instances of Pd that communicate with each others:
>>>>>>>>
>>>>>>>>          http://www.mail-archive.com/__**
>>>>>>>> **pd-list at iem.at/msg33319.html<http://www.mail-archive.com/__**pd-list@iem.at/msg33319.html>
>>>>>>>> **<http://www.mail-archive.com/_**_pd-list@iem.at/msg33319.html<http://www.mail-archive.com/__pd-list@iem.at/msg33319.html>
>>>>>>>> >**<
>>>>>>>> http://www.mail-archive.com/****pd-list@iem.at/msg33319.html<http://www.mail-archive.com/**pd-list@iem.at/msg33319.html>
>>>>>>>> <h**ttp://www.mail-archive.com/pd-**list@iem.at/msg33319.html<http://www.mail-archive.com/pd-list@iem.at/msg33319.html>
>>>>>>>> >
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>               Hth,
>>>>>>>>               Thomas
>>>>>>>>               --
>>>>>>>>               "Spielen Sie Strip Schnipp-Schnapp?" (Adam Weishaupt
>>>>>>>> to
>>>>>>>> Johann
>>>>>>>>               Wolfgang von Goethe in: Robert Shea & Robert A.
>>>>>>>> Wilson,
>>>>>>>> The Golden
>>>>>>>>               Apple)
>>>>>>>>          http://www.residuum.org/
>>>>>>>>
>>>>>>>>               ______________________________****___________________
>>>>>>>>
>>>>>>>>          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<http://lists.puredata.info/__**listinfo/pd-list>
>>>>>>>> <http://**lists.puredata.info/__**listinfo/pd-list<http://lists.puredata.info/__listinfo/pd-list>
>>>>>>>> ><
>>>>>>>> http://lists.puredata.info/****listinfo/pd-list<http://lists.puredata.info/**listinfo/pd-list>
>>>>>>>> <http://lists.**puredata.info/listinfo/pd-list<http://lists.puredata.info/listinfo/pd-list>
>>>>>>>> **>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>          ______________________________****___________________
>>>>>>>>
>>>>>>>>
>>>>>>>>          Pd-list at iem.at <mailto:Pd-list at iem.at> mailing list
>>>>>>>>          UNSUBSCRIBE and account-management ->
>>>>>>>> http://lists.puredata.info/__****listinfo/pd-list<http://lists.puredata.info/__**listinfo/pd-list>
>>>>>>>> <http://**lists.puredata.info/__**listinfo/pd-list<http://lists.puredata.info/__listinfo/pd-list>
>>>>>>>> ><
>>>>>>>> http://lists.puredata.info/****listinfo/pd-list<http://lists.puredata.info/**listinfo/pd-list>
>>>>>>>> <http://lists.**puredata.info/listinfo/pd-list<http://lists.puredata.info/listinfo/pd-list>
>>>>>>>> **>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>
>> _______________________________________________
>> Pd-list at iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130303/4559d135/attachment-0001.htm>


More information about the Pd-list mailing list