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.
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
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)
gfsamdr IOhannes
On Sun, Jan 7, 2018 at 2:10 PM, IOhannes m zmölnig zmoelnig@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@lists.iem.at https://lists.puredata.info/listinfo/gem-dev
I guess what I'm asking is should filmAVF *exactly* match the behavior of filmQT or should it match the behavior in general of the other film* objects?
I'm not a heavy GEM user. Does the "auto" property automatically play the file at it's natural frame rate independent of GEM's frame rate or does it play the file at GEM's frame rate? filmAVF is currently doing the latter and it wile additional work for it to do the former.
On Jan 7, 2018, at 12:15 PM, Dan Wilcox danomatika@gmail.com 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.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On OS X the 'auto' option has always played the movie at whatever rate is specified by the second argument - so auto 1 is 1x and auto 0.38 is 38%. The DirectShow version also does this or did when I wrote them.
The GEM framerate is something entirely different and needs to be much higher than any common film format. At the very least the gemwin should play 60fps in VBL sync and show a movie without any tearing artifacts.
On Sat, Jan 20, 2018 at 9:34 AM, Dan Wilcox danomatika@gmail.com wrote:
I guess what I'm asking is should filmAVF *exactly* match the behavior of filmQT or should it match the behavior in general of the other film* objects?
I'm not a heavy GEM user. Does the "auto" property automatically play the file at it's natural frame rate independent of GEM's frame rate or does it play the file at GEM's frame rate? filmAVF is currently doing the latter and it wile additional work for it to do the former.
On Jan 7, 2018, at 12:15 PM, Dan Wilcox danomatika@gmail.com 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.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
GEM-dev mailing list GEM-dev@lists.iem.at https://lists.puredata.info/listinfo/gem-dev
How are the plugins called by the pixes? As in how is filmAVF called by either pix_film or pix_filmOS? Both pix_film* classes have an auto frame advance and I assumed that was what was used by the film objects in general.
On Jan 20, 2018, at 4:14 PM, Chris Clepper cgclepper@gmail.com wrote:
On OS X the 'auto' option has always played the movie at whatever rate is specified by the second argument - so auto 1 is 1x and auto 0.38 is 38%. The DirectShow version also does this or did when I wrote them.
The GEM framerate is something entirely different and needs to be much higher than any common film format. At the very least the gemwin should play 60fps in VBL sync and show a movie without any tearing artifacts.
On Sat, Jan 20, 2018 at 9:34 AM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote: I guess what I'm asking is should filmAVF *exactly* match the behavior of filmQT or should it match the behavior in general of the other film* objects?
I'm not a heavy GEM user. Does the "auto" property automatically play the file at it's natural frame rate independent of GEM's frame rate or does it play the file at GEM's frame rate? filmAVF is currently doing the latter and it wile additional work for it to do the former.
On Jan 7, 2018, at 12:15 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> 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.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
GEM-dev mailing list GEM-dev@lists.iem.at mailto:GEM-dev@lists.iem.at https://lists.puredata.info/listinfo/gem-dev https://lists.puredata.info/listinfo/gem-dev
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
For each GEM render frame you will have to determine if there is a new frame ready for the video. So if the GEM fps is 60 and the film is 30 fps every other GEM render cycle will have a new frame. If that same film is played at half speed then every GEM frames will have a new frame from the movie.
The flags for new frames have to be set at the correct times. If this is not done the pix_ objects after pix_film will process the frame multiple times.
Check the old code for example of how to do all of this - it is not exactly fun or pretty as I recall.
On Sat, Jan 20, 2018 at 2:11 PM, Dan Wilcox danomatika@gmail.com wrote:
How are the plugins called by the pixes? As in how is filmAVF called by either pix_film or pix_filmOS? Both pix_film* classes have an auto frame advance and I assumed that was what was used by the film objects in general.
On Jan 20, 2018, at 4:14 PM, Chris Clepper cgclepper@gmail.com wrote:
On OS X the 'auto' option has always played the movie at whatever rate is specified by the second argument - so auto 1 is 1x and auto 0.38 is 38%. The DirectShow version also does this or did when I wrote them.
The GEM framerate is something entirely different and needs to be much higher than any common film format. At the very least the gemwin should play 60fps in VBL sync and show a movie without any tearing artifacts.
On Sat, Jan 20, 2018 at 9:34 AM, Dan Wilcox danomatika@gmail.com wrote:
I guess what I'm asking is should filmAVF *exactly* match the behavior of filmQT or should it match the behavior in general of the other film* objects?
I'm not a heavy GEM user. Does the "auto" property automatically play the file at it's natural frame rate independent of GEM's frame rate or does it play the file at GEM's frame rate? filmAVF is currently doing the latter and it wile additional work for it to do the former.
On Jan 7, 2018, at 12:15 PM, Dan Wilcox danomatika@gmail.com 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.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
GEM-dev mailing list GEM-dev@lists.iem.at https://lists.puredata.info/listinfo/gem-dev
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
I understand handling the differences in frame rate.
My question is more regarding the fact that I have *no* auto property handling in filmAVF and yet its being handled *somewhere*, I assume pix_film. It's basically advancing but at the wrong, slower frame rate. I'm trying to find out if this is correct or I need to handle it directly. If so, I need to somehow defeat the automatic advancing.
On Jan 20, 2018, at 9:05 PM, Chris Clepper cgclepper@gmail.com wrote:
For each GEM render frame you will have to determine if there is a new frame ready for the video. So if the GEM fps is 60 and the film is 30 fps every other GEM render cycle will have a new frame. If that same film is played at half speed then every GEM frames will have a new frame from the movie.
The flags for new frames have to be set at the correct times. If this is not done the pix_ objects after pix_film will process the frame multiple times.
Check the old code for example of how to do all of this - it is not exactly fun or pretty as I recall.
On Sat, Jan 20, 2018 at 2:11 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote: How are the plugins called by the pixes? As in how is filmAVF called by either pix_film or pix_filmOS? Both pix_film* classes have an auto frame advance and I assumed that was what was used by the film objects in general.
On Jan 20, 2018, at 4:14 PM, Chris Clepper <cgclepper@gmail.com mailto:cgclepper@gmail.com> wrote:
On OS X the 'auto' option has always played the movie at whatever rate is specified by the second argument - so auto 1 is 1x and auto 0.38 is 38%. The DirectShow version also does this or did when I wrote them.
The GEM framerate is something entirely different and needs to be much higher than any common film format. At the very least the gemwin should play 60fps in VBL sync and show a movie without any tearing artifacts.
On Sat, Jan 20, 2018 at 9:34 AM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote: I guess what I'm asking is should filmAVF *exactly* match the behavior of filmQT or should it match the behavior in general of the other film* objects?
I'm not a heavy GEM user. Does the "auto" property automatically play the file at it's natural frame rate independent of GEM's frame rate or does it play the file at GEM's frame rate? filmAVF is currently doing the latter and it wile additional work for it to do the former.
On Jan 7, 2018, at 12:15 PM, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> 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.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
GEM-dev mailing list GEM-dev@lists.iem.at mailto:GEM-dev@lists.iem.at https://lists.puredata.info/listinfo/gem-dev https://lists.puredata.info/listinfo/gem-dev
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
-
Chris Clepper -
Dan Wilcox -
IOhannes m zmölnig