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@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@lists.iem.at http://lists.puredata.info/listinfo/gem-dev