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 <zmoel...@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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

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

Reply via email to