[PD] Video problems using GEM

Claire O'Connor oconnc26 at tcd.ie
Thu Apr 17 18:46:52 CEST 2014


That does sound quite complicated. I'll see how I get on with pix_buffer;
it could be the answer to all of my problems! Either way, converting my
video files to AIC files has helped immensely so that's a big problem out
of the way :)


On 17 April 2014 17:44, Chris Clepper <cgclepper at gmail.com> wrote:

> I created pix_share for HD videos in cases like this, but it is a little
> tricky to use.  On OSX, you need to edit some deep OS config files to set
> up the shm correctly.  For images at 16MP, the settings will need to be
> pretty large too or it will be very slow.  It's not for the uninitiated!
>
> pix_buffer is much easier to use for this, provided all of the images can
> fit in RAM or less than 4GB total for one Pd process.
>
>
>
> On Thu, Apr 17, 2014 at 12:16 PM, John Harrison <
> john.harrison at alum.mit.edu> wrote:
>
>> I wonder if it would work better if you ran 2 Pd instances, loaded the
>> pics in one and ran the movie in the other, then shared the pics to the
>> movie instance with [pix_share_read] and [pix_share_write]?
>>
>>
>> On Thu, Apr 17, 2014 at 10:51 AM, Claire O'Connor <oconnc26 at tcd.ie>wrote:
>>
>>> Hi Chris,
>>>
>>> Thanks for your help. Converting the videos to those formats definitely
>>> helped. I am using Pure Data in a project which is attempting to create a
>>> slideshow. I am also using pix_image in conjunction with pix_film for this
>>> project and everytime I have a video playing and load a picture during that
>>> time, the video playback slows down. Have you any ideas on how to prevent
>>> this? I am using JPEGs taken on the same camera as mentioned above (Canon
>>> Ixus 127 HS) and they are between 3MB and 6MB each. The most images I would
>>> have banged to load at once is three. Here is some more information on
>>> those images.
>>>
>>> Any thoughts you might have would be a great help. Thank you!
>>>
>>>
>>> On 17 April 2014 14:44, Chris Clepper <cgclepper at gmail.com> wrote:
>>>
>>>> The issue is with the h.264 codec.  On the Mac, compress them as 'Apple
>>>> Intermediate Codec' or ProRes (which comes with what's left of Final Cut
>>>> 'Pro').  The files will be much larger in size on the drive but play back
>>>> much better.  When I wrote the OSX pix_film/movie code long ago, it was
>>>> only intended to play back intraframe codecs like the JPEG based ones and
>>>> not MPEG which are consumer delivery formats.
>>>>
>>>> You should also set the gemwin to render at least 30 frames per second
>>>> and for smoothest playback use 60fps which is the refresh rate of an LCD.
>>>>  I think the default is still 15 or 20fps?
>>>>
>>>>
>>>> On Thu, Apr 17, 2014 at 7:11 AM, Claire O'Connor <oconnc26 at tcd.ie>wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I am currently working on a project which uses films with GEM.
>>>>> However, the films are very glitchy and play very slowly when they load up.
>>>>> I was wondering if anyone knew anything about how to fix this problem?
>>>>>
>>>>> The videos used were taken on a Canon Ixus 127 HS and last between 10
>>>>> and 15 seconds. They are .MOV files and I even tried exporting them as
>>>>> smaller files but it didn't change their glitchiness. Here is an example of
>>>>> the file before and after the export with the original file being 80.8MB
>>>>> and the exported file being 5.9MB. Even with a drastic change in size, the
>>>>> difference in playback did not change much at all.
>>>>>
>>>>> Any thoughts and ideas welcome. Thanks!
>>>>>
>>>>> _______________________________________________
>>>>> Pd-list at iem.at mailing list
>>>>> UNSUBSCRIBE and account-management ->
>>>>> 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/20140417/341f203d/attachment.htm>


More information about the Pd-list mailing list