Did you know that you can use RVIO with your RV license without a separate RVIO license?
There’s one major caveat, it must be a subprocess of an actively licensed interactive RV session.
This is useful for things like custom exporters from RV or if you want to make an embedded tool in RV that uses RVIO; it doesn’t even need to work on things in your current RV session!
All you need to do is:
Immediately after calling commands.rvioSetup(), subprocess your RVIO command (for instance, with the subprocess module in Python).
This doesn’t cover cases like running RVIO on a machine where someone isn’t directly running RV, such as a render farm. If you make use of this already, please give this thread a shout with what you’ve made to inspire others!
Looks like you’ve found an edge case by launching pyeval from the command line. Looks like Python evaluation happens BEFORE RV authenticates, which means that no temp license is generated for the rvc.rvioSetup(). Whoops!
You can get around this by explicitly binding your code to execute after the RV authenticates, in this case the event is license-state-transition. Here’s the modified code that works for me:
import rv.commands as rvc
rvio = os.environ.get("RV_APP_RVIO", None)
args = [rvio, "-vv", "/path/to/input.tiff", "-o", "/path/to/output.jpg"]
out = subprocess.check_output(args)
except subprocess.CalledProcessError as exc:
print("Error: " + str(exc))
# Close out the session after running
## Bind to the event that runs AFTER the RV sets up its license login
rvc.bind("default", "global", "license-state-transition", runCustomRVIO, "Run Custom RVIO")
thanks to the tipps in here, we created our own Cut Export tool which just renders the current assembly as mp4 and publishing it to Shotgun.
We currently have 3 issues with that:
Export is super slow. Guess its because of encoding on the CPU. Before we invest in RVIO licenses it wuold be nice to have a trial license to see if the speed is something we would be happy with
Export always happens with the current scaling/framing “as is”. This leads to scrambled exports in case a user zoomed in on something prior to exporting (letter or pillarboxed and scaled). Parameter “scale 1” did not help so far. Is there a way around that?
Default h.264 exports are pretty much low quality. We are struggling with the syntax on converting our most beloved ffmpeg parameters to work with RVIO (-acodec aac -ab 160k -ac 2 vcodec libx264 -pix_fmt yuv420p -crf 24). Any tips on this?