[PD] file format for GEM

Stephan Elliot Perez dreamoftheshoreofanotherworld at gmail.com
Mon Mar 4 19:31:33 CET 2013 

Well, I do not know why, but if I use auto for everything (instead of line
objects into the right inlet of pix_film), it does fine with one or two
videos, but, when a third one is activated, it skyrockets to over 100.

And this is using 800x450 videos. With this format, I had no such CPU
problems using line objects.

-Stephan

On Mon, Mar 4, 2013 at 6:01 PM, chris clepper <cgclepper at gmail.com> wrote:

> Use the 'rate $1' message to change the playback speed.
>
>
> On Mon, Mar 4, 2013 at 11:31 AM, Stephan Elliot Perez <
> dreamoftheshoreofanotherworld at gmail.com> wrote:
>
>> I am using pix_film to play back the files, do I need to use another
>> object? I ask because when I send the messages auto -1, 1 or 2 into the
>> first inlet, the playback is always the same (1), and if I send auto .5, it
>> turns off (as with 0).
>>
>>
>> On Sun, Mar 3, 2013 at 8:45 PM, chris clepper <cgclepper at gmail.com>wrote:
>>
>>> A laptop drive will probably not play more than two HD ProRes files at
>>> once.  An external Firewire or USB drive might help if half the clips are
>>> on it and the other half on the internal.
>>>
>>> Auto can play at any speed forward or backward: try 'rate -1' or 'rate
>>> 1.5'  etc.  That sets the Quicktime clock for playback to that rate.  It's
>>> more efficient to let QT do the tasking internally.
>>>
>>> You can select the starting frame of playback using the frame number
>>> into the second inlet.
>>>
>>>
>>> On Sun, Mar 3, 2013 at 2:34 PM, Stephan Elliot Perez <
>>> dreamoftheshoreofanotherworld at gmail.com> wrote:
>>>
>>>> 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/20130304/9666d7cc/attachment-0001.htm>

More information about the Pd-list mailing list