<div dir="ltr">I'm aware of Syphon but iirc there is already a pd externals to deal with.<div>But I never tried it.</div><div>Btw I'm looking for such a solution (I mean texture sharing between context and process) for Linux for a while.</div><div><br></div><div>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 !</div><div><br></div><div>+</div><div>a</div></div><div class="gmail_extra"><br clear="all"><div>--<br>do it yourself                       <br><a href="http://antoine.villeret.free.fr" target="_blank">http://antoine.villeret.free.fr</a><br></div>
<br><div class="gmail_quote">2014-09-15 10:01 GMT+02:00 IOhannes m zmoelnig <span dir="ltr"><<a href="mailto:zmoelnig@iem.at" target="_blank">zmoelnig@iem.at</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<span class=""><br>
On 2014-09-14 21:00, Antoine Villeret wrote:<br>
> hello,<br>
><br>
> I'm planning to build some video encoding and decoding plugin based<br>
> on NVENC (see [1]). NVENC works directly with GPU memory, so I'm<br>
> wondering if the plugins API allows me to work directly with Gem<br>
> texture ?<br>
<br>
</span>no.<br>
<span class=""><br>
> And if not, is it possible (I mean : is it no too huge work) to<br>
> update plugins API to work with texture besides pix_block ?<br>
<br>
</span>hmm, i have thought about that in the past, and i think we should NOT<br>
add this capabilities to video/film, BUT...<br>
<br>
- - i would like to have all (current) plugins (that is: video, film,<br>
image and model) to be totally openGL-agnostic.<br>
currently all plugins but "model" already adhere to this (apart from<br>
using some GL_ constants for colorspaces).<br>
"model" does not and this is the reason why model-loading is currently<br>
totally broken for the default multi-context builds!<br>
<br>
- - i *also* think that there is a need to directly input *AND* output<br>
textures via plugins.<br>
my main motivation for this is actually "syphon"[1] (rather than<br>
GPU-based decoding).<br>
another motivation is, that in days long gone, [pix_movie] would have<br>
optimized paths (at least on OSX), that were faster than the current<br>
[pix_film]+[pix_texture] implementation.<br>
<br>
SO:<br>
i think, we need an API for "texin" and "texout" (that's two different<br>
plugins!). i guess "video" is a good starting point (without the<br>
'dialog' parts), for both.<br>
we have to take care about how to properly support multiple-contexts.<br>
(e.g. the texture ID could be different for each window). i'm not<br>
entirely sure about the best way to ensure this.<br>
<br>
internally we could have a texinFILM plugin, that would make all<br>
film-plugins available as texture source (just like there is a<br>
filmIMAGE plugin, that allows to load images as 1-frame films).<br>
<br>
[pix_movie] could then be switched to the texin API.<br>
<br>
and we could have two new objects [tex_input] and [tex_output] as<br>
"native" clients of these plugins.<br>
<br>
<br>
<br>
fgmadr<br>
IOhannes<br>
<br>
<br>
[1] <a href="http://syphon.v002.info/" target="_blank">http://syphon.v002.info/</a><br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1<br>
<br>
iQIcBAEBCAAGBQJUFpzFAAoJELZQGcR/ejb4aisP/iiW9ssrx4eMsB3uNaLrlB7n<br>
KGhCK+25sMcnqDDBDbxcMvHoPADvTFEIA7Tta6en9YSpEr7xeaWRedp/2qb0uaYG<br>
05AzWuDoAH4171cF8iwyq8LiiT5/6RjGpvpzhlR7jDYmjgRd7EDz8m6zRUM6u/CO<br>
sOpafnvK8EssQkeWO8cMPHXMzwCGdrhMjdoxL953doWgQOeXLDg3UbgYzs0JsRjG<br>
ilWrPtRRE05F5rX4/DTmV+ffrL0bVEyaFFeJ5cenDszhN+xY0KhlQeg3RuEVB9tB<br>
om7IjngeEKeTRlwHX6GeSaA+H/Mf5pDf14kgfnL49qkgMUDmdRvp/ahFyz/csFPF<br>
MERd/QgfwYYvc0J2I7Q5GEPebgPOl4BtyHQreq1y8xMDbGkFs+KqY15jk5Xt4j0N<br>
mQNiqr51UtQR5lhPpvjwcPEGADgulcTDH4f1J6o0/00Hz933rpwikxwL1BZH8Scc<br>
J4043FEorZvCAkJnBS0RaFBVCeGZsNcKtp1MV8nyBCyKaZrYh7GY7onp5bYOmAgh<br>
WEUR3VfY7CjhxLzIHCER7oLYAFc5zPlA5Gfz4IJInZh1MXcJeuWLmjzyr2FvOrOg<br>
escx69CTprsB3Qv699KD/73qbMXoyjS3Wh7x22pJxvN0QTwbkgQVvnZNoLDHi9pD<br>
eKBfqvlgBCuP4gVTfTeu<br>
=QvhL<br>
-----END PGP SIGNATURE-----<br>
<br>
_______________________________________________<br>
GEM-dev mailing list<br>
<a href="mailto:GEM-dev@lists.iem.at">GEM-dev@lists.iem.at</a><br>
<a href="http://lists.puredata.info/listinfo/gem-dev" target="_blank">http://lists.puredata.info/listinfo/gem-dev</a><br>
</blockquote></div><br></div>