-----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