The other day i tried [pix_movie] with a HAP file and it worked (on Mac OS), although with non-satisfying performance, compared to Max/Jitter.
I guess this is because it uses quicktime and the respective HAP quicktime component.
My question is why the performance (frame rate) is far worse than in Max (or quicktime player). Is there any additional video texture transfer from/to GPU memory involved?
thanks, Thomas

--
Thomas Grill
http://grrrr.org

> Am 21.09.2016 um 09:00 schrieb IOhannes m zmölnig <zmoelnig@iem.at>:
>
> On 09/20/2016 09:26 PM, ub wrote:
>> i followed the dependency chain and i think (not 100% sure) pix_film
>> uses libquicktime, which in turn uses ffmpeg to play it.
>
> no.
> Gem can use a variety of backends to decode a video, using it's own
> plugin system.
> libquicktime is among them.
> libgmerlin is among them.
> others are as well...
>
>>
>> i was wondering, how difficult it would be to add stable support for the
>> hap-codec in Gem. maybe even bypassing libquicktime/ffmpeg alltogether?
>
> just write a filmHAP plugin :-)
> the main problem is see is that the output of [pix_film] is a *pix*,
> that is a decoded image in main memory.
> i *guess* that HAP would benefit from leaving the image on the GPU
> memory and just making it available as a texture.
> unfortunately the "film" plugin architecture doesn't allow this.
>
> there has been a proposal for a "texture source" plugin, but it hasn't
> got much attention from my side.
>
>>
>> has anyone looked into it yet?
>
> no.
>
> fgmas
> IOhannes
>

> _______________________________________________
> GEM-dev mailing list
> GEM-dev@lists.iem.at
> https://lists.puredata.info/listinfo/gem-dev

_______________________________________________
GEM-dev mailing list
GEM-dev@lists.iem.at
https://lists.puredata.info/listinfo/gem-dev