[GEM-dev] video and film plugin API

[Antoine Villeret]

I'm aware of Syphon but iirc there is already a pd externals to deal with.
But I never tried it.
Btw I'm looking for such a solution (I mean texture sharing between context
and process) for Linux for a while.

Concerning the texin and texout API, I understand what you mean but I'm not
sure to be the man to build such an API :-) but this could be great !

+
a

--
do it yourself
http://antoine.villeret.free.fr

2014-09-15 10:01 GMT+02:00 IOhannes m zmoelnig <zmoelnig at iem.at>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 2014-09-14 21:00, Antoine Villeret wrote:
> > hello,
> >
> > I'm planning to build some video encoding and decoding plugin based
> > on NVENC (see [1]). NVENC works directly with GPU memory, so I'm
> > wondering if the plugins API allows me to work directly with Gem
> > texture ?
>
> no.
>
> > And if not, is it possible (I mean : is it no too huge work) to
> > update plugins API to work with texture besides pix_block ?
>
> hmm, i have thought about that in the past, and i think we should NOT
> add this capabilities to video/film, BUT...
>
> - - i would like to have all (current) plugins (that is: video, film,
> image and model) to be totally openGL-agnostic.
> currently all plugins but "model" already adhere to this (apart from
> using some GL_ constants for colorspaces).
> "model" does not and this is the reason why model-loading is currently
> totally broken for the default multi-context builds!
>
> - - i *also* think that there is a need to directly input *AND* output
> textures via plugins.
> my main motivation for this is actually "syphon"[1] (rather than
> GPU-based decoding).
> another motivation is, that in days long gone, [pix_movie] would have
> optimized paths (at least on OSX), that were faster than the current
> [pix_film]+[pix_texture] implementation.
>
> SO:
> i think, we need an API for "texin" and "texout" (that's two different
> plugins!). i guess "video" is a good starting point (without the
> 'dialog' parts), for both.
> we have to take care about how to properly support multiple-contexts.
> (e.g. the texture ID could be different for each window). i'm not
> entirely sure about the best way to ensure this.
>
> internally we could have a texinFILM plugin, that would make all
> film-plugins available as texture source (just like there is a
> filmIMAGE plugin, that allows to load images as 1-frame films).
>
> [pix_movie] could then be switched to the texin API.
>
> and we could have two new objects [tex_input] and [tex_output] as
> "native" clients of these plugins.
>
>
>
> fgmadr
> IOhannes
>
>
> [1] http://syphon.v002.info/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQIcBAEBCAAGBQJUFpzFAAoJELZQGcR/ejb4aisP/iiW9ssrx4eMsB3uNaLrlB7n
> KGhCK+25sMcnqDDBDbxcMvHoPADvTFEIA7Tta6en9YSpEr7xeaWRedp/2qb0uaYG
> 05AzWuDoAH4171cF8iwyq8LiiT5/6RjGpvpzhlR7jDYmjgRd7EDz8m6zRUM6u/CO
> sOpafnvK8EssQkeWO8cMPHXMzwCGdrhMjdoxL953doWgQOeXLDg3UbgYzs0JsRjG
> ilWrPtRRE05F5rX4/DTmV+ffrL0bVEyaFFeJ5cenDszhN+xY0KhlQeg3RuEVB9tB
> om7IjngeEKeTRlwHX6GeSaA+H/Mf5pDf14kgfnL49qkgMUDmdRvp/ahFyz/csFPF
> MERd/QgfwYYvc0J2I7Q5GEPebgPOl4BtyHQreq1y8xMDbGkFs+KqY15jk5Xt4j0N
> mQNiqr51UtQR5lhPpvjwcPEGADgulcTDH4f1J6o0/00Hz933rpwikxwL1BZH8Scc
> J4043FEorZvCAkJnBS0RaFBVCeGZsNcKtp1MV8nyBCyKaZrYh7GY7onp5bYOmAgh
> WEUR3VfY7CjhxLzIHCER7oLYAFc5zPlA5Gfz4IJInZh1MXcJeuWLmjzyr2FvOrOg
> escx69CTprsB3Qv699KD/73qbMXoyjS3Wh7x22pJxvN0QTwbkgQVvnZNoLDHi9pD
> eKBfqvlgBCuP4gVTfTeu
> =QvhL
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at lists.iem.at
> http://lists.puredata.info/listinfo/gem-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/gem-dev/attachments/20140915/a3d40301/attachment.html>