<div dir="ltr">pix_film asks Quicktime to fill a RAM buffer with pixels so the codec is probably uploading to the GPU, decoding then copying back to RAM.  Sending data to the GPU is incredibly fast, getting something back moves like death warmed over.<div><br></div><div>pix_movie may be able to accommodate the GPU decode process if a special version is written.  </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 21, 2016 at 3:21 PM, Thomas Grill <span dir="ltr"><<a href="mailto:gr@grrrr.org" target="_blank">gr@grrrr.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
I guess this is because it uses quicktime and the respective HAP quicktime component.<br>
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?<br>
thanks, Thomas<br>
<br>
--<br>
Thomas Grill<br>
<a href="http://grrrr.org" rel="noreferrer" target="_blank">http://grrrr.org</a><br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
> Am 21.09.2016 um 09:00 schrieb IOhannes m zmölnig <<a href="mailto:zmoelnig@iem.at">zmoelnig@iem.at</a>>:<br>
><br>
> On 09/20/2016 09:26 PM, ub wrote:<br>
>> i followed the dependency chain and i think (not 100% sure) pix_film<br>
>> uses libquicktime, which in turn uses ffmpeg to play it.<br>
><br>
> no.<br>
> Gem can use a variety of backends to decode a video, using it's own<br>
> plugin system.<br>
> libquicktime is among them.<br>
> libgmerlin is among them.<br>
> others are as well...<br>
><br>
>><br>
>> i was wondering, how difficult it would be to add stable support for the<br>
>> hap-codec in Gem. maybe even bypassing libquicktime/ffmpeg alltogether?<br>
><br>
> just write a filmHAP plugin :-)<br>
> the main problem is see is that the output of [pix_film] is a *pix*,<br>
> that is a decoded image in main memory.<br>
> i *guess* that HAP would benefit from leaving the image on the GPU<br>
> memory and just making it available as a texture.<br>
> unfortunately the "film" plugin architecture doesn't allow this.<br>
><br>
> there has been a proposal for a "texture source" plugin, but it hasn't<br>
> got much attention from my side.<br>
><br>
>><br>
>> has anyone looked into it yet?<br>
><br>
> no.<br>
><br>
> fgmas<br>
> IOhannes<br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> ______________________________<wbr>_________________<br>
> GEM-dev mailing list<br>
> <a href="mailto:GEM-dev@lists.iem.at">GEM-dev@lists.iem.at</a><br>
> <a href="https://lists.puredata.info/listinfo/gem-dev" rel="noreferrer" target="_blank">https://lists.puredata.info/<wbr>listinfo/gem-dev</a><br>
<br>
</div></div><br>______________________________<wbr>_________________<br>
GEM-dev mailing list<br>
<a href="mailto:GEM-dev@lists.iem.at">GEM-dev@lists.iem.at</a><br>
<a href="https://lists.puredata.info/listinfo/gem-dev" rel="noreferrer" target="_blank">https://lists.puredata.info/<wbr>listinfo/gem-dev</a><br>
<br></blockquote></div><br></div>