[GEM-dev] filmAVF

[Chris Clepper]

On Sun, Jan 7, 2018 at 2:10 PM, IOhannes m zmölnig <zmoelnig at iem.at> wrote:

> On 01/07/2018 12:15 PM, Dan Wilcox wrote:
> >
> >> Dan:
> >> seems to work! it doesn't crash! loaded fillm are a little "laggy"
> though
> >> and do not react to sudden frame changes very quickly.... at least from
> >> quick tests with short clips. i did load a 2 hour .mp4 though and
> nothing
> >> crashed so it seems all fairly stable now.
> >
> > By "laggy", do you mean with automatic playback? QT seems to handle that
> itself while filmAVF is currently letting Gem do the "auto" property which
> seems slower. From what the help file says, "auto" does advances the frame
> on the net Gem frame render.
> >
>
> you should be able to increase the speed with "auto 1.5".
> (TODO: document this)
>

I would suggest setting the gemwin FPS to 60 (and VBL sync) and then see
how 'auto 1' responds.  You can check my ancient QT (the real QT) code to
see how I dealt with the QT vs GEM frame rate.  There is a very likely
probability that QT will send duplicate frames down the GEM chain which
will double process all pix_ objects.  My comments in the old code should
remark on this with a fair amount of profanity.  QT likes to be the master
clock and that only gets worse with each post-QT Apple framework.

There was a pix_movieQT version that was designed to somewhat ignore the
GEM frame rate and dump the video frames to the GL buffer with the
assumption that all processing would be GLSL.  Worked like a fucking champ
as I recall.

Best of luck
cgc



>
> gfsamdr
> IOhannes
>
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at lists.iem.at
> https://lists.puredata.info/listinfo/gem-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20180107/fa9b44ae/attachment.html>