[GEM-dev] HAP codec support

[Chris Clepper]

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.

pix_movie may be able to accommodate the GPU decode process if a special
version is written.

On Wed, Sep 21, 2016 at 3:21 PM, Thomas Grill <gr at grrrr.org> wrote:

> 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 at 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 at lists.iem.at
> > https://lists.puredata.info/listinfo/gem-dev
>
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at lists.iem.at
> https://lists.puredata.info/listinfo/gem-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20160922/b3451a48/attachment.html>