Hi all, I have some experience with RED SDK. From what I remember its single threaded and not reentrant (it blocks w/ more than one thread) and its very slow. We managed to get OK performance from it by spawning a group of processes each of which can decode a frame into a shared memory frame buffer. In that case you get no blocking and can decode however many frames you want in parallel. So e.g. you make the OIIO plugin reentrant but its really managing the underlying processes (separate binary) which are actually linked against the RED SDK instead of the plugin itself. AFAIK there’s no way to speed up decoding of a single frame without using the red rocket card.
I realize that sounds like a PITA and it is. But thought I’d share in case it matters. Maybe they’ve changed that behavior in newer versions. -Jim > On Jul 26, 2019, at 1:06 PM, Alex Hughes <[email protected]> wrote: > > That `target_compile_definitions` > Is a clever way of doing the runtime linking that R3D requires. > > Question for LG though... > Do we want to provide the R3DSDK redistibutables with OIIO, in which case I > would set the R3DSDK initializer to look relative to itself. > Another option could be environment variable based so at runtime when the > R3DSDK needs the path to the libraries, it could pull from the environment. > The way will was doing it in his demo was using the preprocessor directives > to define the redist path. Which I think may cause problems because I doubt > people are compiling against the live libraries in their environment. > Also, the "add_oiio_plugin" macro doesn't seem to set the passed > "DEFINITIONS" in a way that would allow the compilation of the plugin to have > the preprocessor directives applied. > I played around with modifying the "libOpenImageIO" CMakeLists file and > added a "target_compile_definitions" call with my required definitions but > having plugin specific logic in the core lib CMakeLists file doesn't seem > like the right way to approach this. > > So I guess, to simplify the above, the R3DSDK requires runtime linking of the > sdk and requires a path in there. I am inclined to try to read an environment > variable and fallback to looking in the same directory for the libraries. > Does that seem like a good way to do it? > > I've got a working R3DInput plugin working I think and am just getting the > test cases up. But I hopefully will have a PR open soon. > > -Alex > > > > On Fri, Jul 26, 2019 at 5:15 PM Alex Hughes <[email protected] > <mailto:[email protected]>> wrote: > Thanks Will, > > I would love to include that in my PR if that's ok with you, with credit of > course. > > -Alex > > On Fri, Jul 26, 2019 at 8:18 AM Will Rosecrans <[email protected] > <mailto:[email protected]>> wrote: > I recently started making a CMake find module for the R3D SDK. It's uhhh... > not quite production ready, (I think it won't work on a Mac yet, and I > haven't tested it on Windows) but it might be a handy starting point. Feel > free to use it or crib from it, etc. It has a trivial example that makes an > OIIO image buf. > > https://github.com/wrosecrans/ImageTypes > <https://github.com/wrosecrans/ImageTypes> > > > > On Thu, Jul 25, 2019 at 1:38 PM Alex Hughes <[email protected] > <mailto:[email protected]>> wrote: > I could take a look at it since I brought it up. > > I've never taken a stab at an OIIO plugin but there are lots of examples and > the docs seem reasonable. > I would be tackling it on my own time without company support at this point > because we don't have an immediate need for it here. > > Is the FFMpeg plugin a decent example to base work off of? At least for the > ImageInput? > > -Alex > _______________________________________________ > Oiio-dev mailing list > [email protected] <mailto:[email protected]> > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> > _______________________________________________ > Oiio-dev mailing list > [email protected] <mailto:[email protected]> > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > <http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org> > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
