[GEM-dev] filmAVF

[Dan Wilcox]

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 at 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 at gmail.com <mailto:danomatika at 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 at gmail.com <mailto:cgclepper at 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 at gmail.com <mailto:danomatika at 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 at gmail.com <mailto:danomatika at 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 at lists.iem.at <mailto:GEM-dev at 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/>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20180120/d5d5951b/attachment.html>